How to Configure Hyper-V Replication on Windows Server 2025

Hyper-V Replica is a built-in disaster recovery feature that provides asynchronous replication of virtual machines from a primary Hyper-V host to one or more replica hosts — without requiring a shared storage infrastructure or a Windows Server Failover Cluster. Changes made to a VM’s virtual hard disks on the primary site are tracked and sent to the replica server at regular intervals (as frequently as 30 seconds), where they are applied to a replica copy of the VM. In the event of a primary-site failure, you can fail over to the replica and resume operations quickly. Windows Server 2025 supports extended replication to a third site, test failover without disrupting production, and both planned and unplanned failover scenarios. This tutorial covers every step from initial setup through to performing and recovering from a failover.

Prerequisites

  • Two Windows Server 2025 hosts with the Hyper-V role installed — one designated Primary, one designated Replica
  • A Windows Server Failover Cluster (WSFC) is not required — Hyper-V Replica works with standalone hosts
  • Both hosts joined to the same Active Directory domain (for Kerberos authentication) or using certificate-based authentication for workgroup/cross-domain scenarios
  • Network connectivity between primary and replica on port 80 (HTTP/Kerberos) or port 443 (HTTPS/certificate)
  • Sufficient disk space on the replica host for all replicated VM VHDXs
  • Matching Hyper-V VM configuration versions on primary and replica (upgrade VMs with Update-VMVersion if needed)
  • Administrator privileges on both hosts

Step 1: Configure the Replica Server

The replica host must be configured to accept incoming replication traffic before any VM can be replicated to it. This is done by enabling the Replica Server capability and specifying which primary servers are allowed to send replicas.

# ---- Run on the REPLICA HOST (e.g., HVREPLICA01) ----

# Enable the Hyper-V Replica server role using Kerberos authentication (port 80)
# -ReplicationEnabled $true turns on the accept-replication capability
# -AllowedAuthenticationType Kerberos means only domain-joined hosts can replicate here
Set-VMReplicationServer -ReplicationEnabled $true `
                        -AllowedAuthenticationType Kerberos `
                        -ReplicationAllowedFromAnyServer $false `
                        -DefaultStorageLocation "D:Hyper-VReplica"

# Alternatively, allow any authenticated host to replicate here (useful in lab environments)
Set-VMReplicationServer -ReplicationEnabled $true `
                        -AllowedAuthenticationType Kerberos `
                        -ReplicationAllowedFromAnyServer $true `
                        -DefaultStorageLocation "D:Hyper-VReplica"

# Verify the Replica server configuration
Get-VMReplicationServer | Select-Object ReplicationEnabled, AllowedAuthenticationType, `
                          ReplicationAllowedFromAnyServer, DefaultStorageLocation, `
                          HttpsPort, KerberosAuthenticationPort

Step 2: Open Firewall Rules on the Replica Host

Hyper-V Replica traffic must be allowed through Windows Firewall on the replica host. HTTP (port 80) is used with Kerberos authentication; HTTPS (port 443) is used with certificate-based authentication.

# ---- Run on the REPLICA HOST ----

# Enable the built-in Hyper-V Replica firewall rule group
Enable-NetFirewallRule -DisplayGroup "Hyper-V Replica HTTP Listener (TCP-In)"

# If using certificate/HTTPS authentication instead, enable:
Enable-NetFirewallRule -DisplayGroup "Hyper-V Replica HTTPS Listener (TCP-In)"

# Or create custom rules if the built-in groups are not present
New-NetFirewallRule -DisplayName "Hyper-V Replica - HTTP (Kerberos)" `
                    -Direction Inbound `
                    -Protocol TCP `
                    -LocalPort 80 `
                    -Action Allow `
                    -Profile Domain

New-NetFirewallRule -DisplayName "Hyper-V Replica - HTTPS (Certificate)" `
                    -Direction Inbound `
                    -Protocol TCP `
                    -LocalPort 443 `
                    -Action Allow `
                    -Profile Domain

# Verify rules are active
Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*Hyper-V Replica*" } | `
    Select-Object DisplayName, Enabled, Direction, Action | Format-Table

Step 3: Enable Replication for a Virtual Machine

With the replica server configured and firewall rules in place, you can enable replication on individual VMs from the primary host. You specify the replica server, authentication type, replication frequency, and how many recovery points to keep.

# ---- Run on the PRIMARY HOST (e.g., HVPRIMARY01) ----

# Enable replication for a VM using Kerberos authentication
# -ReplicationFrequencySec: 30, 300 (5 min), or 900 (15 min)
# -AutoResynchronizeEnabled: automatically re-sync if replication falls behind
Enable-VMReplication -VMName "WEBSRV01" `
                     -ReplicaServerName "HVREPLICA01.contoso.local" `
                     -ReplicaServerPort 80 `
                     -AuthenticationType Kerberos `
                     -ReplicationFrequencySec 300 `
                     -RecoveryHistory 4 `
                     -AutoResynchronizeEnabled $true `
                     -AutoResynchronizeIntervalStart "02:00:00" `
                     -AutoResynchronizeIntervalEnd "06:00:00"

