Following on from part 1 of the series this is the next step in testing the failover.
The most easy way to check whether the replica vm may be brought online is to right-click the replica vm DC on Host2.TestEnterprise.com and navigate to Failover:
In the next step an administrator can choose if he/she will use the latest recovery point…
…or any other standard recovery point or a snapshot (Application-Consistent Recoverysnapshot):
But I find it more interesting to do a planned failover from primary server to replica server with configuring reverse replication from the new primary server (the former replica) to the new replica server (the former primary) – it’s probably the most common way to use replica VMs while having the opportunity to failover back to the initial primary server.
For starting the planned failover I right-click DC vm on the current primary server – Host3.TestEnterprise.com – and navigate to Replication\Planned Failover:
On the next screen I check “Reverse the replication direction after failover” checkbox and press Fail Over:
The result:
The couple of things to take note of:
1) A virtual machine must be shut down before a planned failover (this will make the last standard recovery point “fully consistent” as I wrote in part 1)
2) in spite of the fact that I’ve already configured the https certificate in Hyper-V on the primary server Host3.TestEnterprise.com (please see part1) – I’ve configured it for the virtual machine being replicated (DC), – NOT for the server itself, so I must enable replication in the properties of Hyper-V on Host3:
Upon pressing the Select Certificate… the same window that we’ve already seen in part1 will pop up offering the Host3.Testenterprise.com server certificate. It’s rather interesting that the Configure the firewall to allow inboumd traffic notification has also poped up on Host3 whilst there was no such notification on Host2.
Now I shut down the primary vm DC and start the planned failover once again:
Well, troubleshooting this error may be not too obvious: from the one hand the reason for this error is rather clear – for the reverse replication to work the replica server (Host2) must be able to start replication from Host2 to Host3 and this procedure requires certain priveleges, but the way these priveleges can be granted vary depending on the forum or article being read. For example, I saw the forum post stating that to allow one Hyper-V server in a workgroup to control another server you should establish alternate credentials that can be used for the connection and it realy had helped someone to resolve the error above:
This is weird to me because the ability to control the Hyper-V SERVER (OS!) does not imply the ability to control the Hyper-V itself – both my servers use the same built-in Administratorlogin/password (so no alternate credentials are required) but the error still exists. For example, I have no issues to control Host3 from Host2 and vice versa using Computer Management:
The most easy way to see the root of the problem is ti try to add Host2 to the Hyper-V console on Host3 (and/or vice versa):
Here are the cause of the problem and the way to resolve it: to allow WinRM client on one host to connect to the other in the absense of a domain infrastructure we must add the remote host(s) to TrustedHosts list on the target computer(s), so I add Host3.TestEnterprise.com to TrustedHosts list on Host2.TestEnterprise.com and Host2.TestEnterprise.com to this list onHost3.TestEnterprise.com.
winrm set winrm/config/client @{TrustedHosts=”host2.testenterprise.com”}
winrm set winrm/config/client @{TrustedHosts=”host3.testenterprise.com”}
Now I can add Host2.Testenterprise.com to Hyper-V console on Host3.Testenterprise.com and vice versa:
This time there shouldn’t be any hindrance on the way to the planned failover.
Now Host2 is the new primary server and Host3 is the new replica. Please note that enabling reverse replication means the virtual machine will be replicating back from the new primary server to its initial location (Host3\G$\DC), – not to the folder for storing replica VMs defined on the replication tab of Hyper-V properties:
Let’s make sure the replica vm DC can really be used instead of the original vm DC.
First of all, I must select an appropriate network adapter on Host2 for the replica DC – right after failover the replica DC has no network adapters configured:
Now I can log on to my SQL1 server and access replica DC in the Network folder:
Server Manager on replica DC – checking that Active Directory, CA and other serives work as expected:
In most cases you won’t like to have your working virtual machine on a replica server indefinitely – once a problem in a primary site is resolved odds are you’d like to move your VMs back to the “initial” primary host. Let’s do the second planned failover to move the DCvirtual machine back to Host3.Testenterprise.com from Host2.Testenterprise.com.
Before starting the failover I’ve created Replica.txt file on the DC‘s desktop to illustrate the process of replicating changes from Host2 to Host3:
There’s no need to configure the DC‘s network adapter on Host3 once again – the old setting still applies:
The final check on DC‘s services:
Summary:
This article concludes the two-part series on configuring and testing replication in Windows Server 2016 workgroup environment. We’ve seen that properly configured certificate based authentication ensures that replication and planned failover can work as expected.