How to Set Up Hyper-V Replica Between Two Windows Servers

What Hyper-V Replica does and what you need first

Hyper-V Replica keeps an offline, slightly out-of-date copy of a virtual machine on a second Hyper-V host and tops it up every 30 seconds, 5 minutes or 15 minutes, as you choose. If the first host is lost, you start the copy on the second. That is the whole trick, and it is a good one, provided you are clear about its limits.

It is disaster recovery, not backup. The replica receives every change the primary makes, including accidental deletions, corruption and ransomware encryption, so damage is carried across on a following replication cycle. The optional recovery points (up to 24 hourly ones) let you step back a day at most, and only if you switched them on. Keep independent backups as well.

Failover is not automatic. There is no night watchman: if the primary falls over at 3am, the replica sits there powered off and patient until a person (or a script you wrote) decides to fail over. That differs from a failover cluster, which restarts VMs on another node by itself. Replica is built for the case where the whole host or site is gone, and it accepts a small, defined amount of data loss in return.

This guide uses Hyper-V Manager, which is what most small environments run day to day. Windows Admin Center - Virtualization mode can also do this job, but Microsoft currently labels its Hyper-V Replica support as preview, so we have left it out. We also cover single hosts only, not clusters (which add a Hyper-V Replica Broker role).

• Two hosts running Windows Server with the Hyper-V role. Replica is not available in Hyper-V on Windows client operating systems.
• An account in the Hyper-V Administrators group, or a local administrator, on both hosts.
• A network path from the primary to the replica on TCP 80 (Kerberos) or TCP 443 (certificates), through every firewall in between. Reverse replication later needs the same path in the opposite direction.
• Enough storage on the replica host for the VM files plus any extra recovery points you choose to keep.
• A decision on how the two hosts will prove who they are to each other, which is the next section.

Choose Kerberos or certificates, and get the names right

Kerberos (shown in the wizard as HTTP) is the simple option when both hosts are joined to the same Active Directory domain or to domains that trust each other. It uses port 80 by default. Microsoft positions it for cases where you do not need the replication traffic encrypted, so on a private link between your own sites it is fine. Our judgement: if replication will cross a network you do not control, use certificates (or a VPN) rather than relying on Kerberos alone.

Certificate-based authentication (HTTPS, port 443 by default) is required if either host is in a workgroup or an untrusted domain, and it is the way to get encrypted replication traffic. Each host, sending and receiving, needs a computer certificate in its local machine Personal store. Microsoft's requirements are that the certificate has not expired, carries both Client Authentication and Server Authentication Enhanced Key Usage (EKU) entries with a private key, ends at a valid root certificate, and has a subject common name or subject alternative name matching the host's fully qualified domain name (FQDN). In practice that means the root certificate of whichever CA issued them must also be trusted on the other host. With certificates there is no Active Directory dependency, so workgroup hosts are fine.

Names are where first attempts most often go wrong. You will type the replica host's FQDN into the wizard, so the primary has to resolve it, and with certificates it has to match what the certificate says. Domain-joined hosts get this from AD DNS. Workgroup hosts share no DNS, so create records for both hosts in whatever DNS they do use, or add entries to the hosts file on each machine. Do it in both directions, because failback needs the replica to find the primary again.

These two checks are read-only. Run the first on the primary host to confirm the replica's name resolves. Run the second on each host that will use certificates, to list the certificates in the local machine store and check expiry, names and key usage.

Resolve-DnsName YOUR_REPLICA_FQDN

Get-ChildItem Cert:\LocalMachine\My | Format-List Subject, Thumbprint, NotAfter, DnsNameList, EnhancedKeyUsageList

Prepare both hosts to receive replication

Replication is configured on the receiving host, so start with the host that will hold the replica. Do the same on the primary afterwards, otherwise you will have nowhere to fail back to. Nothing in this section touches a running VM.

The Hyper-V role creates firewall rules for replication but leaves them disabled, so a freshly configured host looks fine and then refuses every connection. Enable the rule that matches your authentication method: the HTTP listener for Kerberos or the HTTPS listener for certificates. If there is a hardware firewall or other security product between the sites, it needs the same port opened.

If you would rather script the host settings than click through steps 1 to 5, the commands below do the equivalent in an elevated PowerShell session on the receiving host. They choose the broader option, accepting replication from any authenticated server, so tighten that in Hyper-V Settings afterwards. Run only the block that matches your authentication method, and replace the capitalised placeholders. The firewall and test steps still apply.

