Hyper-V Replica Stuck at 'Pending' – Fix in 2 Steps

You're staring at 'Pending' for hours. I've been there. Let's skip the frustration and get it syncing.

The Fix

Check the authentication certificate. On the primary host, open PowerShell as Admin and run:
```
Get-VMReplicationServer | fl *
```
Look for CertificateAuthentication. If it's True, get the cert thumbprint:
```
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*Replica*" } | Select-Object Thumbprint
```
If the cert is expired (check NotAfter), delete it and let Hyper-V recreate it:
```
Remove-Item Cert:\LocalMachine\My\<thumbprint>
Restart-Service vmms
```
Then on the replica host, run the same get command to verify a new cert appears. Wait 2 minutes – the 'Pending' should change to 'Synced' if the cert was the issue.
Reduce the replication group size. If certs are fine, the next culprit is the replication group. Open Hyper-V Manager, right-click the VM → Replication → View Replication Health. Look at 'Average Latency' and 'Replication Group Size' (default is 15 minutes). If latency is over 10 seconds with a large group, the host is choking. Change the group size to 5 minutes:
```
Set-VMReplication -VMName "YourVM" -ReplicationFrequencySec 300
```
After this, replication restarts automatically. Check after 5 minutes.

Why This Works

What's actually happening here is that Hyper-V Replica uses certificates to authenticate between hosts. If that cert expires, the primary host can't encrypt or send data. The replica sits in 'Pending' because it never receives the initial handshake. Deleting the cert forces VMMS to create a new one. The reason step 1 works is that the new cert gets automatically trusted by both hosts when you restart the service.

The replication group size matters because Hyper-V batches changes into groups. With the default 15-minute group, a VM that changes a lot (like a database server) generates a huge delta. If the network can't push that in 15 minutes, the next group starts queuing. Stuff piles up, and you see 'Pending'. Dropping to 5 minutes makes each batch smaller, so it gets through before the next one arrives. It's like splitting a big truckload into small vans – each van finishes faster.

Less Common Variations

Port 443 blocked by firewall

If you're using Kerberos or a proxy, Hyper-V Replica defaults to port 443. I've seen admins who open inbound but forget outbound. Check both sides. On the primary host:

Test-NetConnection replica-host -Port 443

If it fails, add an outbound rule on the primary and inbound on the replica. Kerberos auth doesn't need certs, but it does require both hosts in the same domain.

Disk space full on replica

Another case: the replica host's storage is at 99%. Hyper-V Replica won't write a single block. Check with:

Get-Volume | Where-Object { $_.DriveType -eq 'Fixed' } | Select-Object DriveLetter, SizeRemaining

If any drive is under 1 GB free, free up space. The replication stays 'Pending' until you do.

Time skew between hosts

Hyper-V Replica uses timestamps in the auth handshake. If the clocks differ by more than 5 minutes, the cert verification fails silently. Run:

w32tm /stripchart /computer:replica-host /samples:3 /dataonly

If offset is over 300 seconds, sync time with w32tm /resync on both hosts.

Prevention

Set a reminder for cert expiry. Hyper-V Replica certs last one year by default. Create a scheduled task that checks every 10 months:

$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*Replica*" }
if ($cert.NotAfter -lt (Get-Date).AddMonths(2)) { Write-Host "Renew needed" }

Keep replication group size short. For VMs with heavy write workloads, I set 5 minutes from day one. It saves you later.
Monitor replica latency. Use Get-VMReplicationHealth every hour. If average latency goes above 5 seconds, investigate network or storage.

That's it. You should see 'Synced' within minutes after the fix. If not, check the Hyper-V-VMMS event log – it usually tells you exactly why.