Hyper-V replication in a workgroup or across domains using a self signed certificate.

Why would you want a HyperV server in a workgroup environment?

Well if your Domain Controller is a VM you really don’t want to add the HyperV server to the domain as it will boot before the DC comes up. This type of setup is ripe for domain issues, so we’re left with a server that is only in a workgroup. Also if you are doing cross site replication, you might be replicating from/to different domains, this is where the self signed certificate authentication comes in to play as it is domain agnostic.

Kerberos authentication does not work in this setup, so we need to use a certificate authority as a means of authenticating the two servers with each other. The Primary server is where all the VMs are, and the Replica server is where the VMs will be copied to. HyperV replication is native and built into Server 2012 +, so there are no extra licenses necessary.

What are the steps involved?:

  1. Change the DNS suffix on both Primary and Replica servers.
  2. Reboot both servers.
  3. Create self signed certificates on both servers.
  4. Open the Certificate MMC snap-in on the Primary server and export the certificate to a .pfx file.
  5. Copy the export file and RootCA certificate from the Primary to the Replica server.
  6. Import the Primary RootCA certificate file on the Replica server.
  7. Import the .pfx file on the Replica server.
  8. Copy the RootCA certificate from the Replica to the Primary server and import it.
  9. Disable Certificate Revocation Check on both servers for replication and fail over replication.
  10. Setup the Replica server as a replica in HyperV.
  11. Start replication of a Server on the Primary server.

First we need to change the server names, or rather add a DNS suffix to them. Bring up System Properties in the Control Panel, under the Computer Name tab click change. In the Computer Name/Domain Changes window click More…

In the DNS Suffix and NetBIOS Computer Name add a Primary DNS suffix. Something along the lines of “hypervreplica.local”, it doesn’t matter call it what you will.

Click OK and save all the changes. Note that you will be required to reboot the server in order for changes to take effect. Do this to both the Primary and Replica server.

Primary is the server where your VMs reside, and Replica is where your VMs will be replicated or copied to.

