How to Set Up Hyper-V Discrete Device Assignment on Windows Server 2022

Introduction to Hyper-V Replica

Hyper-V Replica is an asynchronous replication feature built into Windows Server 2022 Hyper-V that continuously replicates virtual machine changes from a primary server to a replica server, providing disaster recovery capability without requiring shared storage or expensive SAN replication hardware. Changes made to a VM’s virtual hard disks on the primary server are tracked using log-based replication and transmitted to the replica server at configurable intervals (30 seconds, 5 minutes, or 15 minutes). In the event of a disaster or primary site failure, the replica VM can be brought online at the recovery site with a recovery point objective (RPO) equal to the replication frequency. This guide covers Hyper-V Replica configuration, monitoring, failover procedures, and extended replication to a third site.

Hyper-V Replica Architecture and Requirements

Hyper-V Replica operates using a push model: the primary host sends delta changes to the replica host. Changes to the VM’s VHDX files are tracked at the block level using a dedicated replication log file (AVHDX format) that captures all writes during each replication interval. At the end of each interval, the log is sealed, transmitted to the replica server, and applied to the replica VHDX. Multiple recovery points can be maintained on the replica server, allowing you to recover to a point in time before a logical corruption or ransomware event.

The requirements for Hyper-V Replica are minimal compared to other HA technologies. The primary and replica servers do not need to be in the same domain, do not need shared storage, and do not need to be in a failover cluster (though clustering is supported). Both servers must be running Hyper-V on Windows Server 2012 or later (Windows Server 2022 supports replicating from and to any version in this range). Network connectivity on port 80 (HTTP/Kerberos) or port 443 (HTTPS/certificate-based) must exist between the two servers. In production environments, HTTPS with certificates is strongly recommended to encrypt replication traffic.

Enabling Hyper-V Replica on the Replica Server

Configuration must begin on the replica server — the host that will receive and store the replicated VM data. The replica server must be configured to accept incoming replication connections before the primary server can begin sending data. Configure the replica server using Set-VMReplicationServer:

# Enable replication using Kerberos (HTTP, port 80)
Set-VMReplicationServer -ReplicationEnabled $true `
                        -AllowedAuthenticationType Kerberos `
                        -ReplicationAllowedFromAnyServer $true `
                        -DefaultStorageLocation "D:HyperVReplica"

For certificate-based HTTPS authentication (recommended for production):

Set-VMReplicationServer -ReplicationEnabled $true `
                        -AllowedAuthenticationType Certificate `
                        -CertificateThumbprint "A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2" `
                        -ReplicationAllowedFromAnyServer $true `
                        -DefaultStorageLocation "D:HyperVReplica"

The certificate must be issued by a Certificate Authority trusted by both hosts, must have the “Client Authentication” and “Server Authentication” EKUs, and must be installed in the Local Computer Personal certificate store on both the primary and replica servers. You can also restrict which primary servers are permitted to replicate to this replica host by setting -ReplicationAllowedFromAnyServer $false and then adding approved primary servers individually:

Set-VMReplicationServer -ReplicationEnabled $true `
                        -AllowedAuthenticationType Kerberos `
                        -ReplicationAllowedFromAnyServer $false `
                        -DefaultStorageLocation "D:HyperVReplica"

New-VMReplicationAuthorizationEntry -AllowedPrimaryServer "HYPERV-PRIMARY01.contoso.com" `
                                    -ReplicaStorageLocation "D:HyperVReplicaHYPERV-PRIMARY01" `
                                    -TrustGroup "ProductionSite"

Enabling the Windows Firewall Rules for Hyper-V Replica

The Hyper-V Replica HTTP (port 80) and HTTPS (port 443) Windows Firewall rules must be enabled on the replica server to allow incoming replication connections. These rules exist by default but are disabled:

# Enable Kerberos (HTTP) listener rule on replica server
Enable-NetFirewallRule -DisplayName "Hyper-V Replica HTTP Listener (TCP-In)"

# Enable certificate (HTTPS) listener rule on replica server
Enable-NetFirewallRule -DisplayName "Hyper-V Replica HTTPS Listener (TCP-In)"

Verify the rules are active:

Get-NetFirewallRule -DisplayGroup "Hyper-V" | 
    Where-Object DisplayName -like "*Replica*" | 
    Select-Object DisplayName, Enabled, Direction

