Hyper-V Replica is the disaster recovery feature a lot of small and mid-size shops already own and never turn on. It ships with the Hyper-V role in Windows Server, costs nothing extra, and keeps an up-to-date copy of a running VM on a second host. If the primary host dies, you bring the replica online and you’re back in business.
What it isn’t: synchronous mirroring, a backup, or magic. It copies changes on an interval — 30 seconds at the tightest — so a failover from a dead primary can lose the last chunk of writes. Understanding that trade-off up front saves you from expecting more than it delivers.
This walks through the whole path: prepping the Replica server, enabling replication on a VM, running the three kinds of failover, and fixing the errors that stop most people on their first attempt. Steps target Windows Server 2016 and later (2019, 2022, 2025); the workflow has been stable across those releases.
How Hyper-V Replica works
There’s a primary VM running on one host and a replica VM sitting powered-off on another host.
When you enable replication, Hyper-V does an initial copy of the VM’s virtual disks to the
replica. After that, it tracks every write in a log file (an .hrl file alongside each VHDX)
and ships those changes to the replica on the interval you picked.
The replica stays off until you fail over. It’s a cold copy that’s kept warm — disks current to within your interval, ready to boot.
The two roles in a replication relationship
| Primary server | Hosts the live VM. Sends changes. |
|---|---|
| Replica server | Hosts the offline copy. Receives changes. Must be enabled to accept replication first. |
| Replication interval | 30 seconds, 5 minutes, or 15 minutes — your recovery point objective. |
| Authentication | Kerberos/HTTP on port 80 (domain) or certificate/HTTPS on port 443 (workgroup/untrusted). |
| Recovery points | Latest only, or multiple snapshots so you can roll back to an earlier state. |
No cluster, no SAN, no matched hardware. Each host keeps the VM on its own storage. That’s why Replica fits a two-server branch office as comfortably as a datacenter.
Before you start
A few things need to be true on both hosts, or the wizard fails in ways that aren’t always obvious.
Prerequisites on both hosts
- Hyper-V role installed and the same or compatible Windows Server version
- Network connectivity between the hosts on port 80 (Kerberos) or 443 (certificate)
- Time in sync — large clock skew breaks Kerberos auth
- Enough storage on the Replica host for the VM plus recovery points
- Decided authentication type: domain (Kerberos) or workgroup/untrusted (certificate)
- Firewall rules ready to enable for the replication listener
Step 1: Configure the Replica server
Do this on the destination host — the one that will hold the copy. In Hyper-V Manager, open Hyper-V Settings → Replication Configuration, tick Enable this computer as a Replica server, choose your authentication, and set where replica files land.
The PowerShell version is faster and scriptable. For a domain environment using Kerberos:
# Run on the REPLICA (destination) host
Set-VMReplicationServer `
-ReplicationEnabled $true `
-AllowedAuthenticationType Kerberos `
-ReplicationAllowedFromAnyServer $true `
-DefaultStorageLocation "D:\Replicas"Then open the firewall rule that lets replication traffic in. The built-in rules already exist; you just enable the right one for your auth type:
# Kerberos / HTTP (port 80)
Enable-NetFirewallRule -DisplayName "Hyper-V Replica HTTP Listener (TCP-In)"
# Certificate / HTTPS (port 443) — use this one instead for workgroup/untrusted hosts
Enable-NetFirewallRule -DisplayName "Hyper-V Replica HTTPS Listener (TCP-In)"If you scope replication to specific primary servers instead of allowing any, you add an authorization entry per source and point it at a storage location:
New-VMReplicationAuthorizationEntry `
-AllowedPrimaryServer "host01.contoso.com" `
-ReplicaStorageLocation "D:\Replicas" `
-TrustGroup "BranchOffice"Step 2: Enable replication on the VM
Back on the primary host, right-click the VM and choose Enable Replication, or use PowerShell. Point it at the Replica server, set the auth type and port, and choose the interval.
# Run on the PRIMARY host
Enable-VMReplication -VMName "FS01" `
-ReplicaServerName "replica01.contoso.com" `
-ReplicaServerPort 80 `
-AuthenticationType Kerberos `
-ReplicationFrequencySec 300
# Kick off the initial copy now, over the network
Start-VMInitialReplication -VMName "FS01"ReplicationFrequencySec takes 30, 300, or 900 — the 30-second, 5-minute, and 15-minute
options. The initial replication is the heavy part; it copies the full VHDX. On a slow WAN link
you can export the VM to a USB disk and seed the replica from that instead of saturating the
line, then Hyper-V only ships changes from then on.
Once initial replication finishes, check health:
Get-VMReplication -VMName "FS01" | Format-List State, Health, LastReplicationTime, ReplicationFrequencySecYou want State: Replicating and Health: Normal. A warning state usually means the VM has fallen behind its interval — common right after setup or on a congested link.
This is also a good moment to make sure the replica VM lands on a switch that actually exists on the destination host. If the network names differ between sites, plan to map them — a replica that boots onto a missing switch comes up with no connectivity, the same way a misconfigured external virtual switch leaves a VM stranded.
Step 3: Test failover (do this first, and often)
Test failover is the safe one. It spins up an isolated, read-only copy of the replica — named with a ”- Test” suffix — without disturbing the primary or the ongoing replication. You boot it, confirm the OS and apps come up, then throw it away.
# Run on the REPLICA host
Start-VMFailover -VMName "FS01" -AsTest
# ...verify the test VM boots and apps work...
# Clean up the test copy
Stop-VMFailover -VMName "FS01"The test VM is not connected to your production network by default, which is exactly what you want — no IP conflicts, no duplicate domain controllers talking to live clients. Run this monthly. A replica you’ve never test-failed-over is a replica you’re only hoping works.
Step 4: Planned vs unplanned failover
The two real failovers are very different events.
Planned failover is for maintenance or a controlled site move. You run it from the primary while it’s still healthy. Hyper-V replicates the final outstanding changes, then brings the VM up on the replica with zero data loss. The primary VM has to be shut down first.
# 1) On the PRIMARY: shut the VM down
Stop-VM -Name "FS01"
# 2) On the PRIMARY: planned failover sends the last changes
Start-VMFailover -VMName "FS01" -Prepare
# 3) On the REPLICA: complete the failover and start the VM
Start-VMFailover -VMName "FS01"
Start-VM -Name "FS01"
# 4) On the REPLICA: reverse replication so the old primary becomes the new replica
Set-VMReplication -VMName "FS01" -ReverseUnplanned failover is for when the primary is already gone — host dead, site down. You run it from the replica, and you accept that any changes that hadn’t replicated yet are lost. If you kept multiple recovery points, you can choose to come up on the latest or roll back to an earlier one.
# Run on the REPLICA host when the primary is unavailable
Start-VMFailover -VMName "FS01"
Start-VM -Name "FS01"After any real failover, the relationship is “broken” until you re-establish it. Reverse
replication (the -Reverse step above) flips the roles so the now-live host replicates back to
the recovered one, ready to fail back later.
Common problems and how to fix them
Most Replica failures cluster around a handful of causes. Here’s the short diagnostic path.
Enabling replication fails immediately. Almost always the Replica server isn’t enabled to receive replication, or its listener firewall rule is off. Re-check Step 1 on the destination. Confirm the port matches the auth type — 80 for Kerberos, 443 for certificate.
Authentication / certificate errors. Kerberos needs both hosts in the same or trusted AD domains with synced clocks. For workgroup hosts or cross-forest, switch to certificate auth and make sure each host trusts the other’s certificate. Mismatched auth type is the classic mistake — picking Kerberos for two workgroup servers can’t work.
Replication health shows Warning and the VM is “behind”. The link can’t keep up with the change rate, or there was a transient outage. Resume replication and let it catch up:
Resume-VMReplication -VMName "FS01"If it’s chronically behind, the interval is too aggressive for the bandwidth — move from 30 seconds to 5 minutes, or seed/reseed over a faster path.
Replica disk is filling up. Multiple recovery points each keep a differencing disk on the replica side. More recovery points means more storage. Trim the number of recovery points in the VM’s replication settings if the destination is tight on space — this is the same differencing-disk growth that bites people with Hyper-V checkpoint files, just on the replica.
Resynchronization keeps running. A resync recomputes differences between primary and replica and is I/O heavy. Schedule resync for off-hours in the VM’s replication settings, and investigate why it triggered — usually an unclean shutdown or a storage hiccup on one side.
Quick error-to-cause map
| Can't enable replication | Replica server not enabled / listener firewall rule off |
|---|---|
| Auth or certificate failure | Wrong auth type for the trust, clock skew, or untrusted cert |
| Health: Warning, VM behind | Link can't keep up — resume, or lengthen the interval |
| Replica storage filling | Too many recovery points — reduce the count |
| Repeated resynchronization | Unclean shutdown or storage error — schedule resync off-hours |
A note on what Replica is for
Keep the boundary clear: Replica is disaster recovery, not backup. It gives you a second copy you can run when a host or site fails. It does not protect you from a deleted file, a bad change, or ransomware — those replicate right along with everything else unless you’re catching them in an older recovery point. The same lesson that applies to VMware snapshots, which are not backups applies here: a live or near-live copy is not an independent, restorable backup. Run both.
Wrapping up
Hyper-V Replica earns its keep for branch offices and small datacenters that need a recovery option without the cost of a cluster or array-based replication. Enable the Replica server first, open the matching listener, enable replication on the VM, and — this is the part people skip — test failover on a schedule so you trust it when it counts.
Pick your interval honestly against the link you have and the data loss you can stomach. Use planned failover for maintenance, unplanned only when the primary is truly gone, and reverse replication afterward so you can fail back cleanly. For more on building out the host side, browse the rest of the virtualization guides.
