VMware & Azure Site Recovery – Part 1: Pre-Requisites

I’ve had the opportunity of investigating Disaster Recovery in my role recently. I have been looking at costs and methods of bringing our critical systems online in the event of a primary data center outage.

Without going into too much detail on my existing employer, there are many things to review and architecting DR into the existing infrastructure isn’t the easiest thing to do. Given our relationship with Microsoft, I was asked to investigate Azure Site Recovery to see if it was a viable option to provide us with a DR site in the cloud.

I’m going to be blogging in a small series on the technical implementation required to achieve VMware VM’s failing over from an on-site VMware cluster to an Azure Site Recovery instance. Hopefully if all goes well I’ll add to the series as I go, but for now I’m going to keep it simple with basic deployment.


The entire process that I am following has been documented by Microsoft and gives some good detail on how to achieve VM replication into the cloud.

It is important to read through the checklist of required items before starting the setup. This can be done beforehand or during the actual implementation. I surmised it down to the following:


1) An Azure account, free trial possible (I have MSDN sub)
2) Azure Storage, somewhere to put your data.
3) Azure Network, VM’s location after fail over.


1) Build a new 2012 R2 Process/Management Server with necessary specification (Ready for installing ASR components)
2) External network connectivity to cloud services.
3) VMware vCenter + ESXi 5.5 or greater.
4) Guest machines that do not exceed certain limitations of the service (e.g. – No disks larger than 1TB)

Once the pre-steps are complete, it was on to configuring the magic….

1) Signed in to my MSDN subscription and setup the Azure Free trial ($150 a month)

2) Login to https://portal.azure.com

3) Navigate to the market place, Networking, Virtual Network.

4) If this is all new, it’s best to stick with the Resource Manager deployment model as that is the latest and greatest. Click Create.

5) Create your virtual network by filling in your requirements. I went for the large default address space, naming it and then a small subnet within that for testing. In this instance I also created a new Resource Group for


NB:- A handy tip is to pin certain objects to the dashboard so you can see them on your main screen. I found this useful for the on-site Process/Management server.

6) Navigate to the market place, Storage, Storage account.

7) Create a storage account as instructed. I opted for standard performance and keeping the data geographically local as I’m only performing a PoC. Maintaining the resource in the previously created group.

8) Navigate to the market place, Monitoring + management, Backup and Site Recovery. Create a recovery vault to group resources together.


The next thing worth doing is creating an account in your Directory Services that VMware and ASR can use.

1) Create AD Service account
2) Add to vCenter/Datacenter object where VM’s will be replicated from.
3) Create a role for “Azure Site Recovery” and give it the following permissions:


Here is a good place to stop with this part of the guide. The hard part of this post was making sure all the pre-configuration bits are done and that you are ready to proceed.

In the next post I’ll run through configuring the actual Site Recovery and making the components communicate. The most notable comment I’d have for all of this is that Microsoft have gone quite a distance in making this process as easy as possible. That doesn’t mean, however, that it goes completely without technical caveats which I’ll cover later on in the series.
Until next time!


  1. Ryan Harris
    Ryan Harris

    Thanks, I think that there could be a use case for it under certain circumstances. I’ve got more posts lined up on this. I’m familiar with Zerto, which relies on you providing your own DR site/kit to perform the replication/failover/back. (AFAIK).

    This solution I can see being a very easy win for small/medium businesses (with small budgets) with relatively simple IT environments to provide them with some continuity in the event of a disaster.

    This solution, in my eyes, relies on continued opex costs and the reliance that you won’t have to fail over unless you are up **** creek. Thus saving massive capex costs on infrastructure in order to fail over.

Leave a Reply

Your email address will not be published. Required fields are marked *