Next we need to create a self signed certificate. For this you will either need Visual Studio or the Windwos SDK(https://www.microsoft.com/en-us/download/details.aspx?id=8442).

What we really need out of either of these is the makecert.exe file.

If you have VS installed the makecert.exe file is located under C:\Program Files (x86)\Windows Kits\8.1\bin\x64, or a similar path, the 8.1 will change depending on the version of Visual Studio you have installed.

Copy the makecert.exe file from here to the primary and the replica servers.

On both those servers create an empty directory somewhere, place the makecert file in there. This is also where we will create and store the self signed certificates.

On the Replica server open up an elevated command prompt and navigate to the directory where the “mekecert.exe” file is located and type in the following:

makecert -pe -n “CN=ReplicaRootCA” -ss root -sr LocalMachine -sky signature -r “ReplicaRootCA.cer”

The above command assigns a signature certificate issuer name to the replica server of “ReplicaRootCa”

Followed by:

makecert -pe -n “CN=replicahostname” -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in “ReplicaRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 ReplicaCert.cer

…where the replicahostname is replaced by the name of the server with the DNS suffix and all. Ex. hostname.domain.local.

Now move over to the Primary server, open up an elevated command prompt and navigate over to the folder where “makecert.exe” is located, and type the following:

makecert -pe -n “CN=PrimaryRootCA” -ss root -sr LocalMachine -sky signature -r “PrimaryRootCA.cer”

Followed by:

makecert -pe -n “CN=primaryhostname” -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in “PrimaryRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 PrimaryCert.cer

… where the primaryhostname reflects the name of the Primary server with the added DNS suffix. The above 4 commands will create two files on each server.

On the Primary server run > mmc, click File and select Add/Remove Snap-in…

Select the Certificates snap in and click Add>, on the next windows select Computer Account, click Next>, and then select Local computer:. Click Finish.

In the Certificates snap in, expand the Personal store and then click on Certificates.

 

You should have a certificate here with the Replica serve name and Issued by ReplicaRootCa.

Right click this certificate, select All Tasks and select Export…

Capture7

This will open the Certificate Export Wizard, when prompted select Yes, export the private key.

Export File Format, use Personal Information Exchange…. (.PFX), Include all certificates and the certification path if possible.

On the Security page check the password box, and input a password you will remember.

Click the Browse button to save the export in a *.pfx file format, give it a file name (PrimaryServer.pfx) and click save.

Double check all your settings on the final page and click Finish.

Copy the PrimaryRootCA.cer file and the PrimaryServer.pfx files to the Replica server. Put it in the folder where you created your Replica Server certificates.

On the Replica server we will now import the cer and pfx files. Open up an elevated command prompt and navigate to the file location. Type in the follwing:

certutil -addstore -f Root “PrimaryRootCA.cer”

The quotes are only necessary if you have spaces or special characters in the file name.

Open up MMC, expand the Personal section, right click on Certificates and select All Tasks > Import.

The Certificate Import Wizard will open up. Click Next. On the File to Import page click Browse…

You might have to change the file type to view the pfx file.

Navigate over to the location of your PrimaryServer.pfx file and select it, click Open. Click Next. On the next screen enter the password for the Private Key. You can mark the key as exportable if you’d like, this means you can export it at a later time if you do not keep a copy of it somewhere. Also check off Include all extended properties. Click Next.

Place the certificate in the Personal certificate store. Click Next. On the final page inspect all the details and make they are correct. Finally click Finish.

*Please be aware that for fail over replication you will more than likely need to export the certificate in the pfx format from both servers and then copy them over and import them on both servers as well. The reason for this is that replication is only one way, where as fail over replication goes both ways. Something to think about.

Now copy the ReplicaRootCA.cer file over to the primary server, place it in the folder with all the other certificate files. In and elevated command prompt add it to the certificate store.

certutil -addstore -f Root “ReplicaRootCA.cer”

Run the following two commands on both servers in an elevated command prompt.

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\FailoverReplication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

Note that the only difference between the two registry commands is FailoverReplication and Replication. You shouldn’t need to restart either of the servers after these commands.

Next you need to enable the Replica server as the replica.

On the Replica server open the HyperV manager.

Select HyperV Replication Configuration, in the configuration window check off Enable this computer as a Replica server. Check off Use certificate-based Authentication (HTTPS). It should prompt you to select a certificate, if not click on Select Certificate… you should have the option to select the certificate you created on the Replica server. Select it and click Apply.

*Note, that you will get a prompt about the Windows Firewall, I have mine disabled on all servers so this message never applied to my setup. However if you have your fire wall turned on I would recommend adding a rule to it to allow the traffic on port 443 to pass.

Now the real test, go to your Primary HyperV server and attempt to enable replication. Open up HyperV manager, select a virtual machine, right click it and slect Enable Replication…

You will be presented with a Before You Begin page, click Next >.

On the Specify Replica Server page, type in the FQDN of the replica server, for example, replicahostname.domain.local, or whatever the hostname and dns suffix that you assigned to your replica server is. Click Next >.

On the Specify Connection Parameters, make sure that certificate-based authentication is selected. Kerberos authentication only works on a domain. You may need to select the proper certificate, this will be the Primary server certificate. Also check off Compress the data that is transmitted over the network. If you see a yellow exclamation sign with the text “Could not get configuration details of the specified server.” at the bottom, don’t worry about it, if everything is setup properly it should not impact the replication in any way, shape, or form. Click Next >.

Choose Replication VHDs, here you can pick and choose which storage attached to the server you want to replicate. Select the storage you want and click Next >.

Configure Replication Frequency. The options here are 30 seconds, 5 minutes, or 15 minutes. Depending on how mission critical your data is choose accordingly. Note that replication frequency differs from Server 2012 to Server 2012 R2.

Configure Additional Recovery Points. Depending on how many recovery points you require here is where you set that up. You can setup additional hourly recovery points and even use VSS for snapshots. Hourly recovery points provide granularity, no only can you recover form the last replication point, but with this option enabled you can go back hours. You also have the option of VSS snapshots which, from personal experience, can fail. I don’t have experience with VSS on replication, but VSS on backups and more often than not VSS was always the culprit for failed backups. VSS has a tendency to fail, not ofter but every once in a while. Either way I usually only maintain the latest recovery point. Again the number of recovery points differs from 2012 to 2012 R2, 15 vs 24.

Pick your poison and click Next >.

Choose Initial Replication Method. These options are self explanatory. Chose your replication method and when. I usually just send it over the network, I find that the impact is minimal. You can also start the initial replication at a defined time, perhaps when your system is not as busy at night etc.

 

*One thing to note about replication and this is important, replication creates an avhdx file. This is a HyperV change file, and during the initial replication this can grow quite large in size. On a normal active system I have observed that this file can grow to 33% size of the original VHDX/VHD file. So be careful and be warned, because if the storage medium runs out of space it will pause the VM.

Click Next >. Confirm your settings and click Finish. Your replication should now begin.

Advertisements

24 thoughts on “Hyper-V replication in a workgroup or across domains using a self signed certificate.

  1. makecert -pe -n “CN=ReplicaRootCA” -ss root -sr LocalMachine -sky signature -r “ReplicaRootCA.cer”

    i got this error.
    Error: CryptCertStrToNameW failed => 0x80092023 (-2146885597)
    Failed

    • You need to be running the command prompt as administrator. Also if you’re copying and pasting the command you need to make sure the formatting is removed. Copy and paste into notepad, then copy and paste into command prompt. Better yet just type it out manually.

  2. Hello. Very good explanation of how set up replica with HTTPS. I have 1 question: I need to enable replica between 2 clusters in 2 different domain and I want to use an Enterprise CA to create all the certificates. The problem is that they cannot give me the Enterprise CA root certificate in .pfx format; I tried putting the .cer CA root certificate in the Trusted Root folder of all the hosts but it didn’t work.

    Now I’m using self-signed certificate and everything is working but I’m afraid that the customers will require an Enterprise CA. How can I solve this issue? Can I solve this issue?

    Thanks for your time

    • I’m actually not surprised that they refuse to give you the root cert. To be honest you don’t need it. The certificate is to prevent a man in the middle attack, and a signed certificate such as they are using is overkill and should only be used for public facing sites/servers.

      The self signed certificate is just as secure, can even be more secure depending on the hash and bit encryption you use, the only difference is that it is not signed by a certificate authority but it is not public facing. Also the cost involved would be very high for this.

      So I wouldn’t worry about it.

      • Hi Drivel.

        Thanks for your reply. My problem is that if I use an Enterprise CA the Hyper-V doesn’t seem to recognize the certificates even if I put the CA is in the trusted domain and every host has its own certificate (beside the replica broker certificate).
        When I try using self-signed certificates it works only if I export the root certificates with the private key (.pfx format).

  3. This may be a typo. Shouldn’t it say Now move over to the Primary Server?

    On both those servers create an empty directory somewhere, place the makecert file in there. This is also where we will create and store the self signed certificates.

    On the Replica server open up an elevated command prompt and navigate to the directory where the “mekecert.exe” file is located and type in the following:

    makecert -pe -n “CN=ReplicaRootCA” -ss root -sr LocalMachine -sky signature -r “ReplicaRootCA.cer”

    The above command assigns a signature certificate issuer name to the replica server of “ReplicaRootCa”

    Followed by:

    makecert -pe -n “CN=replicahostname” -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in “ReplicaRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 ReplicaCert.cer

    …where the replicahostname is replaced by the name of the server with the DNS suffix and all. Ex. hostname.domain.local.
    …………………
    —-> Now move over to the Replica server, open up an elevated command prompt and navigate over ………………….. <————-
    to the folder where “makecert.exe” is located, and type the following:

  4. To get this to fully work you will need to add an entry in each of the server’s host file for the other system. The host file on primary will have the IP address and server name with DNS suffix ex. replicahostname.domain.local on on the replica server ex. primaryhostname.domain.local and that systems IP address. If you don’t do this step you will get an error stating that the system name is not the same as in the certificate. Also when you are setting up the replication on the primary server use the full name with the DNS suffix when adding the replica server should look something like this /workgroup/replicahostname.domain.local

    • Lester, yes but this is only true if you are not running a DHCP/DNS server on a network and your server IPs are statically assigned. Otherwise you add a static DNS entry on your DHCP/DNS server.

  5. Following your instructions, I was able to get the certifications created. I encountered an issue where makecert creates a root agency in the certification path. It states that the certificate has an invalid digital certificate. Under the general tab, an message states that the integrity of the certificate cannot be guaranteed. The certificate maybe corrupted or may have been altered. How can I fix this issue.

  6. What about if i have a domain with hyper-v cluster with replica broker and a VPN to branch office and standalone Hyper-v server in workgroup ? is the same procedure ?

    I don´t want to make any change over DNS suffix, because the cluster is in production. how can i solve it ?

    Can i create the certificate with an enterprise domain CA Root and then import them together with server certificate ? and then import in each cluster host a self signed certificate from workgroup replica server ?

    Or i need to follow this tutorial anyway ?

    I repeat, i don´t want to make critical changes to the production environment.

    What about if i decide to conserve Branch Office Hyper-V as parto of actual domain without any external Domain Controller in this site ? is right if i think the only issue that maybe will occurs is if i suffer a VPN disconnection or if the server try to find domain and is temporary down, the server will wait 10/15 minutes and then all VM´s will start up and running don´t you ?, and i still have the oportunity (without domain connection to main office) to make an unplanned failover ?

    • Yes it should be the same procedure. Because you are trying to replicate from a domain joined server on to a workgroup HyperV server you need to use the certificate, you can not use kerberos since there is no domain trust between the two locations.

  7. Very detailed walk-though, but apparently I still missed something 😦
    I have a domain joined replica server, and non domain hyper-v Host (has a domain controller guest that I am trying to replicate).
    I have the certs setup on both side, and the import completed on the primary.
    When I setup the replication on the replica server, when I specify the certificate I get the cert for the remote server, and all appears to be correct here.
    I think go back to the primary server server, right click on the vm to enable replication, and when I click Select Certificate, I get a no valid certificate found.
    When I open the MMC Certificates add in, I only show the Primary Root CA there. Should I also see the Replica CA?

    • I found a slightly different walkthrough that was successful. The only difference was it had me create both certificates on the primary, export the remote, and import that on the remote. Everything came up, and I am a happy camper. A couple less steps overall, but basically the same thing.

    • I just did the exact replication on my Domain several weeks ago, I like to test my own instructions.
      Yes you should import each others certificates on both servers. I have a suggestion up there ….

      *Please be aware that for fail over replication you will more than likely need to export the certificate in the pfx format from both servers and then copy them over and import them on both servers as well.

      I will change this to be an instruction instead of a suggestion.

      • Oh, I am sure that it was something I missed on yours!! Not faulting your walkthrough at all, it gave me the boost I needed. If you want, I can get you a link to the one that I used and maybe you can see whats different. Thanks very much though!!!

  8. Dear Mr Drivel

    Thanks for a brilliant write up on such a tricky topic, certificates are a complete dark-art to me.

    To clarify though…
    Initially you say that we should change or add a DNS suffix to both primary and replica server, but to simply add a DNS suffix we only need go in to the NIC IPV4 and under the DNS tab add a DNS suffix from there without going to change under the computer name tab?

    • I’m not 100% sure, and could be way out to lunch on this one, but I my understanding is that the DNS suffix in the IPv4 setting is for name resolution, it looks for this DNS suffix to find computers on the network.
      Where as adding a DNS suffix to the actual machine name promotes the hostname on said suffix as being part of the domain even though it is not domain joined.

  9. why is any of this necessary in the first place, why can’t we just do straight replications from one server to another without having to be on an active directory joined server ( uses the kerberos option) or having to user certs for workgroup joined servers? I’ve been workin gon it for two days now, 2 workgroup servers, doesn’t work. I’ve done everything to the last letter as described here ( and other sites too) tried multiple times..nothing working.
    you cna acheive this same goal by installing Veeam B/U and replication,it uses the same tools..I just dont understand why Citrix and Vmware dont care how you replicate but apparently MS has to limit you to one of two options.seems the best scenario is for MS to drop both of these options and allow replication with just a commands..I dont get the dog and pony show with certificates. theyre far more problematic than they’re worth.
    sorry to rant, I find replcation a nice feature but completely useless out of the box,requiring significant input to get things working. why they wouldnt make it work out of the box is beyond me.

    • Rob

      I couldn’t agree with you more. I too have followed these instructions and instructions on other sites and I just can’t get this certificate nonsense to work. I have wasted hours and hours It all seems unnecessarily complicated MS not giving us the option.

      I think my next step is to investigate Veeam

    • Certificates are necessary because of Security.
      Last thing you want to be doing is replicating a domain controller and it ending up on the wrong server.
      I use Veeam as well but it is not capable of doing the same thing. While it has similar functionality this is for a different purpose.
      Sorry to hear that it is not working for you, I actually use my own post as a reference when I’m setting up replication across domains.
      I have set up replication using this post 3 times now.
      One thing I noticed is you have to manually type in the certificate commands otherwise the certificate does not get created properly.
      Do not copy and paste, the formatting screws something up.

      I will do a video tutorial this weekend.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s