Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

How to: Protect physical servers with Azure Site Recovery

How to: Protect physical servers with Azure Site Recovery 

Hello Folks,

Last week I was reading about the devastating fires in western Canada. I happen to come across a post from Dave Kawula a Canadian MVP who has been a collaborator to the CANITPRO team and Microsoft Canada for a long time. It was about how a group of MVP were able to help the Northern Lights School District of La Ronge in Northern Saskatchewan, when the town was threatened by a massive forest fire. An estimated 7,000 people who were forced to leave their communities in the La Ronge area of Saskatchewan.

I’m so proud of the MVPs who gave their time and efforts to help communities in need. When I asked Dave about it he said:

“It was a no brainer. Now we will setup something official for MVP’s around the world to help out when called on. Not just to speak at conferences and user groups but to really help out when needed. It is a great honour to be able to help out those in their time of need.”

That story reminded me that it’s important for any organization to ensure they have a proper DR (Disaster Recovery) plan. In Azure, the Site Recovery service is a part of a robust business continuity and disaster recovery (BCDR) solution, that helps protects your on-premises physical servers and virtual machines. It does so by orchestrating and automating the replication and the failover of your on-premises workloads to Azure, or to a secondary datacenter.

Learn More here:

Azure Site Recovery works in the following scenarios:

Replicate to                   

Replicate from (on-premises)          



Hyper-V site

Replicate virtual machine on one or more on-premises Hyper-V host servers that are defined as a Hyper-V site to Azure. No VMM server required.


VMM server

Replicate virtual machines on one or more on-premises Hyper-V host servers located in a VMM cloud to Azure.


Physical Windows server

Replicate a physical Windows or Linux server to Azure


VMware virtual machine

Replicate VMware virtual machines to Azure

Secondary datacenter

VMM server

Replicate virtual machines on on-premises Hyper-V host servers located in a VMM cloud to a secondary VMM server in another datacenter

Secondary datacenter

VMM server with SAN

Replicate virtual machines on on-premises Hyper-V host servers located in a VMM cloud to a secondary VMM server in another datacenter using SAN replication

Secondary datacenter

Single VMM server

Replicate virtual machines on on-premises Hyper-V host servers located in a VMM cloud to a secondary cloud on the same VMM server

Today we’ll look at how we can setup Azure to facilitate the replication on a physical server from my Datacenter (the closet in my basement) to Azure.

Please note: We will do this in 2 parts today the Azure side config.  Next post, the On-Prem side config.

But before we start. Protected physical servers or VMware virtual machines running Windows have a number of requirements.

  • A supported 64-bit operating system: Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2 with at least SP1.
  • The host name, mount points, device names, Windows system path (eg: C:\Windows) should be in English only.
  • The operating system should be installed on C:\ drive.
  • Only basic disks are supported. Dynamic disks aren’t supported.

You’ll need to provide an administrator account (must be a local administrator on the Windows machine) to push install the Mobility Service on Windows servers.If the provided account is a non-domain account you’ll need to disable Remote User Access control on the local machine.

To do this add the LocalAccountTokenFilterPolicy DWORD registry entry with a value of 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.

You will also need a pre-configure virtual network configure in your Azure subscription.  Pleas ensure that this is done ahead of time since it will take a few minutes to populate throughout the system.

Step 1: Create a Site Recovery Vault

From the Azure management Portal. Click New, Expand Data Services (1)  Recovery Services (2)  and click Site Recovery Vault (3).


Then Click Quick Create (1) . In Name, enter a friendly name to identify the vault (2) . In Region, select the geographic region for the vault where you want it located (3)  and click Create vault (4).


Step 2: Deploy a Configuration Server

The configuration server coordinates communication between protected machines, the process server, and master target servers in Azure. It sets up replication and coordinates recovery in Azure when failover occurs.

Once the vault is created, in the Recovery Services page, click it to open the Quick Start page.  and in the dropdown list, select Between an on-premises site with VMware/physical servers and Azure.


Once you selected the right item in the list above the Quick Start page will change and in the Prepare Target(Azure) Resources section, click Deploy Configuration Server.


You will then be prompted to fill in the information in the following dialogue box.  (this is where the pre-configure Vnet comes into play) and click the checkbox to start the process.  A standard A3 vm based on an Azure Site Recovery Windows Server 2012 R2 gallery image will be created in your subscription for the configuration server.


After the configuration server is deployed.  please note the public IP address assigned to it on the Virtual Machines page in the portal and note the configuration of the ENDPOINTS for the public HTTPS port mapped to private port 443. You’ll need this information later when you register the master target and process servers with the configuration server.

The configuration server is deployed with these endpoints:

  • HTTPS: used to coordinate communication between component servers and Azure over the internet. 
  • Custom: Public port is used for failback tool communication over the internet.
  • the PowerShell: Private port 5986 and Remote desktop: Private port 3389 are self explanatory.

For the rest of the steps, please go to:

Related posts