In contradistinction to workgroup clusters which were made available only in Windows Server 2016 – I wrote about them in Windows Server 2016: Testing Workgroup Cluster – Part1 and Windows Server 2016: Testing Workgroup Cluster – Part2 – certificate based replication was presented in the earlier version of Windows Server: the possibility of having a non-domain replica server is a great feature for any company, not speaking of the ones with only 2-3 servers at their disposal.
In a workgroup environment the most common way to create the certificates for Hyper-V hosts was to use the makecert utility but, given that this utility is depricated now and the new cmdlet New-SelfSignedCertificate is available instead in Windows Server 2016, the process of configuring workgroup replicas became a bit easier. In these two articles I’d like to walk all the steps required for setting up replication in Windows Server 2016 workgroup as well the steps required for the testing of the newly-created replica.
It is ridiculous but I failed to find any COMPLETE step by step explanation from MS regarding setting up replication in a non-domain environment so I will explain here all issues an administrator may be facing with while configuring replication according to the few articles found on msdn/technet sites.
Let’s get started by finding out whether any prerequisites exist for deploying a workgroup replica.
As you already may know there are two types of authentication in Hyper-V: Kerberos and HTTPS certificates. Considering Kerberos is available only in domain environments we have no any other choice but to use the certificate based authentication. The prerequisites for this type of authentication are rather simple: the Subject field of a certificate should be set to Hyper-V server name (either primary or replica server) and the Enhanced Key Usage should be the Client and Server authentication – here is the full explanation of the prerequisites.
Of course, https traffic should be allowed on server firewalls (I’ve disabled the firewalls on my host servers so I won’t publish the corresponding screenshots).
One more thing to note: virtual machine to be replicated should not have any checkpoints – there should be only one vhdx file available for replication so I delete the single checkpoint of the vm – DC – that I’m going to replicate:
Having determined the prerequisites I can proceed to creating these certificates with the New-SelfSignedCertificate cmdlet…. But although it’s not a prerequisite I prefer adding the main dns suffix to those of my workgroup servers which are used in cluster/hyper-v deployments (for example, adding the main dns suffix is the prerequisite for a workgroup cluster as I wrote in Windows Server 2016: Testing Workgroup Cluster*) so my very first action will be this:
Now my goal is to create the two certificates: for Host3.Testenterprise.com and Host2.Testenterprise.com.
On Host3 I run the following commands:
New-SelfSignedCertificate -DnsName “Host3.TestEnterprise.com” –
CertStoreLocation “cert:\LocalMachine\My” -TestRoot
New-SelfSignedCertificate -DnsName “Host2.TestEnterprise.com” –
CertStoreLocation “cert:\LocalMachine\My” -TestRoot
– as a result, the three certificates will be created: one for each server with the Enhanced Usage Key set to Client and Server authentication (although that was not explicitly stated!) and the test root CA certificate – CertReq Test Root – which by default will be placed in the Intermidiate Certification Authorities.
I’d like to stress the need for the -TestRoot parameter: you may create certificates without it but Hyper-V will not allow to use self-signed certificates for replication!
As the CertReq Test Root certificate is NOT in the Trusted Root Certification Authorities these certificates will be untrusted:
The certificates for the primary server – Host3.Testenterprise.com – have been configured. The next step is to export the host2 server certificate along with the CertReq Test Root certificate and import them into Host2.Testenterprise.com.
…and run the Import wizard on Host2.Testenterprise.com for two times.
After all certificates have been created we must add the following registry key on both host servers:
reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
…and Apply – configuration of the replica server is complete.
In the next window an administrator should choose whether there’ll be only the last recovery point available or any number of additional (<=24) recovery points (created hourly), and – if required – he/she may tick Volume Shadow Copy Service (VSS) snapshot frequency (in hours) checkbox to enable creation of application-consistent snapshots.
In short, recovery points are the incremental file-consistent archives that don’t take into account the content of memory of replicated VMs – in case of a planned failover it won’t be a problem because a VM must be shut down before a planned failover, thus making a VM “fully consistent”, but in case of unplanned failover many programs will lose their open transactions held in memory (SQL, Exchange…) making file-consistent archives (the recovery points) rather useless. In contrast, application-consistent archives (snapshots) guarantee the application will work inside the replica even after unplanned failover because VSS service will do all required job regarding the information in memory. More information on this here.
In this part we’ve seen how to enable replication in a workgroup using two Windows Server 2016 based hosts. The next part will be devoted to testing the replica VM.