Orphaned Objects in Resource Groups – Lessons Learned

Recently, I developed and published my first OMS solution ARM template, namely the SCOM ACS Dashboard.

That was definitely a learning experience in itself. However, when I was developing and testing my ARM template code, I obviously ran into issues with failed and partial deployments.


Partial Deployments Lead to Orphaned Objects

One specific scenario that I encountered, was the deployment of a Resource Group, and OMS Solution (i.e. my SCOM ACS Dashboard solution has a dependency on the Security And Audit solution in OMS), but where the OMS Workspace was not deployed.

This effectively made for an orphaned OMS Solution (depicted below).


The Errors

The problem with this is, when I attempted to delete the entire Resource Group to clean up my trial-and-error testing, I would get an error.

Even attempting to -Force delete the Resource Group in PowerShell returned an error.

PS C:\WINDOWS\system32> Remove-AzureRmResourceGroup -Name ARMDeployTest2 -Force -Verbose
VERBOSE: Performing the operation “Removing resource group …” on target “ARMDeployTest2”.
Remove-AzureRmResourceGroup : Long running operation failed with status ‘Conflict’.
At line:1 char:1
+ Remove-AzureRmResourceGroup -Name ARMDeployTest2 -Force -Verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Remove-AzureRmResourceGroup], CloudException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Resources.RemoveAzureResourceGroupCmdlet

At first, you might think about Resource Locks, but upon checking, there were none. And for the few that did have locks, even after removing the resource lock (via PowerShell), it would still fail to delete.

So how can I clean up all my orphaned / semi-deployed Resource Groups?


The Solution

The solution is simple, but not directly obvious.

In my specific case, the delete operation failed because the Solution was, somehow, still linked to an OMS Workspace it expected to be present (or at least it expected a Workspace as part of the delete sequence). I’m not sure exactly how/why that was.

However, I found that by just creating a new OMS Workspace within the target Resource Group, with the Workspace Name that the existing Solution was referencing (i.e. “OMSARMDeploy” in the screenshot above), I was then able to successfully delete the entire Resource Group and effectively clean up my orphaned objects.

I’m not sure if this will work in all scenarios, and it doesn’t seem to work every time I try it, but it’s something that seemed to work in my case.

%d bloggers like this: