Back in May 2016, Microsoft announced the general availability of Azure Site Recovery (ASR) in the new Azure portal. True, ASR had been around before then, but in the Classic portal. With the release of ASR in the new Azure portal, Microsoft combined the Site Recovery and Backup services into a single “Recovery Services” solution.

When working with ASR, you protect your targeted machines through replication. This could either be virtual or physical machines and can be hosted on Hyper-V or VMware.

When you protect and replication a target machine, you can trigger an individual machine failover, or develop a more complex orchestrated method through Recovery Plans.

One of the nice features of ASR is the ability to initiate a Test Failover; so as to validate your BCDR playbook prior to an actual legitimate disaster.


Original Test Failover Settings

Originally, when initiating a Test Failover in ASR, there was a hard-coded limit enforced. Through the replication and orchestration process, ASR would programmatically create the Virtual Machine(s) in Azure, and attach the disk(s) that had been replicated. It would then stop, and wait for a human to tell it that the test was complete.

However, the Test Failover mechanism had a limit of 14 days. This meant that the Virtual Machine(s) that were created, could only be left running in Azure for a maximum of 14 days; then the system would force-complete the test, and tear down the systems.

In most circumstances, this would usually suffice for testing needs. Many organizations could/would use this Test Failover feature to effectively test how the Virtual Machine would come up if actual failover was done, test Windows patches, new versions of application code, etc. prior to deploying in Production. And it worked well. The Test Failover functionality empowered people and teams to test against the Production version of the systems/applications, without affecting actual Production.


New Test Failover Settings

But, Microsoft is always improving, enhancing, and refining their tools and products; and most importantly, are listening to their customers.

While the 14-day limit in the Test Failover process may have worked for most organizations in most circumstances, it didn’t work for all.

So Microsoft changed it!!! Now we no longer have the 14-day force-complete/tear down!!! We can now keep our Test Failover machines running as long as we need.

With this change, some of the options have now changed. For example, a Cleanup Test Failover button has been added to the Recovery Plan and replicated item, and the failover job no longer includes the “Complete Teat” option.


So now we can use ASR’s Test Failover to perform longer testing cycles beyond the original 14 days. You can read more about how ASR Test failover works here.