Azure Site Recovery error help!

Hi @Chalee Thank you for sharing the additional details. We understand that the planned failover from Azure to your on-premises environment reports a failure, although the on-premises VM becomes available and you are subsequently able to Commit and Reprotect it.

The successful Commit and Reprotect operations are positive indicators, but they do not confirm which Planned Failover subtask failed or establish that the underlying issue is resolved. The failure may have occurred during VM shutdown, appliance or disk handling, vCenter/datastore operations, on-premises VM startup, application validation, cancellation, or job-status reporting.

To identify the exact cause, please share the following from the failed job:

1. Open Recovery Services vault > Site Recovery jobs.
2. Open the failed Planned Failover job.
3. Expand the failed task and open Errors.
4. Copy the Error ID, Error message, Provider error, Possible causes, and Recommendation exactly as displayed.
5. Share the failed subtask name and confirm whether the deployment uses an Azure Site Recovery replication appliance or a legacy Configuration Server setup.

Before retrying, please validate that:

• Replication health shows Healthy.
• The replication appliance and all components show Healthy.
• The Azure VM is running and the required mobility services are operational.
• vCenter is connected and the configured account has the required permissions.
• The target datastore is accessible to the selected appliance.
• The protected disk inventory matches the expected on-premises disk inventory.

If this is a Modernized deployment and the failed job presents Cancel Failover, please follow the job recommendation and complete cancellation before retrying. Cancel Failover is designed to restore the machine to its pre-failover state and resume replication. Please do not disable replication while the failed planned failover or cancellation issue is being investigated.

Please also note:

• iSCSI configuration is not retained during planned failover from Azure to on-premises; VMDK disks are created on-premises.
• Disks added only after the VM was failed over to Azure are not replicated back to the on-premises machine.
• Commit finalizes the failback operation and should be performed only after validating the on-premises VM, applications, disks, and data. It should not be treated as the fix for the failed job.

At this stage, the workaround has allowed the failback process to continue, but the root cause of the Planned Failover failure has not yet been confirmed. Once we have the exact Error ID, provider message, architecture, and failed subtask, we can map the failure to the appropriate corrective action.

Relevant Microsoft documentation

• Trouhoot failback and reprotection for VMware VMs
• Fail over VMware VMs using Modernized Azure Site Recovery
• Overview of Modernized failover and failback
• Prepare for reprotection and VMware failback

If you have further questions regarding this answer, feel free to click "Comment". If you find the answer helpful, please click "upvote". This helps the community by allowing others with similar queries to easily find the solution.

Hi ,

Thanks for reaching out to Microsoft Q&A.

This is a recorded azure site recovery (ASR) post-failover cleanup issue, not an actual failback failure. Error 510025 during “Preparing on-premise virtual machine” typically means ASR failed in post-failover tasks (mainly disk detachment/cache/ mobility service sync) on the Process Server or source VM, not the VM itself. Since your failover, commit, and reprotect all succeed, the core replication path is healthy.

Start with Process Server logs (C:\ProgramData\ASRLogs) and check for disk/mount or agent communication errors during that timestamp; also verify Mobility Service is up-to-date and running on the onprem VM, and that there are no stale disks still registered in the Replication policy (InMage/RcmSvc mappings). This commonly happens when temporary disks or old replication metadata are not cleaned up. Safe fix: update Mobility Agent, restart InMage/ASR services, and run a test failover + cleanup once to reset state. If it persists, manually remove and re-add disk mappings in reprotect step or re-enable replication for that VM.

I would suggest ignore + commit working confirms it is a non-blocking clean-up defect, not data risk.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.