Azure VM backup fails with UserErrorGuestAgentStatusUnavailable or extension timeouts: fix the agent, the snapshot extension and outbound access

#Symptoms

Backup jobs in the Recovery Services vault fail with one of these error codes:

Get the exact code first:

az backup job list --resource-group rg-backup --vault-name rsv-prod \
  --status Failed --query "[].{vm:properties.entityFriendlyName, op:properties.operation, err:properties.errorDetails[0].errorCode, start:properties.startTime}" -o table

#Step 1: Is the VM agent healthy?

az vm get-instance-view -g rg-app -n vm-app01 \
  --query "{agent:instanceView.vmAgent.statuses[0].displayStatus, version:instanceView.vmAgent.vmAgentVersion, prov:provisioningState}" -o table

Ready is good. Not Ready or an empty version means the agent isn't talking to the platform.

Windows (inside the VM, or via Run Command / Serial Console):

Get-Service WindowsAzureGuestAgent, RdAgent | Select Name, Status, StartType
Restart-Service WindowsAzureGuestAgent
Get-Content C:\WindowsAzure\Logs\WaAppAgent.log -Tail 50

Linux:

sudo systemctl status walinuxagent || sudo systemctl status waagent
sudo systemctl restart walinuxagent
sudo tail -100 /var/log/waagent.log

If the agent is very old, update it (Windows: install the latest VM agent MSI; Linux: update the WALinuxAgent / walinuxagent package from the distro repo).

Tip

The agent talks to the wire server at 168.63.129.16 on ports 80 and 32526. A host firewall rule, proxy setting or NVA route that blocks that IP is a very common cause of "agent not ready". It must not go through a proxy.

Test-NetConnection 168.63.129.16 -Port 80
Test-NetConnection 168.63.129.16 -Port 32526

#Step 2: Fix a failed provisioning state

If provisioningState is Failed, Backup refuses to run. Usually an extension failed. Find it:

az vm get-instance-view -g rg-app -n vm-app01 \
  --query "instanceView.extensions[].{name:name, status:statuses[0].displayStatus, msg:statuses[0].message}" -o table

Fix or remove the broken extension, then reapply the VM model to clear the state:

az vm extension delete -g rg-app --vm-name vm-app01 -n <BrokenExtension>
az vm reapply -g rg-app -n vm-app01

#Step 3: Reset the snapshot extension

Backup installs VMSnapshot (Windows) or VMSnapshotLinux (Linux). A stuck or corrupt copy causes repeated GuestAgentSnapshotTaskStatusError. Delete it; the next backup reinstalls it:

az vm extension list -g rg-app --vm-name vm-app01 --query "[].name" -o tsv
az vm extension delete -g rg-app --vm-name vm-app01 -n VMSnapshot        # Windows
az vm extension delete -g rg-app --vm-name vm-app01 -n VMSnapshotLinux   # Linux

Then trigger an on-demand backup:

az backup protection backup-now --resource-group rg-backup --vault-name rsv-prod \
  --container-name "<container>" --item-name vm-app01 --backup-management-type AzureIaasVM \
  --retain-until 30-12-2026

#Step 4: Windows VSS writers

App-consistent backups on Windows use VSS. Check writer health:

vssadmin list writers

Any writer not in [1] Stable with No error is a problem. Restart the service that owns it (for example SQLWriter for SqlServerWriter, VSS for the system writer), then re-run. If a third-party backup agent also uses VSS at the same time, schedule them apart.

As a short-term workaround you can make Backup take file-system-consistent snapshots by setting the registry value that Microsoft documents for this (SnapshotWithoutThreads / SnapshotMethod under HKLM\SOFTWARE\Microsoft\BcdrAgent). Check the current Azure Backup troubleshooting article for exact values before changing it.

#Step 5: Restore point collection limit

Azure Backup keeps instant-restore snapshots in a restore point collection, in a resource group named like AzureBackupRG_<region>_1. If cleanup fails, you hit UserErrorRpCollectionLimitReached. Causes:

• A resource lock on that resource group (or the VM's group, if collections live there) blocks deletion.
• Someone moved or deleted the resource group.

az lock list --resource-group AzureBackupRG_centralindia_1 -o table

Caution

Remove the lock on the restore point resource group, not by deleting restore point collections by hand unless Microsoft's guidance says so. Deleting the wrong collection removes instant-restore points you may need.

#Quick symptom → fix table

#Prevent it next time

• Alert on failed backup jobs with Azure Monitor (Backup alerts in Business Continuity Center) instead of reading the vault weekly.
• Don't lock AzureBackupRG_* resource groups; exclude them from lock policies.
• Allow 168.63.129.16 in every host firewall baseline and bypass it in proxy settings.
• Keep VM agents current through your image pipeline.
• Separate the backup window from the patching window by at least two hours.