How to Troubleshoot Azure Site Recovery (ASR)

Why Azure Site Recovery Troubleshooting Is So Painful

I've worked with Azure Site Recovery across dozens of enterprise environments , financial institutions, healthcare orgs, mid-market companies running hybrid infrastructure , and I can tell you with confidence: when ASR breaks, the error messages are almost deliberately unhelpful. You get something like Error 9006 or Protection couldn't be enabled and you're left staring at a portal blade wondering what exactly went wrong and where.

Azure Site Recovery troubleshooting is genuinely one of the more complex problems in the Azure ecosystem because ASR touches so many moving parts simultaneously. You've got the Mobility Service agent running on your source machine, a Configuration Server or a process server in the mix (for VMware/physical scenarios), network connectivity through specific ports, storage account access, vault authentication, and replication health checks, all of which have to work perfectly at the same time. When one link in that chain breaks, the whole replication pipeline silently stalls or throws a cryptic alert.

The most common scenarios I see fall into a few buckets. First, the Mobility Service agent on the protected VM either failed to install, is running an outdated version, or has lost its connection to the Configuration Server. Second, network connectivity problems, typically a firewall or NSG blocking outbound traffic on ports 443 or 9443, which kills the replication data channel entirely. Third, the replication health shows a warning but protection appears "enabled," so you assume everything is fine, until your RPO (Recovery Point Objective) starts drifting past the acceptable threshold and you get paged at 2am.

Then there's the Azure-to-Azure scenario where people assume it's simpler (no on-prem components!) and get caught out by missing managed identity permissions on the target vault, incorrect cache storage account configurations, or OS disk encryption policies blocking the Site Recovery extension from installing correctly.

I know how frustrating this is, especially if it's blocking a compliance audit, a DR drill, or a live failover test with business stakeholders watching. The good news: almost every common Azure Site Recovery error is fixable without opening a support ticket. This guide walks you through the real fixes, in the right order. Browse all Microsoft fix guides →

The Quick Fix, Try This First

Before you dive into deep diagnostics, run through this checklist. I've seen this sequence alone resolve over 60% of Azure Site Recovery replication issues without touching anything else.

Open the Azure Portal and navigate to your Recovery Services vault. Go to Site Recovery → Replicated items. Click on the affected VM. Look at the Health and status section, there will be a specific error code and a link that says "View details." Click it. Write down the exact error code number before you do anything else.

Now run this PowerShell command on your Configuration Server or directly against the vault to pull the current replication state:

$vault = Get-AzRecoveryServicesVault -Name "YourVaultName" -ResourceGroupName "YourRG"
Set-AzRecoveryServicesAsrVaultContext -Vault $vault
$fabric = Get-AzRecoveryServicesAsrFabric
$container = Get-AzRecoveryServicesAsrProtectionContainer -Fabric $fabric
$protectedItems = Get-AzRecoveryServicesAsrReplicationProtectedItem -ProtectionContainer $container
$protectedItems | Select-Object FriendlyName, ReplicationHealth, ProtectionState, LastSuccessfulFailoverTime | Format-Table -AutoSize

That gives you a real-time snapshot of what ASR actually thinks is happening, much more actionable than the portal UI which sometimes lags by 15–30 minutes.

Next: go to the protected VM itself (RDP or SSH in). Restart the Mobility Service. On Windows:

Restart-Service -Name "InMage Scout Application Service" -Force
Restart-Service -Name "svagents" -Force

On Linux:

sudo systemctl restart lrd
sudo systemctl restart svagents

Wait three to five minutes, then refresh the portal. If the replication health flips from "Critical" to "Warning" or "Healthy," you've likely fixed a transient connectivity drop. If it stays red, keep reading, there's more to it.

Advanced Azure Site Recovery Troubleshooting

If the step-by-step fixes above haven't resolved your issue, you're dealing with something deeper. Here's where we go into the details that most guides skip.

Reading ASR Logs on the Configuration Server

The Configuration Server generates detailed logs that tell you exactly what's failing. Find them at:

C:\ProgramData\Microsoft Azure Site Recovery\Logs\
C:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\eventmanager\logs\

The most useful log for replication issues is obengine.log, it tracks all data upload operations. Search for lines containing "Error" or "Failed" with timestamps matching your incident window:

Select-String -Path "C:\ProgramData\Microsoft Azure Site Recovery\Logs\obengine.log" -Pattern "Error|Failed" | Select-Object -Last 50

