Azure Site Recovery and Azure Resource Manager

Recently, I was working with the new Azure Site Recovery Resource Provider in Azure Resource Manager.

Since we now have support for this through PowerShell, I wanted to create a solution that would automatically add VMs to the protection group.

To get VMs protected, it is quite straightforward, but you want to plan this a bit more carefully when you are designing for real-world scenarios.

Planning and Considerations

·         Resource Groups

Everything you create in ARM will belong to a Resource Group. This should be common knowledge by now, but it is worth a friendly reminder to avoid any potential confusion

·         Storage Accounts

For using ASR and having Azure as the Recovery Site, you must also create a storage account that can receive and hold the vhds for the protected virtual machines. When you power up a virtual machine – either as part of a DR drill (test failover) or perhaps for a more permanent time using planned/unplanned failover, remember that this is where the disks will be located. As a friendly reminder, the storage accounts must also belong to a Resource Group. It is important that the storage account is created in the same region as the ASR resource itself.

If you choose to use a storage account created in classic (Azure Service Management API), then the VMs will be visible in the classic portal afterwards. If you use a storage account in the ARM model, you are good to go in the new portal.

·         Network

You want to be able to connect to your virtual machines post failover. This requires network connectivity – among other things. Where you place the virtual network isn’t imported as long as it is within the same region.

·         Virtual Machines

During test/planned/unplanned failover, the virtual machine will have their storage located on the storage account you have created for your ASR configuration. The virtual networks might be in a different resource group as well. This is important to know, as every VM (regardless of test/planned/unplanned failover) will be instantiated in its own – new Resource Group, only containing the virtual machine object and the virtual network interface. All other resources are in different Resource Group(s).

What you need to be aware of

In addition to the design considerations for Resource Groups, storage and networking, you must remember a couple of things. For being able to access virtual machines post a failover, you need to ensure that you have enabled RDP within the guest (Windows) if doing so. Next, you must have either a jump-host on the target virtual network where the recovered VM is running, or simply create a Network Security Group with the required rules, associated with either the subnet or the vNics itself.

I have created a PowerShell script that is currently being polished before publishing, where I will share my findings on this topic to make an efficient DR process of your virtual machines.