A practical Hyper-V Replica runbook for replication health, authentication, recovery points, test failover and planned failover.
01

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.

02

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.

03

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.

04

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.

05

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.

06

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 80
Production checklist: capture the original state, test one dependency at a time, make the smallest controlled change and validate the original symptom before closing the incident.
07

What 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.

Workflow
Symptom → hypothesis → direct test → controlled change → validation → documentation
08

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.

09
10

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 →
TechRunbook · Practical infrastructure knowledge, ready when it matters.