Leveraging Microsoft Azure as your disaster recovery/failover data center

Microsoft has put out in Preview a technology that will completely change how we view disaster recovery and failover of virtual machines and the benefits of the Cloud! What Azure Site Recovery (ASR) does, in a nutshell, is replicate Virtual Machines (VMs) from an on-premise datacenter to Azure on a regular basis, and then the organization can failover their on-premise datacenter so that the VMs are now running in Azure. AND the kicker, Microsoft is doing this at a cost of US$27 per protected VM per month (with an added cost of $60 to ~$150/mo when the VM is failed over and actually running in Azure, which presumably will being during a test or disaster, and the run time in Azure might be limited to a few hours or few days).

Organizations no longer need to setup their own secondary datacenters, buy space in racks and setup and maintain hardware, no longer have to pay thousands of $$$ a month for the production of a server, this is simply the monthly protection fee and usage if any.

This article goes through the various business scenarios we've been using Azure Site Recovery for as well as a Step by Step guide on how to "try out" ASR in your environment.

Background:

Microsoft has provided this HyperV Replica functionality between Private Clouds (corporate datacenter to corporate datacenter) for some time now, but for organization that don't have secondary datacenters themselves or want to get out of the secondary datacenter business, there's a need/desire to replicate their VMs and leverage Microsoft Azure as the "failover datacenter".

This solution was highlighted in this TechEd 2014 session.

To make this scenario work, the following assumptions exist:

• The Hypervisor used on-premise is HyperV (preferably based on the latest HyperV 2012 R2)
• A VMM 2012R2 server is setup and is configured to "see" the on-premise datacenter AND configured to access the Azure Subscription
• An Azure Subscription

I highly suggest anyone doing anything Windows Server, System Center, Azure related fiddle with this! In the current Preview Program, you can gain access to ASR for free within a 30-day Azure Trial where you get a chance to work with an upcoming technology that WILL be fundamental in organizations being able to do Disaster Recovery failover from on-prem to Azure.

Step by Step documentation is provided by Microsoft, however I wrote my step-by-step guide below that takes in account various quirks we've found to make the thing work, and I think it is simpler and more direct approach to getting your hands dirty with Azure Site Recovery. In any case, you can refer back to the Microsoft guide as a general "framework" as you see fit. As you walk the process, if you get stuck anywhere, just leave a blog comment and I'll post responses.

So my step by steps:

