Failing Back From Azure Site Recovery: Part 2

In the previous blog post we performed the initial installation for failing back to on-premises vSphere.  Now it’s time to configure our on-premises Master Target Server.

Login to your on-premises Master Target Server and launch vContinuum.  Change the Application Type to P2V (this is how vContinuum sees Azure VM’s) and select new Protection

Azure 66

Select your Azure Virtual Machines.

Azure 67

If you have performed several failovers and failbacks (like I have) you will be greeted with a remove duplicate entries dialogue box.Azure 68

Azure Site Recovery uses the context of ‘Host ID’.  To identify which entry should be kept, login to your protected VM and go to C:Program Files (x86)Microsoft Azure Site RecoveryApplication Dataetc and open the file drscout.conf using notepad.  Locate the Host ID and remove all other entries from the duplicated entries screen.

Azure 69

Click Next and enter the following details:

  • vCenter Name
  • Username
  • Password

Then select Get Details and select the your Master Target Server and Click Next

Azure 70

I have chosen the following settings:

  • Retention Size – Size of log disk E Drive.
  • Retention Value – Up to 2 logs of 100MB will be stored
  • Days or Hours – Logs will be stored for up to 2 days
  • Consistency Interval – Replication interval will be checked every 15 minutes to ensure it is in line with this target
  • Datastore – Target datastore

Azure 71

Next onto the network settings, these are pretty straight forward:

  • Network Configuration – Select IP Address and Port Group the VM should be attached to on failback
  • Hardware Configuration – CPU and Memory the VM will have when failed back
  • Display Name – Hope I don’t have to explain this
  • NAT Configuration – This is how each item communicates with each other.  A little more details below.

Use PS NAT IP between source and process server for data transfer – This is between the Azure Protected VM and the Process Server.  If they are on the same Azure subnet then this can be left blank.  If on different subnets then tick the box.

Use PS NAT IP between process server and target for data transfer – This is between the Azure Process Server and our on-premises Master Target.  If they are on the same subnet or using a Site to Site VPN this can be left blank.  If transfering data over the public internet via SSL then tick the box.

Azure 72

Note: If using PS NAT IP between Azure Process Server and target for data transfer you will need to enter the public IP address of the Azure Process Server under ‘Update PS NAT IP(s)’

Azure 73

Now we are ready to run the ‘Readiness Check’.  Figures crossed it goes smoothly.  Click ‘Run Readiness Checks’

Azure 74

If you pass correctly you should be in a position to create a New Failback Plan.  Enter a name and Click Protect

Azure 75

The Protection Status window is displayed which shows the steps which are being performed.

Azure 76

Final Thought

At the moment, it is a manual process to update the IP Address and hardware configuration from Azure to on on-premises.  It would be great if the Azure team could introduce:

  • A bulk subnet change for example every VM on in Azure should go to on premises with a default gateway of and DNS Servers
  • A bulk hardware change by grouping VM’s for example tick a group of VM’s and they have 2 vCPU and 4GB RAM

In the next blog post we will perform the failback to our on-premises vSphere environment.


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