Azure Monitor Workspace stuck in 'Deleting' state - ghost DCR association from deleted resource group blocks all cleanup

Hello Peter, The Azure Monitor Workspace defaultazuremonitorworkspace-weu (and its managed RG MA_defaultazuremonitorworkspace-weu_westeurope_managed) cannot be deleted because the AMCS control plane still holds an internal association reference to a DCR (collect-events-linux) whose resource group (AzureBackupRG_westus2_1) was deleted first. The error ExistingAssociationsPreventDelete fires because ARM validates associations during delete and blocks it even though the target DCR no longer exists anywhere in the subscription.

When an Azure Monitor Workspace is created, it auto-provisions a managed RG (MA_<name>_<location>_managed) with a Data Collection Endpoint (DCE) and a Data Collection Rule. Associations (DCRAs) between DCRs and DCEs/workspaces are stored as metadata on the target resource, not just on the DCR itself. When you deleted the resource group AzureBackupRG_westus2_1, ARM successfully removed the DCR and its resource group, but the association pointer on the workspace/DCE side was not cleaned up by the AMCS resource provider. This creates an orphaned reference that blocks all subsequent delete operations.

1. You can try re-create the RG + DCR, Then Cascade-Delete (Still the Best Shot)

This approach works on the DCR side, not the workspace side, so the workspace's stuck Deleting state shouldn't block it. The idea is to make ARM "see" the phantom DCR again so the ?deleteAssociations=true parameter can clean up the orphaned association metadata.

# 1. Recreate the resource group
az group create --name "AzureBackupRG_westus2_1" --location "westus2"
# 2. Recreate the DCR via REST PUT (minimal body — just needs to exist at the exact resource ID)
az rest --method PUT \
  --url "https://management.azure.com/subscriptions/{sub-id}/resourceGroups/AzureBackupRG_westus2_1/providers/Microsoft.Insights/dataCollectionRules/collect-events-linux?api-version=2023-03-11" \
  --body '{
    "location": "westus2",
    "properties": {
      "dataFlows": [{"streams":["Microsoft-Syslog"],"destinations":["dest1"]}],
      "destinations": {
        "logAnalytics": [{
          "workspaceResourceId": "/subscriptions/{sub-id}/resourceGroups/{any-existing-rg}/providers/Microsoft.OperationalInsights/workspaces/{any-existing-workspace}",
          "name": "dest1"
        }]
      }
    }
  }'
# 3. Delete the DCR with cascading association cleanup
az rest --method DELETE \
  --url "https://management.azure.com/subscriptions/{sub-id}/resourceGroups/AzureBackupRG_westus2_1/providers/Microsoft.Insights/dataCollectionRules/collect-events-linux?api-version=2024-03-11&deleteAssociations=true"
# 4. Retry deleting the Azure Monitor Workspace
az rest --method DELETE \
  --url "https://management.azure.com/subscriptions/{sub-id}/resourceGroups/defaultresourcegroup-weu/providers/Microsoft.Monitor/accounts/defaultazuremonitorworkspace-weu?api-version=2023-04-03"
# 5. Clean up
az group delete --name "AzureBackupRG_westus2_1" --yes --no-wait

If step 2 fails because the DCR PUT requires a valid Log Analytics workspace destination, you can create a temporary throwaway workspace first, reference it, then clean up after.

2. Use Azure Resource Explorer to Find & Delete the Orphaned Association Directly

The Q&A moderator for the identical DCE/AMPLS orphan case specifically recommended using https://resources.azure.com to locate and manually delete orphaned associations that aren't visible through CLI or portal.

1. Go to https://resources.azure.com
2. Navigate to:
   • subscriptions/{sub-id}/resourceGroups/defaultresourcegroup-weu/providers/Microsoft.Monitor/accounts/defaultazuremonitorworkspace-weu
   • Also check: subscriptions/{sub-id}/resourceGroups/MA_defaultazuremonitorworkspace-weu_westeurope_managed/providers/Microsoft.Insights/dataCollectionEndpoints/{dce-name}
3. Expand each resource and look for a child node called providers/Microsoft.Insights/dataCollectionRuleAssociations
4. If you find the orphaned association referencing collect-events-linux, try DELETE directly from Resource Explorer

Also try the direct REST call to list associations on the DCE inside the managed RG:

