Diagnose Hyper-V Replication Critical or Paused State

Problem and takeaway

A virtual machine protected by Hyper-V Replica shows ReplicationHealth as Critical or Warning, and ReplicationState is Paused, Resynchronization Required, or stuck in Initial Replication. The replica is not receiving changes, so a failover would lose recent data.

Takeaway: check the replication network path and certificate trust first, then storage latency and checkpoint chains on the replica. Only resume or resynchronize after the underlying condition is corrected.

Recognizable conditions and likely causes

Condition seen in Hyper-V Manager or PowerShell	Most likely cause area
ReplicationHealth = Critical; ReplicationState = Paused	Blocked replication port or expired certificate trust
ReplicationState = Resynchronization Required	Replication log grew too large or source changed-block volume spiked
Initial Replication stuck at a percentage for hours	Network throughput, storage latency, or certificate authentication failure
ReplicationHealth = Warning with frequent state changes	High storage latency or long differencing disk chain on the replica

Check 1: Confirm replication state on both hosts

Run this on both the primary and replica Hyper-V hosts. You need membership in the local Hyper-V Administrators group or equivalent administrator rights.

Get-VMReplication -VMName "VM01" | Select-Object ReplicationState, ReplicationHealth, LastReplicationTime

Expected check: both hosts should show the same VM name. If the primary shows Replicating but the replica shows Paused, the inbound path on the replica is the likely problem. This command is read-only and carries no state-change risk.

Check 2: Test the replication network port

Hyper-V Replica typically uses TCP 443 for certificate-based replication, or a custom port if you configured one. Run this from the primary host:

Test-NetConnection -ComputerName "REPLICA01" -Port 443

Required permissions: administrator or a user allowed to run network diagnostics. Expected result: TcpTestSucceeded is True. If False, a firewall, network security group, or host-based rule is blocking the path. Correct the rule, then re-run the test before touching replication settings.

Check 3: Verify certificate trust, if used

If you configured certificate-based replication, an expired or untrusted certificate on either host causes authentication failures. Check the replication certificate on both primary and replica hosts. Renew or re-establish the trust if the certificate has expired, then proceed to the resume step.

Check 4: Inspect replica storage and checkpoint chain

A checkpoint is a point-in-time save of a virtual machine's state and data. Each retained checkpoint adds a differencing disk layer that replication must track. A long chain on the replica VM can block replication progress.

On the replica host, review the VM's checkpoints in Hyper-V Manager. If several checkpoints exist, especially ones taken before the replication issue started, they are a likely contributor. Also check storage latency on the volume holding the replica virtual hard disks; sustained high latency slows changed-block processing.

Fix: network or certificate finding

1. Open the required replication port on the replica host firewall or network security group.
2. Renew expired certificates and re-establish the replication trust if certificate-based authentication is in use.
3. On the primary host, resume replication:

Resume-VMReplication -VMName "VM01"

Required permissions: Hyper-V administrator. Risk: resuming on a large VM during business hours can saturate the replication link and degrade production workload performance. Schedule this during low-usage periods if the VM is busy.

Fix: storage or checkpoint finding

1. Move the replica virtual hard disks to a lower-latency volume if storage latency is the bottleneck.
2. Remove unneeded checkpoints during a maintenance window. Removing checkpoints merges differencing disks and causes temporary I/O spikes.
3. Start resynchronization on the primary host:

Start-VMReplication -VMName "VM01" -Resynchronize

Required permissions: Hyper-V administrator. Risk: resynchronization retransmits changed blocks and can saturate the network. Do not force it on large production VMs during business hours.

Escalation criteria

• ReplicationHealth remains Critical after network, certificate, storage, and checkpoint checks are complete.
• Resynchronization repeatedly fails with the same error across multiple attempts.
• Initial replication cannot complete despite valid network connectivity and trust.

Before engaging support, collect the Microsoft-Windows-Hyper-V-VMMS operational event log from both hosts and note the replication event IDs surrounding the failures.

Verification

After applying a fix, wait one or two replication cycles, then run:

Get-VMReplication -VMName "VM01" | Select-Object ReplicationState, ReplicationHealth, LastReplicationTime

Successful result: ReplicationState returns to Replicating and LastReplicationTime advances. Also review the Hyper-V-VMMS event log to confirm the error stopped recurring. If the state does not change, meet the escalation criteria above.

Limitations

• Default ports and trust behavior can differ between Windows Server Hyper-V and Hyper-V on Windows client. Confirm the target platform before applying commands.
• This guide covers common replication health issues. It does not address cluster shared volume failures, storage migration mid-replication, or guest operating system issues inside the VM.
• No command output shown here was captured from a live system; placeholders such as VM01 and REPLICA01 must be replaced with your actual values.