Azure Site Recovery (ASR) replication fails with error code 150060 when an internal error blocks the replication job from completing. This error most commonly appears on Windows VMs and points to one of three root causes: a VM agent that is not in a Ready state, a network connectivity problem blocking outbound HTTPS traffic to Azure endpoints, or a disk configuration change that broke the replication sync.

This guide walks you through every validated fix for error 150060 and covers related ASR replication errors you may encounter alongside it.
Table of Contents
What Causes Azure Site Recovery Error 150060
ASR depends on three components working correctly at the same time: the Azure VM Agent, outbound network access to specific Azure endpoints, and a stable disk configuration on the source VM. If any one of these fails, ASR throws error 150060 and halts replication.
The most common causes are:
- VM Agent not Ready: ASR uses the Azure VM Agent to deploy and manage the Site Recovery extension. If the agent is outdated, stopped, or unresponsive, replication fails at initialization.
- Network blocked: ASR requires outbound HTTPS on ports 443 and 9443 to reach Azure recovery endpoints. A misconfigured firewall, proxy, or NSG rule silently blocks these connections.
- Disk change during replication: If a disk was detached, resized, reattached, or recreated while replication was active, ASR loses sync state and raises an internal error.
Fix 1: Check the VM Provisioning State
Before anything else, confirm the VM itself is in a healthy provisioning state. ASR cannot enable or continue replication on a VM that is not fully provisioned.
- Open the Azure Portal and go to All Services > Resource Explorer.
- Expand Subscriptions, then ResourceGroups, and select the resource group that contains your VM.
- Expand Resources and select your VM.
- In the instance view on the right, locate the provisioningState field.
The value must read Succeeded.
- If it reads Failed, open a support case with Microsoft and provide the error details.
- If it reads Updating, another extension is deploying. Wait for the operation to finish, then retry the ASR replication job.
Fix 2: Verify and Update the VM Agent
ASR deploys the Mobility Service extension through the Azure VM Agent. An outdated or stopped agent is one of the most frequent causes of error 150060.
Check agent status in the portal:
- Go to Azure Portal > Virtual Machines > select your VM > Properties.
- Look for Agent status, it must show Ready.
Check agent status with PowerShell:
Get-Service RdAgentThe service must be Running. If it is stopped, start it:
Start-Service RdAgentIf the agent is outdated or stuck:
- Restart the VM from the Azure portal.
- If restarting does not resolve it, reinstall the VM agent by downloading the latest version from the Microsoft Azure VM Agent page and running the installer on the VM.
Note: If you are following any changes Microsoft announced regarding legacy agent data uploads in Azure Monitor, keep in mind that the ASR Mobility extension agent is separate from the legacy MMA/OMS agents. Ensure you are updating the correct component.
Fix 3: Validate Network Connectivity
ASR requires outbound HTTPS access on ports 443 and 9443 to communicate with Azure recovery endpoints. A firewall rule, NSG, or proxy misconfiguration silently drops this traffic and causes replication to fail.
Test connectivity with PowerShell:
Test-NetConnection login.microsoftonline.com -Port 443
Test-NetConnection hypervrecoverymanager.windowsazure.com -Port 443Both commands must return TcpTestSucceeded : True. If either fails, check your NSG outbound rules and firewall policies.
If your VM is on a closed network with no internet access:
ASR still requires outbound connectivity to Azure endpoints, but you do not have to route traffic over the public internet. You can use Azure Private Link or service endpoints to reach ASR endpoints through your internal network. Configure the following:
- Set up a Private Link for Azure Site Recovery in your virtual network.
- If using a proxy, add the required ASR URLs to the proxy allowlist and configure the Mobility Service proxy settings on the VM.
- Review your NSG rules to confirm outbound traffic to the AzureSiteRecovery service tag is allowed.
Closed-network replication is supported, but it requires explicit network configuration. Blocking all outbound traffic without a Private Link in place will always cause error 150060.
Fix 4: Check the Disk Configuration
Disk changes during an active replication session break the sync state and trigger internal errors. ASR cannot track a disk that was detached, resized, or recreated mid-replication.
Check for disk issues:
- In the Azure portal, open your VM and go to Disks.
- Confirm every disk listed is Attached and shows a healthy state.
- If you recently resized a VM and a data disk went missing, follow the steps in How to Fix an Azure VM Data Disk Missing After Resize to reattach and reinitialize it before retrying replication.
If a disk was changed during replication:
- Go to Recovery Services Vault > Replicated Items > select your VM.
- Click Replication > Disable Replication to stop the current replication job.
- Correct the disk configuration (reattach or recreate any missing disks, reinitialize as needed).
- Re-enable replication from Replicated Items > Enable Replication to rebuild the replication chain from scratch.
Fix 5: Retry the Replication Job
After fixing the VM agent, network, or disk issue, manually retry the replication job. ASR does not automatically retry after an internal error.
- Open the Recovery Services Vault in the Azure portal.
- Go to Replicated Items and select your VM.
- Click Replication in the top menu.
- Select Re-enable Replication and follow the prompts.
If the job fails again with error 150060, collect the ASR agent logs before contacting support. The logs are at:
C:\Program Files (x86)\Microsoft Azure Site Recovery\agentOther Azure Site Recovery Replication Errors
If you see other error codes alongside 150060, here is how to handle each one.
1. Error 150039: Disk Not Found in VM
ASR raises error 150039 when a data disk attached to the VM was not initialized inside the OS. The disk appears in Azure but the VM reports no matching LUN value.
Fix: Initialize the disk inside the VM before enabling replication.
- Windows: Use Disk Management or
diskpartto initialize the disk. - Linux: Use
fdiskorpartedto initialize the disk and create a partition.
Once initialized, retry enabling replication.
2. Error 150225 and 150226: Stale Site Recovery Configuration
Error 150225 appears when ASR removes VM protection but cannot clean up all resource links because of a resource lock on the VM. Error 150226 appears when a stale ASR configuration from a previous replication session blocks you from re-enabling replication.
Fix:
- Go to the VM in the Azure portal and remove any resource locks on the VM or its resource group.
- Download and run the Cleanup-stale-asr-config-Azure-VM.ps1 script. Pass the Subscription ID, VM Resource Group, and VM name as parameters.
- After the script completes without errors, re-enable replication from the Recovery Services vault.
3. Error 150019: VM Provisioning State Not Valid
This error blocks replication when the VM’s provisioningState is not Succeeded. Follow Fix 1 above to check and resolve the provisioning state.
4. Cannot Select VM or Resource Group in Enable Replication
If the VM or resource group does not appear in the Enable Replication wizard, check these three causes:
- Different locations: The source VM and resource group must be in the same Azure region. If they are not, enable replication directly from the VM under Properties > Disaster Recovery.
- Resource group outside subscription: The resource group must belong to the selected subscription.
- Stale configuration: Run the
Cleanup-stale-asr-config-Azure-VM.ps1script as described in the error 150225/150226 fix above.
FAQs
Does Azure Site Recovery require internet access on the source VM?
ASR requires outbound connectivity to Azure recovery endpoints on ports 443 and 9443, but the traffic does not have to go over the public internet. You can route it through Azure Private Link or service endpoints if your VM is on a closed network.
Why does error 150060 appear after I resize a VM?
Resizing a VM can cause data disks to go offline or appear unallocated inside the OS. ASR treats a missing or inaccessible disk as a disk change and fails with an internal error. Reinitialize any missing disks and re-enable replication.
Can I re-enable replication without losing my recovery points?
Disabling and re-enabling replication resets the replication chain and removes existing recovery points. You will need to wait for the initial replication to complete again before failover is available.
What logs should I collect if error 150060 persists?
Collect the ASR agent logs from C:\Program Files (x86)\Microsoft Azure Site Recovery\agent and share them when opening a Microsoft support case.
