Welcome back to our series on Disaster Recovery. In the first installment in the ASR Survival Guide series, we discussed the importance of ASR Replication Health and some of the issues related to maintaining it. In this next segment, we’ll consider network and availability considerations that are important to a successful business continuity solution based upon ASR. First, let’s look at Network Mapping.

  1. Network mapping – ensure that both required network mappings exist, from Source to Target and Target to Source

In the Azure-to-Azure site recovery scenario where systems can fail over from one Azure region to another, an important planning consideration is necessary to ensure that the proper Network mappings have been created. If new systems have been added to the Recovery vault over time, ASR can add new – and often undesired – network mappings. This can result in some or all systems starting up in the wrong vnet, causing the entire service to be unavailable in spite of what could be reported as a successful Failover.

To validate your Network mappings, from the portal navigate to Recovery Services vaults > RecoveryServicesVaultName > Site Recovery Infrastructure – Network Mapping and verify the correct mappings exist as seen here:

You should find two mappings as seen above, one in each direction to support re-protection and failback.

If more than one administrator has added additional systems to the Recovery Vault for protection, it’s easy to inadvertently add network mappings. Check everytime new systems are added to the Recovery vault and delete any incorrect or unnecessary mappings. If you do not correct this, some systems could failover into the wrong network, causing the overall process to fail to properly restore service operation in the Target region.

  1. Availability sets – Ensure Availability sets are properly created and are contained in the correct Resource groups before attempting a Test failover or Failover.

If your application uses Availability sets to enhance business continuity by distributing VMs across multiple fault and update domains, you’ll need to ensure that the Availability sets are available in the Target Resource group before executing a Recovery Plan. When a Recovery Plan is triggered, ASR first does a prerequisite check and will fail immediately if the Availability set has not been created previously. It is essential that you validate your Availability set configuration prior to conducting any failover testing.

When protecting a system(s), ASR will offer to create an Availability set if the Source VM is already part of one. It will use the same set name with -ASR appended. You can use this, or opt to select from another Availability set that must have been previously created in the Target Resource group. From the portal, you can navigate here to review the configuration and make any changes: Recovery Services vaults > VaultName – Replicated items > VMname – Compute and Network

Next, check the Availability set. Confirm it is in the proper Resource group under Target, and ensure it has the required Managed Disks property setting:


As you can see above, on the Overview tab, our Availability set is in the correct Target Resource group and the Managed property is correctly set to Yes. Be sure similarly validate all your Availability sets so that any Failover is able to proceed without error.

Following these guidelines will substantially enhance the likelihood of a successful Failover in the event of a disaster. In the upcoming installments, we’ll look at IP Addressing considerations, the importance of testing, and additional considerations such as monitoring of Replication health. Stay tuned for more!