• Have a working Microsoft System Center Virtual Machine Manager (VMM) 2012R2 server and a HyperV host connected to Active Directory that'll be the basis of your on-premise virtual machine environment.
• Within VMM, create a "cloud" and assign the HyperV host to that cloud
• Right click the cloud and create a VM and place that VM on the HyperV host. Make sure the Property on the VM Operating System says it is Win2008 or higher that is supported by Azure. By default, VMs take on the OS property of "undefined" and that'll cause a failover later when you try to replicate the VM to Azure as Azure only wants replicas of Azure supported OSs. Also, when you create the VM, if you have the option, make sure it is a Generation 1 VM. Azure currently does not support Gen2 VMs and that'll trip you up.
• Use an existing Azure Subscription account and login, or sign up for a free trial by going to this site and selecting "try it now."
• Within the Azure Portal screen, scroll down to Recovery Services (on the left menu), and click on "Create a New Vault" (this is where your VMs will be replicated to) which will bring up a Data Services / Recovery Services / Site Recovery Vault option, select Quick Create
• For the name of the Vault, give it something you'd remember, in my case, I'll call it RandsVault, and I'll choose the Region West US since I'm in the Western United States, then click Create Vault
• Once the Vault has been created, click on the Right Arrow next to the name of your vault. Under Setup Recovery, choose "Between an on-premise site and Microsoft Azure" so that you are telling the configuration settings that you are going to be replicating between your on-premise datacenter and Azure in the cloud.
• You will now see a list of things you need to do which the first thing is to create a key exchange of certificates between Microsoft Azure and your VMM server.
• From a Command Prompt, run:  makecert.exe -r -pe -n CN=CertificateName -ss my -sr localmachine -eku 1.3.6.1.5.5.7.3.2 -len 2048 -e 01/01/2016 CertificateName.cer   that will create a self-signed certificate for your VMM host (the makecert.exe program can be found from a Visual Studio installation in the c:Program FilesWindows Kits?.?binx64  You can download a free copy of Visual Studio Express for Windows Desktops here. Note: Visual Studio is not used for anything else on this process, so you could install VS on a separate system, all you are looking to do is get a copy of the makecert.exe utility)
• Export a PFX copy of the cert you just created by running MMC from a Command Prompt, doing a File Add/Remote Snap-in, choose Certificates for the Local Computer, and then browsing the Certificates Tree to Personal Certificates. You'll see the name of the certificate you just created. Right click the Certificate and choose "Export", click Next, then choose "Yes, export the private key", select Personal Information Exchange (PFX) and choose to "include all certificates in the certification path if possible" and choose "Export all extended properties", the click Next. Click Password and choose a password, could be something simple like 123456, Click Next. Then select a name that you want to name this PFX file (in my case, I'll call it RandVaultExport, then click Finish to export the cert.
• Go back to the Azure Portal, and click on "Manage Certificate" that is under 1-Configure the Vault of the main Recovery Services page, and select the CER file of the first certificate your created (the one you created with MakeCert)
• Click "Get Vault Key" and copy the Vault Key (you'll use this in an upcoming step)
• Still, on your VMM Server, it's time to install the VMM ASR Provider software. Go to the Azure Portal, click on "Download Microsoft Azure Site Recovery Provider" within the Azure Portal under the 2-Prepare VMM Servers, and run the installer. Choose to Install, click Next, enter in the Proxy settings if you use a Proxy to gain access to the Internet from this VMM server (otherwise leave blank), click Next. Click on Browser to select the certificate you had exported to PFX. Paste in the Vault Key that you saved earlier, then click Next. For Data Encryption, you can choose to encrypt content but for the sake of simplicity for this test, you can leave the Data Encryption unchecked and click Next. Click to Register the VMM server. Click Close that will automatically start the VMM service on the system and establish connection to Azure.
• Back to the Azure Portal, select "Add an Azure Storage Account" in the 3-Prepare Resources section of the Recovery Services. Under Quick Create, give your store a name (in my case, I'm calling it RandVaultStore), select a location (such as West US), and choose the redundancy you want (Locally redundant means Microsoft has multiple redundant copies, but you are at risk of downtime if a site is down. The Geo-Redundant option replicates copies of your storage in multiple Microsoft Sites, providing you redundancy of your data across multiple Microsoft Datacenters (this costs a little more for storage). Azure Site Recovery requires the storage to be Geo-Redundant. Click to create the storage account.
• On your HyperV Host servers, do the following:
  • On your HyperV server, from an Administrator RunAs account, from a Command Prompt, run  REG.EXE add "HKLMSOFTWAREMicrosoftWindows Azure BackupConfig" /f /t REG_DWORD /v HttpsCertValidationEnabled /d 0   (this will allow for an Administrator role of the HyperV Agent that is required)
  • On your HyperV server, go to the Azure Portal and select the "Download the Microsoft Azure Recovery Services Agent" and run the agent on your HyperV host.
  • Still on your HyperV host server, go in to the Administrative Tool / Services, scroll down and find the Microsoft Azure Recovery Service Agent and change the agent from starting Manually to starting Automatically. Then start the agent. This agent allows your HyperV host to talk to Azure…
  • Repeat the installation of the RunAs and Agent install on all HyperV host servers that you want VMs replicated to Azure
• Assuming all of the above is setup and working right, in your VMM Console, when you click on the Navigation Bar "Settings" (under the VMs and Services, Fabric, Library, and Jobs options, you'll see that the VMM server should be registered to the Hyper-V Recovery Manager Vault
• You can now start protecting VMs by replicating them from on-prem to Azure. From the Azure Portal, click on Protected Items at the top of the Azure screen (which is inline with Dashboard, Protected Items, Recovery Plans, Resources, Jobs) and you'll see your VMM clouds (in my case, I see my TokyoCloud and my SFCloud)
• Click on the cloud you want to protect (the one that you have test VMs in that you want to replicate to Azure), then click Configure Protection Settings
• Select a Target (Microsoft Azure), you'll see the Storage Account location you noted earlier is set by default. You can change the Copy Frequency, Recovery Points, Snapshot Frequency, and Start time, although the defaults are fine, click Save.
• After the configuration takes, be in the Azure Portal / Recovery Services / Protected Items / {your cloud} section and click on Virtual Machines and click "Enable Protection" or the + to add a new virtual machines to protect. Note: the VM you select needs to have the OS property set to something that Azure supports (ie: Win2008R2, Win2012R2) and the VM needs to be a Generation 1 VM. You can change the OS property of a VM by right-clicking the VM in VMM and choose properties. On the General Page, you can select the Operating System of the VM. Also on this General Page, you can see if the VM is a Gen1 or Gen2 VM. If it says it is a Gen2 VM, you need to recreate the VM as a Gen1 VM for now.
• Select the VM and then wait (this could take 15 minutes for a tiny VM with a high speed network connection to the Internet, or it could take a few hours for a large VM (ie: overnight)). The process is replicating the VM between on-premise and Azure, so be patient the first time on each VM.

• Once replicated successfully, go to the Recovery Plans tab and create a recovery plan by pressing + to Create Plan, specify a Plan name (like "RandsRecPlan1") select source of your local VMM servers, and Target as Azure, then select the VMs that have successfully replicated to be part of your plan. My suggestion, pick just 1 VM to start, if you pick multiple VMs as part of the plan, they "all" have to successfully replicate over during a failover, and that can take a long long time. Save the plan

• Click to highlight the plan you just created and choose "failover" (you should do the "test failover" that'll copy the failover process without impacting the VMs, so that'll be smart to do in production, but for the sake of time of test VMs, just run a "failover" and it'll shutdown your VMs and prepare your VMs for failover). The VMs will be offline for a while as it copies over any new data from the last snapshot it created. A Planned Failover will copy over any unreplicated bits to make sure the target in Azure is most up to date, an unplanned failover will not replicate bits that have not yet been replicated that could lead to data loss. So if you have the ability to do a planned failover, that'll ensure data integrity in the failover process.
• When the failover preparation has been completed, you then have to click the "commit" at the bottom of the Recovery Plan page, that'll then switch the VMs, networking, everything over to Azure
• Once the thing shows that the commit took, now you go into the Virtual Machines section of the Azure Portal and within the normal Azure management UI, you'll see your VM happily running as a virtual machine.

Obviously to do this right, you'd need to do DNS changes so that if you had an app going to a public DNS address, that it now goes to the address that Azure is publishing, so there will be some fine tuning needed after a failover. However for this Preview, to be able to quickly see how you can simply replicate VMs to Azure and then failover the VMs to Azure, this is a pretty incredible offering!

End of the day, On-site Datacenter to Azure DR failover and failback for $27/month per VM!