# Enable replication for multiple VMs using a loop
$vmsToReplicate = @("APPSRV01", "DBSRV01", "FILESRV01")
foreach ($vmName in $vmsToReplicate) {
    Enable-VMReplication -VMName $vmName `
                         -ReplicaServerName "HVREPLICA01.contoso.local" `
                         -ReplicaServerPort 80 `
                         -AuthenticationType Kerberos `
                         -ReplicationFrequencySec 300 `
                         -RecoveryHistory 2
}

# View replication configuration for all VMs
Get-VMReplication | Select-Object VMName, State, Health, Mode, `
                    ReplicaServerName, ReplicationFrequencySec, RecoveryHistory | Format-Table

Step 4: Perform the Initial Replication

Before ongoing replication begins, Hyper-V must copy the entire VHDX contents to the replica host. This is the initial replication. For large VMs over slow WAN links, you can seed the replica using an external medium (USB drive, shipped hard disk) to avoid saturating the network.

# ---- Run on the PRIMARY HOST ----

# Start initial replication immediately over the network
Start-VMInitialReplication -VMName "WEBSRV01"

# Schedule initial replication at a specific time (off-peak hours)
Start-VMInitialReplication -VMName "WEBSRV01" `
                           -InitialReplicationStartTime "2025-05-18 02:00:00"

# Export the initial replication to external media (for seeding the replica offline)
Start-VMInitialReplication -VMName "WEBSRV01" `
                           -DestinationPath "E:ReplicaSeedWEBSRV01" `
                           -UseBackup

# On the REPLICA HOST — import the seed and complete the initial replication
Import-InitialVMReplication -VMName "WEBSRV01" `
                            -Path "E:ReplicaSeedWEBSRV01"

Step 5: Monitor Replication Health

# Check replication status for all VMs on the primary host
Get-VMReplication | Format-Table VMName, State, Health, LastReplicationTime, `
                    PendingReplicationSize, Mode -AutoSize

# Get detailed replication statistics for a specific VM
Get-VMReplication -VMName "WEBSRV01" | Select-Object *

# Monitor replication health across all VMs in a loop
while ($true) {
    Clear-Host
    Get-VMReplication | Select-Object VMName, State, Health, `
        @{N="LastReplMin"; E={ [math]::Round(((Get-Date) - $_.LastReplicationTime).TotalMinutes, 1) }}, `
        PendingReplicationSize | Format-Table -AutoSize
    Start-Sleep -Seconds 30
}

# Check Hyper-V Replica event log for errors
Get-WinEvent -LogName "Microsoft-Windows-Hyper-V-VMMS-Operational" |
    Where-Object { $_.Message -like "*replication*" -and $_.LevelDisplayName -eq "Error" } |
    Select-Object TimeCreated, Id, Message | Select-Object -First 10 | Format-List

Step 6: Configure Extended Replication (Three-Site Disaster Recovery)

Extended Replication allows the replica VM on the secondary site to itself be replicated to a third site. This creates a three-tier protection chain: Primary → Replica → Extended Replica. It is configured on the replica host, which acts as the primary for the extended replica relationship.

# ---- Run on the REPLICA HOST (HVREPLICA01) ----
# The replica VM on this host is further replicated to an extended replica host

# First, enable the extended replica host (HVEXTENDED01) as a replica server
# (Follow Steps 1 and 2 on HVEXTENDED01 as well)

# Enable extended replication on the replica VM
# Note: The VM on the replica host must already be receiving replication from the primary
Set-VMReplication -VMName "WEBSRV01" `
                  -Reverse `
                  -ReplicaServerName "HVEXTENDED01.contoso.local" `
                  -ReplicaServerPort 80 `
                  -AuthenticationType Kerberos `
                  -ReplicationFrequencySec 900

# Alternatively use Enable-VMReplication with -AsReplica to mark it as an extended replica source
# Extended replication frequency must be equal to or greater than the primary replication frequency

# Verify the extended replication chain
Get-VMReplication -VMName "WEBSRV01" | Select-Object VMName, Mode, State, ReplicaServerName

Step 7: Perform a Test Failover

A test failover creates a temporary copy of the replica VM and starts it in an isolated network environment, allowing you to verify that the replica is usable without interrupting ongoing replication. The production replica VM continues receiving updates throughout the test.

# ---- Run on the REPLICA HOST ----

# Start a test failover — creates a temporary test VM from the most recent recovery point
Start-VMFailover -VMName "WEBSRV01" -AsTest

# Start a test failover from a specific recovery point
$recoveryPoints = Get-VMRecoveryCheckpoint -VMName "WEBSRV01"
$recoveryPoints | Select-Object Name, CreationTime, ParentCheckpointName | Format-Table
$selectedPoint = $recoveryPoints | Sort-Object CreationTime | Select-Object -Last 2 | Select-Object -First 1
Start-VMFailover -VMName "WEBSRV01" -VMRecoveryCheckpoint $selectedPoint -AsTest

# The test VM is created with "-Test" appended to the name
# Connect to it for validation
vmconnect.exe localhost "WEBSRV01 - Test"

# Stop the test failover — removes the test VM and resumes normal replication
Stop-VMFailover -VMName "WEBSRV01"

Step 8: Perform a Planned Failover

A Planned Failover is used when you want to move production workloads to the replica site in a controlled, orderly way — for example, before scheduled maintenance on the primary site. The VM is gracefully shut down on the primary, a final replication cycle synchronises all pending changes, and then the VM starts on the replica host. This results in zero data loss.

# ---- Run on the PRIMARY HOST ----

# Initiate a planned failover — the VM must be running or saved
# This shuts down the VM, replicates final changes, and prepares the replica for start-up
Start-VMFailover -VMName "WEBSRV01" -Prepare

# ---- Run on the REPLICA HOST ----

# Complete the planned failover — starts the VM on the replica host
Start-VMFailover -VMName "WEBSRV01"

# Finalise the failover (required after both planned and unplanned failover)
Complete-VMFailover -VMName "WEBSRV01"

# Verify the VM is running on the replica host
Get-VM -Name "WEBSRV01" | Select-Object Name, State, ComputerName

Step 9: Perform an Unplanned Failover

An Unplanned Failover is used when the primary site fails unexpectedly (power outage, hardware failure, natural disaster). Because the final replication cycle may not have completed, there is a risk of data loss corresponding to the replication frequency interval (up to 15 minutes by default).

# ---- Run on the REPLICA HOST ----

# Start the unplanned failover from the latest recovery point
Start-VMFailover -VMName "WEBSRV01"

# Or choose a specific earlier recovery point if the latest is suspected to be corrupted
$recoveryPoints = Get-VMRecoveryCheckpoint -VMName "WEBSRV01"
$recoveryPoints | Select-Object Name, CreationTime | Format-Table
$cleanPoint = $recoveryPoints | Sort-Object CreationTime | Select-Object -Last 3 | Select-Object -First 1
Start-VMFailover -VMName "WEBSRV01" -VMRecoveryCheckpoint $cleanPoint

# Complete the failover to make the replica the new primary
Complete-VMFailover -VMName "WEBSRV01"

# Start the VM
Start-VM -Name "WEBSRV01"

# After the primary site is restored, set up reverse replication to protect the now-live replica
# This replicates from the old replica back to the recovered primary
Set-VMReplication -VMName "WEBSRV01" `
                  -Reverse `
                  -ReplicaServerName "HVPRIMARY01.contoso.local" `
                  -ReplicaServerPort 80 `
                  -AuthenticationType Kerberos

Start-VMInitialReplication -VMName "WEBSRV01"

Step 10: Modify and Manage Existing Replication

# Change replication frequency on a running replication relationship
Set-VMReplication -VMName "WEBSRV01" -ReplicationFrequencySec 30

# Add more recovery points (maximum 24 for 30-second frequency; 15 for 5-minute frequency)
Set-VMReplication -VMName "WEBSRV01" -RecoveryHistory 8

# Pause replication (e.g., during a maintenance window on the primary)
Suspend-VMReplication -VMName "WEBSRV01"

# Resume replication
Resume-VMReplication -VMName "WEBSRV01"

# Remove replication entirely (does NOT delete the replica VM)
Disable-VMReplication -VMName "WEBSRV01"

# Remove replication and delete the replica VM
Disable-VMReplication -VMName "WEBSRV01"
Remove-VM -Name "WEBSRV01" -ComputerName "HVREPLICA01.contoso.local" -Force

Conclusion

Hyper-V Replica on Windows Server 2025 delivers a powerful, low-cost disaster recovery solution that requires no specialised hardware or shared storage. In this tutorial you configured a replica server with the appropriate firewall rules, enabled replication on virtual machines using Kerberos authentication, performed initial replication, and monitored ongoing replication health. You set up extended replication for three-site protection, ran a test failover to validate your DR plan without impacting production, and executed both planned failover (zero data loss) and unplanned failover (minimal data loss) procedures. With reverse replication configured, you can restore the original primary-to-replica direction after recovery, completing a full disaster recovery and restoration cycle entirely within the Windows Server 2025 platform.