# Kerberos: accept replication from any authenticated server over port 80
Set-VMReplicationServer -ReplicationEnabled $true -AllowedAuthenticationType Kerberos -ReplicationAllowedFromAnyServer $true -DefaultStorageLocation 'YOUR_REPLICA_STORAGE_FOLDER'

# Certificates: accept replication from any authenticated server over port 443
Set-VMReplicationServer -ReplicationEnabled $true -AllowedAuthenticationType Certificate -CertificateThumbprint YOUR_CERTIFICATE_THUMBPRINT -ReplicationAllowedFromAnyServer $true -DefaultStorageLocation 'YOUR_REPLICA_STORAGE_FOLDER'

1. On the receiving host, open Hyper-V Manager, select the host and choose Hyper-V Settings in the Actions pane.
2. Under Server, select Replication Configuration and tick Enable this computer as a Replica server.
3. Under Authentication and ports, choose Use Kerberos (HTTP) or Use certificate-based authentication (HTTPS). For certificates, select Select Certificate and pick this host's certificate. Leave the default ports unless something else already uses them.
4. Under Authorization and storage, we suggest Allow replication from the specified servers. Select Add, then in Add Authorization Entry enter the primary host's FQDN, a storage location with room for the replica VM files and any extra recovery points, and a trust group. The trust group is just a free-text label for grouping primary servers. Choosing Allow replication from any authenticated server is quicker but accepts any server that can authenticate.
5. Select OK, then enable the matching Windows Firewall rule on this host from an elevated PowerShell session. Run only the line for your authentication method.
   powershellCopy

   # Kerberos (HTTP, port 80) - run only if you chose Kerberos
   Enable-NetFirewallRule -DisplayName 'Hyper-V Replica HTTP Listener (TCP-In)'

   powershellCopy

   # Certificates (HTTPS, port 443) - run only if you chose certificates
   Enable-NetFirewallRule -DisplayName 'Hyper-V Replica HTTPS Listener (TCP-In)'

6. Repeat steps 1 to 5 on the other host. Both hosts now accept replication, which is what makes failback possible.
7. From the primary host, run the connection test for your authentication method. For certificates, use the thumbprint of the primary host's own certificate from the listing in the previous section. A successful test returns the message: The connection to the specified Replica server with the specified parameters was successful. If it fails, jump to the troubleshooting section before going further.
   powershellCopy

   Test-VMReplicationConnection -ReplicaServerName 'YOUR_REPLICA_FQDN' -ReplicaServerPort 80 -AuthenticationType Kerberos

   powershellCopy

   Test-VMReplicationConnection -ReplicaServerName 'YOUR_REPLICA_FQDN' -ReplicaServerPort 443 -AuthenticationType Certificate -CertificateThumbprint YOUR_PRIMARY_CERTIFICATE_THUMBPRINT

Enable replication for a VM and let the first copy finish

Replication is switched on per VM, from the primary host. The wizard is where you make the two decisions that matter: how much data you can stand to lose (the replication frequency, which sets your recovery point objective or RPO) and how far back you want to be able to step (the recovery points). Both are explained in the steps below.

The initial copy is the slow part. Its duration depends on the size of the VM and the speed of the link, and Microsoft gives no figure. As rough arithmetic only: 100 GB is about 800,000 megabits, so even a perfect 100 Mbit/s link needs a little over two hours, and real links rarely manage perfect. Large VMs are better scheduled out of hours, or seeded from external media. The VM keeps running throughout, but the copy takes real bandwidth.

The PowerShell equivalent of the wizard is below. It sets a 5 minute interval, four extra hourly recovery points and compression, which are example values to adjust. Use the second block instead if you chose certificates. The monitoring and network steps afterwards still apply.

# Kerberos example. Run on the primary host in an elevated session.
$parameters = @{
    VMName = 'YOUR_VM_NAME'
    ReplicaServerName = 'YOUR_REPLICA_FQDN'
    ReplicaServerPort = 80
    AuthenticationType = 'Kerberos'
    ReplicationFrequencySec = 300
    RecoveryHistory = 4
    CompressionEnabled = $true
}
Enable-VMReplication @parameters
Start-VMInitialReplication -VMName 'YOUR_VM_NAME'

# Certificate example. Run on the primary host in an elevated session.
$parameters = @{
    VMName = 'YOUR_VM_NAME'
    ReplicaServerName = 'YOUR_REPLICA_FQDN'
    ReplicaServerPort = 443
    AuthenticationType = 'Certificate'
    CertificateThumbprint = 'YOUR_PRIMARY_CERTIFICATE_THUMBPRINT'
    ReplicationFrequencySec = 300
    RecoveryHistory = 4
    CompressionEnabled = $true
}
Enable-VMReplication @parameters
Start-VMInitialReplication -VMName 'YOUR_VM_NAME'

1. On the primary host, open Hyper-V Manager, right-click the VM and choose Enable Replication. If you see Before You Begin, select Next.
2. On Specify Replica Server, enter the replica host's FQDN and select Next. The wizard contacts the host to read its authentication and port settings, so an error here usually points at DNS, the firewall rule or a mismatch in authentication type.
3. On Specify Connection Parameters, check the authentication type and port. For certificates, select Select Certificate and choose the primary host's certificate. Tick the compression option to reduce bandwidth, which we would leave on in most cases. Select Next.
4. On Choose Replication VHDs, untick any disk whose contents you would not need after a failover, such as a dedicated page file or temp disk. Never untick the disk holding the operating system, because the replica would not start. Select Next.
5. On Configure Replication Frequency, choose 30 seconds, 5 minutes or 15 minutes. This is the longest you are prepared to lose recent changes. Shorter intervals lose less but generate more traffic and more work on the replica. Five minutes is the default and a sensible start; pick the shortest interval your link can keep up with at its busiest.
6. On Configure Additional Recovery Points, choose Maintain only the latest recovery point or Create additional hourly recovery points (up to 24). Latest-only means a failover always lands on the newest state, even if that state is damaged. A handful of hourly points gives you a few earlier states to fall back on, at the cost of more storage and disk activity on the replica. For applications such as SQL Server, also consider ticking Volume Shadow Copy Service (VSS) snapshot frequency so that points are application-consistent. Select Next.
7. On Choose Initial Replication, the default is Send initial copy over the network, and the wizard shows the total size. The alternatives are Send initial copy using external media or Use an existing virtual machine on the Replica server as the initial copy. Network and existing-VM copies can start immediately or at a set time up to seven days ahead. Select Next.
8. Review the summary and select Finish. The success dialog confirms replication is enabled, not that the copy has finished.
9. Watch progress from the primary host. Right-click a column heading in the VM list, choose Add/Remove Columns and add Replication Health. For detail, right-click the VM, choose Replication, then View Replication Health. The first copy is finished when health reads Normal and the last synchronised time keeps up with your chosen interval. Normal means cycles complete on schedule; Warning means it works but is lagging; Critical means it has stalled.
   powershellCopy

   Get-VMReplication -VMName 'YOUR_VM_NAME'
   Measure-VMReplication -VMName 'YOUR_VM_NAME'

10. When the first copy is done, open the settings of the replica VM on the replica host and connect its network adapter to a virtual switch, because replicas are created with no network connection. If the replica site uses different IP addressing, also set Failover TCP/IP under Network Adapter in the same settings window, which injects a static address when the VM starts after failover. That needs synthetic network adapters and up-to-date integration services in the guest. Later changes to the primary VM's memory, processors or network adapters are not copied across automatically, so update the replica by hand or remove and re-enable replication.

Run a test failover

A test failover is the safe rehearsal, and the one you should do first and repeat regularly. You run it on the replica host. Hyper-V builds a temporary copy of the replica VM from the recovery point you choose, named after the original with - Test on the end, while the primary VM and ongoing replication carry on untouched. Only one test failover can run per VM at a time.

The test copy is not connected to any network by default, and that is deliberate. In our experience of how servers behave, a second live copy of the same machine on the production network invites duplicate names, duplicate IP addresses and confused domain membership, so do not plug it into the live LAN. If you need to test network-dependent applications, create a private virtual switch and point the VM's test network at it first (step 1 is optional for this reason).

Testing proves that the replica boots and the data is intact. It does not prove the surrounding recovery plan, such as DNS, firewall rules, user access and application dependencies, so use the test to check those too.

1. Optional: on the replica host, create a private switch and set it as the test network for the replica VM. This changes the replica VM's settings only. The private switch connects test VMs to each other and nothing else.
   powershellCopy

   New-VMSwitch -Name 'ReplicaTest' -SwitchType Private
   Set-VMNetworkAdapter -VMName 'YOUR_VM_NAME' -TestReplicaSwitchName 'ReplicaTest'

2. Still on the replica host, open Hyper-V Manager, right-click the replica VM, choose Replication and then Test Failover.
3. On the Test Failover screen, choose the recovery point from the drop-down and select Test Failover. The latest point is used unless you pick another.
   powershellCopy

   Start-VMFailover -VMName 'YOUR_VM_NAME' -AsTest

4. Find the new VM named with - Test appended, start it and open its console. Check that it boots, that services and applications start, and that recent data is present up to roughly your replication interval.
   powershellCopy

   Start-VM -Name 'YOUR_VM_NAME - Test'

5. When you are done, right-click the replica VM itself, not the test copy, choose Replication and then Stop Test Failover, and confirm. This deletes the test VM and discards everything written to it. Check that the test VM has gone and that the replica's health is still Normal.
   powershellCopy

   Stop-VMFailover -VMName 'YOUR_VM_NAME'

Planned failover: moving a VM on purpose

Use a planned failover when you can take the primary VM down deliberately, for example before site maintenance, when moving a workload, or to practise a full recovery. The primary is shut down, any remaining changes are sent across, and the replica takes over with no data loss.

The impact is real: the VM is offline from shutdown until the replica is running, and users lose that service in between. Pick a quiet window and tell people. You need Hyper-V Administrator or local administrator rights on both hosts, and replication health should read Normal before you begin. For the reverse step to work, the original primary must also be set up to receive replication, which you did earlier.

The PowerShell route in step 5 replaces steps 2 to 4. It involves both hosts, so the commands are split by host. Start-VMFailover asks you to confirm.

1. Confirm replication health is Normal and that you are happy for the VM to be offline for a while.
2. On the primary host, shut down the VM. A planned failover will not run against a running VM.
3. Still on the primary host, right-click the VM, choose Replication and then Planned Failover. Tick Reverse the replication direction after failover, and tick Start the Replica virtual machine after failover if you want it to boot straight away. The dialog lists the prerequisite checks it performs. Select Fail Over.
4. On the replica host, which now holds the live copy, connect the VM's network adapter to a virtual switch if you have not done so, and start the VM if it is not already running.
5. PowerShell alternative to steps 2 to 4: run the first block on the primary host, then the second block on the replica host.
   powershellCopy

   # On the primary host
   Stop-VM -Name 'YOUR_VM_NAME'
   Start-VMFailover -VMName 'YOUR_VM_NAME' -Prepare

   powershellCopy

   # On the replica host
   Start-VMFailover -VMName 'YOUR_VM_NAME'
   Set-VMReplication -VMName 'YOUR_VM_NAME' -Reverse
   Start-VM -Name 'YOUR_VM_NAME'

6. Check the result: the VM should be running on the new host and your users or applications should be able to reach it. Once reverse replication is running, replication health returns to Normal, now flowing from the new host back to the old one. To return to the original arrangement, repeat the same planned failover from the new primary.

Unplanned failover and reverse replication

An unplanned failover is for when the primary is genuinely unavailable, such as after a power failure, a dead host or a lost site. You run it on the replica host. The replica starts from a recovery point, and anything the primary had not yet replicated is lost. It is the one that matters in a real emergency, and the one most worth rehearsing with a test failover first.

Because nothing automatic decides this, someone has to. Agree in advance who makes the call and how they confirm the primary is truly down. This is our engineering judgement rather than a Microsoft requirement: Hyper-V starts the replica without shutting the primary down, so if the primary is merely unreachable rather than dead, you can end up with two live copies of one server. Power off or isolate the original before the replica goes onto the network.

Two steps below are one-way. Remove Recovery Points merges the replica and discards its earlier points, and reverse replication turns the original VM into the target that receives changes. Export the replica first if you want to keep earlier points, and copy off anything you need from the old primary that was never replicated.

The PowerShell alternatives sit under the relevant steps. In PowerShell, Start-VMFailover creates the checkpoint but does not start the VM, so you start it yourself.

1. Confirm the primary is down or isolated, and decide which recovery point to use. The latest is the default.
2. On the replica host, right-click the replica VM, choose Replication and then Failover.
3. On the Failover screen, choose the recovery point from the drop-down and select Fail Over. Hyper-V creates a checkpoint on the replica VM and starts it.
   powershellCopy

   # On the replica host
   Start-VMFailover -VMName 'YOUR_VM_NAME'
   Start-VM -Name 'YOUR_VM_NAME'

4. Connect the network adapter to a virtual switch if needed, then check that the VM and its applications are healthy. If the recovery point looks wrong, right-click the replica VM, choose Replication and then Cancel Failover, and start again with a different point.
5. When you are satisfied, right-click the replica VM, choose Replication and then Remove Recovery Points. This completes the failover. Replication health now shows Warning, which is expected because no replication direction is configured yet.
   powershellCopy

   # On the replica host, once satisfied
   Complete-VMFailover -VMName 'YOUR_VM_NAME'

6. When the original host is back, prepare the original VM to receive replication. Hyper-V Manager cannot do this part, so run the command on the original primary host in an elevated session. The check afterwards should show ReplicationMode as Replica and ReplicationState as WaitingForInitialReplication.
   powershellCopy

   # On the original primary host
   Set-VMReplication -VMName 'YOUR_VM_NAME' -AsReplica
   Get-VMReplication -VMName 'YOUR_VM_NAME' | Format-List VMName, ReplicationMode, ReplicationState

7. On the host now running the VM, right-click it, choose Replication and then Reverse Replication. The wizard is pre-filled from the original settings, so select Next through the pages unless you want to change something, then Finish. Replication health returns to Normal once changes flow back to the original host. To go back to the original roles later, do a planned failover.
   powershellCopy

   # PowerShell alternative to the wizard, on the host now running the VM
   Set-VMReplication -VMName 'YOUR_VM_NAME' -Reverse -ReplicaServerName 'YOUR_ORIGINAL_HOST_FQDN'
   Start-VMInitialReplication -VMName 'YOUR_VM_NAME'
   Get-VMReplication -VMName 'YOUR_VM_NAME' | Format-List VMName, ReplicationMode, ReplicationState

If it does not work

Start with Test-VMReplicationConnection from the primary host. It separates network and authentication problems from VM problems quickly, and most first-time failures are in the first group.

• The wizard cannot reach the replica, or reports that Hyper-V failed to authenticate the replica server using Kerberos (error 0x00002EFE): check that the firewall rule is enabled on the replica host (they ship disabled), that any firewall between the sites allows the port, that the replica is set to the same authentication type you chose, and that the FQDN resolves from the primary. For Kerberos, both hosts must be in the same or trusted domains.
• Certificate authentication fails: re-run the certificate listing from earlier on both hosts and check the certificate has not expired, has a private key, carries both Client Authentication and Server Authentication EKU entries, chains to a root the other host trusts, and has a name matching the FQDN you are connecting to.
• Enabling replication fails with The parameter is incorrect (0x80070057): Microsoft lists this among common errors. Recheck the wizard values, in particular that the port matches the authentication type the replica is configured for, and that the replica storage path exists and is accessible.
• Health shows Warning or Critical on a replication that used to work: Warning is usually lag from network or storage load, while Critical means it has stalled. Check bandwidth, free space on both hosts and the Hyper-V-VMMS Admin event log. Watch free space on the primary in particular, because change-tracking log files (HRL files) grow while replication is stalled. If the state is Resynchronization Required, a resync is heavy on storage and processing, so run it off-peak.
• The test failover will not start: only one test failover can run per VM, so stop any earlier one with Stop Test Failover on the replica VM.
• Reverse replication is unavailable after an unplanned failover: the original VM has not yet been marked as a replication target. Run Set-VMReplication with -AsReplica on the original primary host first.
• The replica VM starts without a network, or with outdated settings: adapters are not connected on a new replica, and configuration changes made later on the primary are not copied across automatically.

Final working checklist

Tick these off and you have a replication setup you can trust, rather than one that merely shows a green icon.

• Both hosts are enabled as Replica servers, with the same authentication method, and the matching firewall rule is enabled on both (and on any firewall between them).
• Each host resolves the other's FQDN, and any certificates are valid, trusted and name-matched.
• Test-VMReplicationConnection succeeds in the direction you will actually use.
• Each protected VM shows health Normal, with a last synchronised time that keeps pace with the interval you chose.
• Excluded disks, the replication frequency and the number of recovery points were chosen deliberately.
• The replica VM's network adapter is connected to a switch, failover addressing is set if the replica site differs, and any test network is isolated.
• You have run a test failover, looked at the result and cleaned it up with Stop Test Failover.
• You have practised a planned failover and reversed it, or have a date for doing so.
• Someone owns the decision to run an unplanned failover and knows how to confirm the primary is really down.
• Independent backups exist, are not stored on the replica host, and have had a test restore, because replication is not a backup.