There are many articles out there explaining how Hyper-V Replication can be done. When I tried it, I needed to do a few more additional things to make it work. I think I needed to do those additional things because 1. my servers are not in the same subnet, 2. my servers do not have the same password. This article details what I did. PowerShell is the tool.
The setup giving the names and IPs used in this article...
 |
| The setup. The names and IPs in the diagram will be used in this article. |
Get the Computer Names
Firstly, and very important (at least in my tests), get the computer names of the servers, and use only those computer names in the commands, certificates, etc. Use the hosts file to resolve the names if the computer name cannot be resolved by the DNS servers configured in the server.
Use the command
$env:computername to get the computer name.
 |
| Getting the computer name of the primary (i.e. source) server. |
 |
| Getting the computer name of the replica server. |
 |
| Editing the hosts file of the primary (i.e. source) server so that the computer name of the replica server can be resolved in the primary server. |
Get the Certificates Right
Both the primary and the replica server must have their own certificate. Whatever method we use to get the certificates, we must get these things right.
- The computer name must either be in the "Common Name" or "Subject Alternative Name".
- The "Enhanced Key Usage" must have "Server Authentication" and "Client Authentication".
- The "CRL Distribution Point" must be reachable by the Hyper-V servers. (There are articles out there that shows us how to disable this requirement.)
 |
| The computer name must either be in "Common Name" or "Subject Alternative Name". |
 |
| "Enhanced Key Usage" in the certificate. |
 |
| The "CRL Distribution Point", which is "http://LinuxCA.test.quek.tech/crl/LinuxCAcrl.pem" in this example, must be reachable by the Hyper-V servers. |
To get the certificates, I use the method described in
https://work.quek.tech/2019/05/be-your-own-root-certificate-authority.html. After getting the certificates, I used "Local devices and resources" in "Remote Desktop Connection" to copy the certificates into the servers. (Many other ways are available.) After that, we need to import the certificates into the server's certificate store. The screenshots below shows some parts of the process being done on the replica server. The process is repeated on both primary and replica server, the only difference being the certificate for server.
 |
| Copying certificates in to the server via Remote Desktop. |
 |
Importing the root CA.
Command: Import-Certificate -FilePath "C:\certs\LinuxCA.crt" -CertStoreLocation Cert:\LocalMachine\Root |
 |
Display the certificate to ensure that the root CA's certificate is OK.
Command: certutil.exe -viewstore "Root" "LinuxCA.test.quek.tech" |
 |
Importing the certificate for the replica server, storing the password of the PFX file in a variable.
Command: $mypwd = Get-Credential -UserName 'Enter password below' -Message 'Enter password below' |
 |
