Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Three

Here is the final part to my VMM to ASR quick start guide. Its quite a long post with a lot of images, so apologise for that. I have still not covered every little option, but hopefully enough to point anyone in the correct direction.

Items covered in this post include:

  • Mapping networks
  • Recovery plans
  • Failover options.

Mapping networks:

Mapping networks is required in an Azure Site Recovery Vault so when virtual machines fail over to Azure, they know which networks each of their adapters should connect. Its here that a mapping between an on-premise SCVMM logical network is linked to an Azure network. This requires a VPN link or ExpressRoute connection and predefined Azure networks.

Click on the Site Recovery Vault in Azure, then Resources from the top menu and finally on Networks.


From the drop down menus select the Source Location then the Target Location, this will display the various location that can be mapped together. i.e. Azure or an on-premises cluster.

Once a source and target location have been chosen, select a source network, then click Map on the bottom menu. From the dialog box that is displayed, select the network that should be mapped to from Azure.

Once completed, you are able to view the two mapped networks from the main resources tab. If required you can Unmap or Modify the network mapping here also.


Recovery Plans:

Recovery plans are essentially a list of processes that should be carried out during a failover to Azure Site Recovery Services. This can include automated, manual and scripted processes.

To create a Recovery Plan, click on the ASR Vault that requires the Recovery Plan and select Recovery Plans from the top menu. If this is the first recovery plan of the recovery vault, you will be prompted with the window below. Alternatively you can select the +NEW button from the bottom menu bar.


On the first page of the Create Recovery Plan wizard, fill in the required details, Name, Source Type, Source, and Target then click on the arrow to continue to the second page.


From the second page of the wizard, select the virtual machines that the Recovery Plan will apply to and then finalise the wizard by clicking on the small tick button.


Once created, the recovery plan is listed under the Recovery Plans tab of the ASR Vault. By clicking on the recovery plan, it can be configured further.


From here its possible to add more virtual machines to the current group, additional groups of virtual machines. Each groups of resources can have assigned to it a different set of processes which will be run against them during the processing of this recovery plan. This allows the administrator to run different tasks against different resources in the same recovery plan. Form here it is also possible to assign scripts as part of the process and manual actions. Manual actions can be used to flag up manual processes during a failover, for example to remind the engineer initiating the failover to patch in a network router or make any DNS changes that might be required.



There are two main failover options in an Azure Site Recovery Vault.

  • Test Failover: This option makes it possible to test a single machine failover or a complete recovery plan failover, whilst isolating the resources from the relevant networks.
  • Failover: This option initiates a full DR failover based on a single machine or full recovery plan failover. It also offers two different scenarios, planned or unplanned failover.

To initiate a Test Failover, browse to the protected machine or recovery plan that you wish to test. Then from the bottom ribbon select Test Failover.


After initiating a Test Failover, it will be necessary to select the network that the cloned resources will be connected to. Generally for most testing its acceptable to select None.


The status bar at the bottom of the Azure portal will report that the process is underway.


Once the test failover has deployed the relevant machines, the job will stop and require manual attention to confirm that things have gone as expected.


The test failover job properties show the virtual machine, source server, source cloud and target, in this case Azure.


At this point in the test failover, the cloned resources should have been deployed to the Virtual Machine area of the Azure Portal.


NOTE: If you want to RDP into the VM after failover occurs, you’ll need to open up port 3389 under ENDPOINTS. This can be found by clicking on the cloned machine and then selecting Endpoints from the top ribbon.


Once port 3389 is open, its now possible to connect via RDP. If opening this port up is not an option, the other way is to connect the test failover to a different network at the beginning of the process. It will need to be a different network to the one its currently configured with.


Once all testing has been completed, the test failover process will need to be completed. Jump back to the waiting job and click Complete Test.  This will display a dialog window which requires confirmation of the test end by checking the ‘The test failover is complete. Clean up test environment.’ box and clicking the tick.


The test failover will then continue to clean up the environment.


Once finished, the latest failover test is recorded along side the protected item in the recovery services vault.


Initiating a full Failover is done from the same location a Test Failover. Browse to the protected machine or recovery plan that you wish to failover and then from the bottom ribbon select Failover.


There are two main options when initiating a failover:

Planned Failover

Selecting a planned failover displays the following dialog box which requires the tick to be selected to confirm the action.


The first part of the planned failover is to shutdown on-premises resources, before syncing latest’s changes to Azure. The final step is to then deploy the resources into Azure and start them up.

Unplanned failover

When choosing to run an unplanned failover, there are a further two options.

on-premises is still available:

Click on the unplanned failover option, but then tick the small box to ‘Shut down virtual machines and synchronise the latest data‘.


In the event the on-premises resources are still available, an unplanned failover will follow the same process as the planned and attempt to cleanly shutdown the on-premises resources before syncing data and starting up the Azure clones. However, if the sync fails, the failover will continue regardless using the latest replica point.

Once the on-premises resource has been stopped and the data has been synced, a final commit is required before the process is complete.


At this point it is possible to change the recovery point that should be failover to if the Latest is not the one required.


on-premises is offline:

Click on the unplanned failover option, but then DO NOT tick the small box to ‘Shut down virtual machines and synchronise the latest data‘.


In the event that the on-premises resources are offline, the option to showdown and synchronise data can be left unchecked and the failover process will continue, booting the resources from the latest replica points. This will cause a slightly older version of the resource to boot and cause a potential data lose situation.

Fail back to on-premises:

Once failed over to Azure, its is then possible to failover back to on-premises using the same processes. i.e. selecting the machine or the recovery plan, selecting planned or unplanned failover then completing the popup dialogue box.


That’s it! Hope its of some help.

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part One

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Two

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Three

Reader Comments

  1. Hi,
    great post,
    I’ve made test failover, VM was connected to isolated vNET on Azure, endpoint has been enabled but I can’t reach out VM over RDP via its public IP address – VM FW was off.
    Any hints ?


    1. Hi Artur,

      Rather than testing with the external IP address, try using the hostname of the Azure VM, then append that with the external port configured on your Remote Desktop endpoint.

      For Example:

      Kind Regards

Leave a Reply

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