Failing Over To Azure Site Recovery

We are ready to failover our on-premises vSphere virtual machines to Azure.  Before we do it’s important to verify that our Configuration Server and Master Target Server are functioning correctly.

In the Azure Portal, select Recovery Services > VMFocusVault > Servers > Configuration Servers > Select Configuration Server.  Verify that displayed details are healthy.

Azure 46

Before we proceed any further, it’s worthwhile noting that Azure Site Recovery is in it’s infancy from an on-premises vSphere to Azure perspective.  Therefore it’s worthwhile noting that:

  • Only unplanned failover is supported
  • If you want your data to be consistent, shutdown your protected VM’s on-premises and wait for the next replication interval to complete

We need to create a Recovery Plan (which I would expect you to have in place already).  The purpose of a Recovery Plan is to group together virtual machines which should failover together.

  • Virtual Machines across different Protection Groups can be in the same Recovery Plan.  The use case for this is perhaps you have a three tier application where VM1 RPO is daily, VM2 PPO is 4 Hourly and VM3 is Hourly.
  • Once in a Recovery Plan, virtual machine start up order can be determined
  • Before a virtual machine is started a manual action can be inserted e.g. prompt to verify that a service has been checked before moving onto the next step
  • Before or after a virtual machines is started a script can be triggered

To create a Recovery Plan select Recovery Services > VMFocusVault > Recovery Plans > Create Recovery Plan

Azure 47

I’m going to create a single Recovery Plans called VMF-RP01:

  • Virtual machine VMF-AZ01 needs to maintain it’s current IP address, as if I had stretched my on-premises layer 2 network into Azure
  • Virtual machine VMF-AZ02 need a new IP address and therefore will be RE-IP’d as part of this process
  • VMF-AZ01 needs to start before VMF-AZ02

The screenshot below confirms the name of the Recovery Plan I have created called VMF-RP01.

Azure 48

As described the Protected Entities are VMF-AZ01 and VMF-AZ02.

Azure 49

Once the Recovery Plan is created.   Select the it by clicking on it’s name (in my case VMF-RP01) and you will see the following screen.

Azure 50

By default all VM’s will be started and stopped at the same time. To change this select the Group+ icon and you will see a Group 2 has been created.

Azure 51

Expand Group 1 and Select VMF-AZ02 and Select Move Virtual Machine > Group 2

Azure 52

Once done it should look like this

Azure 53

Note: Don’t forget to save your changes to the Recovery Plan


Time to failover, to test things properly, I’m going to mimic an actual disaster in which our on-premises virtual machines are unable to communicate with Azure Site Recovery.  The easiest way for us to do this is to disable the virtual NICs on our on-premises Process Server, VMF-AZ01 and VMF-AZ02 in vCenter.

Back to the Azure Portal, Select Recovery Services > VMFocusVault> Recovery Plans > Failover

Azure 54

Select either Latest Recovery Point In Time or Latest Application Consistent Recovery Point

Azure 55

That’s it sit back and make a cup of tea whilst our Recovery Plan goes into full effect.  If however, you do want to monitor the Job, select View Job.

Azure 56

In total VMF-RP01 took 24 minutes to complete.Azure 57

We should now see two more virtual machine instances available.

Azure 58

Checking the virtual machines, I can verify the following:

  • VMF-AZ01 is on IP Address which is our extended on-premises Layer 2 network
  • VMF-AZ02 is on IP Address which is our routed Layer 3 network

Interestingly, EndPoints  aren’t configured for RDP and PowerShell as per a standard virtual machine deployed in Azure.  External access if required, will need to be configured manually.

Azure 58

In the next blog post, we are going to reprotect and failback to on-premises.

3 thoughts on “Failing Over To Azure Site Recovery

  1. Hi There, I have noticed that when I recover my VM’s its not domain joined. My recovery plan is configured to bring Domain Controllers first then run a script to add remote and Powershell endpoints. Then recover the rest of the vms. All my vms can ping each other but all is showing as not connected to a domain network. They show as public network. Even the domain controllers is showing up as public network. In my ASR setup I’m replicating vms across the Internet. Have you came across this problem? Am I missing something. All Vms has been recovered with the exact same IP addresses as on-premises….

    Thank you in advanced

    1. Hi Warren, thank you for reading the blog series. First of all I would recommend having Domain Controllers already up and running in Azure with AD Connect, so you don’t need to fail these over.

      In relation to the network, have you specified which vNET you want your VM’s to come up in? This can only be performed after the initial replication. See bottom of part of this post

Leave a Reply

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

You are commenting using your 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 )

Connecting to %s