The actual importing of the certificate, and ensuing that the server's certificate is OK.
Command: Import-PfxCertificate -FilePath "C:\certs\HvRplc.pfx" -CertStoreLocation "Cert:\LocalMachine\My" -Password $mypwd.Password
Command: certutil.exe -viewstore "My" "HvRplc" |
The above import process is repeated on the primary server as well. (For more details on how the root CA certificate "LinuxCA.crt" and the server's certificate in PFX "HvRplc.pfx" are generated, please refer to
https://work.quek.tech/2019/05/be-your-own-root-certificate-authority.html.)
Set Up the Replica Server
We now can configure the replica server, so that it is ready to receive replication traffic from the primary server. First we need to get the thumbprint of the server's certificate.
 |
Getting the thumbprint.
Command to display the certificate: certutil.exe -viewstore "My" "HvRplc" |
The command to enable the server as a Hyper-V Replication server that can receive replication data from other Hyper-V servers:
Set-VMReplicationServer -AllowedAuthenticationType Certificate -CertificateAuthenticationPort 443 -CertificateThumbprint 7ACD3F9E37E0FC9F30B6F20E6F95EC8758E7EDF5 -DefaultStorageLocation "C:\replicatedVMs\" -ReplicationAllowedFromAnyServer $true -ReplicationEnabled $true
If we did not get the CRL part done up properly, the process will fail, as illustrated be below.
 |
Set-VMReplicationServer failed because the server cannot access the CRL.
There are articles out there that shows how this CRL checking can be disabled. |
If everything is OK, the command will simply complete without any output. We can check on the status of the replication server by using the command
Get-VMReplicationServer.
 |
| Server configured as Hyper-V Replication server. |
Open Firewalls in Replica Server
Next, we need to open 2 firewalls in the replication server. We start with firewall rule "Hyper-V Replica HTTPS Listener (TCP-In)". Command to enable the rule (so that replication traffic is allowed in):
Set-NetFirewallRule -Name "VIRT-HVRHTTPSL-In-TCP-NoScope" -Enabled True
 |
| Enabling rule that allows replication traffic, and checking the rule to ensure that it is enabled. |
Next is the firewall rule that allows WinRM. (I believe I need to do this because, 1. the primary server and replica server are not the same subnet, and 2. the server's connection profile is set to "public".) In this article, we are going to configure to the rule to allow connections from 2 particular IPs (one of them is the primary server's IP). The commands...
$ips = @("103.26.41.119", "43.229.128.87")
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress $ips
 |
| Allows WinRM from primary server to replica server. |
Put Replica Server in TrustedHosts List of Primary Server
We need to tell the primary server that it is OK to connect to the replica server. To do that, we need to put the replica server in the primary server's TrustedHosts list. (It may look a bit counter-intuitive but that is how Windows works when servers need to send commands to each other in a non-domain environment. We need to tell the client, the computer making the connection, that it is safe to connect to a particular computer and issue commands to it.) The commands...
Start-Service winrm
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "HvRplc" -Concatenate
 |
| Tell the primary server that it is safe to send commands to the replica server. |
Replicate the VM
First, we need to get the thumbprint of the primary server's certificate. Command:
certutil.exe -viewstore "My" "SG0743"
 |
| Getting the certificate's thumbprint. |
Next, we need to create a PSCredential object. This PSCredential object will contain the credentials of an account in the replica server, an account with high enough privileges to do up the replica VM in the replica server.
(At this point, I only managed to get the "Administrator" account to work. Another other user accounts, even when in "Administrators" group, I cannot get it to work. If anyone knows how it is done, in a non-domain based environment, please DM me. Thanks.) The commands...
$secpasswd = Read-Host -AsSecureString
$mycreds = New-Object System.Management.Automation.PSCredential ("HvRplc\Administrator", $secpasswd)
... and then we enable the replication of a particular VM using the command...
Enable-VMReplication -VMName LinuxCA -ReplicaServerName HvRplc -ReplicaServerPort 443 -AuthenticationType Certificate -CertificateThumbprint 3BAA7F7FEDE5E60CBB3662AC3D8AE1E27E15D5CB -Credential $mycreds
 |
Create PSCredential object.
Enable replication for a VM. |
Replication does not start immediately. We need to use
Start-VMInitialReplication to start the replication. The initial replication will require more bandwidth. It is sending an entire VM across the network. After the initial replication, only changes will be replicated. We can use
Get-VMReplication and
Measure-VMReplication to monitor the progress.
 |
| Start-VMInitialReplication and monitoring its progress. |
 |
| Initial replication has completed. |
 |
What it looks like after replicating for almost a day.
Notice the "SuccessfulReplicationCount". |
 |
| The view from the replica server. |
Replication is configured on a per-VM basis. The screenshots below shows another VM ("WinAdmCtrGW" in the example) being replicated.
 |
Replicating another VM.
Notice that the "PendingReplicationSize" is dropping. |
 |
| View from the replica server. |
 |
Initial replication completed.
Only changes will be replication from now on. |
 |
| The view from the replica server. |
In this article, we took a Windows 2016 Server with Hyper-V role enabled, and configured 2 VMs in it to replicate to a Hyper-V Server 2016, using PowerShell.