# List all DCRA children on the DCE
az rest --method GET \
  --url "https://management.azure.com/subscriptions/{sub-id}/resourceGroups/MA_defaultazuremonitorworkspace-weu_westeurope_managed/providers/Microsoft.Insights/dataCollectionEndpoints/{dce-name}/providers/Microsoft.Insights/dataCollectionRuleAssociations?api-version=2023-03-11"
# List all DCRA children on the workspace itself
az rest --method GET \
  --url "https://management.azure.com/subscriptions/{sub-id}/resourceGroups/defaultresourcegroup-weu/providers/Microsoft.Monitor/accounts/defaultazuremonitorworkspace-weu/providers/Microsoft.Insights/dataCollectionRuleAssociations?api-version=2023-03-11"

If any association IDs appear, delete them directly:

az rest --method DELETE \
  --url "{full-association-resource-id}?api-version=2023-03-11"

Hope this helps! Please let us if you still facing an issue. Thanks

Hello Peter van Barneveld,

Greetings! Thanks for raising this question in Q&A forum.

You've done an exceptionally thorough job of investigating this and you've correctly identified the root cause. This is a classic ghost DCR association issue, where Azure Monitor Workspace holds an internal backend reference to a Data Collection Rule that was deleted as part of a resource group deletion, but the ARM-level association record was never cleaned up. Since the resource group AzureBackupRG_westus2_1 no longer exists, the standard DELETE and PATCH API calls bounce back with ResourceGroupNotFound or Conflict, leaving the workspace permanently stuck in Deleting state. This is a known platform-side cleanup bug in Azure Monitor.

To answer your direct question unfortunately, there is no self-service REST call or CLI workaround that can resolve this particular scenario. Here's why: the ghost association exists in Azure Monitor's internal datastore at the backend, not in ARM. Since the resource group is already gone, ARM has no object to operate on, and the workspace delete operation cannot progress because the backend cleanup workflow is waiting for a dependency that no longer exists in a resolvable state. The ExistingAssociationsPreventDelete error is being thrown by an internal Azure Monitor service check that ARM-level tools cannot bypass.

Here is the recommended path forward:

Step 1: Try One More REST Call — Force-Cancel the Stuck Delete Operation

Before escalating, try cancelling the stuck delete operation using the Azure REST API. Run the following command using the Azure CLI:

az rest --method post \
  --url "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/defaultresourcegroup-weu/providers/microsoft.monitor/accounts/defaultazuremonitorworkspace-weu/cancel?api-version=2023-04-03"

Replace {subscriptionId} with your actual subscription ID. If a cancel operation endpoint is supported for this resource type, it may reset the provisioning state and allow a fresh delete attempt.

Step 2: Try Deleting the Managed Resource Group Directly via REST with Force Flag

Some ARM resource providers support a force delete parameter. Try the following REST call to force-delete the managed resource group:

az rest --method delete \
  --url "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/MA_defaultazuremonitorworkspace-weu_westeurope_managed?api-version=2021-04-01&forceDeletionTypes=Microsoft.Insights/dataCollectionRules"

Step 3: Escalate via a No-Cost Support Request — Developer Community or Azure Feedback

Since you are on a Visual Studio Enterprise MPN subscription without a paid technical support plan, you have two no-cost escalation paths. First, file a bug report on the Azure Feedback / Developer Community portal at https://feedback.azure.com describing the ghost DCR association and include your Tracking ID: dc496908-82b4-4dcd-8b00-b702d9fced96. Second, post in the Microsoft Tech Community Azure Monitor forum at https://techcommunity.microsoft.com/t5/azure-monitor/bd-p/AzureMonitor the Azure Monitor product team actively monitors that forum and has resolved similar ghost association issues for community members by triggering backend cleanup from their side.

Step 4: Open a Basic Support Request (Available Free on All Subscriptions)

Even without a paid support plan, every Azure subscription includes Basic support which covers billing and subscription management issues, and in practice, the Azure Monitor team has resolved stuck-deletion bugs through Basic support tickets. Go to https://aka.ms/azuresupport, select Service and subscription limits (quotas) or Technical as the issue type, and under service select Azure Monitor. In the description, include your Tracking ID, the workspace name, the ghost DCR path, and confirm the resource group no longer exists. Mention this is a platform-side ghost reference that cannot be resolved via self-service. The support agent can escalate to the Azure Monitor engineering team to trigger a backend cleanup of the orphaned association record, which is the only way to unblock the delete.

This is genuinely a platform bug and not something you caused or can fix yourself the Azure Monitor team needs to clean up the internal association record on their end.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix