How to Set Up Hyper-V Replication on Windows Server 2019

March 23, 2026
Tutorials
Comment off

Introduction to Hyper-V Replication on Windows Server 2019

Hyper-V Replica is an asynchronous virtual machine replication feature built into Windows Server 2019 that continuously replicates VMs from a primary Hyper-V server to one or more replica servers. It provides a disaster recovery capability without requiring shared storage — each site has its own independent storage. In the event of a disaster or primary server failure, the replica can be brought online in minutes. Windows Server 2019 Hyper-V Replica supports three-point replication (primary, replica, extended replica), configurable replication intervals as short as 30 seconds, and application-consistent checkpoints using VSS. This guide covers enabling, configuring, monitoring, and failing over Hyper-V Replica.

Hyper-V Replica Architecture

Hyper-V Replica works by tracking changes to VM virtual hard disks (VHDs/VHDXs) in a log file and periodically transferring those changes to the replica server over HTTPS or Kerberos. The replica server maintains an exact copy of the VM’s disks, updated at the configured replication frequency. The replica VM exists in a saved/off state until a failover is initiated. During replication, only disk write operations are tracked — memory and CPU state are not replicated.

Prerequisites

# Verify Hyper-V is installed on both primary and replica servers
Get-WindowsFeature -Name Hyper-V | Select-Object Name, InstallState

# Both servers need network connectivity — test connectivity
Test-NetConnection -ComputerName "replica-server.corp.example.com" -Port 80
Test-NetConnection -ComputerName "replica-server.corp.example.com" -Port 443

Enable Hyper-V Replica on the Replica Server

First, configure the replica server to accept incoming replication requests. You can use Kerberos authentication (for domain-joined servers in the same domain) or certificate-based authentication (for workgroup servers or cross-domain replication):

# On the REPLICA server: enable Hyper-V Replica with Kerberos authentication
Set-VMReplicationServer `
    -ReplicationEnabled $true `
    -AllowedAuthenticationType Kerberos `
    -KerberosAuthenticationPort 80 `
    -ReplicationAllowedFromAnyServer $false `
    -DefaultStorageLocation "D:HyperVReplica"

# Allow replication only from the specific primary server
New-VMReplicationAuthorizationEntry `
    -AllowedPrimaryServer "primary-server.corp.example.com" `
    -ReplicaStorageLocation "D:HyperVReplica" `
    -TrustGroup "Default"

# Verify replica server configuration
Get-VMReplicationServer | Format-List

# Configure firewall rules on the replica server to allow replication traffic
# Kerberos uses port 80, HTTPS uses port 443
Enable-NetFirewallRule -DisplayName "Hyper-V Replica HTTP Listener (TCP-In)"
Enable-NetFirewallRule -DisplayName "Hyper-V Replica HTTPS Listener (TCP-In)"

# Or create a custom rule
New-NetFirewallRule `
    -DisplayName "Hyper-V Replica Kerberos" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 80 `
    -RemoteAddress "192.168.1.10" `
    -Action Allow

Enable Replication for a VM on the Primary Server

# On the PRIMARY server: enable replication for a specific VM
Enable-VMReplication `
    -VMName "WebServer01" `
    -ReplicaServerName "replica-server.corp.example.com" `
    -ReplicaServerPort 80 `
    -AuthenticationType Kerberos `
    -ReplicationFrequencySec 30 `
    -CompressionEnabled $true `
    -RecoveryHistory 2    # Number of recovery points to maintain

# Verify replication is configured
Get-VMReplication -VMName "WebServer01" | Format-List

Start Initial Replication

The first replication copies the full VHD/VHDX files to the replica server. This can be done over the network or, for large VMs, via exported media (USB/external drive) to seed the initial copy:

# Start initial replication over the network
Start-VMInitialReplication -VMName "WebServer01"

# Monitor initial replication progress
Get-VMReplication -VMName "WebServer01" | 
    Select-Object VMName, State, Health, LastReplicationTime, ReplicationFrequencySec | Format-List

# For large VMs — export to media for out-of-band seeding
Start-VMInitialReplication -VMName "WebServer01" `
    -DestinationPath "D:InitialSeedWebServer01" `
    -UseBackup

# After physically transferring to replica server and importing:
# Import-VM -Path "D:InitialSeedWebServer01..."
# Then mark the initial replication complete:
Start-VMInitialReplication -VMName "WebServer01" -InitialReplicationStartTime (Get-Date)

Monitor Replication Health

# Check replication status for all VMs
Get-VMReplication | 
    Select-Object VMName, State, Health, LastReplicationTime, 
                  PrimaryServerName, ReplicaServerName | Format-Table

# Replication health states:
# Normal    - Replication is working correctly
# Warning   - Minor issues (missed replication cycles)
# Critical  - Replication has failed and needs attention

# Get detailed statistics
Get-VMReplicationStatistics -VMName "WebServer01" | Format-List

# Check replication event log
Get-WinEvent -LogName "Microsoft-Windows-Hyper-V-VMMS-Admin" |
    Where-Object Message -match "replica|replication" |
    Select-Object -First 20 TimeCreated, Id, Message | Format-List

Configure Recovery Points

Additional recovery points allow you to roll back to a VM state from before the incident rather than just the latest replication:

# Modify recovery history (max 24 hourly points)
Set-VMReplication -VMName "WebServer01" -RecoveryHistory 24

# Enable VSS-based application-consistent snapshots
Set-VMReplication -VMName "WebServer01" `
    -VSSSnapshotFrequencyHours 4 `
    -RecoveryHistory 24

# View available recovery points on the replica server
Get-VMRecoveryCheckpoint -VMName "WebServer01" -ComputerName "replica-server" |
    Select-Object VMName, CheckpointId, CreationTime | Format-Table

Perform a Test Failover

Test failover brings up a copy of the replica VM in isolation without interrupting ongoing replication. Use this to verify the replica is bootable and the application works:

# On the REPLICA server: start a test failover
Start-VMFailover -VMName "WebServer01" -AsTest

# Start the test VM
Start-VM -Name "WebServer01 - Test"

# Verify application is working, then stop the test
Stop-VMFailover -VMName "WebServer01"

# The test VM is removed and normal replication resumes

Perform a Planned Failover

A planned failover is used when the primary server needs maintenance. The VM is gracefully shut down, final changes are replicated, then the replica is brought online:

# On the PRIMARY server: initiate planned failover
# This shuts down the VM and sends final deltas
Start-VMFailover -VMName "WebServer01"

# On the REPLICA server: complete the failover and start the VM
Complete-VMFailover -VMName "WebServer01" -ComputerName "replica-server"
Start-VM -Name "WebServer01" -ComputerName "replica-server"

# After completing primary maintenance, reverse replication direction
# so the original primary becomes the new replica
Set-VMReplication -VMName "WebServer01" `
    -Reverse `
    -ComputerName "replica-server"

Start-VMInitialReplication -VMName "WebServer01" -ComputerName "replica-server"

Unplanned Failover

# On the REPLICA server: perform unplanned failover (primary is unavailable)
# Choose a specific recovery point or use latest
Get-VMRecoveryCheckpoint -VMName "WebServer01" -ComputerName "replica-server"

# Failover to latest recovery point
Start-VMFailover -VMName "WebServer01" -ComputerName "replica-server"
Complete-VMFailover -VMName "WebServer01" -ComputerName "replica-server"
Start-VM -Name "WebServer01" -ComputerName "replica-server"

Summary

Hyper-V Replica on Windows Server 2019 provides an accessible, no-shared-storage disaster recovery solution with 30-second replication frequency, multiple recovery points, VSS application-consistent snapshots, and test failover capability. For small to medium environments, it provides an enterprise-grade DR capability without the cost of dedicated replication software. For production deployments, automate health monitoring, schedule regular test failovers, document the failover runbook, and consider extended replication to a third site for additional resilience against region-wide failures.