Hyper-V Replica tracks the write operations on the primary virtual machine and then replicates these changes to the Replica server over a WAN. The network connection between the two servers uses the HTTP protocol and supports Kerberos authentication and certificate-based authentication, with optional support for encryption. Hyper-V Replica is closely integrated with failover clustering in Windows Server 2012, and it provides nearly seamless replication across different migration scenarios in the primary and Replica servers. This allows virtual hard disks to be stored in a different location to enable recovery in case the data center goes down due to natural disaster or other causes.
In this case we have Windows Server 2012 Hyper-V Replica with SSL via HTTPS :
We have two Hypervisors Hyperv-V1 and Hyperv-V2.
– open on hyper-v1 and hyper-v2 the appropriate Hyper-V HTTPS firewall rules
– in our test environment we are using two self signed certificates via the tool “Makecert”.
MakeCert is available as part of the Windows SDK, which you can download from http://go.microsoft.com/fwlink/?linkid=84091
– Copy the “makecert” utility to the primary server hyper-v1 and to the replica server hyper-v2
– On hyper-v1 create a self-signed test root authority certificate by running the following command from an elevated command prompt:
makecert -pe -n “CN=PrimaryTestRootCA” -ss root -sr LocalMachine -sky signature -r “PrimaryTestRootCA.cer”
– Create a new certificate signed by the primary test root authority certificate by running the following command from an elevated command prompt, supplying the FQDN of the primary server:
makecert -pe -n “CN=<FQDN>” -ss my -sr LocalMachine -sky exchange -eku 188.8.131.52.184.108.40.206.1,220.127.116.11.18.104.22.168.2 -in “PrimaryTestRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 PrimaryTestCert.cer
– Two certificates are created in the root where “makecert” was run.
– On hyper-v2 create a self-signed test root authority certificate by running the following command from an elevated command prompt:
makecert -pe -n “CN=ReplicaTestRootCA” -ss root -sr LocalMachine -sky signature -r “ReplicaTestRootCA.cer”
– Create a new certificate signed by the replica test root authority certificate by running the following command from an elevated command prompt, supplying the FQDN of the Replica server:
makecert -pe -n “CN=hyper-v2.unx.local” -ss my -sr LocalMachine -sky exchange -eku 22.214.171.124.126.96.36.199.1,188.8.131.52.184.108.40.206.2 -in “ReplicaTestRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 ReplicaTestCert.cer
– Two certificates are created in the root where “makecert” was run
– Copy the file ReplicaTestRootCA.cer from the Replica server to the primary server, and then import it with the following command:
certutil -addstore -f Root “ReplicaTestRootCA.cer”
– Copy the file PrimaryTestRootCA.cer from the Primary server to the replica server, and then import it with the following command:
certutil -addstore -f Root “PrimaryTestRootCA.cer”
– By default, a certificate revocation check is required; however, self-signed certificates don’t support revocation checks. Disable the check by editing the registry on both the primary and Replica servers with the following command:
reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
– On the primary server Enable replication
– Click Select Certificate and OK
– Click Apply
– On the primary server Enable replication
– Click Select Certificate
– initial replication will start (via HTTP port 443 using the self-signed certificates)
Connecting a Windows Azure Subscription to App Controller
Certificates are used to set up trust between the Windows Azure management API and App Controller. This authentication allows App Controller to call on the Windows Azure API when you perform tasks such as deploying services or change configuration properties. The service certificate, or Personal Information Exchange certificate (.pfx file), contains a private key. App Controller stores this certificate in the App Controller database. Since the certificate contains the private key, you need to provide the password so that App Controller can use the private key. The management certificate (.cer file) contains only the public key, which is kept in Windows Azure for accessing the API. Windows Azure allows customers to create their own management certificates, either self-signed certificates or using their preferred certification authority (CA). By giving Windows Azure the public key and keeping the private key local, the authentication can be completed.
If you are creating a certificate, you will need to export the certificate twice—once as a .cer file, and then a second time as a .pfx file, for use in App Controller. For more information about how to create and export certificates for connections to Windows Azure subscriptions, see How to Create a Management Certificate and How to Add a Management Certificate to a Windows Azure Subscription in the Windows Azure Platform section of the MSDN Library.
Before you begin with the WindowsAzure subscription you have to make an Management X.509 Certificate for Windows Azure.
Step by step how to make the Certicates :
First you start certmgr.msc and go to personal Certificate and make a Export for Windows Azure management.
When you saved the Certificate for Windows Azure Management, you have to upload this certificate to Windows Azure portal.
After this you have to make a secure certificate (PFX) for System Center 2012 App Controller Beta.
We need this certificate in System Center 2012 SP1 App Controller Beta.
Give the Windows Azure Subscription a name and browse to the PFX certificate and type the password of the certificate and click on OK.
This is all you have to do to make Windows Azure Available in System Center 2012 SP1 App Controller Beta.
Here are some screenshots of getting started with Windows Azure :
When you have an MSDN subscription, you can get Windows Azure Visual studio Ultimate subscription and sign in.
Windows Azure management portal is now also available in preview version.
To Make your first virtual Server in the Cloud on Windows Azure is really easy :
The Virtual Machine with Windows Server 2012 is being provisioned in a few minutes.
Here you see the Dashboard of the Virtual Machine.
You can connect the virtual machine via the Management Portal :
When you don’t have a MSDN subscription, you can get here your free trail version of Windows Azure ( for 90 – Days free )
Here you an find also all the information you need about Windows Azure features.
This part 3 of 3 Working with Microsoft Windows Server 2012 Hyper-V Replica is about unplanned failover of a Virtual Machine.
– If the primary server, in our case server hyper-v1, fails you can do an unplanned failover of the virtual machine
– On the replica server, in our case server hyper-v2, do:
When you have more RecoveryPoints then you can choose here.
– The (unplanned) failover is complete and the replica of the virtual machine on the hyper-v2 is now started.
– Fix the primary server hyper-v1 and replicate the replica back to the original primary server. On the replica server hyper-v2 choose Replication à Reverse Replication
– Specify the replication server you want to replicate to, in our case hyper-v1
– Last step is to do a planned failover back to the original primary server hyper-v1. Note that with every planned failover you must turn off the virtual machine.
– It can’t do a live failover.
– On hyper-v2 do:
– On hyper-v1 do:
– You notice now that the virtual machine is running on the original primary hyper-v server hyper-v1
Microsoft Windows Server 2012 Hyper-V Replica Overview
This part 2 of 3 is about Hyper-v replica Planned Failed over of a Virtual Machine.
Step by step screenshots of a Planned Hyperv Replica failover of a VirtualMachine
Turn off the primary virtual you want to failover, then choose
Replication, Planned Failover.