Check replication health first
Open the VM replication health view and identify whether the problem is initial replication, ongoing replication, authentication, network transfer or storage. Do not begin failover while replication health is unknown.
Validate the replica path
Confirm that the primary host can reach the replica server on the configured replication port and that the selected authentication method matches the deployment. Certificate-based authentication requires the required certificates to be trusted.
Check recovery points
Confirm that the replica is receiving changes and that the available recovery points match the recovery objective. A replica that is powered on is not proof that recent application data has been replicated.
Use test failover before a real event
A test failover creates an isolated test copy and allows you to validate boot, networking, application startup and recovery procedures without interrupting the primary VM. Document the expected result before the test.
Planned versus unplanned failover
A planned failover is used when the primary VM can be shut down cleanly and remaining changes can be replicated. An unplanned failover is used when the primary is unavailable and can result in data loss based on the last replicated state.
Post-failover validation
Validate DNS, application dependencies, IP configuration, monitoring, backup protection and user access. Record the final role of each host so reverse replication can be planned correctly.
Useful commands
Get-VMReplication -VMName <VMName>
Get-VMReplicationStatistics -VMName <VMName>
Test-NetConnection <ReplicaHost> -Port 80What good troubleshooting looks like
Use evidence before configuration changes. Record the symptom, test result, change made and validation result so another engineer can repeat the procedure.
Symptom → hypothesis → direct test → controlled change → validation → documentation
Frequently asked questions
What should I check first?
Start with the exact failed path or dependency and test it directly before changing configuration.
Should I change production configuration immediately?
No. Capture the current state first and make one controlled change at a time.
How should I document the fix?
Record the symptom, commands, result, configuration change and validation result.
Related TechRunbook guides
Primary reference
This guide was independently written for TechRunbook. Technical details were checked against current Microsoft documentation. Microsoft Learn reference →
Need more infrastructure runbooks?
Explore the TechRunbook article library for Windows Server, VMware, Hyper-V, Azure, PowerShell and MABS troubleshooting.
Browse all articles →Explore more TechRunbook guides
Browse practical troubleshooting guides, PowerShell scripts, checklists and infrastructure resources for your environment.
Browse all articles →