Configuring Replication on the Primary Server

With the replica server ready to accept connections, configure replication for each VM on the primary host. The Enable-VMReplication cmdlet configures the replication partnership for a specific VM. Enable replication using Kerberos to a remote replica host, with a 5-minute replication frequency and 24 recovery points:

Enable-VMReplication -VMName "WebServer01" `
                     -ReplicaServerName "HYPERV-REPLICA01.contoso.com" `
                     -ReplicaServerPort 80 `
                     -AuthenticationType Kerberos `
                     -ReplicationFrequencySec 300 `
                     -RecoveryHistory 24 `
                     -CompressionEnabled $true

For certificate-based HTTPS replication on port 443:

Enable-VMReplication -VMName "WebServer01" `
                     -ReplicaServerName "HYPERV-REPLICA01.contoso.com" `
                     -ReplicaServerPort 443 `
                     -AuthenticationType Certificate `
                     -CertificateThumbprint "A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2" `
                     -ReplicationFrequencySec 300 `
                     -RecoveryHistory 24 `
                     -CompressionEnabled $true

The -ReplicationFrequencySec parameter accepts three values: 30 (30 seconds, highest RPO granularity, highest network usage), 300 (5 minutes), or 900 (15 minutes, lowest network usage). The -RecoveryHistory parameter specifies the number of additional recovery points to retain on the replica server beyond the current state. Setting this to 24 with a 5-minute frequency provides up to 2 hours of recovery points. Higher recovery counts require more disk space on the replica server.

Starting the Initial Replication

After enabling replication, you must initiate the initial replication, which copies the full VM state from the primary to the replica server. For small VMs on a fast network, choose network-based initial replication:

Start-VMInitialReplication -VMName "WebServer01"

For large VMs or slow WAN links where copying tens of gigabytes over the network is impractical, Hyper-V Replica supports offline initial replication. Export the VM state to an external disk, ship the disk to the replica site, and import it there. Configure offline initial replication specifying a local export path:

Start-VMInitialReplication -VMName "WebServer01" `
                           -InitialReplicationStartTime (Get-Date).AddHours(2) `
                           -UseBackup

Alternatively, export the VHD to media for shipping:

Start-VMInitialReplication -VMName "WebServer01" `
                           -DestinationPath "E:OfflineReplicationWebServer01"

On the replica server, after the media arrives, import the offline initial replication data:

