+
+ | 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 + User Access Administrator**, on every subscription / resource group that holds deployment resources. **Contributor alone is not enough** to remove resource locks (Step 2) or delete role assignments (Step 5c) — those need `Microsoft.Authorization` rights (Owner or User Access Administrator).
+- The list of **all** resource groups involved — workload resources (VMs, disks, NICs) may live in different resource groups than the platform resources; if **Insights** or **Azure Backup** was enabled, include the **monitoring / backup resource group** (often separate — Step 5b)
+- **Microsoft Entra Directory Readers** (Graph directory-read) to resolve principal names in Step 5c, plus **Application / User Administrator** if you also delete a throwaway deployment service principal or user
+- The **ActiveDirectory PowerShell module (RSAT)** on a domain-joined admin host, with delete rights over the deployment OU, for the on-premises AD cleanup (Step 5d)
+- 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 5b: Untie Azure Monitor / Insights (and Backup, if enabled)](#step-5b-untie-azure-monitor--insights-and-backup-if-enabled)
+- [Step 5c: Remove Orphaned Role Assignments and Identities](#step-5c-remove-orphaned-role-assignments-and-identities)
+- [Step 5d: Clean Up On-Premises Active Directory](#step-5d-clean-up-on-premises-active-directory)
+- [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.
+
+> [!IMPORTANT]
+> A deployment also creates objects that live **outside** the resource group and are **not** removed by deleting the resource group: **Entra ID role assignments and identities** (the deployment service principal / user, plus system-assigned managed identities), **Azure Monitor / Insights configuration** (the Azure Monitor Agent, data collection rules, and a Log Analytics workspace), and **on-premises Active Directory objects** (Azure Local requires AD DS, so every deployment has these: a dedicated OU with the cluster name object, node computer accounts, and deployment accounts). These are cleaned up in Steps 5b–5d and are easy to leave behind. Especially on **test subscriptions**, a deleted deployment principal leaves its role assignments dangling as **"Identity not found (Unknown)"** — the Azure equivalent of an unresolved SID on an AD ACL.
+
+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. If your only backup is **Azure Backup**, back up to a target **outside** that Recovery Services vault — Step 5b tears the vault down (`--delete-backup-data true`), destroying those recovery points.
+
+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