How to configure and enable Hyper-V to Azure replication

In this post; we go through the steps required to enable Azure replication for our on-premises Hyper-V Virtual Machines.

We will utilize Azure Site Recovery (ASR) for that purpose; one of the most identifiable services in Microsoft’s Azure.

For those familiarized with on-premises Hyper-V to Hyper-V replication, the concept is pretty much the same. You replicate your production workloads to separate hardware, but this time, not to the replica hypervisors in your datacenter. You are replicating the VMs to Microsoft’s cloud.

In all deployment scenarios, the replicated VMs remain powered off unless a disaster strikes and you need them to be powered on.

Whether replicating from standalone, clustered or System Center Virtual Machine Manager (SCVMM) Hyper-V infrastructure, the procedure is quite similar.

The prerequisites

We distinguish the requirements below to on-premises and cloud:

On-premises datacenter

a) Hyper-V server(s) with internet connectivity

b) An average to a fast internet line

c) Firewall, a proxy or any other device inside the perimeter that manages traffic; configured to allow traffic on port 443

Microsoft Azure

a) An Azure Subscription

b) A Resource Group where we will create the required entities

c) A Storage Account where we will house our data

d) A Recovery Vault that will hold our ASR setup

e) A Virtual Network that replicated VMs will use once they get powered on in Azure

f) A Replication Policy where we set the replication settings

We will also need to download the following from our Azure tenant:

a) Azure Site Recovery Provider installer

b) A vaultcredentials file which is tied exclusively to the tenant and is used to register the Hyper-V servers to the cloud service

Better safe than sorry

Before proceeding to such a deployment, it is vital to ensure that the solution; not only matches your requirements but it does match its own requirements and limitations.

You would not want to spend time and effort on building a solution that ultimately is not going to prove useful. 

Up to that stage, we consider our checks done concerning Operating System compatibility with Azure. We don’t want to include any unsupported OS and/or application in our replicated workloads.

What is important to check as well; is the compatibility of the virtual hard disks attached to the replicated VMs. We must ensure that the type and size are both supported by Azure.

After checking that all the above prerequisites are fulfilled, we can proceed to the next steps.

The implementation

On Azure

Let’s get into action and create a Recovery Services Vault. As with the most Azure resources we create, we must pay attention to the region selection. It should match the region settings of the majority of all other resources we’ve created so far. I’ll check West Europe since this is the region I’m closest to.

After the vault creation, let’s head to Site Recovery Infrastructure. Here we will configure almost all of our implementation settings.

Now let’s add a Hyper-V site in our Site Recovery Infrastructure. Click on the + button and type any name you like.

After creating the Hyper-V site, it’s a good idea to create and associate a Retention Policy with our Hyper-V site. This can be done in the Prepare infrastructure option in the Site Recovery tab:

As always, whilst we configure any backup or replication solution, we must pay attention to each workload. Does it need to be Application Consistent (e.g. Domain Controller, Exchange Server, SQL Server etc.)? In case it needs, we should configure that value that matches our RPO requirements.

The next step is quite important since it connects the Hyper-V hosts in our datacenter with the Azure resources.

Again, click on the + button to get the following display:

Now let’s review our options:

  1. Firstly; we ensure our Hyper-V server runs Windows Server 2012 R2 or above to be compatible with the ASR service.
  2. Secondly; we review the Service URLs to allow Outbound Connections from the on-premises datacenter to Azure. Keep in mind that this option is usually not needed unless one has a URL-based firewall proxy. Whatever the case, you won’t lose something to have a look.
  3. Thirdly; we download Microsoft Azure Site Recovery Provider installer so we install it to our hypervisor(s).
  4. In this fourth step, we download the vault registration key to register the hosts on-premises. We should copy this key to each of the hosts. Bear in mind that this key is unique per each Hyper-V site.
  5. This step exists to provide instructions on what needs to be done next.


Let’s head back to our on-premises environment and complete the configuration.

We log in to our Hyper-V server and execute the installer downloaded above in step 3:

Moreover; we need to provide the key file which we also downloaded above in step 4. The installer will retrieve the Subscription, Vault name and Hyper-V site name information automatically. Then, we click on Next:

Again, in case we use any proxy settings; we need to set them up accordingly. Otherwise, we choose the first option which is to proceed with a direct connection to the ASR service:

Next, the installer will register our hypervisor to Azure and we should get the below screen. Complete the registration by finishing the wizard:

On Azure again

Now, let’s finish the procedure by adding the VMs we want to replicate. They will display as Protected Items in Replicated Items tab. We want to replicate VMs from standalone Hyper-V; thus, we select the Hyper-V machines to Azure option:

In these next options, we are going to select the VMs we want to replicate. We also select the post-failover options: Resource Group, Deployment Model, Storage Account and the Virtual Network we want to use along with the desired subnet.

Likewise, we select the disks from each VM we replicate as well as the Replication Policy.

As the final step, we get a summary of the options we chose and we are ready to go by clicking the Enable replication:

That’s it! We’re all set!


Azure Site Recovery (ASR) is generally a straightforward disaster recovery service but it requires careful planning, deployment and execution practices. That’s to ensure that you will succeed in your RTO and RPO objectives.

As always, I hope you found this post informative and I would like to thank you for reading!


Leave a Reply