Import-InitialVMReplication -VMName "WebServer01" `
                            -Path "E:OfflineReplicationWebServer01"

Monitoring Hyper-V Replication Health

Ongoing replication health monitoring is essential in production. The Get-VMReplication cmdlet returns the current state of all VM replication relationships on the host:

Get-VMReplication | Select-Object VMName, State, Health, LastReplicationTime, `
                                  ReplicationFrequency, RecoveryHistory, `
                                  PrimaryServerName, ReplicaServerName

The Health property will be Normal, Warning, or Critical. A Warning state indicates that replication is lagging behind schedule — the last successful replication is older than the replication interval. A Critical state means replication has failed and may require manual intervention. Get detailed statistics for a specific VM’s replication:

Get-VMReplicationStatistics -VMName "WebServer01"

This returns metrics including average replication size, last replication duration, and the number of pending bytes to replicate. Use these statistics to assess whether your replication network has sufficient bandwidth for the current write rate. Monitor replication health across all VMs and alert on non-Normal states with a simple script:

Get-VMReplication | Where-Object Health -ne Normal | ForEach-Object {
    Write-Warning "REPLICATION ISSUE: VM '$($_.VMName)' - Health: $($_.Health) - Last replication: $($_.LastReplicationTime)"
}

Test Failover

Test failover creates a temporary copy of the replica VM in an isolated network and starts it, allowing you to verify that the VM boots and operates correctly at the replica site without affecting ongoing replication or the production VM. Test failover is a non-destructive operation — the replica VM remains in its replicated state and replication continues while the test VM runs. Start a test failover using the most recent recovery point:

Start-VMFailover -VMName "WebServer01" -AsTest

Start a test failover using a specific recovery point (run Get-VMRecoveryCheckpoint to list available points):

$recoveryPoint = Get-VMRecoveryCheckpoint -VMName "WebServer01" | 
                 Where-Object Name -like "*2026-05-17*" | 
                 Select-Object -First 1

Start-VMFailover -VMName "WebServer01" -VMRecoveryCheckpoint $recoveryPoint -AsTest

The test VM starts in a paused state. Start it and verify functionality, then stop the test failover to remove the temporary VM and resume replication:

Start-VM -Name "WebServer01 - Test"
# ... perform testing ...
Stop-VMFailover -VMName "WebServer01"

Planned Failover

A planned failover is used when you want to intentionally switch the active VM from the primary to the replica site — for example, before planned maintenance on the primary server or during a primary datacenter migration. During a planned failover, Hyper-V performs a final synchronisation of all pending changes from the primary to the replica, then shuts down the primary VM and starts the replica. This results in near-zero data loss (the pending replication delta at the time of shutdown). A planned failover can also be reversed — roles switch so the original replica becomes the primary and vice versa. To perform a planned failover:

# On the PRIMARY server - initiate planned failover
# The primary VM must be running
Start-VMFailover -VMName "WebServer01" -Prepare

# On the REPLICA server - complete the failover
Start-VMFailover -VMName "WebServer01"

# Start the VM on the replica server
Start-VM -Name "WebServer01"

# Set the replica server as the new primary (reverse replication)
Set-VMReplication -VMName "WebServer01" -Reverse

Unplanned Failover

An unplanned failover is performed when the primary site has failed unexpectedly and the primary VM is no longer accessible. In this scenario, you bring the replica VM online from the most recent recovery point. Data loss will equal the amount of data written to the primary VM between the last successful replication and the failure. On the replica server, initiate the unplanned failover:

# Fail over using the latest recovery point
Start-VMFailover -VMName "WebServer01"

# Or fail over to a specific older recovery point
$rp = Get-VMRecoveryCheckpoint -VMName "WebServer01" | Sort-Object CreationTime -Descending | Select-Object -First 1
Start-VMFailover -VMName "WebServer01" -VMRecoveryCheckpoint $rp

# Start the failover VM
Start-VM -Name "WebServer01"

After the failover VM is running and the primary site is restored, you can configure reverse replication to replicate changes back to the original primary from the now-active replica:

Set-VMReplication -VMName "WebServer01" -Reverse

Extended Replication: Three-Copy Configuration

Hyper-V Replica supports extended replication, which adds a third copy of the VM at a second replica site. The replication chain is: Primary → Replica 1 → Replica 2 (Extended Replica). The extended replica host replicates from the Replica 1 host, not directly from the primary. This provides a three-copy disaster recovery architecture across three locations. Configure extended replication on the Replica 1 host (which acts as a secondary primary for extended replication):

# On Replica 1 host - enable extended replication to Replica 2
Enable-VMReplication -VMName "WebServer01" `
                     -ReplicaServerName "HYPERV-REPLICA02.contoso.com" `
                     -ReplicaServerPort 80 `
                     -AuthenticationType Kerberos `
                     -AsReplica `
                     -ReplicationFrequencySec 900

Monitor extended replication alongside primary replication:

Get-VMReplication -VMName "WebServer01" -ReplicationRelationshipType Extended

Note that the extended replica relationship uses a 15-minute minimum replication frequency, and extended replication only replicates the VM’s disk state — it does not support application-consistent VSS checkpoints or the 30-second replication frequency.

Disabling and Removing Replication

To stop replication for a VM without deleting the replica, disable it on the primary:

Disable-VMReplication -VMName "WebServer01"

To permanently remove the replication configuration and delete the replica VM files, remove replication from both the primary and replica hosts:

# On primary host
Remove-VMReplication -VMName "WebServer01"

# On replica host - remove the replica VM
Remove-VM -Name "WebServer01" -Force
# Then manually delete the VHDX files if required

Conclusion

Hyper-V Replica on Windows Server 2022 delivers a practical, storage-agnostic disaster recovery solution that requires no additional licensing beyond Windows Server and no shared storage infrastructure between sites. By configuring certificate-based HTTPS authentication for security, choosing an appropriate replication frequency for your RPO requirements, maintaining multiple recovery points for ransomware protection, and regularly testing failover procedures, you can build a reliable DR capability with minimal cost and complexity. Extended replication to a third site adds an additional layer of protection for the most critical workloads, and the Get-VMReplication monitoring commands make it straightforward to integrate replication health into existing monitoring and alerting workflows.