An Azure native disaster recovery service. Previously known as Microsoft Azure Hyper-V Recovery Manager.
Azure Site Recovery replication failed due to internal error - error code : 150060
Azure Site Recovery replication failed due to internal error - error code : 150060
Source VM : Windows 11 Enterprise N
VM Agent version : 2.7.41491.1216 v25H2
Azure Site Recovery
-
Bharath Y P • 8,495 Reputation points • Microsoft External Staff • Moderator
2026-04-28T06:40:31.87+00:00 Hello Kamil Bahrudin, thank you for posting your query on Microsoft Q&A platform.
We are looking into your issue and will keep you posted updates. Thanks
-
Bharath Y P • 8,495 Reputation points • Microsoft External Staff • Moderator
2026-04-28T09:05:28.4533333+00:00 Hello Kamil Bahrudin, it looks like your ASR job is hitting error 150060 "internal error".
ASR relies on the Azure VM Agent to deploy and manage the Site Recovery extension. If the agent is not in a “Ready” state, outdated, or unresponsive, replication can fail.
ASR requires outbound connectivity to Azure endpoints over HTTPS (ports 443 and 9443). Network restrictions or firewall/proxy misconfiguration can prevent replication.
Disk-related issues such as disk changes, detachments, or inconsistencies during replication can cause initialization failures. Changes to disks during replication can break sync state.
Here’s few below things you can validate from your side.
Check VM provisioning state: In Azure Resource Explorer: Subscriptions > ResourceGroups > Resources > your VM > confirm provisioningState is equal to Succeeded.
Verify and Update VM Agent: Check agent status Go to Azure Portal > Select VM > Properties > Agent status
Or PowerShell:
Get-Service RdAgent- Restart VM
- If still failing: Reinstall/upgrade VM Agent
Validate Network Connectivity: Ensure outbound HTTPS allowed.
Test-NetConnection login.microsoftonline.com -Port 443 Test-NetConnection hypervrecoverymanager.windowsazure.com -Port 443Also validate Proxy config (if used) and NSG / Firewall rules.
Check Disk Configuration: Ensure no disks were detached, reattached, resized, or recreated during replication. For Azure VMs, verify that all disks exist and are properly attached in Azure. If a disk change occurred:
- Disable replication for the VM.
- Correct the disk configuration (reattach or recreate missing disks).
- Re-enable replication to rebuild the replication chain.
Retry Replication:
- Recovery Services Vault > Replicated Items > VM > Replication > Re-enable Replication
- Collect logs if failure persists:
C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
If the issue still persist, could you please help us with the below details:
- Is this Azure-to-Azure VM replication or On-premises > Azure replication?
- Has there been any change to disks recently? Is the disk still attached and healthy in Azure?
- Is Mobility Service Running? or is it Recently updated?
Reference documents:
Azure Site Recovery Network Security Guide
Azure-to-Azure support matrix (replicating VMs)
Hope this helps. and please feel free to reach out if you have any further questions. Thanks
-
Bharath Y P • 8,495 Reputation points • Microsoft External Staff • Moderator
2026-04-29T02:57:25.6133333+00:00 Hello Kamil Bahrudin, Just checking to see If the information shared was helpful. Please feel free to reach out if you have any additional questions or need further clarification. Thanks
-
Bharath Y P • 8,495 Reputation points • Microsoft External Staff • Moderator
2026-04-30T03:22:46.54+00:00 Hello Kamil Bahrudin, Just checking to see If the information shared was helpful. Please feel free to reach out if you have any additional questions or need further clarification. Thanks
-
Kamil Bahrudin • 0 Reputation points
2026-04-30T07:38:01.47+00:00 Hi @Bharath Y P is outbound HTTPS required ? what if the VM must be in closed-network without internet access ?
-
Kamil Bahrudin • 0 Reputation points
2026-04-30T07:45:46.53+00:00 Hi @Bharath Y P is outbound HTTPS required ? what if the VM must be in closed-network without internet access ?
-
Bharath Y P • 8,495 Reputation points • Microsoft External Staff • Moderator
2026-04-30T09:52:33.7733333+00:00 Yes, Replication requires outbound connectivity to specific Azure endpoints (for storage, authentication, and service communication). The VM must reach endpoints such as:
-
login.microsoftonline.com> authentication -
*.hypervrecoverymanager.windowsazure.com> replication coordination -
*.blob.core.windows.net> data transfer
To assist you further, could you please help us with the below details:
- Is the VM in a fully isolated (air‑gapped) network, or is limited outbound access allowed?
- Is outbound HTTPS (TCP 443) currently permitted from the VM?
- Are there any URL/FQDN restrictions for outbound Azure service endpoints?
- Do you have Azure Firewall, Private Endpoint, or ExpressRoute (Microsoft peering) available in your environment?
Thanks.
-
-
Kamil Bahrudin • 0 Reputation points
2026-05-01T01:33:25.9233333+00:00 DNS resolution is successful
TCP connection test is successful
VM Status is running and VM Agent status is Ready
NSG allows outbound internet access
Is there any other reasons on why this error occurs ?
Which logs within "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent" do I need to provide ?
-
Bharath Y P • 8,495 Reputation points • Microsoft External Staff • Moderator
2026-05-01T02:51:07.22+00:00 Looks like there is no error and DNS, TCP, NSG, and VM Agent are all healthy. The error message "An internal error occurred" without a specific sub-reason (disk not found, sync time failure, etc.) is a generic 150060 variant. Combined with error 539 (Replication Provider failure), the actual failure is happening might be at the Mobility Service / filter driver / VSS layer on the VM.Here are few troubleshooting step you can try:
- The ASR Mobility Service filter driver is loaded into system memory only during system restart. If the Mobility Service was installed or updated without a subsequent reboot, the filter driver changes haven't taken effect. Ensure reboot the VM after confirming the Mobility Service extension is installed, then retry replication.
- COM+ System Application and Volume Shadow Copy Service (VSS) are required for ASR to create application-consistent snapshots. If either service is disabled, replication fails silently with 150060. Ensure both are running or at least set to Manual, then check VSS writers with
vssadminlist writers. Troubleshoot Azure VM replication in Azure Site Recovery - other issues - Azure Site Recovery | Microsoft Learn - Anti-Virus software, including Defender, can block Mobility Service DLL registration and filter driver attachment at boot. Excluding ASR folders is a documented mitigation. Windows 11 Enterprise N ships with Defender, so also verify Defender real-time protection isn't blocking ASR filter driver attachment at boot. Troubleshoot Mobility Service push installation with Azure Site Recovery - Azure Site Recovery | Microsoft Learn
- The Windows 11 Enterprise N edition lacks some media and COM components, which can indirectly cause COM+ or VSS instability. While not explicitly documented as a 150060 cause, it is a known factor in similar replication failures. Verify COM+ functionality; optionally install the Media Feature Pack for N editions if COM or VSS errors are present.
- Disabling and re-enabling replication forces a clean reinstallation of the Mobility Service extension, which often resolves persistent 150060 errors. Disable replication > wait for cleanup > re-enable. Ensure no resource locks on the Recovery Services Vault.
- If the Mobility Service heartbeat is failing due to an expired tenant context, the fix involves retrieving updated
mobilityAgentTenantIdToUpdateandmobilityAgentClientIdToUpdatevalues via the REST API and updatingC:\ProgramData\Microsoft Azure Site Recovery\Config\RCMInfo.confwith the correct AAD Tenant ID and Client ID. This is more relevant if the VM was migrated between tenants or subscriptions. Troubleshoot replication of Azure VMs with Azure Site Recovery - Azure Site Recovery | Microsoft Learn
The portal error is intentionally generic for 150060. The real sub-reason is in the agent logs:
- Mobility Agent installer >
C:\ProgramData\ASRSetupLogs\ASRUnifiedAgentInstaller.log - VSS/application consistency >
C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\Application Data\ApplicationPolicyLogs\vacp.log - General ASR logs >
C:\ProgramData\ASRLogs\
Hope this helps. and please feel free to reach out if you have any further questions.
Thanks
-
Kamil Bahrudin • 0 Reputation points
2026-05-02T00:38:41.5733333+00:00 - I have rebooted the VM
- COM+ System Application and Volume Shadow Copy Service (VSS) are set to Manual on Startup Type column
- Defender for cloud is off for this VM
- I've Disabled and re-enabled replication
- VM was not migrated between tenants nor subscriptions
- I couldn't find C:\ProgramData\ folder
- The C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\Application Data\ApplicationPolicyLogs\ is empty
Can you provide guidance on how to proceed ?
-
Kamil Bahrudin • 0 Reputation points
2026-05-04T05:05:46.6533333+00:00 - I have rebooted the VM
- COM+ System Application and Volume Shadow Copy Service (VSS) are set to Manual on Startup Type column
- Defender for cloud is off for this VM
- I've Disabled and re-enabled replication
- VM was not migrated between tenants nor subscriptions
- I couldn't find C:\ProgramData\ folder
- The C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\Application Data\ApplicationPolicyLogs\ is empty
Can you provide guidance on how to proceed ?
-
Bharath Y P • 8,495 Reputation points • Microsoft External Staff • Moderator
2026-05-04T18:27:44.6966667+00:00 Thanks for the update. We’ll review this and get back to you shortly.
-
Sign in to comment