- Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
- Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
- Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016
If you’ve ever been part of planning a disaster recovery (DR) strategy (or maybe you’re in the process of doing it now), you know what a huge, and potentially expensive, process it can be. If you’re building out your own DR site, you’re looking at data, power, cooling, floor space, physical security—the list goes on. If you opt for a colocation (colo) facility, you’re still looking at server hardware purchases, networking, storage, and monthly cost for floor space services from the colo such as environmental monitoring and security.
This is where Azure Site Recovery can be of value to your organization. Rather than building out a DR site (whether in your facility or a colo facility), you can use Azure Site Recovery to replicate your critical infrastructure from your on-premises data center into Azure. Azure Site Recovery uses System Center Virtual Machine Manager (SCVMM) to replicate VMs inside of SCVMM clouds into Azure as Azure virtual machines. During a recovery, orchestration is available to ensure that VMs are brought up in the order you specify.
Azure Site Recovery on-premises to Azure overview diagram
You’ll need a few things to get started with Azure Site Recovery. First, you’ll need an Azure account that has a configured storage account. Geo-replication must be enabled on the storage account, and it must exist in the same geographic region as your Azure Site Recovery service. The current cost for Azure protection of VMs is $16 per VM per month.
In addition to the Azure subscription, you’ll also need to have an SCVMM server running 2012 R2 that has at least one cloud configured. All VMs will have to be configured as Generation 1 VMs because Azure does not currently support Generation 2 VMs. The VMs will also need to be running a supported Azure OS: Windows Server 2008 (or later) or a supported Linux variant (CentOS, openSUSE, SUSE, or Ubuntu). VMs should be configured in supported Azure configuration: no static IP addresses, only one NIC, no iSCSI disks (in the VM), no Shared VHD, OS disk sized 20MB to 127GB, and data disks sized 20MB to 1023GB.
You can review a full list of prerequisites that covers all of the options. After speaking to a few colleagues and friends running Hyper-V, I found that 95 percent of our combined infrastructure would meet the prerequisites with the glaring exception of Generation 2 VMs. I am hoping that Microsoft will add support for Generation 2 VMs to Azure soon; but, as of today, it isn’t supported.
Last, I highly recommend having either ExpressRoute or Site-to-Site connectivity into your Azure networking. This allows your on-premises network to have seamless connectivity to Azure and makes the failover process much smoother.
Create your storage account ^
To get started, we’ll need to create a storage account in Azure. In the Azure Management Portal, click New in the bottom left corner. Next, click Data Services, Storage, and Quick Create. Ensure that Geo-Redundant Replication is selected and note the location/affinity group that you’ve selected. When you’re done, click Create Storage Account.
Creating a storage account in Azure with geo-redundant replication
Create, export, and import a certificate ^
System Center Virtual Machine Manager requires a certificate for secure communications with Azure. You can use either a self-signed certificate or a certificate from a public CA. For the purposes of this tutorial, we’ll be creating a self-signed certificate.
Start by downloading the Windows SDK installer. When you run it, you’ll only need to install the Windows Software Development Kit portion of the SDK.
Installing Windows Software Development Kit from the Windows SDK
After the install, open a command prompt with Administrative rights and change the directory to C:\Program Files (x86)\Windows Kits\%version%\bin\x64. In my lab, I’m using Server 2012 R2, meaning %version% is 8.1 for me. Next, run the following command to generate the cert:
makecert.exe -r -pe -n CN=AzureSiteRecoveryCert -ss my -sr localmachine -eku 18.104.22.168.22.214.171.124.2 -len 2048 -e 01/01/2016 C:\AzureSiteRecovery.cer
Using makecert to create a certificate for Azure Site Recovery
Last, we’ll need to export the certificate. Start by opening the Certificate Manager MMC console:
Browse to Personal and then Certificates, and find the AzureSiteRecoveryCert that we just created. Right-click the certificate and choose All Tasks and then Export.
Exporting the certificate for Azure Site Recovery in Certificate Manager
Run through wizard and make sure to check the Yes, export private key option since we’ll be putting the cert on another server. Also, ensure that you check the Personal Information Exchange – PKCS #12 (.pfx) file format for the file.
Last, we’ll need to import the certificate to our SCVMM server. (This assumes you didn’t create the certificate on the VMM server. If you did, you can skip this last step.) In Certificate Manager, right-click the Personal store, choose All Tasks, and then select Import.
Importing the certificate for Azure Site Recovery in Certificate Manager
Run through the wizard. Your certificate should now be on the VMM server.
At this point, we have some of our basic prerequisites out of the way and can start configuring our servers. In the next part of our series on Azure Site Recovery (on-premises to Azure), I’ll cover configuring the Hyper-V and Virtual Machine Manager Servers as well as configuring the cloud protection.