Azure VMware Solution Reset Backups at Root Level

In a large Azure VMware Solution (AVS) environment with around 300 VMs across 7 nodes, the initial backup setup used a single Microsoft Azure Backup Server (MABS) instance. The plan was to scale vertically as needed, but eventually CPU and RAM constraints caused performance degradation and backup failures.

The natural solution was to spin up a second MABS instance to share the load — but enrolling VMs into the new server's backup policies immediately hit an error: VMs appeared to already be claimed by the original server, despite that server having no active policies for them.

Root Cause

When a VM is enrolled in MABS, vCenter automatically creates a custom attribute called DPMServer and stores the DPM server's FQDN as the value. This attribute acts as a lock — MABS checks for it before allowing enrolment elsewhere.

The original server's policies had been removed, but the DPMServer custom attribute remained, still pointing to the old server.

The Problem with Removing It

The straightforward fix would be to delete or clear the DPMServer attribute. However, cloudadmin permissions in AVS don't allow complete removal of custom attributes at the vCenter root level.

The Solution

Rename the problematic attribute. If MABS can't find an attribute named DPMServer, it treats the VM as unclaimed and allows enrolment.

In vCenter:

1. Navigate to Menu → Administration → Custom Attributes
2. Find the DPMServer attribute
3. Rename it — e.g., DPMServerOld

Once renamed, new VMs (and previously enrolled VMs) can be enrolled in the second MABS instance's policies without conflict.

Trade-off

This approach leaves orphaned DPMServerOld attributes on VMs over time. In a large environment that's not ideal, but it's significantly more practical than manually clearing the attribute value from hundreds of individual VMs. The accumulated legacy tags are a minor nuisance compared to the alternative.