+
+ | Component |
+ Deployment / Lifecycle (Azure resources, Arc resource bridge, custom location) |
+
+
+ | Topic |
+ Cleanup before redeploy: delete the Azure resources from a prior deployment in dependency order to avoid orphaned cloud resources |
+
+
+ | Applicable Scenarios |
+ Azure Local, version 23H2 and later: redeploying after a failed or irrecoverable deployment, rebuilding a system, or decommissioning then redeploying |
+
+
+
+## Overview
+
+Every Azure Local deployment creates a set of Azure resources (the Arc resource bridge, a custom location, the Azure Local instance, per-node Arc machine resources, storage paths, a key vault, and storage accounts). Before you can cleanly redeploy, these resources must be removed.
+
+The order matters. Workload resources (VMs, disks, NICs, storage paths, logical networks) are projected into Azure **through** the custom location and Arc resource bridge, and Azure does **not** reliably block deletion of a parent while its dependents still exist. Deleting a parent first — or bulk-deleting the resource group, which is not dependency-aware — leaves **orphaned resources** that become difficult or impossible to delete and that block a clean redeployment. This guide gives the dependency-safe order.
+
+This guide extends the official [Decommission Azure Local](https://learn.microsoft.com/azure/azure-local/manage/decommission-azure-local) procedure — which lists the resources to remove — with the dependency-safe **deletion order**, the cross-resource-group dependency check, and the CLI, verification, and troubleshooting steps that procedure does not cover.
+
+> [!IMPORTANT]
+> Delete from the inside out: **workload resources first, then the Arc resource bridge, then the custom location, then the infrastructure resources.** Never delete the Arc resource bridge or custom location while any workload still depends on them.
+
+## What and Why
+
+### What This Guide Covers
+
+- The Azure resources a deployment creates, and the dependency-safe order to delete them
+- A checkpoint to confirm nothing still depends on the platform before you remove it
+- When to delete the whole resource group vs. delete resources individually
+- Reimaging the machines before re-running deployment
+
+### When to Use This Guide
+
+- A deployment failed and the recommended recovery is a full redeploy (reimage + redeploy)
+- You are rebuilding a system after an irrecoverable cluster or configuration state
+- You are decommissioning a system, optionally to redeploy onto the same hardware
+
+> [!WARNING]
+> These deletions are **destructive and irreversible**. The Arc resource bridge is the Azure control plane for the system's VMs; deleting it removes the ability to manage those VMs from Azure. Proceed only when a full redeployment (or decommission) is the agreed plan.
+
+## Prerequisites
+
+- **Owner** or **Contributor** on every subscription / resource group that holds deployment resources
+- The list of **all** resource groups involved — workload resources (VMs, disks, NICs) may live in different resource groups than the platform resources
+- Azure portal access; optionally Azure CLI with the `stack-hci-vm`, `customlocation`, and `arcappliance` extensions if you prefer CLI
+- Console or out-of-band access to the physical machines for the reimage step
+
+## Table of Contents
+
+- [Overview](#overview)
+- [What and Why](#what-and-why)
+- [Prerequisites](#prerequisites)
+- [Step 1: Inventory the Deployment Resources](#step-1-inventory-the-deployment-resources)
+- [Step 2: Remove Resource Locks](#step-2-remove-resource-locks)
+- [Step 3: Delete Workload Resources First](#step-3-delete-workload-resources-first)
+- [Step 4: Delete the Arc Resource Bridge, Then the Custom Location](#step-4-delete-the-arc-resource-bridge-then-the-custom-location)
+- [Step 5: Delete the Infrastructure and Registration Resources](#step-5-delete-the-infrastructure-and-registration-resources)
+- [Step 6: Reimage and Redeploy](#step-6-reimage-and-redeploy)
+- [Verification](#verification)
+- [Troubleshooting](#troubleshooting)
+
+## Step 1: Inventory the Deployment Resources
+
+Identify every Azure resource the deployment created so nothing is missed. A standard deployment creates the following (the inventory follows [Decommission Azure Local](https://learn.microsoft.com/azure/azure-local/manage/decommission-azure-local)):
+
+| Count | Resource type |
+|-------|---------------|
+| 1 per machine | Machine - Azure Arc |
+| 1 | Azure Local (the instance / cluster resource) |
+| 1 | Arc resource bridge |
+| 1 | Key vault (only if dedicated to this deployment) |
+| 1 | Custom location |
+| Up to 2 | Storage account (key vault audit logs; plus cloud witness if a cloud witness is used) |
+| 1 per workload volume | Azure Local storage path - Azure Arc |
+
+Plus any workload resources created after deployment: Azure Local VMs, AKS Arc clusters, VM images, logical networks, network interfaces, virtual hard disks (data disks), and network security groups.
+
+> [!NOTE]
+> Counts reflect a typical deployment — confirm against your portal. A cloud witness storage account is required for a 2-node system and optional otherwise (a file-share witness means no cloud witness account). In a **failed** deployment, some resources may never have been created; skip any that don't exist — the order still holds for those that do.
+
+Open the resource group(s) in the [Azure portal](https://portal.azure.com/) and review the resource list and the **Settings > Deployments** blade to confirm the full set before deleting anything.
+
+## Step 2: Remove Resource Locks
+
+By default, deployment applies **DoNotDelete** locks to the resources it creates; governance policies may also apply **ReadOnly** locks. Either kind blocks deletion, and locks can be **inherited** from a parent subscription scope, not just the resource or its resource group.
+
+1. In the Azure portal, open the resource group, expand **Settings**, and select **Locks**.
+2. Delete the **DoNotDelete** and **ReadOnly** locks on the resources you are about to remove. If a delete later fails with a lock error, check parent scopes for an inherited lock.
+
+## Step 3: Delete Workload Resources First
+
+Delete every resource that depends on the custom location / Arc resource bridge **before** touching those platform resources. Work top-down: delete the top-level workloads (VMs, then AKS clusters) first, then the resources they used (network interfaces, data disks), then the containers those lived in (storage paths, logical networks). Deleting a container before the resources inside it orphans them:
+
+1. **Azure Local VMs**, then **AKS Arc clusters** — the top-level workloads. Deleting an Azure Local VM does **not** remove its network interfaces or data disks; those are separate resources you must delete yourself (steps below). In the portal, use **Show hidden types** on the resource group to reveal resources a VM delete left behind.
+2. **VM images**.
+3. **Network interfaces**, then **virtual hard disks** (data disks) that were attached to the VMs.
+4. **Network security groups**.
+5. **Storage paths** (delete after the virtual hard disks they contain) and **logical networks** (delete after the network interfaces they host).
+
+CLI equivalents use the `az stack-hci-vm` command group — for example `az stack-hci-vm delete` (VMs) and the `image`, `network nic`, `disk`, `network nsg`, `storagepath`, and `network lnet` subgroups for the respective resources. (Note: `az stack-hci-vm nic` only attaches/detaches a vNIC to a VM; the NIC **resource** is managed under `az stack-hci-vm network nic`.)
+
+> [!IMPORTANT]
+> Confirm each VM is actually gone — both the Azure resource **and** the underlying VM on the cluster (`Get-VM` on a node) — before continuing. "Gone in Azure" does not mean "gone on the cluster," and deleting the Arc resource bridge while an orphaned VM remains makes the on-premises VM very hard to remove.
+
+> [!IMPORTANT]
+> **Checkpoint — prove nothing still depends on the platform.** Before Step 4, confirm no resource still projects through the custom location, in **any** resource group or subscription. In **Azure Resource Graph Explorer** (or `az graph query`), run the following with the full custom location resource ID; it must return **zero rows**:
+> ```kusto
+> resources
+> | where extendedLocation.name =~ '