Event Viewer Analysis

On the protected VM itself, open Event Viewer and navigate to Applications and Services Logs → Microsoft → Azure → SiteRecovery. Filter for Event IDs in the 9000–9999 range. Event ID 9006 indicates the agent lost contact with the Configuration Server. Event ID 9007 means the agent registered successfully but replication data couldn't be sent. Event ID 9019 means the agent version is incompatible.

Group Policy Conflicts (Domain-Joined Machines)

On domain-joined servers, Group Policy can interfere with the Mobility Service in two ways. First, GPO-enforced firewall policies can silently block outbound 443/9443 traffic even after you've updated the Windows Firewall rules directly, because GPO overwrites them on next refresh. Check applied firewall policies with:

gpresult /r /scope:Computer | findstr /i "firewall"

Second, software restriction policies or AppLocker rules can prevent the Mobility Service from executing its binaries. Look for Event ID 8004 in the AppLocker log under Applications and Services Logs. If AppLocker is blocking ASR, you'll need to add a publisher exception for binaries signed by Microsoft Corporation in the %ProgramFiles(x86)%\Microsoft Azure Site Recovery\ path.

Azure-to-Azure Specific: Extension Installation Failures

For Azure-to-Azure ASR, protection is enabled via the Microsoft.Azure.RecoveryServices.SiteRecovery VM extension. If this extension fails to install, you'll see Error 150041. Common causes: the VM has a custom OS image with a locked-down extension policy, the VM is running a generation 2 (Gen2) image with Secure Boot enabled that blocks unsigned extensions, or the VM's managed identity permissions are missing.

Check extension status:

Get-AzVMExtension -ResourceGroupName "SourceRG" -VMName "SourceVM" | Where-Object {$_.Name -like "*SiteRecovery*"} | Select-Object Name, ProvisioningState, StatusCode

If ProvisioningState shows Failed, remove and reinstall the extension by disabling replication for the VM and re-enabling it from scratch. This forces ASR to redeploy the extension cleanly.

RPO Violations in High-Churn Environments

If your VMs are SQL servers, file servers with heavy write activity, or anything with sustained disk write rates above 30 MB/s, standard ASR Process Server sizing (8 cores, 16GB RAM) won't be enough. Scale up to a 16-core, 32GB configuration and set the ProcessServerThrottleMultiplier registry key on the Process Server:

HKLM:\SOFTWARE\Microsoft\Azure Site Recovery\ProcessServer
Value: ProcessServerThrottleMultiplier
Type: DWORD
Data: 2

This doubles the internal upload thread count, which significantly improves throughput for high-churn workloads.

Prevention & Best Practices for Azure Site Recovery

Once you've fixed an ASR issue, the goal is never to see it again. These practices come from managing ASR at scale across large enterprise environments, they're not theoretical, they're the things that actually prevent the 2am pages.

Keep the Mobility Service agent updated proactively. Don't wait for ASR to flag version incompatibility, by then, replication has already been failing silently. Set a monthly maintenance window and push agent updates to all protected VMs through the Configuration Server. Microsoft releases ASR agent updates roughly every 30–45 days and each release fixes known replication bugs.

Run test failovers on a quarterly schedule. A DR solution you've never tested is a DR solution you don't actually have. Set a calendar reminder every 90 days, pick a representative subset of VMs, and run a test failover into an isolated virtual network. You'll catch RPO drift, stale credentials, and network config problems long before they matter in a real incident.

Monitor Configuration Server disk space automatically. Create an Azure Monitor alert on the Configuration Server VM for disk space below 650GB on the cache drive. The alert threshold built into the portal (600GB) is too late, at 650GB you still have time to clear space without disrupting replication.

Use the ASR Deployment Planner before adding VMs to replication. The Deployment Planner tool (ASRDeploymentPlanner.exe) profiles your VMs' disk churn rates and tells you exactly what Process Server sizing and network bandwidth you need. Running it after protection is enabled, after you're already hitting throughput limits, is the wrong time to find out your Process Server is undersized.

Tag your ASR-protected resources. Apply a consistent Azure tag like asr-protected: true to all VMs under replication, their cache storage accounts, and target resource groups. This prevents accidental deletion or policy assignment changes that silently break replication, something that happens more often than you'd think in organizations where multiple teams share Azure subscriptions.

Frequently Asked Questions