+
+ | 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 |
+
+
+ | Who runs this |
+ Owner or Contributor on every subscription and resource group that holds deployment resources |
+
+
+ | Reversibility |
+ Irreversible: deleted resources cannot be recovered (a soft-deleted key vault is recoverable only until it is purged or its retention period ends) |
+
+
+ | Impact / downtime |
+ Total: every workload on the system is destroyed; the system is offline until it is reimaged and redeployed |
+
+
+ | Estimated time |
+ Azure resource deletion is typically tens of minutes; the full reimage and redeploy adds several hours (varies by hardware and node count) |
+
+
+
+## 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.
+
+## Glossary
+
+- **Arc resource bridge (ARB)** — the on-premises appliance VM that Azure uses as the control plane to manage the system's VMs. It runs on the cluster as a `*-control-plane-*` VM and is what `az arcappliance delete hci` removes.
+- **Custom location** — the Azure resource that points at the Arc resource bridge and gives Azure a target to create resources (VMs, disks, logical networks) on your system. It is deleted only **after** the Arc resource bridge.
+- **extendedLocation** — the property on each projected Azure resource that references the custom location it was created through. The Step 3 Resource Graph checkpoint queries this property to find resources that still depend on the platform.
+- **Soft-delete vs. purge (Key Vault)** — deleting a key vault **soft-deletes** it: the vault and its secrets stay recoverable for a retention period and the name stays reserved. **Purging** permanently removes the soft-deleted vault and frees the name, unless purge protection is enforced.
+
+## 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)
+- [Glossary](#glossary)
+- [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
+
+> [!WARNING]
+> **Back up workload data before you start.** The deletions in this step are irreversible and destroy all workload data on the system — VM guest data, AKS Arc workloads, and their data disks. Export or back up anything you need to keep, and capture any VM, disk, and network configuration you intend to recreate, before deleting anything.
+
+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. Delete one resource type at a time, in the same inside-out order, using the names from your Step 1 inventory (or the matching `... list` command). Run each command once per resource of that type:
+
+```azurecli
+# --yes skips the per-resource confirmation prompt; omit it to confirm each delete.
+
+# 1. Azure Local VMs (deleting a VM does NOT delete its NICs or data disks)
+az stack-hci-vm delete --resource-group