Download Microsoft: Azure Site Recovery

Table of Contents
Overview
What is Site Recovery?
How does Site Recovery work?
How does Hyper-V replication to Azure work?
What workloads can you protect?
Site Recovery support matrix
FAQ
Watch an introduction
Get Started
Replicate VMware VMs to Azure
Replicate physical servers to Azure
Replicate Hyper-V VMs to Azure (with VMM)
Replicate Hyper-V VMs to Azure
Replicate Hyper-V VMs to a secondary site (with VMM)
Replicate VMware VMs and physical servers to a secondary site
Replicate VMware VMs to Azure in a multi-tenant deployment (CSP)
How To
Plan
Deployment prerequisites
Plan network infrastructure
Plan capacity and scale VMware replication to Azure
Deployment Planner for VMware replication to Azure
Capacity Planner for Hyper-V replication
Configure
Set up the source environment
Set up the target environment
Configure replication settings
Deploy the Mobility service for VMware replication
Enable replication
Fail over and fail back
Fail over protected machines
Set up recovery plans
Run a test failover
Reprotect machines after failover
Fail back from Azure
Migrate
Migrate to Azure
Migrate between Azure regions
Migrate AWS Windows instances to Azure
Workloads
Active Directory and DNS
SQL Server
SharePoint
Dynamics AX
RDS
Exchange
SAP
Other workloads
Automate replication
Automate Hyper-V replication to Azure (no VMM)
Automate Hyper-V replication to Azure (with VMM)
Automate Hyper-V replication to a secondary site (with VMM)
Manage
Edit replication settings
Manage process servers in Azure
Manage the configuration server
Manage scaled-out process servers
Manage vCenter servers
Remove servers and disable protection
Monitor and troubleshoot
Reference
PowerShell
PowerShell
PowerShell classic
REST
Related
Azure Automation
Resources
Learning path
Forum
Blog
Pricing
Service updates
What is Site Recovery?
3/14/2017 • 3 min to read • Edit Online
Welcome to the Azure Site Recovery service! This article provides a quick overview of the service.
Outages are causes by natural events and operational failures. Your organization needs a business continuity
and disaster recovery (BCDR) strategy so that, during planned and unplanned downtime, data stays safe, apps
remain available, and business recovers to normal working conditions as soon as possible.
Azure Recovery Services contribute to your BCDR strategy. The Azure Backup service keeps your data safe and
recoverable. Site Recovery replicates, fails over, and recovers workloads, so that they remain available when
failure occurs.
What does Site Recovery provide?
Disaster recovery in the cloud—You can replicate workloads running on VMs and physical servers to
Azure, rather than to a secondary site. This eliminates the cost and complexity of maintaining a secondary
datacenter.
Flexible replication for hybrid environments—You can replicate any workload running on supported onpremises Hyper-V VMs, VMware VMs, and Windows/Linux physical servers.
Migration—You can use Site Recovery to migrate on-premises AWS instances to Azure VMs, or to migrate
Azure VMs between Azure regions.
Simplified BCDR—You can deploy replication from a single location in the Azure portal. You can run simple
failovers and failback of single and multiple machines.
Resilience—Site recovery orchestrates replication and failover, without intercepting application data.
Replicated data is stored in Azure storage, with the resilience that provides. When failover occurs, Azure VMs
are created based on the replicated data.
Replication performance—Site Recovery provides replication frequency as low as 30 seconds for Hyper-V,
and continuous replication for VMware. You can set recovery point objective (RPO) thresholds to control how
often data recovery points are created, and you can reduce recovery time objective (RTO) with Site Recovery's
automated recovery process, and integration with Azure Traffic Manager
Application consistency—Machines replicate using application-consistent snapshots. In addition to
capturing disk data, application-consistent snapshots capture all data in memory, and all transactions in
process.
Testing without disruption—You can easily run test failovers to support disaster recovery drills, without
affecting production environments.
Flexible failover and recovery—You can run planned failovers for expected outages with zero-data loss, or
unplanned failovers with minimal data loss (depending on replication frequency) for unexpected disasters.
You can easily fail back to your primary site when it's available again.
Custom recovery plans—Recovery plans allow you to model and customize failover and recovery of multitier applications that are spread over multiple VMs. You order groups within plans, and add scripts and
manual actions. Recovery plans can be integrated with Azure automation runbooks.
Multi-tier apps—You can create recovery plans for sequenced failover and recovery of multi-tiered apps.
You can group machines in different tiers (for example database, web, app) within a recovery plan, and
customize how each group fails over and starts up.
Integration with existing BCDR technologies—Site Recovery integrates with other BCDR technologies.
For example, you can use Site Recovery to protect the SQL Server backend of corporate workloads, including
native support for SQL Server AlwaysOn, to manage the failover of availability groups.
Integration with the automation library—A rich Azure Automation library provides production-ready,
application-specific scripts that can be downloaded and integrated with Site Recovery.
Simple network management—Advanced network management in Site Recovery and Azure simplifies
application network requirements, including reserving IP addresses, configuring load-balancers, and
integrating Azure Traffic Manager for efficient network switchovers.
What's supported?
SUPPORTED
DETAILS
Which regions are supported for Site Recovery?
Supported regions
What can I replicate?
On-premises VMware VMs, Hyper-V VMs, Windows and
Linux physical servers.
What operating systems do replicated machines need?
Supported operating systems for VMware VMs
For Hyper-V VMs, any guest OS supported by Azure and
Hyper-V is supported.
Operating systems for physical servers
Where can I replicate to?
To Azure storage, or to a secondary datacenter
For Hyper-V, only VMs on Hyper-V hosts managed in
System Center VMM clouds can replicate to a secondary
datacenter.
What VMware servers/hosts do I need?
VMware VMs you want to replicate can be managed by
supported vSphere hosts/vCenter servers
What workloads can I replicate
You can replicate any workload running on a supported
replication machine. In addition, the Site Recovery team have
performed app-specific testing for a number of apps.
Which Azure portal?
Site Recovery can be deployed in both the newer Azure portal, and in the Azure classic portal .
In the Azure classic portal, you can support Site Recovery with the classic services management model.
In the Azure portal, you can support the classic model, or the newer Resource Manager deployment model.
The classic portal should only be used to maintain existing Site Recovery deployments. You can't create new
vaults in the classic portal.
Next steps
Read more about workload support
Learn more about Site Recovery architecture and components
How does Azure Site Recovery work?
3/14/2017 • 12 min to read • Edit Online
This article describes underlying architecture of the Azure Site Recovery service, and the components that make it
work.
Post any comments at the bottom of this article, or in the Azure Recovery Services Forum.
Replicate to Azure
You can replicate the following to Azure:
VMware: On-premises VMware VMs running on a supported host. You can replicate VMware VMs running
supported operating systems
Hyper-V: On-premises Hyper-V VMs running on supported hosts.
Physical machines: On-premises physical servers running Windows or Linux on supported operating systems.
You can replicate Hyper-V VMs running any guest operating system supported by Hyper-V and Azure.
VMware to Azure
Here's what you need for replicating VMware VMs to Azure.
AREA
COMPONENT
DETAILS
Azure
In Azure you need an Azure account, an
Azure storage account, and an Azure
network.
Storage and network can be Resource
Manager accounts, or classic accounts.
Replicated data is stored in the storage
account, and Azure VMs are created
with the replicated data when failover
from your on-premises site occurs. The
Azure VMs connect to the Azure virtual
network when they're created.
Configuration server
A single management server (VMWare
VM) runs all on-premises components configuration server, process server,
master target server
The configuration server coordinates
communications between on-premises
and Azure, and manages data
replication.
Process server:
Installed by default on the configuration
server.
Acts as a replication gateway. Receives
replication data, optimizes it with
caching, compression, and encryption,
and sends it to Azure storage.
The process server also handles push
installation of the Mobility service to
protected machines, and performs
automatic discovery of VMware VMs.
As your deployment grows you can add
additional separate dedicated process
servers to handle increasing volumes of
replication traffic.
AREA
COMPONENT
DETAILS
Master target server
Installed by default on the on-premises
configuration server.
Handles replication data during failback
from Azure.
If volumes of failback traffic are high,
you can deploy a separate master
target server for failback.
VMware servers
VMware VMs are hosted on vSphere
ESXi servers, and we recommend a
vCenter server to manage the hosts.
You add VMware servers to your
Recovery Services vault.
I
Replicated machines
The Mobility service will be installed on
each VMware VM you want to replicate.
It can be installed manually on each
machine, or with a push installation
from the process server.
Figure 1: VMware to Azure components
Replication process
1. You set up the deployment, including Azure components, and a Recovery Services vault. In the vault you specify
the replication source and target, set up the configuration server, add VMware servers, create a replication
policy, deploy the Mobility service, enable replication, and run a test failover.
2. Machines start replicating in accordance with the replication policy, and an initial copy of the data is replicated
to Azure storage.
3. Replication of delta changes to Azure begins after the initial replication finishes. Tracked changes for a machine
are held in a .hrl file.
Replicating machines communicate with the configuration server on port HTTPS 443 inbound, for
replication management.
Replicating machines send replication data to the process server on port HTTPS 9443 inbound (can be
configured).
The configuration server orchestrates replication management with Azure over port HTTPS 443
outbound.
The process server receives data from source machines, optimizes and encrypts it, and sends it to Azure
storage over port 443 outbound.
If you enable multi-VM consistency, then machines in the replication group communicate with each
other over port 20004. Multi-VM is used if you group multiple machines into replication groups that
share crash-consistent and app-consistent recovery points when they fail over. This is useful if machines
are running the same workload and need to be consistent.
4. Traffic is replicated to Azure storage public endpoints, over the internet. Alternately, you can use Azure
ExpressRoute public peering. Replicating traffic over a site-to-site VPN from an on-premises site to Azure isn't
supported.
Figure 2: VMware to Azure replication
Failover and failback
1. After you verify that test failover is working as expected, you can run unplanned failovers to Azure as required.
Planned failover isn't supported.
2. You can fail over a single machine, or create recovery plans, to fail over multiple VMs.
3. When you run a failover, replica VMs are created in Azure. You commit a failover to start accessing the
workload from the replica Azure VM.
4. When your primary on-premises site is available again, you can fail back. You set up a failback infrastructure,
start replicating the machine from the secondary site to the primary, and run an unplanned failover from the
secondary site. After you commit this failover, data will be back on-premises, and you need to enable replication
to Azure again. Learn more
There are a few failback requirements:
Temporary process server in Azure: If you want to fail back from Azure after failover you'll need to set up an
Azure VM configured as a process server, to handle replication from Azure. You can delete this VM after failback
finishes.
VPN connection: For failback you'll need a VPN connection (or Azure ExpressRoute) set up from the Azure
network to the on-premises site.
Separate on-premises master target server: The on-premises master target server handles failback. The
master target server is installed by default on the management server, but if you're failing back larger volumes
of traffic you should set up a separate on-premises master target server for this purpose.
Failback policy: To replicate back to your on-premises site, you need a failback policy. This is automatically
created when you created your replication policy.
Figure 3: VMware/physical failback
Physical to Azure
When you replicate physical on-premises servers to Azure, replication uses also the same components and
processes as VMware to Azure, but note these differences:
You can use a physical server for the configuration server, instead of a VMware VM
You will need an on-premises VMware infrastructure for failback. You can't fail back to a physical machine.
Hyper-V to Azure
Here's what you need for replicating Hyper-V VMs to Azure.
AREA
COMPONENT
DETAILS
Azure
In Azure you need a Microsoft Azure
account, an Azure storage account, and
a Azure network.
Storage and network can be Resource
Manager-based, or classic accounts.
Replicated data is stored in the storage
account, and Azure VMs are created
with the replicated data when failover
from your on-premises site occurs.
The Azure VMs connect to the Azure
virtual network when they're created.
AREA
COMPONENT
DETAILS
VMM server
Hyper-V hosts located in VMM clouds
If Hyper-V hosts are managed in VMM
clouds, you register the VMM server in
the Recovery Services vault.
On the VMM server you install the Site
Recovery Provider to orchestrate
replication with Azure.
You need logical and VM networks set
up to configure network mapping. A
VM network should be linked to a
logical network that's associated with
the cloud.
Hyper-V host
Hyper-V servers can be deployed with
or without VMM server.
If there's no VMM server, the Site
Recovery Provider is installed on the
host to orchestrate replication with Site
Recovery over the internet. If there's a
VMM server, the Provider is installed on
it, and not on the host.
The Recovery Services agent is installed
on the host to handle data replication.
Communications from both the
Provider and the agent are secure and
encrypted. Replicated data in Azure
storage is also encrypted.
Hyper-V VMs
You need one or more VMs on the
Hyper-V host server.
Nothing needs to explicitly installed on
VMs
Replication process
1. You set up the Azure components. We recommend you set up storage and network accounts before you begin
Site Recovery deployment.
2. You create a Replication Services vault for Site Recovery, and configure vault settings, including:
Source and target settings. If you're not managing Hyper-V hosts in a VMM cloud, for the target you
create a Hyper-V site container, and add Hyper-V hosts to it. If Hyper-V hosts are managed in VMM, the
source is the VMM cloud. The target is Azure.
Installation of the Azure Site Recovery Provider and the Microsoft Azure Recovery Services agent. If you
have VMM the Provider will be installed on it, and the agent on each Hyper-V host. If you don't have
VMM, both the Provider and agent are installed on each host.
You create a replication policy for the Hyper-V site or VMM cloud. The policy is applied to all VMs located
on hosts in the site or cloud.
You enable replication for Hyper-V VMs. Initial replication occurs in accordance with the replication
policy settings.
3. Data changes are tracked, and replication of delta changes to Azure begins after the initial replication finishes.
Tracked changes for an item are held in a .hrl file.
4. You run a test failover to make sure everything's working.
Failover and failback process
1. You can run a planned or unplanned failover from on-premises Hyper-V VMs to Azure. If you run a planned
failover, then source VMs are shut down to ensure no data loss.
2. You can fail over a single machine, or create recovery plans to orchestrate failover of multiple machines.
3. After you run the failover, you should be able to see the created replica VMs in Azure. You can assign a public IP
address to the VM if required.
4. You then commit the failover to start accessing the workload from the replica Azure VM.
5. When your primary on-premises site is available again, you can fail back. You kick off a planned failover from
Azure to the primary site. For a planned failover you can select to failback to the same VM or to an alternate
location, and synchronize changes between Azure and on-premises, to ensure no data loss. When VMs are
created on-premises, you commit the failover.
Figure 4: Hyper-V site to Azure replication
Figure 5: Hyper-V in VMM clouds to Azure replication
Replicate to a secondary site
You can replicate the following to your secondary site:
VMware: On-premises VMware VMs running on a supported host. You can replicate VMware VMs running
supported operating systems
Physical machines: On-premises physical servers running Windows or Linux on supported operating systems.
Hyper-V: On-premises Hyper-V VMs running on supported Hyper-V hosts managed in VMM clouds. supported
hosts. You can replicate Hyper-V VMs running any guest operating system supported by Hyper-V and Azure.
VMware/physical to a secondary site
You replicate VMware VMs or physical servers to a secondary site using InMage Scout.
Components
AREA
COMPONENT
DETAILS
Azure
InMage Scout.
To obtain InMage Scout you need an
Azure subscription.
After you create a Recovery Services
vault, you download InMage Scout and
install the latest updates to set up the
deployment.
Process server
Located in primary site
You deploy the process server to
handle caching, compression, and data
optimization.
It also handles push installation of the
Unified Agent to machines you want to
protect.
Configuration server
Located in secondary site
The configuration server manages,
configure, and monitor your
deployment, either using the
management website or the
vContinuum console.
vContinuum server
Optional. Installed in the same location
as the configuration server.
It provides a console for managing and
monitoring your protected
environment.
Master target server
Located in the secondary site
The master target server holds
replicated data. It receives data from
the process server, creates a replica
machine in the secondary site, and
holds the data retention points.
The number of master target servers
you need depends on the number of
machines you're protecting.
If you want to fail back to the primary
site, you need a master target server
there too. The Unified Agent is installed
on this server.
VMware ESX/ESXi and vCenter
server
VMs are hosted on ESX/ESXi hosts.
Hosts are managed with a vCenter
server
You need a VMware infrastructure to
replicate VMware VMs.
VMs/physical servers
Unified Agent installed on VMware VMs
and physical servers you want to
replicate.
The agent acts as a communication
provider between all of the
components.
Replication process
1. You set up the component servers in each site (configuration, process, master target), and install the Unified
Agent on machines that you want to replicate.
2. After initial replication, the agent on each machine sends delta replication changes to the process server.
3. The process server optimizes the data, and transfers it to the master target server on the secondary site. The
configuration server manages the replication process.
Figure 6: VMware to VMware replication
Hyper-V to a secondary site
Here's what you need for replicating Hyper-V VMs to a secondary site.
AREA
COMPONENT
Azure
You need a Microsoft Azure account.
VMM server
We recommend a VMM server in the
primary site, and one in the secondary
site
DETAILS
Each VMM server should be connected
to the internet.
Each server should have at least one
VMM private cloud, with the Hyper-V
capability profile set.
You install the Azure Site Recovery
Provider on the VMM server. The
Provider coordinates and orchestrates
replication with the Site Recovery
service over the internet.
Communications between the Provider
and Azure are secure and encrypted.
AREA
COMPONENT
Hyper-V server
One or more Hyper-V host servers in
the primary and secondary VMM
clouds.
DETAILS
Servers should be connected to the
internet.
Data is replicated between the primary
and secondary Hyper-V host servers
over the LAN or VPN, using Kerberos or
certificate authentication.
Hyper-V VMs
Located on the source Hyper-V host
server.
The source host server should have at
least one VM that you want to
replicate.
Replication process
1. You set up the Azure account.
2. You create a Replication Services vault for Site Recovery, and configure vault settings, including:
The replication source and target (primary and secondary sites).
Installation of the Azure Site Recovery Provider and the Microsoft Azure Recovery Services agent. The
Provider is installed on VMM servers, and the agent on each Hyper-V host.
You create a replication policy for source VMM cloud. The policy is applied to all VMs located on hosts in
the cloud.
You enable replication for Hyper-V VMs. Initial replication occurs in accordance with the replication
policy settings.
3. Data changes are tracked, and replication of delta changes to begins after the initial replication finishes. Tracked
changes for an item are held in a .hrl file.
4. You run a test failover to make sure everything's working.
Figure 7: VMM to VMM replication
Failover and failback
1. You can run a planned or unplanned failover between on-premises sites. If you run a planned failover, then
source VMs are shut down to ensure no data loss.
2. You can fail over a single machine, or create recovery plans to orchestrate failover of multiple machines.
3. If you perform an unplanned failover to a secondary site, after the failover machines in the secondary location
aren't enabled for protection or replication. If you ran a planned failover, after the failover, machines in the
secondary location are protected.
4. Then, you commit the failover to start accessing the workload from the replica VM.
5. When your primary site is available again, you initiate reverse replication to replicate from the secondary site to
the primary. Reverse replication brings the virtual machines into a protected state, but the secondary datacenter
is still the active location.
6. To make the primary site into the active location again, you initiate a planned failover from secondary to
primary, followed by another reverse replication.
Next steps
Learn more about the Hyper-V replication workflow.
Check prerequisites
How does Hyper-V replication to Azure work?
3/6/2017 • 6 min to read • Edit Online
Read this article to understand the architecture and workflows for Hyper-V replication to Azure using the Azure
Site Recovery service.
Post any comments at the bottom of this article, or in the Azure Recovery Services Forum.
You can replicate the following to Azure:
Hyper-V with VMM: VMs located on on-premises Hyper-V hosts managed in System Center Virtual MAchine
Manager (VMM) clouds. Hosts can be running any supported operating system. You can replicate Hyper-V VMs
running any guest operating system supported by Hyper-V and Azure.
Hyper-V without VMM: On-premises VMs located on Hyper-V hosts that aren't managed in VMM clouds.
Hosts can run any of the supported operating systems. You can replicate Hyper-V VMs running any guest
operating system supported by Hyper-V and Azure.
Architectural components
AREA
COMPONENT
DETAILS
Azure
In Azure you need a Microsoft Azure
account, an Azure storage account, and
a Azure network.
Storage and network can be Resource
Manager-based, or classic accounts.
Replicated data is stored in the storage
account, and Azure VMs are created
with the replicated data when failover
from your on-premises site occurs.
The Azure VMs connect to the Azure
virtual network when they're created.
VMM server
Hyper-V hosts located in VMM clouds
If Hyper-V hosts are managed in VMM
clouds, you register the VMM server in
the Recovery Services vault.
On the VMM server you install the Site
Recovery Provider to orchestrate
replication with Azure.
You need logical and VM networks set
up to configure network mapping. A
VM network should be linked to a
logical network that's associated with
the cloud.
AREA
COMPONENT
DETAILS
Hyper-V host
Hyper-V servers can be deployed with
or without VMM server.
If there's no VMM server, the Site
Recovery Provider is installed on the
host to orchestrate replication with Site
Recovery over the internet. If there's a
VMM server, the Provider is installed
on it, and not on the host.
The Recovery Services agent is installed
on the host to handle data replication.
Communications from both the
Provider and the agent are secure and
encrypted. Replicated data in Azure
storage is also encrypted.
Hyper-V VMs
You need one or more VMs on the
Hyper-V host server.
Nothing needs to explicitly installed on
VMs
Deployment steps
1. Azure: You set up the Azure components. We recommend you set up storage and network accounts before you
begin Site Recovery deployment.
2. Vault: You create a Recovery Services vault for Site Recovery, and configure vault settings, including
configuring source and target settings, setting up a replication policy, and enabling replication.
3. Source and target:
Hyper-V hosts in VMM clouds: As part of specifying source settings, you download and install the
Azure Site Recovery Provider on the VMM server, and the Azure Recovery Services agent on each
Hyper-V host. The source will be the VMM server. The target is Azure.
Hyper-V hosts without VMM: When you specify source settings, you download and install the
Provider and agent on each Hyper-V host. During deployment you gather the hosts into a Hyper-V
site, and specify this site as the source. The target is Azure.
4. Replication policy: You create a replication policy for the Hyper-V site or VMM cloud. The policy is applied
to all VMs located on hosts in the site or cloud.
5. Enable replication: You enable replication for Hyper-V VMs. Initial replication occurs in accordance with the
replication policy settings. Data changes are tracked, and replication of delta changes to Azure begins after the
initial replication finishes. Tracked changes for an item are held in a .hrl file.
6. Test failover: You run a test failover to make sure everything's working as expected.
Learn more about deployment:
Get started with Hyper-V VM replication to Azure - with VMM
Get started with Hyper-V VM replication to Azure - without VMM
Hyper-V replication workflow
Enable protection
1. After you enable protection for a Hyper-V VM, in the Azure portal or on-premises, the Enable protection
starts.
2. The job checks that the machine complies with prerequisites, before invoking the
CreateReplicationRelationship, to set up replication with the settings you've configured.
3. The job starts initial replication by invoking the StartReplication method, to initialize a full VM replication, and
send the VM's virtual disks to Azure.
4. You can monitor the job in the Jobs tab.
Initial replication
1. A Hyper-V VM snapshot snapshot is taken when initial replication is triggered.
2. Virtual hard disks are replicated one by one until they're all copied to Azure. It could take a while, depending on
the VM size, and network bandwidth. To optimize your network usage, see How to manage on-premises to
Azure protection network bandwidth usage.
3. If disk changes occur while initial replication is in progress, the Hyper-V Replica Replication Tracker tracks those
changes as Hyper-V Replication Logs (.hrl). These files are located in the same folder as the disks. Each disk has
an associated .hrl file that will be sent to secondary storage.
4. The snapshot and log files consume disk resources while initial replication is in progress.
5. When the initial replication finishes, the VM snapshot is deleted. Delta disk changes in the log are synchronized
and merged to the parent disk.
Finalize protection
1. After the initial replication finishes, the Finalize protection on the virtual machine job configures network
and other post-replication settings, so that the virtual machine is protected.
2. If you're replicating to Azure, you might need to tweak the settings for the virtual machine so that it's ready for
failover. At this point you can run a test failover to check everything is working as expected.
Delta replication
1. After the initial replication, delta synchronization begins, in accordance with replication settings.
2. The Hyper-V Replica Replication Tracker tracks the changes to a virtual hard disk as .hrl files. Each disk that's
configured for replication has an associated .hrl file. This log is sent to the customer's storage account after
initial replication is complete. When a log is in transit to Azure, the changes in the primary disk are tracked in
another log file, in the same directory.
3. During initial and delta replication, you can monitor the VM in the VM view. Learn more.
Replication synchronization
1. If delta replication fails, and a full replication would be costly in terms of bandwidth or time, then a VM is
marked for resynchronization. For example, if the .hrl files reach 50% of the disk size, then the VM will be
marked for resynchronization.
2. Resynchronization minimizes the amount of data sent by computing checksums of the source and target virtual
machines, and sending only the delta data. Resynchronization uses a fixed-block chunking algorithm where
source and target files are divided into fixed chunks. Checksums for each chunk are generated and then
compared to determine which blocks from the source need to be applied to the target.
3. After resynchronization finishes, normal delta replication should resume. By default resynchronization is
scheduled to run automatically outside office hours, but you can resynchronize a virtual machine manually.
For example, you can resume resynchronization if a network outage or another outage occurs. To do this,
select the VM in the portal > Resynchronize.
Retries
If a replication error occurs, there's a built-in retry. This logic can be classified into two categories:
CATEGORY
DETAILS
Non-recoverable errors
No retry is attempted. VM status will be Critical, and
administrator intervention is required. Examples of these
errors include: broken VHD chain; Invalid state for the replica
VM; Network authentication errors: authorization errors; VM
not found errors (for standalone Hyper-V servers)
Recoverable errors
Retries occur every replication interval, using an exponential
back-off that increases the retry interval from the start of the
first attempt by 1, 2, 4, 8, and 10 minutes. If an error persists,
retry every 30 minutes. Examples include: network errors; low
disk errors; low memory conditions
Protection and recovery lifecycle
Next steps
Check deployment prerequisites
Troubleshoot with:
Monitor and troubleshoot protection
Help from Microsoft support
Common errors and resolutions
What workloads can you protect with Azure Site
Recovery?
4/3/2017 • 8 min to read • Edit Online
This article describes workloads and applications you can replicate with the Azure Site Recovery service.
Post any comments or questions at the bottom of this article, or on the Azure Recovery Services Forum.
Overview
Organizations need a business continuity and disaster recovery (BCDR) strategy to keep workloads and data safe
and available during planned and unplanned downtime, and recover to regular working conditions as soon as
possible.
Site Recovery is an Azure service that contributes to your BCDR strategy. Using Site Recovery, you can deploy
application-aware replication to the cloud, or to a secondary site. Whether your apps are Windows or Linux-based,
running on physical servers, VMware or Hyper-V, you can use Site Recovery to orchestrate replication, perform
disaster recovery testing, and run failovers and failback.
Site Recovery integrates with Microsoft applications, including SharePoint, Exchange, Dynamics, SQL Server and
Active Directory. Microsoft also works closely with leading vendors including Oracle, SAP, IBM and Red Hat. You can
customize replication solutions on an app-by-app basis.
Why use Site Recovery for application replication?
Site Recovery contributes to application-level protection and recovery as follows:
App-agnostic, providing replication for any workloads running on a supported machine.
Near-synchronous replication, with RPOs as low as 30 seconds to meet the needs of most critical business apps.
App-consistent snapshots, for single or multi-tier applications.
Integration with SQL Server AlwaysOn, and partnership with other application-level replication technologies,
including AD replication, SQL AlwaysOn, Exchange Database Availability Groups (DAGs) and Oracle Data Guard.
Flexible recovery plans, that enable you to recover an entire application stack with a single click, and include to
include external scripts and manual actions in the plan.
Advanced network management in Site Recovery and Azure to simplify app network requirements, including the
ability to reserve IP addresses, configure load-balancing, and integration with Azure Traffic Manager, for low
RTO network switchovers.
A rich automation library that provides production-ready, application-specific scripts that can be downloaded
and integrated with recovery plans.
Workload summary
Site Recovery can replicate any app running on a supported machine. In addition we've partnered with product
teams to carry out additional app-specific testing.
WORKLOAD
REPLICATE HYPER-V
VMS TO A SECONDARY
SITE
REPLICATE HYPER-V
VMS TO AZURE
REPLICATE VMWARE
VMS TO A SECONDARY
SITE
REPLICATE VMWARE
VMS TO AZURE
Active Directory, DNS
Y
Y
Y
Y
WORKLOAD
REPLICATE HYPER-V
VMS TO A SECONDARY
SITE
REPLICATE HYPER-V
VMS TO AZURE
REPLICATE VMWARE
VMS TO A SECONDARY
SITE
REPLICATE VMWARE
VMS TO AZURE
Web apps (IIS, SQL)
Y
Y
Y
Y
System Center
Operations Manager
Y
Y
Y
Y
Sharepoint
Y
Y
Y
Y
SAP
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Exchange (non-DAG)
Y
Coming soon
Y
Y
Remote Desktop/VDI
Y
Y
Y
N/A
Linux (operating
system and apps)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Dynamics AX
Y
Y
Y
Y
Dynamics CRM
Y
Coming soon
Y
Coming soon
Oracle
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Windows File Server
Y
Y
Y
Y
Citrix XenApp and
XenDesktop
N/A
Y
N/A
Y
Replicate SAP site to
Azure for non-cluster
Replicate Active Directory and DNS
An Active Directory and DNS infrastructure are essential to most enterprise apps. During disaster recovery, you'll
need to protect and recover these infrastructure components, before recovering your workloads and apps.
You can use Site Recovery to create a complete automated disaster recovery plan for Active Directory and DNS. For
example, if you want to fail over SharePoint and SAP from a primary to a secondary site, you can set up a recovery
plan that fails over Active Directory first, and then an additional app-specific recovery plan to fail over the other
apps that rely on Active Directory.
Learn more about protecting Active Directory and DNS.
Protect SQL Server
SQL Server provides a data services foundation for data services for many business apps in an on-premises data
center. Site Recovery can be used together with SQL Server HA/DR technologies, to protect multi-tiered enterprise
apps that use SQL Server. Site Recovery provides:
A simple and cost-effective disaster recovery solution for SQL Server. Replicate multiple versions and editions of
SQL Server standalone servers and clusters, to Azure or to a secondary site.
Integration with SQL AlwaysOn Availability Groups, to manage failover and failback with Azure Site Recovery
recovery plans.
End-to-end recovery plans for the all tiers in an application, including the SQL Server databases.
Scaling of SQL Server for peak loads with Site Recovery, by “bursting” them into larger IaaS virtual machine
sizes in Azure.
Easy testing of SQL Server disaster recovery. You can run test failovers to analyze data and run compliance
checks, without impacting your production environment.
Learn more about protecting SQL server.
Protect SharePoint
Azure Site Recovery helps protect SharePoint deployments, as follows:
Eliminates the need and associated infrastructure costs for a stand-by farm for disaster recovery. Use Site
Recovery to replicate an entire farm (Web, app and database tiers) to Azure or to a secondary site.
Simplifies application deployment and management. Updates deployed to the primary site are automatically
replicated, and are thus available after failover and recovery of a farm in a secondary site. Also lowers the
management complexity and costs associated with keeping a stand-by farm up-to-date.
Simplifies SharePoint application development and testing by creating a production-like copy on-demand
replica environment for testing and debugging.
Simplifies transition to the cloud by using Site Recovery to migrate SharePoint deployments to Azure.
Learn more about protecting SharePoint.
Protect Dynamics AX
Azure Site Recovery helps protect your Dynamics AX ERP solution, by:
Orchestrating replication of your entire Dynamics AX environment (Web and AOS tiers, database tiers,
SharePoint) to Azure, or to a secondary site.
Simplifying migration of Dynamics AX deployments to the cloud (Azure).
Simplifying Dynamics AX application development and testing by creating a production-like copy on-demand,
for testing and debugging.
Learn more about protecting Dynamic AX.
Protect RDS
Remote Desktop Services (RDS) enables virtual desktop infrastructure (VDI), session-based desktops, and
applications, allowing users to work anywhere. With Azure Site Recovery you can:
Replicate managed or unmanaged pooled virtual desktops to a secondary site, and remote applications and
sessions to a secondary site or Azure.
Here's what you can replicate:
REPLICATE
HYPER-V VMS
TO A
SECONDARY
SITE
REPLICATE
HYPER-V VMS
TO AZURE
REPLICATE
VMWARE VMS
TO A
SECONDARY
SITE
Pooled
Virtual
Desktop
(unmanaged)
Yes
No
Pooled
Virtual
Desktop
(managed
and without
UPD)
Yes
Remote
applications
and Desktop
sessions
(without
UPD)
Yes
RDS
REPLICATE
VMWARE VMS
TO AZURE
REPLICATE
PHYSICAL
SERVERS TO A
SECONDARY
SITE
REPLICATE
PHYSICAL
SERVERS TO
AZURE
Yes
No
Yes
No
No
Yes
No
Yes
No
Yes
Yes
Yes
Yes
Yes
Learn more about protecting RDS.
Protect Exchange
Site Recovery helps protect Exchange, as follows:
For small Exchange deployments, such as a single or standalone servers, Site Recovery can replicate and fail over
to Azure or to a secondary site.
For larger deployments, Site Recovery integrates with Exchange DAGS.
Exchange DAGs are the recommended solution for Exchange disaster recovery in an enterprise. Site Recovery
recovery plans can include DAGs, to orchestrate DAG failover across sites.
Learn more about protecting Exchange.
Protect SAP
Use Site Recovery to protect your SAP deployment, as follows:
Enable protection of the entire SAP deployment, by replicating different deployment layers to Azure, or to a
secondary site.
Simplify cloud migration, by using Site Recovery to migrate your SAP deployment to Azure.
Simplify SAP development and testing, by creating a production-like copy on-demand for testing and debugging
applications.
Learn more about protecting SAP.
Protect IIS
Use Site Recovery to protect your IIS deployment, as follows:
Azure Site Recovery provides disaster recovery by replicating the critical components in your environment to a cold
remote site or a public cloud like Microsoft Azure. Since the virtual machine with the web server and the database
are being replicated to the recovery site, there is no requirement to backup configuration files or certificates
separately. The application mappings and bindings dependent on environment variables that are changed post
failover can be updated through scripts integrated into the disaster recovery plans. Virtual Machines are brought up
on the recovery site only in the event of a failover. Not only this, Azure Site Recovery also helps you orchestrate the
end to end failover by providing you the following capabilities:
Sequencing the shutdown and startup of virtual machines in the various tiers.
Adding scripts to allow update of application dependencies and bindings on the virtual machines after they have
been started up. The scripts can also be used to update the DNS server to point to the recovery site.
Allocate IP addresses to virtual machines pre-failover by mapping the primary and recovery networks and hence
use scripts that do not need to be updated post failover.
Ability for a one-click failover for multiple web applications on the web servers, thus eliminating the scope for
confusion in the event of a disaster.
Ability to test the recovery plans in an isolated environment for DR drills.
Learn more about protecting IIS web farm.
Protect Citrix XenApp and XenDesktop
Use Site Recovery to protect your Citrix XenApp and XenDesktop deployments, as follows:
Enable protection of the Citrix XenApp and XenDesktop deployment, by replicating different deployment layers
including (AD DNS server, SQL database server, Citrix Delivery Controller, StoreFront server, XenApp Master
(VDA), Citrix XenApp License Server) to Azure.
Simplify cloud migration, by using Site Recovery to migrate your Citrix XenApp and XenDesktop deployment to
Azure.
Simplify Citrix XenApp/XenDesktop testing, by creating a production-like copy on-demand for testing and
debugging.
This solution is only applicable for Windows Server operating system virtual desktops and not client virtual
desktops as client virtual desktops are not yet supported for licensing in Azure. Learn More about licensing for
client/server desktops in Azure.
Learn more about protecting Citrix XenApp and XenDesktop deployments.
Next steps
Check prerequisites
Azure Site Recovery support matrix for replicating to
Azure
4/17/2017 • 7 min to read • Edit Online
This article summarizes supported configurations and components for Azure Site Recovery when replicating and
recovering to Azure. For more about Azure Site Recovery requirements, see the prerequisites.
Support for deployment options
DEPLOYMENT
VMWARE/PHYSICAL SERVER
HYPER-V (WITH/WITHOUT VIRTUAL
MACHINE MANAGER)
Azure portal
On-premises VMware VMs to Azure
storage, with Azure Resource Manager
or classic storage and networks.
On-premises Hyper-V VMs to Azure
storage, with Resource Manager or
classic storage and networks.
Failover to Resource Manager-based or
classic VMs.
Failover to Resource Manager-based or
classic VMs.
Classic portal
Maintenance mode only. New vaults
can't be created.
Maintenance mode only.
PowerShell
Not currently supported.
Supported
Support for datacenter management servers
Virtualization management entities
DEPLOYMENT
SUPPORT
VMware VM/physical server
vSphere 6.0, 5.5, or 5.1 with latest update
Hyper-V (with Virtual Machine Manager)
System Center Virtual Machine Manager 2016 and System
Center Virtual Machine Manager 2012 R2
NOTE
A System Center Virtual Machine Manager 2016 cloud with a mixture of Windows Server 2016 and 2012 R2 hosts isn't
currently supported.
Host servers
DEPLOYMENT
SUPPORT
VMware VM/physical server
vCenter 5.5 or 6.0 (support for 5.5 features only)
Hyper-V (with/without Virtual Machine Manager)
Windows Server 2016, Windows Server 2012 R2 with latest
updates.
If SCVMM is used, Windows Server 2016 hosts should be
managed by SCVMM 2016.
NOTE
A Hyper-V site that mixes hosts running Windows Server 2016 and 2012 R2 isn't currently supported. Recovery to an
alternate location for VMs on a Windows Server 2016 host isn't currently supported.
Support for replicated machine OS versions
Virtual machines that are protected must meet Azure requirements when replicating to Azure. The following table
summarizes replicated operating system support in various deployment scenarios while using Azure Site Recovery.
This support is applicable for any workload running on the mentioned OS.
VMWARE/PHYSICAL SERVER
HYPER-V (WITH/WITHOUT VIRTUAL MACHINE MANAGER)
64-bit Windows Server 2012 R2, Windows Server 2012,
Windows Server 2008 R2 with at least SP1
Any guest OS supported by Azure
Red Hat Enterprise Linux 6.7, 6.8, 7.1, 7.2
CentOS 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2
Oracle Enterprise Linux 6.4, 6.5 running either the Red Hat
compatible kernel or Unbreakable Enterprise Kernel Release 3
(UEK3)
SUSE Linux Enterprise Server 11 SP3
SUSE Linux Enterprise Server 11 SP4
(Upgrade of replicating machines from SLES 11 SP3 to SLES 11
SP4 is not supported. If a replicated machine has been
upgraded from SLES 11SP3 to SLES 11 SP4, you'll need to
disable replication and protect the machine again post the
upgrade.)
IMPORTANT
(Applicable to VMware/Physical servers replicating to Azure)
On Red Hat Enterprise Linux Server 7+ and CentOS 7+ servers, kernel version 3.10.0-514 is supported starting from version
9.8 of the Azure Site Recovery mobility service.
Customers on the 3.10.0-514 kernel with a version of the mobility service lower than version 9.8 are required to disable
replication, update the version of the mobility service to version 9.8 and then enable replication again.
Supported file systems and guest storage configurations on Linux
(VMware/Physical servers)
The following file systems and storage configuration software is supported on Linux servers running on VMware or
Physical servers:
File systems: ext3, ext4, ReiserFS (Suse Linux Enterprise Server only), XFS (upto v4 only)
Volume manger : LVM2
Multipath software : Device Mapper
Physical servers with the HP CCISS storage controller aren't supported.
NOTE
On Linux servers the following directories (if set up as separate partitions/file-systems) must all be on the same disk (the OS
disk) on the source server: / (root), /boot, /usr, /usr/local, /var, /etc
XFS v5 features such as metadata checksum are currently not supported by ASR on XFS filesystems. Ensure that your XFS
filesystems aren't using any v5 features. You can use the xfs_info utility to check the XFS superblock for the partition. If ftype
is set to 1, then XFSv5 features are being used.
Support for network configuration
The following tables summarize network configuration support in various deployment scenarios that use Azure
Site Recovery to replicate to Azure.
Host network configuration
CONFIGURATION
VMWARE/PHYSICAL SERVER
HYPER-V (WITH/WITHOUT VIRTUAL
MACHINE MANAGER)
NIC teaming
Yes
Yes
Not supported in physical machines
VLAN
Yes
Yes
IPv4
Yes
Yes
IPv6
No
No
CONFIGURATION
VMWARE/PHYSICAL SERVER
HYPER-V (WITH/WITHOUT VIRTUAL
MACHINE MANAGER)
NIC teaming
No
No
IPv4
Yes
Yes
IPv6
No
No
Static IP (Windows)
Yes
Yes
Static IP (Linux)
No
No
Multi-NIC
Yes
Yes
Guest VM network configuration
Failed-over Azure VM network configuration
AZURE NETWORKING
VMWARE/PHYSICAL SERVER
HYPER-V (WITH/WITHOUT VIRTUAL
MACHINE MANAGER)
Express Route
Yes
Yes
ILB
Yes
Yes
AZURE NETWORKING
VMWARE/PHYSICAL SERVER
HYPER-V (WITH/WITHOUT VIRTUAL
MACHINE MANAGER)
ELB
Yes
Yes
Traffic Manager
Yes
Yes
Multi-NIC
Yes
Yes
Reserved IP
Yes
Yes
IPv4
Yes
Yes
Retain source IP
Yes
Yes
Support for storage
The following tables summarize storage configuration support in various deployment scenarios that use Azure Site
Recovery to replicate to Azure.
Host storage configuration
CONFIGURATION
VMWARE/PHYSICAL SERVER
HYPER-V (WITH/WITHOUT VIRTUAL
MACHINE MANAGER)
NFS
Yes for VMware
N/A
No for physical servers
SMB 3.0
N/A
Yes
SAN (ISCSI)
Yes
Yes
Multi-path (MPIO)
Tested with: Microsoft DSM, EMC
PowerPath 5.7 SP4, EMC PowerPath
DSM for CLARiiON
Yes
Yes
Guest or physical server storage configuration
CONFIGURATION
VMWARE/PHYSICAL SERVER
HYPER-V (WITH/WITHOUT VIRTUAL
MACHINE MANAGER)
VMDK
Yes
N/A
VHD/VHDX
N/A
Yes
Gen 2 VM
N/A
Yes
EFI/UEFI
No
Yes
Shared cluster disk
Yes for VMware
No
N/A for physical servers
CONFIGURATION
VMWARE/PHYSICAL SERVER
HYPER-V (WITH/WITHOUT VIRTUAL
MACHINE MANAGER)
Encrypted disk
No
No
NFS
No
N/A
SMB 3.0
No
No
RDM
Yes
N/A
N/A for physical servers
Disk > 1 TB
No
No
Volume with striped disk > 1 TB
Yes
Yes
Storage Spaces
No
Yes
Hot add/remove disk
No
No
Exclude disk
Yes
Yes
Multi-path (MPIO)
N/A
Yes
AZURE STORAGE
VMWARE/PHYSICAL SERVER
HYPER-V (WITH/WITHOUT VIRTUAL
MACHINE MANAGER)
LRS
Yes
Yes
GRS
Yes
Yes
RA-GRS
Yes
Yes
Cool storage
No
No
Hot storage
No
No
Encryption at rest(SSE)
Yes
Yes
Premium storage
Yes
Yes
Import/export service
No
No
LVM-Logical Volume Management
Support for Azure compute configuration
COMPUTE FEATURE
VMWARE/PHYSICAL SERVER
HYPER-V (WITH/WITHOUT VIRTUAL
MACHINE MANAGER)
Availability sets
Yes
Yes
COMPUTE FEATURE
VMWARE/PHYSICAL SERVER
HYPER-V (WITH/WITHOUT VIRTUAL
MACHINE MANAGER)
HUB
Yes
Yes
Failed-over Azure VM requirements
You can deploy Site Recovery to replicate virtual machines and physical servers running any operating system
supported by Azure. This includes most versions of Windows and Linux. On-premises VMs that you want to
replicate must conform with the following Azure requirements while replicating to Azure.
ENTITY
REQUIREMENTS
DETAILS
Guest operating system
Hyper-V to Azure replication: Site
Recovery supports all operating
systems that are supported by Azure.
Prerequisites check will fail if
unsupported.
For VMware and physical server
replication: Check the Windows and
Linux prerequisites
Guest operating system architecture
64-bit
Prerequisites check will fail if
unsupported
Operating system disk size
Up to 1023 GB
Prerequisites check will fail if
unsupported
Operating system disk count
1
Prerequisites check will fail if
unsupported.
Data disk count
64 or less if you are replicating
VMware VMs to Azure; 16 or less if
you are replicating Hyper-V VMs to
Azure
Prerequisites check will fail if
unsupported
Data disk VHD size
Up to 1023 GB
Prerequisites check will fail if
unsupported
Network adapters
Multiple adapters are supported
Shared VHD
Not supported
Prerequisites check will fail if
unsupported
FC disk
Not supported
Prerequisites check will fail if
unsupported
Hard disk format
VHD
Although VHDX isn't currently
supported in Azure, Site Recovery
automatically converts VHDX to VHD
when you fail over to Azure. When you
fail back to on-premises the virtual
machines continue to use the VHDX
format.
VHDX
Bitlocker
Not supported
Bitlocker must be disabled before
protecting a virtual machine.
ENTITY
REQUIREMENTS
DETAILS
VM name
Between 1 and 63 characters. Restricted
to letters, numbers, and hyphens. The
VM name must start and end with a
letter or number.
Update the value in the virtual machine
properties in Site Recovery.
VM type
Generation 1
Generation 2 VMs with an OS disk type
of basic (which includes one or two data
volumes formatted as VHDX) and less
than 300 GB of disk space are
supported.
Linux Generation 2 VMs aren't
supported. Learn more
Generation 2 -- Windows
Support for Recovery Services vault actions
ACTION
VMWARE/PHYSICAL SERVER
HYPER-V (NO VIRTUAL
MACHINE MANAGER)
HYPER-V (WITH VIRTUAL
MACHINE MANAGER)
Move vault across resource
groups
No
No
No
No
No
No
Within and across
subscriptions
Move storage, network,
Azure VMs across resource
groups
Within and across
subscriptions
Support for Provider and Agent
NAME
DESCRIPTION
LATEST VERSION
DETAILS
Azure Site Recovery
Provider
Coordinates
communications between
on-premises servers and
Azure
5.1.19 (available from portal)
Latest features and fixes
9.3.4246.1 (available from
portal)
Latest features and fixes
Installed on on-premises
Virtual Machine Manager
servers, or on Hyper-V
servers if there's no Virtual
Machine Manager server
Azure Site Recovery
Unified Setup (VMware to
Azure)
Coordinates
communications between
on-premises VMware
servers and Azure
Installed on on-premises
VMware servers
NAME
DESCRIPTION
LATEST VERSION
DETAILS
Mobility service
Coordinates replication
between on-premises
VMware servers/physical
servers and Azure/secondary
site
N/A (available from portal)
N/A
Installed on VMware VM or
physical servers you want to
replicate
Microsoft Azure Recovery
Services (MARS) agent
Coordinates replication
between Hyper-V VMs and
Azure
Installed on on-premises
Hyper-V servers (with or
without a Virtual Machine
Manager server)
Next steps
Check prerequisites
Latest agent (available from
portal)
Azure Site Recovery: Frequently asked questions
(FAQ)
4/27/2017 • 12 min to read • Edit Online
This article includes frequently asked questions about Azure Site Recovery. If you have questions after reading this
article, post them on the Azure Recovery Services Forum.
General
What does Site Recovery do?
Site Recovery contributes to your business continuity and disaster recovery (BCDR) strategy, by orchestrating and
automating replication from on-premises virtual machines and physical servers to Azure, or to a secondary
datacenter. Learn more.
What can Site Recovery protect?
Hyper-V virtual machines: Site Recovery can protect any workload running on a Hyper-V VM.
Physical servers: Site Recovery can protect physical servers running Windows or Linux.
VMware virtual machines: Site Recovery can protect any workload running in a VMware VM.
Does Site Recovery support the Azure Resource Manager model?
In addition to Site Recovery in the Azure classic portal, Site Recovery is available in the Azure portal with support
for Resource Manager. For most deployment scenarios Site Recovery in the Azure portal provides a streamlined
deployment experience and you can replicate VMs and physical servers into classic storage or Resource Manager
storage. Here are the supported deployments:
Replicate VMware VMs or physical servers to Azure in the Azure portal
Replicate Hyper-V VMs in VMM clouds to Azure in the Azure portal
Replicate Hyper-V VMs (without VMM) to Azure in the Azure portal
Replicate Hyper-V VMs in VMM clouds to a secondary site in the Azure portal
What do I need in Hyper-V to orchestrate replication with Site Recovery?
For the Hyper-V host server what you need depends on the deployment scenario. Check out the Hyper-V
prerequisites in:
Replicating Hyper-V VMs (without VMM) to Azure
Replicating Hyper-V VMs (with VMM) to Azure
Replicating Hyper-V VMs to a secondary datacenter
If you're replicating to a secondary datacenter read about Supported guest operating systems for Hyper-V VMs.
If you're replicating to Azure, Site Recovery supports all the guest operating systems that are supported by
Azure.
Can I protect VMs when Hyper-V is running on a client operating system?
No, VMs must be located on a Hyper-V host server that's running on a supported Windows server machine. If you
need to protect a client computer you could replicate it as a physical machine to Azure or a secondary datacenter.
What workloads can I protect with Site Recovery?
You can use Site Recovery to protect most workloads running on a supported VM or physical server. Site Recovery
provides support for application-aware replication, so that apps can be recovered to an intelligent state. It
integrates with Microsoft applications such as SharePoint, Exchange, Dynamics, SQL Server and Active Directory,
and works closely with leading vendors, including Oracle, SAP, IBM and Red Hat. Learn more about workload
protection.
Do Hyper-V hosts need to be in VMM clouds?
If you want to replicate to a secondary datacenter, then Hyper-V VMs must be on Hyper-V hosts servers located in a
VMM cloud. If you want to replicate to Azure, then you can replicate VMs on Hyper-V host servers with or without
VMM clouds. Read more.
Can I deploy Site Recovery with VMM if I only have one VMM server?
Yes. You can either replicate VMs in Hyper-V servers in the VMM cloud to Azure, or you can replicate between
VMM clouds on the same server. For on-premises to on-premises replication, we recommend that you have a VMM
server in both the primary and secondary sites.
What physical servers can I protect?
You can replicate physical servers running Windows and Linux to Azure or to a secondary site. Learn about
operating system requirements. The same requirements apply whether you're replicating physical servers to Azure,
or to a secondary site.
Note that physical servers will run as VMs in Azure if your on-premises server goes down. Failback to an onpremises physical server isn't currently supported. For a machine protected as physical, you can only failback to a
VMware virtual machine.
What VMware VMs can I protect?
To protect VMware VMs you'll need a vSphere hypervisor, and virtual machines running VMware tools. We also
recommend that you have a VMware vCenter server to manage the hypervisors. Learn more about exact
requirements for replicating VMware servers and VMs to Azure, or to a secondary site.
Can I manage disaster recovery for my branch offices with Site Recovery?
Yes. When you use Site Recovery to orchestrate replication and failover in your branch offices, you'll get a unified
orchestration and view of all your branch office workloads in a central location. You can easily run failovers and
administer disaster recovery of all branches from your head office, without visiting the branches.
Pricing
What charges do I incur while using Azure Site Recovery?
When you use Site Recovery, you incur charges for the Site Recovery license, Azure storage, storage transactions,
and outbound data transfer. Learn more.
The Site Recovery license is per protected instance, where an instance is a VM, or a physical server.
If a VM disk replicates to a standard storage account, the Azure storage charge is for the storage consumption.
For example, if the source disk size is 1 TB, and 400 GB is used, Site Recovery creates a 1 TB VHD in Azure, but
the storage charged is 400 GB (plus the amount of storage space used for replication logs).
If a VM disk replicates to a premium storage account, the Azure storage charge is for the provisioned storage
size, rounded out for the nearest premium storage disk option. For example, if the source disk size is 50 GB, Site
Recovery creates a 50 GB disk in Azure, and Azure maps this to the nearest premium storage disk (P10). Costs
are calculated on P10, and not on the 50 GB disk size. Learn more. If you're using premium storage, a standard
storage account for replication logging is also required, and the amount of standard storage space used for
these logs is also billed.
Costs are also incurred during test failover, where the VM, storage, egress, and storage transactions costs will be
applied.
Security
Is replication data sent to the Site Recovery service?
No, Site Recovery doesn't intercept replicated data, and doesn't have any information about what's running on
your virtual machines or physical servers. Replication data is exchanged between on-premises Hyper-V hosts,
VMware hypervisors, or physical servers and Azure storage or your secondary site. Site Recovery has no ability to
intercept that data. Only the metadata needed to orchestrate replication and failover is sent to the Site Recovery
service.
Site Recovery is ISO 27001:2013, 27018, HIPAA, DPA certified, and is in the process of SOC2 and FedRAMP JAB
assessments.
For compliance reasons, even our on-premises metadata must remain within the same geographic region. Can
Site Recovery help us?
Yes. When you create a Site Recovery vault in a region, we ensure that all metadata that we need to enable and
orchestrate replication and failover remains within that region's geographic boundary.
Does Site Recovery encrypt replication?
For virtual machines and physical servers, replicating between on-premises sites encryption-in-transit is supported.
For virtual machines and physical servers replicating to Azure, both encryption-in-transit and encryption-at-rest (in
Azure) are supported.
Replication
Can I replicate over a site -to -site VPN to Azure?
Azure Site Recovery replicates data to an Azure storage account, over a public endpoint. Replication isn't over a
site-to-site VPN. You can create a site-to-site VPN, with an Azure virtual network. This doesn't interfere with Site
Recovery replication.
Can I use ExpressRoute to replicate virtual machines to Azure?
Yes, ExpressRoute can be used to replicate virtual machines to Azure. Azure Site Recovery replicates data to an
Azure Storage Account over a public endpoint. You need to set up public peering to use ExpressRoute for Site
Recovery replication. After the virtual machines have been failed over to an Azure virtual network you can access
them using the private peering setup with the Azure virtual network.
Are there any prerequisites for replicating virtual machines to Azure?
Virtual machines you want to replicate to Azure should comply with Azure requirements.
Can I replicate Hyper-V generation 2 virtual machines to Azure?
Yes. Site Recovery converts from generation 2 to generation 1 during failover. At failback the machine is converted
back to generation 2. Read more.
If I replicate to Azure how do I pay for Azure VMs?
During regular replication, data is replicated to geo-redundant Azure storage and you don’t need to pay any Azure
IaaS virtual machine charges, providing a significant advantage. When you run a failover to Azure, Site Recovery
automatically creates Azure IaaS virtual machines, and after that you'll be billed for the compute resources that you
consume in Azure.
Can I automate Site Recovery scenarios with an SDK?
Yes. You can automate Site Recovery workflows using the Rest API, PowerShell, or the Azure SDK. Currently
supported scenarios for deploying Site Recovery using PowerShell:
Replicate Hyper-V VMs in VMMs clouds to Azure PowerShell Resource Manager
Replicate Hyper-V VMs without VMM to Azure PowerShell Resource Manager
If I replicate to Azure what kind of storage account do I need?
Azure classic portal: If you're deploying Site Recovery in the Azure classic portal, you'll need a standard geo-
redundant storage account. Premium storage isn't currently supported. The account must be in the same region
as the Site Recovery vault.
Azure portal: If you're deploying Site Recovery in the Azure portal, you'll need an LRS or GRS storage account.
We recommend GRS so that data is resilient if a regional outage occurs, or if the primary region can't be
recovered. The account must be in the same region as the Recovery Services vault. Premium storage is now
supported for VMware VM, Hyper-V VM, and physical server replication, when you deploy Site Recovery in the
Azure portal.
How often can I replicate data?
Hyper-V: Hyper-V VMs can be replicated every 30 seconds (except for premium storage), 5 minutes or 15
minutes. If you've set up SAN replication then replication is synchronous.
VMware and physical servers: A replication frequency isn't relevant here. Replication is continuous.
Can I extend replication from existing recovery site to another tertiary site?
Extended or chained replication isn't supported. Request this feature in feedback forum.
Can I do an offline replication the first time I replicate to Azure?
This isn't supported. Request this feature in the feedback forum.
Can I exclude specific disks from replication?
This is supported when you're replicating VMware VMs and Hyper-V VMs to Azure, using the Azure portal.
Can I replicate virtual machines with dynamic disks?
Dynamic disks are supported when replicating Hyper-V virtual machines. They are also supported when replicating
VMware VMs and physical machines to Azure. The operating system disk must be a basic disk.
Can I add a new machine to an existing replication group?
Adding new machines to existing replication groups is supported. To do so, select the replication group (from
'Replicated items' blade) and right click/select context menu on the replication group and select the appropriate
option.
Can I throttle bandwidth allotted for Hyper-V replication traffic?
Yes. You can read more about throttling bandwidth in the deployment articles:
Capacity planning for replicating VMware VMs and physical servers
Capacity planning for replicating Hyper-V VMs in VMM clouds
Capacity planning for replicating Hyper-V VMs without VMM
Failover
If I'm failing over to Azure, how do I access the Azure virtual machines after failover?
You can access the Azure VMs over a secure Internet connection, over a site-to-site VPN, or over Azure
ExpressRoute. You'll need to prepare a number of things in order to connect. Learn more
If I fail over to Azure how does Azure make sure my data is resilient?
Azure is designed for resilience. Site Recovery is already engineered for failover to a secondary Azure datacenter, in
accordance with the Azure SLA if the need arises. If this happens, we make sure your metadata and vaults remain
within the same geographic region that you chose for your vault.
If I'm replicating between two datacenters what happens if my primary datacenter experiences an unexpected
outage?
You can trigger an unplanned failover from the secondary site. Site Recovery doesn't need connectivity from the
primary site to perform the failover.
Is failover automatic?
Failover isn't automatic. You initiate failovers with single click in the portal, or you can use Site Recovery
PowerShell to trigger a failover. Failing back is a simple action in the Site Recovery portal.
To automate you could use on-premises Orchestrator or Operations Manager to detect a virtual machine failure,
and then trigger the failover using the SDK.
Read more about recovery plans.
Read more about failover.
Read more about failing back VMware VMs and physical servers
If my on-premises host is not responding or crashed, can I failover back to a different host?
Yes, you can use the alternate location recovery to failback to a different host from Azure. Read more about the
options in the below links for VMware and Hyper-v virtual machines.
For VMware virtual machines
For Hyper-v virtual machines
Service providers
I'm a service provider. Does Site Recovery work for dedicated and shared infrastructure models?
Yes, Site Recovery supports both dedicated and shared infrastructure models.
For a service provider, is the identity of my tenant shared with the Site Recovery service?
No. Tenant identity remains anonymous. Your tenants don't need access to the Site Recovery portal. Only the
service provider administrator interacts with the portal.
Will tenant application data ever go to Azure?
When replicating between service provider-owned sites, application data never goes to Azure. Data is encrypted intransit, and replicated directly between the service provider sites.
If you're replicating to Azure, application data is sent to Azure storage but not to the Site Recovery service. Data is
encrypted in-transit, and remains encrypted in Azure.
Will my tenants receive a bill for any Azure services?
No. Azure's billing relationship is directly with the service provider. Service providers are responsible for generating
specific bills for their tenants.
If I'm replicating to Azure, do we need to run virtual machines in Azure at all times?
No, Data is replicated to an Azure storage account in your subscription. When you perform a test failover (DR drill)
or an actual failover, Site Recovery automatically creates virtual machines in your subscription.
Do you ensure tenant-level isolation when I replicate to Azure?
Yes.
What platforms do you currently support?
We support Azure Pack, Cloud Platform System, and System Center based (2012 and higher) deployments. Learn
more about Azure Pack and Site Recovery integration.
Do you support single Azure Pack and single VMM server deployments?
Yes, you can replicate Hyper-V virtual machines to Azure, or between service provider sites. Note that if you
replicate between service provider sites, Azure runbook integration isn't available.
Next steps
Read the Site Recovery overview
Learn about Site Recovery architecture
Replicate VMware virtual machines to Azure with
Site Recovery
3/22/2017 • 22 min to read • Edit Online
This article describes how to replicate on-premises VMware virtual machines to Azure, using the Azure Site
Recovery service in the Azure portal.
If you want to migrate VMware VMs to Azure (failover only), read this article to learn more.
Post comments and questions at the bottom of this article, or on the Azure Recovery Services Forum.
Deployment steps
Here's what you need to do:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Verify prerequisites and limitations.
Set up Azure network and storage accounts.
Prepare the on-premises machine that you want to deploy as the configuration server.
Prepare VMware accounts to be used for automatic discovery of VMs, and optionally for push installation of
the Mobility service.
Create a Recovery Services vault. The vault contains configuration settings, and orchestrates replication.
Specify source, target, and replication settings.
Deploy the Mobility service on VMs you want to replicate.
Enable replication for the VMs.
Run a test failover to make sure everything's working as expected.
Prerequisites
SUPPORT REQUIREMENT
DETAILS
Azure
Learn about Azure requirements
On-premises configuration server
You need a VMware VM running Windows Server 2012 R2 or
later. You set up this server during Site Recovery deployment.
By default the process server and master target server are
also installed on this VM. When you scale up, you might need
a separate process server, and it has the same requirements
as the configuration server.
Learn more about these components here
On-premises VMware servers
One or more VMware vSphere servers, running 6.0, 5.5, 5.1
with latest updates. Servers should be located in the same
network as the configuration server (or separate process
server).
We recommend a vCenter server to manage hosts, running
6.0 or 5.5 with the latest updates. Only features that are
available in 5.5 are supported when you deploy version 6.0.
SUPPORT REQUIREMENT
DETAILS
On-premises VMs
VMs you want to replicate should be running a supported
operating system, and conform with Azure prerequisites. VM
should have VMware tools running.
URLs
The configuration server needs access to these URLs:
*.accesscontrol.windows.net
: Used for access control and
identity management
\*.backup.windowsazure.com
: Used for replication data
transfer and orchestration
\*.blob.core.windows.net : Used for access to the storage
account that stores replicated data
\*.hypervrecoverymanager.windowsazure.com : Used for
replication management operations and orchestration
and time.windows.com : Used to check
time synchronization between system and global time
time.nist.gov
URLs for Azure Government Cloud: *.ugv.hypervrecoverymanager.windowsazure.us *.ugv.backup.windowsazure.us *.ugi.hypervrecoverymanager.windowsazure.us *.ugi.backup.windowsazure.us
If you have IP address-based firewall rules, ensure they allow
communication to Azure.
Allow the Azure Datacenter IP Ranges, and the HTTPS (443)
port.
Allow IP address ranges for the Azure region of your
subscription, and for West US (used for Access Control and
Identity Management).
Allow this URL for the MySQL download:
http://cdn.mysql.com/archives/mysql-5.5/mysql-5.5.37win32.msi.
Mobility service
Installed on every replicated VM.
Limitations
LIMITATION
DETAILS
Azure
Storage and network accounts must be in the same region as
the vault
If you use a premium storage account, you also need a
standard store account to store replication logs
You can't replicate to premium accounts in Central and South
India.
LIMITATION
DETAILS
On-premises configuration server
VMware VM adapter type should be VMXNET3. If it isn't,
install this update
vSphere PowerCLI 6.0 should be installed.
The machine shouldn't be a domain controller. The machine
should have a static IP address.
The host name should be 15 characters or less, and operating
system should be in English.
VMware
Only 5.5 features are supported in vCenter 6.0. Site Recovery
doesn't support new vCenter and vSphere 6.0 features such
as cross vCenter vMotion, virtual volumes, and storage DRS.
VMs
Verify Azure VM limitations
You can't replicate VMs with encrypted disks, or VMs with
UEFI/EFI boot.
Shared disk clusters aren't supported. If the source VM has
NIC teaming, it's converted to a single NIC after failover.
If VMs have an iSCSI disk, Site Recovery converts it to a VHD
file after failover. If the iSCSI target can be reached by the
Azure VM, it connects to it, and sees both it and the VHD. If
this happens, disconnect the iSCSI target.
If you want to enable multi-VM consistency, which enables
VMs running the same workload to be recovered together to
a consistent data point, open port 20004 on the VM.
Windows must be installed on the C drive. The OS disk
should be basic, and not dynamic. The data disk can be
dynamic.
Linux /etc/hosts files on VMs should contain entries that map
the local host name to IP addresses associated with all
network adapters. The host name, mount points, device
name, system paths, and file names (/etc; /usr) should be in
English only.
Specific types of Linux storage are supported.
Create or set disk.enableUUID=true in the VM settings. This
provides a consistent UUID to the VMDK, so that it mounts
correctly, and ensures that only delta changes are transferred
back to on-premises during failback, without full replication.
Set up Azure
1. Set up an Azure network.
Azure VMs will be placed in this network when they're created after failover.
You can set up a network in Resource Manager, or in classic mode.
2. Set up an Azure storage account for replicated data.
The account can be standard or premium.
You can set up an account in Resource Manager, or in classic mode.
3. Prepare an account on the vCenter server or vSphere hosts, so that Site Recovery can automatically detect
VMware VMs.
Prepare the configuration server
1. Install Windows Server 2012 R2 or later, on a VMware VM.
2. Make sure the VM has access to the URLs listed in prerequisites.
3. Install VMware vSphere PowerCLI 6.0.
Prepare for automatic discovery and push installation
Prepare an account for auto-discovery: The Site Recovery process server automatically discovers VMs.
To do this, Site Recovery needs credentials that can access vCenter servers and vSphere ESXi hosts.
1. To use a dedicated account, create a role (at the vCenter level, with these permissions. Give it a name
such as Azure_Site_Recovery.
2. Then, create a user on the vSphere host/vCenter server, and assign the role to the user. You specify this
user account during Site Recovery deployment.
Prepare an account to push the Mobility service: If you want to push the Mobility service to VMs, you
need an account that can be used by the process server to access the VM. The account is only used for the
push installation. You can use a domain or local account:
For Windows, if you're not using a domain account, you need to disable Remote User Access control on
the local machine. To do this, in the register under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, add
the DWORD entry LocalAccountTokenFilterPolicy, with a value of 1.
If you want to add the registry entry for Windows from a CLI, type:
REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v
LocalAccountTokenFilterPolicy /t REG_DWORD /d 1.
For Linux, the account should be root on the source Linux server.
Create a Recovery Services vault
1. Sign in to the Azure portal > Site Recovery
2. Click New > Monitoring & Management > Backup and Site Recovery >
3. In Name, specify a friendly name to identify the vault. If you have more than one subscription, select one of
them.
4. Create a resource group, or select an existing one. Specify an Azure region. To check supported regions, see
Geographic Availability in Azure Site Recovery Pricing Details
5. If you want to quickly access the vault from the Dashboard, click Pin to dashboard and then click Create.
The new vault will appear on the Dashboard > All resources, and on the main Recovery Services vaults
blade.
Select the protection goal
Select what you want to replicate, and where you want to replicate to.
1. Click Recovery Services vaults > vault.
2. In the Resource Menu, click Site Recovery > Step 1: Prepare Infrastructure > Protection goal.
3. In Protection goal, select To Azure > Yes, with VMware vSphere Hypervisor.
Set up the source environment
Set up the configuration server, register it in the vault, and discover VMs.
1. Click Site Recovery > Step 1: Prepare Infrastructure > Source.
2. If you don’t have a configuration server, click +Configuration server.
3. In Add Server, check that Configuration Server appears in Server type.
4. Download the Site Recovery Unified Setup installation file.
5. Download the vault registration key. You need this when you run Unified Setup. The key is valid for five
days after you generate it.
Run Site Recovery Unified Setup
Do the following before you start, then run Unified Setup to install the configuration server, the process server,
and the master target server.
Get a quick video overview
On the configuration server VM, make sure that the system clock is synchronized with a Time Server. It
should match. If it's 15 minutes in front or behind, setup might fail.
Run setup as a Local Administrator on the configuration server VM.
Make sure TLS 1.0 is enabled on the VM.
1. Run the Unified Setup installation file.
2. In Before you begin, select Install the configuration server and process server.
3. In Third Party Software License, click I Accept to download and install MySQL.
4. In Registration, select the registration key you downloaded from the vault.
5. In Internet Settings, specify how the Provider running on the configuration server connects to Azure Site
Recovery over the Internet.
If you want to connect with the proxy that's currently set up on the machine, select Connect with
existing proxy settings.
If you want the Provider to connect directly, select Connect directly without a proxy.
If the existing proxy requires authentication, or if you want to use a custom proxy for the Provider
connection, select Connect with custom proxy settings.
If you use a custom proxy, you need to specify the address, port, and credentials.
If you're using a proxy, you should have already allowed the URLs described in prerequisites.
6. In Prerequisites Check, Setup runs a check to make sure that installation can run. If a warning appears
about the Global time sync check, verify that the time on the system clock (Date and Time settings) is
the same as the time zone.
7. In MySQL Configuration, create credentials for logging on to the MySQL server instance that is installed.
8. In Environment Details, select whether you're going to replicate VMware VMs. If you are, then setup
checks that PowerCLI 6.0 is installed.
9. In Install Location, select where you want to install the binaries and store the cache. The drive you select
must have at least 5 GB of disk space available, but we recommend a cache drive with at least 600 GB of
free space.
10. In Network Selection, specify the listener (network adapter and SSL port) on which the configuration
server sends and receives replication data. Port 9443 is the default port used for sending and receiving
replication traffic, but you can modify this port number to suit your environment's requirements. In
addition to the port 9443, we also open port 443, which is used by a web server to orchestrate replication
operations. Do not use Port 443 for sending or receiving replication traffic.
11. In Summary, review the information and click Install. When installation finishes, a passphrase is
generated. You will need this when you enable replication, so copy it and keep it in a secure location.
After registration finishes, the server is displayed on the Settings > Servers blade in the vault.
NOTE
The configuration server can also be installed from the command line.
Add the account for automatic discovery
1. On your configuration server, launch CSPSConfigtool.exe. It is available as a shortcut on the desktop and
located in the install location\home\svsystems\bin folder.
2. Click Manage Accounts > Add Account.
3. In Account Details, add the account that will be used for automatic discovery.
NOTE
It can take 15 minutes or more for the account name to appear in the portal. To update immediately, click
Configuration Servers > server name > Refresh Server.
Connect to VMware servers
Connect to vSphere ESXi hosts or vCenter servers, to discover VMware VMs.
If you add the vCenter server or vSphere hosts with an account without administrator privileges on the server,
the account needs these privileges enabled:
Datacenter, Datastore, Folder, Host, Network, Resource, Virtual machine, vSphere Distributed Switch.
The vCenter server needs Storage views permissions.
When you add VMware servers, it can take 15 minutes or longer for them to appear in the portal. To allow
Azure Site Recovery to discover virtual machines running in your on-premises environment, you need to
connect your VMware vCenter Server or vSphere ESXi hosts with Site Recovery.
Select +vCenter to start connecting a VMware vCenter server or a VMware vSphere ESXi host.
In Add vCenter, specify a friendly name for the vSphere host or vCenter server, and then specify the IP
address or FQDN of the server. Leave the port as 443 unless your VMware servers are configured to listen
for requests on a different port. Select the account that is to connect to the VMware vCenter or vSphere
ESXi server. Click OK.
NOTE
If you're adding the VMware vCenter server or VMware vSphere host with an account that doesn't have
administrator privileges on the vCenter or host server, make sure that the account has these privileges enabled:
Datacenter, Datastore, Folder, Host, Network, Resource, Virtual machine, and vSphere Distributed Switch. In
addition, the VMware vCenter server needs the Storage views privilege enabled.
Site Recovery connects to VMware servers using the specified settings, and discovers VMs.
Set up the target
Before you set up the target environment, check you have an Azure storage account and network
1. Click Prepare infrastructure > Target, and select the Azure subscription you want to use.
2. Specify whether your target deployment model is Resource Manager-based, or classic.
3. Site Recovery checks that you have one or more compatible Azure storage accounts and networks.
4. If you haven't created a storage account or network, click +Storage account or +Network, to create a
Resource Manager account or network inline.
Set up replication settings
Get a quick video overview before you start:
1. To create a new replication policy, click Site Recovery infrastructure > Replication Policies >
+Replication Policy.
2. In Create replication policy, specify a policy name.
3. In RPO threshold, specify the RPO limit. This value specifies how often data recovery points are created. An
alert is generated if continuous replication exceeds this limit.
4. In Recovery point retention, specify (in hours) how long the retention window is for each recovery point.
Replicated VMs can be recovered to any point in a window. Up to 24 hours retention is supported for
machines replicated to premium storage, and 72 hours for standard storage.
5. In App-consistent snapshot frequency, specify how often (in minutes) recovery points containing
application-consistent snapshots will be created. Click OK to create the policy.
6. When you create a new policy it's automatically associated with the configuration server. By default, a
matching policy is automatically created for failback. For example, if the replication policy is rep-policy then
the failback policy will be rep-policy-failback. This policy isn't used until you initiate a failback from Azure.
Plan capacity
1. Now that you have your basic infrastructure set up you can think about capacity planning, and figure out
whether you need additional resources. Learn more.
2. When you’re done with capacity planning, select Yes in Have you completed capacity planning?
Prepare VMs for replication
The Mobility service must be installed on all VMware VMs that you want to replicate. You can install the Mobility
service in a number of ways:
1. Install with a push installation from the process server. You need to prepare VMs to use this method.
2. Install using deployment tools such as System Center Configuration Manager, or Azure automation DSC.
3. Install manually.
Learn more
Enable replication
Before you start:
When you add or modify VMs, it can take up to 15 minutes or longer for changes to take effect, and for them
to appear in the portal.
You can check the last discovered time for VMs in Configuration Servers > Last Contact At.
To add VMs without waiting for the scheduled discovery, highlight the configuration server (don’t click it), and
click Refresh.
If a VM is prepared for push installation, the process server automatically installs the Mobility service when
you enable replication.
Exclude disks from replication
By default all disks on a machine are replicated. You can exclude disks from replication. For example you might
not want to replicate disks with temporary data, or data that's refreshed each time a machine or application
restarts (for example pagefile.sys or SQL Server tempdb).
Replicate VMs
Before you start, watch a quick video overview
1.
2.
3.
4.
5.
Click Step 2: Replicate application > Source.
In Source, select the configuration server.
In Machine type, select Virtual Machines.
In vCenter/vSphere Hypervisor, select the vCenter server that manages the vSphere host, or select the host.
Select the process server. If you haven't created any additional process servers this will be the
configuration server. Then click OK.
6. In Target, select the subscription and the resource group in which you want to create the failed over VMs.
Choose the deployment model that you want to use in Azure (classic or resource management), for the
failed over VMs.
7. Select the Azure storage account you want to use for replicating data. If you don't want to use an account
you've already set up, you can create a new one.
8. Select the Azure network and subnet to which Azure VMs will connect, when they're created after failover.
Select Configure now for selected machines, to apply the network setting to all machines you select for
protection. Select Configure later to select the Azure network per machine. If you don't want to use an
existing network, you can create one.
9. In Virtual Machines > Select virtual machines, click and select each machine you want to replicate. You
can only select machines for which replication can be enabled. Then click OK.
10. In Properties > Configure properties, select the account that will be used by the process server to
automatically install the Mobility service on the machine.
11. By default all disks are replicated. Click All Disks and clear any disks you don't want to replicate. Then click
OK. You can set additional VM properties later.
12. In Replication settings > Configure replication settings, verify that the correct replication policy is
selected. If you modify a policy, changes will be applied to replicating machine, and to new machines.
13. Enable Multi-VM consistency if you want to gather machines into a replication group, and specify a name
for the group. Then click OK. Note that:
Machines in replication groups replicate together, and have shared crash-consistent and app-consistent
recovery points when they fail over.
We recommend that you gather VMs and physical servers together so that they mirror your workloads.
Enabling multi-VM consistency can impact workload performance, and should only be used if machines
are running the same workload and you need consistency.
14. Click Enable Replication. You can track progress of the Enable Protection job in Settings > Jobs > Site
Recovery Jobs. After the Finalize Protection job runs the machine is ready for failover.
After you enable replication, the Mobility service will be installed if you set up push installation. After the Mobility
service is push installed on a VM, a protection job will start and fail. After the failure you need to manually restart
each machine. Then the protection job begins again, and initial replication occurs.
View and manage VM properties
We recommend that you verify the VM properties, and make any changes you need to.
1. Click Replicated items >, and select the machine. The Essentials blade shows information about machines
settings and status.
2. In Properties, you can view replication and failover information for the VM.
3. In Compute and Network > Compute properties, you can specify the Azure VM name and target size.
Modify the name to comply with Azure requirements if you need to.
4. Modify settings for the target network, subnet, and IP address that will be assigned to the Azure VM:
You can set the target IP address.
If you don't provide an address, the failed over machine will use DHCP.
If you set an address that isn't available at failover, failover won't work.
The same target IP address can be used for test failover, if the address is available in the test
failover network.
The number of network adapters is dictated by the size you specify for the target virtual machine:
If the number of network adapters on the source machine is the same as, or less than, the
number of adapters allowed for the target machine size, then the target will have the same
number of adapters as the source.
If the number of adapters for the source virtual machine exceeds the number allowed for the
target size, then the target size maximum will be used.
For example, if a source machine has two network adapters and the target machine size supports
four, the target machine will have two adapters. If the source machine has two adapters but the
supported target size only supports one then the target machine will have only one adapter.
If the virtual machine has multiple network adapters they will all connect to the same network.
If the virtual machine has multiple network adapters then the first one shown in the list becomes the
Default network adapter in the Azure virtual machine.
5. In Disks, you can see the VM operating system, and the data disks that will be replicated.
Run a test failover
After you've set everything up, run a test failover to make sure everything's working as expected. Get a quick
video overview before you start
1. To fail over a single machine, in Settings > Replicated Items, click the VM > +Test Failover icon.
2. To fail over a recovery plan, in Settings > Recovery Plans, right-click the plan > Test Failover. To create a
recovery plan, follow these instructions.
3. In Test Failover, select the Azure network to which Azure VMs will be connected after failover occurs.
4. Click OK to begin the failover. You can track progress by clicking on the VM to open its properties, or on
the Test Failover job in vault name > Settings > Jobs > Site Recovery jobs.
5. After the failover completes, you should also be able to see the replica Azure machine appear in the Azure
portal > Virtual Machines. You should make sure that the VM is the appropriate size, that it's connected
to the appropriate network, and that it's running.
6. If you prepared for connections after failover, you should be able to connect to the Azure VM.
7. Once you're done, click on Cleanup test failover on the recovery plan. In Notes, record and save any
observations associated with the test failover. This will delete the VMs that were created during test
failover.
Learn more about test failovers.
VMware account permissions
Site Recovery needs access to VMware for the process server to automatically discover VMs, and for failover and
failback of VMs.
Migrate: If you only want to migrate VMware VMs to Azure, without ever failing them back, you can use a
VMware account with a read-only role. Such a role can run failover, but can't shut down protected source
machines. This isn't necessary for migration.
Replicate/Recover: If you want to deploy full replication (replicate, failover, failback) the account must be able
to run operations such as creating and removing disks, powering on VMs etc.
Automatic discovery: At least a read-only account is required.
TASK
REQUIRED ACCOUNT/ROLE
PERMISSIONS
DETAILS
Process server
automatically discovers
VMware VMs
You need at least a readonly user
Data Center object –>
Propagate to Child Object,
role=Read-only
User assigned at datacenter
level, and has access to all
the objects in the
datacenter.
To restrict access, assign the
No access role with the
Propagate to child object,
to the child objects (vSphere
hosts, datastores, VMs and
networks).
Failover
You need at least a readonly user
Data Center object –>
Propagate to Child Object,
role=Read-only
User assigned at datacenter
level, and has access to all
the objects in the
datacenter.
To restrict access, assign the
No access role with the
Propagate to child object
to the child objects (vSphere
hosts, datastores, VMs and
networks).
Useful for migration
purposes, but not full
replication, failover, failback.
TASK
REQUIRED ACCOUNT/ROLE
PERMISSIONS
DETAILS
Failover and failback
We suggest you create a
role (Azure_Site_Recovery)
with the required
permissions, and then
assign the role to a VMware
user or group
Data Center object –>
Propagate to Child Object,
role=Azure_Site_Recovery
User assigned at datacenter
level, and has access to all
the objects in the
datacenter.
Datastore -> Allocate space,
browse datastore, low-level
file operations, remove file,
update virtual machine files
Network -> Network assign
To restrict access, assign the
No access role with the
Propagate to child object,
to the child objects (vSphere
hosts, datastores, VMs and
networks).
Resource -> Assign VM to
resource pool, migrate
powered off VM, migrate
powered on VM
Tasks -> Create task,
update task
Virtual machine ->
Configuration
Virtual machine -> Interact
-> answer question, device
connection, configure CD
media, configure floppy
media, power off, power on,
VMware tools install
Virtual machine ->
Inventory -> Create,
register, unregister
Virtual machine ->
Provisioning -> Allow virtual
machine download, allow
virtual machine files upload
Virtual machine ->
Snapshots -> Remove
snapshots
Next steps
After you get replication up and running, when an outage occurs you fail over to Azure, and Azure VMs are
created from the replicated data. You can then access workloads and apps in Azure, until you fail back to your
primary location when it returns to normal operations.
Learn more about different types of failovers, and how to run them.
If you're migrating machines rather than replicating and failing back, read more.
Read about failback, to fail back and replicate Azure VMs back to the primary on-premises site.
Third-party software notices and information
Do Not Translate or Localize
The software and firmware running in the Microsoft product or service is based on or incorporates material from
the projects listed below (collectively, “Third Party Code”). Microsoft is the not original author of the Third Party
Code. The original copyright notice and license, under which Microsoft received such Third Party Code, are set
forth below.
The information in Section A is regarding Third Party Code components from the projects listed below. Such
licenses and information are provided for informational purposes only. This Third Party Code is being relicensed
to you by Microsoft under Microsoft's software licensing terms for the Microsoft product or service.
The information in Section B is regarding Third Party Code components that are being made available to you by
Microsoft under the original licensing terms.
The complete file may be found on the Microsoft Download Center. Microsoft reserves all rights not expressly
granted herein, whether by implication, estoppel or otherwise.
Replicate physical machines to Azure with Site
Recovery
4/24/2017 • 16 min to read • Edit Online
This article describes how to replicate on-premises physical machines to Azure, using the Azure Site Recovery
service in the Azure portal.
If you want to migrate physical machines to Azure (failover only), read this article to learn more.
Post comments and questions at the bottom of this article, or on the Azure Recovery Services Forum.
Deployment summary
Here's what you need to do:
1.
2.
3.
4.
5.
6.
7.
8.
Verify prerequisites and limitations.
Set up Azure network and storage accounts.
Prepare an on-premises machine to act as the configuration server.
Create a Recovery Services vault. The vault contains configuration settings, and orchestrates replication.
Specify source, target, and replication settings.
Deploy the Mobility service on machines that you want to replicate.
Enable replication for the machines.
Run a test failover to make sure everything's working as expected
Prerequisites
SUPPORT REQUIREMENT
DETAILS
Azure
Learn about Azure requirements
On-premises configuration server
On-premises machine (physical or VMware VM) running
Windows Server 2012 R2 or later. You set up the
configuration server during Site Recovery deployment.
By default the process server and master target server are also
installed on this machine. When you scale up, you might need
a separate process server, and it has the same requirements as
the configuration server.
Learn more about these components here
On-premises VMs
Machines you want to replicate should be running a
supported operating system, and conform with Azure
prerequisites.
SUPPORT REQUIREMENT
DETAILS
URLs
The configuration server needs access to these URLs:
*.accesscontrol.windows.net
: Used for access control and
identity management
\*.backup.windowsazure.com
: Used for replication data
transfer and orchestration
: Used for access to the storage
account that stores replicated data
\*.blob.core.windows.net
\*.hypervrecoverymanager.windowsazure.com : Used for
replication management operations and orchestration
time.nist.gov and time.windows.com : Used to check time
synchronization between system and global time
URLs for Azure Government Cloud: *.ugv.hypervrecoverymanager.windowsazure.us *.ugv.backup.windowsazure.us *.ugi.hypervrecoverymanager.windowsazure.us *.ugi.backup.windowsazure.us
If you have IP address-based firewall rules, ensure they allow
communication to Azure.
Allow the Azure Datacenter IP Ranges, and the HTTPS (443)
port.
Allow IP address ranges for the Azure region of your
subscription, and for West US (used for Access Control and
Identity Management).
Allow this URL for the MySQL download:
http://cdn.mysql.com/archives/mysql-5.5/mysql-5.5.37win32.msi.
Mobility service
This will be installed on each machine you want to replicate.
Limitations
LIMITATION
DETAILS
Azure
Storage and network accounts must be in the same region as
the vault
If you use a premium storage account, you also need a
standard store account to store replication logs
You can't replicate to premium accounts in Central and South
India.
LIMITATION
DETAILS
On-premises configuration server
If you install the configuration server on a VMware VM, the
VM adapter type should be VMXNET3. If it isn't, install this
update
If you're using a VMware VM, vSphere PowerCLI 6.0 should
be installed on it.
The machine shouldn't be a domain controller.
The machine should have a static IP address.
The host name should be 15 characters or less, and operating
system should be in English.
Replicated machines
Verify Azure VM limitations
If you want to enable multi-VM consistency, which enables
machines running the same workload to be recovered
together to a consistent data point, open port 20004 on the
machine.
Specific types of Linux storage are supported.
Failback
You can't fail back from Azure to a physical machine. If you
want to be able to fail back to on-premises after failover, you
need a VMware environment, so that you can fail back to a
VMware VM.
Set up Azure
1. Set up an Azure network.
Azure VMs will be placed in this network when they're created after failover.
You can set up a network in Resource Manager, or in classic mode.
2. Set up an Azure storage account for replicated data.
The account can be standard or premium.
You can set up an account in Resource Manager, or in classic mode.
Prepare the configuration server
1. Install Windows Server 2012 R2 or later, on an on-premises physical server, or VMware VM.
2. Make sure the machine has access the URLs listed in prerequisites.
Prepare for Mobility service installation
If you want to push the Mobility service to physical machine, you need an account that can be used by the process
server to access the machines. The account is only used for the push installation. You can use a domain or local
account:
For Windows, if you're not using a domain account, you need to disable Remote User Access control on the local
machine. To do this, in the register under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, add the
DWORD entry LocalAccountTokenFilterPolicy, with a value of 1.
If you want to add the registry entry for Windows from a CLI, type:
REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v
LocalAccountTokenFilterPolicy /t REG_DWORD /d 1.
For Linux, the account should be a root user on the source Linux server.
Create a Recovery Services vault
1. Sign in to the Azure portal > Site Recovery
2. Click New > Monitoring & Management > Backup and Site Recovery >
3. In Name, specify a friendly name to identify the vault. If you have more than one subscription, select one of
them.
4. Create a resource group, or select an existing one. Specify an Azure region. To check supported regions, see
Geographic Availability in Azure Site Recovery Pricing Details
5. If you want to quickly access the vault from the Dashboard, click Pin to dashboard and then click Create.
The new vault will appear on the Dashboard > All resources, and on the main Recovery Services vaults
blade.
Select the protection goal
Select what you want to replicate, and where you want to replicate to.
1. Click Recovery Services vaults > vault.
2. In the Resource Menu > click Site Recovery > Prepare Infrastructure > Protection goal.
3. In Protection goal, select To Azure, and select Not virtualized/other.
Set up the source environment
Set up the configuration server, register it in the vault, and discover VMs.
1. Click Site Recovery > Prepare Infrastructure > Source.
2. If you don’t have a configuration server, click +Configuration server.
3. In Add Server, check that Configuration Server appears in Server type.
4. Download the Site Recovery Unified Setup installation file.
5. Download the vault registration key. You need this when you run Unified Setup. The key is valid for five days
after you generate it.
Run Site Recovery Unified Setup
Before you start, do the following:
Get a quick video overview (the video describes how to replicate VMware VMs but the process is similar for
physical machine replication)
On the configuration server machine, make sure that the system clock is synchronized with a Time Server. If
it's 15 minutes in front or behind, setup might fail.
Run setup as a Local Administrator on the configuration server machine.
Make sure TLS 1.0 is enabled on the machine.
1. Run the Unified Setup installation file.
2. In Before you begin, select Install the configuration server and process server.
3. In Third Party Software License, click I Accept to download and install MySQL.
4. In Registration, select the registration key you downloaded from the vault.
5. In Internet Settings, specify how the Provider running on the configuration server connects to Azure Site
Recovery over the Internet.
If you want to connect with the proxy that's currently set up on the machine, select Connect with
existing proxy settings.
If you want the Provider to connect directly, select Connect directly without a proxy.
If the existing proxy requires authentication, or if you want to use a custom proxy for the Provider
connection, select Connect with custom proxy settings.
If you use a custom proxy, you need to specify the address, port, and credentials.
If you're using a proxy, you should have already allowed the URLs described in prerequisites.
6. In Prerequisites Check, Setup runs a check to make sure that installation can run. If a warning appears
about the Global time sync check, verify that the time on the system clock (Date and Time settings) is the
same as the time zone.
7. In MySQL Configuration, create credentials for logging on to the MySQL server instance that is installed.
8. In Environment Details, select whether you're going to replicate VMware VMs. If you are, then setup
checks that PowerCLI 6.0 is installed.
9. In Install Location, select where you want to install the binaries and store the cache. The drive you select
must have at least 5 GB of disk space available, but we recommend a cache drive with at least 600 GB of free
space.
10. In Network Selection, specify the listener (network adapter and SSL port) on which the configuration
server sends and receives replication data. Port 9443 is the default port used for sending and receiving
replication traffic, but you can modify this port number to suit your environment's requirements. In addition
to the port 9443, we also open port 443, which is used by a web server to orchestrate replication operations.
Do not use Port 443 for sending or receiving replication traffic.
11. In Summary, review the information and click Install. When installation finishes, a passphrase is generated.
You will need this when you enable replication, so copy it and keep it in a secure location.
After registration finishes, the server is displayed on the Settings > Servers blade in the vault.
NOTE
The configuration server can also be installed from the command line.
Set up the target environment
Before you set up the target environment, check you have an Azure storage account and network
1. Click Prepare infrastructure > Target, and select the Azure subscription you want to use.
2. Specify whether your target deployment model is Resource Manager-based, or classic.
3. Site Recovery checks that you have one or more compatible Azure storage accounts and networks.
4. If you haven't created a storage account or network, click +Storage account or +Network, to create a
Resource Manager account or network inline.
Set up replication settings
Before you start, get a quick video overview (the video describes how to replicate VMware VMs but the process is
similar for physical machine replication).
1. To create a new replication policy, click Site Recovery infrastructure > Replication Policies > +Replication
Policy.
2. In Create replication policy, specify a policy name.
3. In RPO threshold, specify the RPO limit. This value specifies how often data recovery points are created. An
alert is generated if continuous replication exceeds this limit.
4. In Recovery point retention, specify (in hours) how long the retention window is for each recovery point.
Replicated VMs can be recovered to any point in a window. Up to 24 hours retention is supported for machines
replicated to premium storage, and 72 hours for standard storage.
5. In App-consistent snapshot frequency, specify how often (in minutes) recovery points containing
application-consistent snapshots will be created. Click OK to create the policy.
6. When you create a new policy it's automatically associated with the configuration server. By default, a matching
policy is automatically created for failback. For example if the replication policy is rep-policy then the failback
policy will be rep-policy-failback. This policy isn't used until you initiate a failback from Azure.
Plan capacity
1. Now that you have your basic infrastructure set up you can think about capacity planning, and figure out
whether you need additional resources. Learn more.
2. When you’re done with capacity planning, select Yes in Have you completed capacity planning?
Prepare VMs for replication
All machines that you want to replicate must have the Mobility service installed. You can install the Mobility service
in a number of ways:
1. Install with a push installation from the process server. You need to prepare machines in advance to use this
method.
2. Install using deployment tools such as System Center Configuration Manager, or Azure automation DSC.
3. Install manually.
Learn more
Enable replication
Before you start:
When you add or modify VMs, it can take up to 15 minutes or longer for changes to take effect, and for them to
appear in the portal.
You can check the last discovered time for VMs in Configuration Servers > Last Contact At.
To add VMs without waiting for the scheduled discovery, highlight the configuration server (don’t click it), and
click Refresh.
If a VM is prepared for push installation, the process server automatically installs the Mobility service when you
enable replication.
Before you start, get a quick video overview (the video describes how to replicate VMware VMs but the
process is similar for physical machine replication).
Exclude disks from replication
By default all disks on a machine are replicated. You can exclude disks from replication. For example you might not
want to replicate disks with temporary data, or data that's refreshed each time a machine or application restarts (for
example pagefile.sys or SQL Server tempdb).
Replicate VMs
1. Click Replicate application > Source.
2. In Source, select On-premises
3. In Source-location, select the configuration server name
4. In Machine type, select Physical Machines.
5. In Process server choose the process server. If you haven't created any additional process servers this will
be the configuration server. Then click OK.
6. In Target, select the subscription and the resource group in which you want to create the Azure VMs after
failover. Choose the deployment model that you want to use in Azure (classic or resource management), for
the failed over VMs.
7. Select the Azure storage account you want to use for replicating data. If you don't want to use an account
you've already set up, you can create a new one.
8. Select the Azure network and subnet to which Azure VMs will connect after failover. Select Configure now
for selected machines, to apply the network setting to all machines you select for protection. Select
Configure later to select the Azure network per machine. If you don't want to use an existing network, you
can create one.
9. In Physical Machines, Click the '+' button and enter Name, IP address and choose the operating system
of the machine you want to replicate.
It will take a few minutes until machines are discovered, and shown in the list.
10. In Properties > Configure properties, select the account that will be used by the process server to
automatically install the Mobility service on the machine.
11. By default all disks are replicated. Click All Disks and clear any disks you don't want to replicate. Then click
OK. You can set additional VM properties later.
12. In Replication settings > Configure replication settings, verify that the correct replication policy is selected.
If you modify a policy, changes will be applied to replicating machine, and to new machines.
13. Enable Multi-VM consistency if you want to gather machines into a replication group, and specify a name
for the group. Then click OK. Note that:
Machines in replication groups replicate together, and have shared crash-consistent and app-consistent
recovery points when they fail over.
We recommend that you gather VMs and physical servers together so that they mirror your workloads.
Enabling multi-VM consistency can impact workload performance, and should only be used if machines
are running the same workload and you need consistency.
14. Click Enable Replication. You can track progress of the Enable Protection job in Settings > Jobs > Site
Recovery Jobs. After the Finalize Protection job runs the machine is ready for failover.
After you enable replication, the Mobility service will be installed if you set up push installation. After the Mobility
service is push installed on a machine, a protection job will start and fail. After the failure you need to manually
restart each machine. Then the protection job begins again, and initial replication occurs.
View and manage Azure VM properties
We recommend that you verify the VM properties, and make any changes you need to.
1. Click Replicated items >, and select the machine. The Essentials blade shows information about machines
settings and status.
2. In Properties, you can view replication and failover information for the VM.
3. In Compute and Network > Compute properties, you can specify the Azure VM name and target size.
Modify the name to comply with Azure requirements if you need to.
4. Modify settings for the target network, subnet, and IP address that will be assigned to the Azure VM:
You can set the target IP address.
If you don't provide an address, the failed over machine will use DHCP.
If you set an address that isn't available at failover, failover won't work.
The same target IP address can be used for test failover, if the address is available in the test
failover network.
The number of network adapters is dictated by the size you specify for the target virtual machine:
If the number of network adapters on the source machine is the same as, or less than, the number
of adapters allowed for the target machine size, then the target will have the same number of
adapters as the source.
If the number of adapters for the source virtual machine exceeds the number allowed for the
target size, then the target size maximum will be used.
For example, if a source machine has two network adapters and the target machine size supports
four, the target machine will have two adapters. If the source machine has two adapters but the
supported target size only supports one then the target machine will have only one adapter.
If the virtual machine has multiple network adapters they will all connect to the same network.
If the virtual machine has multiple network adapters then the first one shown in the list becomes the
Default network adapter in the Azure virtual machine.
5. In Disks, you can see the VM operating system, and the data disks that will be replicated.
Run a test failover
After you've set everything up, run a test failover to make sure everything's working as expected. Watch a quick
video overview before you start.
1. To fail over a single machine, in Settings > Replicated Items, click the VM > +Test Failover icon.
2. To fail over a recovery plan, in Settings > Recovery Plans, right-click the plan > Test Failover. To create a
recovery plan, follow these instructions.
3. In Test Failover, select the Azure network to which Azure VMs will be connected after failover occurs.
4. Click OK to begin the failover. You can track progress by clicking on the VM to open its properties, or on the
Test Failover job in vault name > Settings > Jobs > Site Recovery jobs.
5. After the failover completes, you should also be able to see the replica Azure machine appear in the Azure portal
> Virtual Machines. You should make sure that the VM is the appropriate size, that it's connected to the
appropriate network, and that it's running.
6. If you prepared for connections after failover, you should be able to connect to the Azure VM.
7. Once you're done, click on Cleanup test failover on the recovery plan. In Notes record and save any
observations associated with the test failover. This will delete the virtual machines that were created during test
failover.
For more details, refer to Test failover to Azure document.
Next steps
After you get replication up and running, when an outage occurs you fail over to Azure, and Azure VMs are created
from the replicated data. You can then access workloads and apps in Azure, until you fail back to your primary
location when it returns to normal operations.
Learn more about different types of failovers, and how to run them.
If you're migrating machines rather than replicating and failing back, read more.
When replicating physical machines, you can only failback to a VMWare environment. Read about failback.
Third-party software notices and information
Do Not Translate or Localize
The software and firmware running in the Microsoft product or service is based on or incorporates material from
the projects listed below (collectively, “Third Party Code”). Microsoft is the not original author of the Third Party
Code. The original copyright notice and license, under which Microsoft received such Third Party Code, are set forth
below.
The information in Section A is regarding Third Party Code components from the projects listed below. Such
licenses and information are provided for informational purposes only. This Third Party Code is being relicensed to
you by Microsoft under Microsoft's software licensing terms for the Microsoft product or service.
The information in Section B is regarding Third Party Code components that are being made available to you by
Microsoft under the original licensing terms.
The complete file may be found on the Microsoft Download Center. Microsoft reserves all rights not expressly
granted herein, whether by implication, estoppel or otherwise.
Replicate Hyper-V virtual machines in VMM clouds
to Azure using Site Recovery in the Azure portal
4/6/2017 • 23 min to read • Edit Online
This article describes how to replicate on-premises Hyper-V virtual machines managed in System Center VMM
clouds to Azure, using the Azure Site Recovery service in the Azure portal.
After reading this article, post any comments at the bottom, or on the Azure Recovery Services Forum.
If you want to migrate machines to Azure (without failback), learn more in this article.
Deployment steps
Follow the article to complete these deployment steps:
1. Learn more about the architecture for this deployment. In addition, learn about how Hyper-V replication works
in Site Recovery.
2. Verify prerequisites and limitations.
3. Set up Azure network and storage accounts.
4. Prepare the on-premises VMM server and Hyper-V hosts.
5. Create a Recovery Services vault. The vault contains configuration settings, and orchestrates replication.
6. Specify source settings. Register the VMM server in the vault. Install the Azure Site Recovery Provider on the
VMM server Install the Microsoft Recovery Services agent on Hyper-V hosts.
7. Set up target and replication settings.
8. Enable replication for the VMs.
9. Run a test failover to make sure everything's working as expected.
Prerequisites
SUPPORT REQUIREMENT
DETAILS
Azure
Learn about Azure requirements.
On-premises servers
Learn more about requirements for the on-premises VMM
server and Hyper-V hosts.
On-premises Hyper-V VMs
VMs you want to replicate should be running a supported
operating system, and conform with Azure prerequisites.
SUPPORT REQUIREMENT
DETAILS
Azure URLs
The VMM server needs access to these URLs:
*.accesscontrol.windows.net
: Used for access control and
identity management
\*.backup.windowsazure.com
: Used for replication data
transfer and orchestration
: Used for access to the storage
account that stores replicated data
\*.blob.core.windows.net
\*.hypervrecoverymanager.windowsazure.com : Used for
replication management operations and orchestration
time.nist.gov and time.windows.com : Used to check
time synchronization between system and global time
URLs for Azure Government Cloud: *.ugv.hypervrecoverymanager.windowsazure.us *.ugv.backup.windowsazure.us *.ugi.hypervrecoverymanager.windowsazure.us *.ugi.backup.windowsazure.us
If you have IP address-based firewall rules, ensure they allow
communication to Azure.
Allow the Azure Datacenter IP Ranges, and the HTTPS (443)
port.
Allow IP address ranges for the Azure region of your
subscription, and for West US (used for Access Control and
Identity Management).
Prepare for deployment
To prepare for deployment, you need to:
1.
2.
3.
4.
Set up an Azure network in which Azure VMs will be located after failover.
Set up an Azure storage account for replicated data.
Prepare the VMM server for Site Recovery deployment.
Prepare for network mapping. Set up networks so that you can configure network mapping during Site
Recovery deployment.
Set up an Azure network
You need an Azure network to which Azure VMs created after failover will connect.
The network should be in the same region as the Recovery Services vault.
Depending on the resource model you want to use for failed over Azure VMs, you set up the Azure network in
Resource Manager mode or classic mode.
We recommend you set up a network before you begin. If you don't, you need to do it during Site Recovery
deployment. Azure networks used by Site Recovery can't be moved within the same, or across different,
subscriptions.
Set up an Azure storage account
You need a standard/premium Azure storage account to hold data replicated to Azure.Premium storage is used
for virtual machines that need a consistently high IO performance, and low latency to host IO intensive
workloads. If you want to use a premium account to store replicated data, you also need a standard storage
account to store replication logs that capture ongoing changes to on-premises data. The account must be in
the same region as the Recovery Services vault.
Depending on the resource model you want to use for failed over Azure VMs, you set up an account in
Resource Manager mode or classic mode.
We recommend that you set up an account before you begin. If you don't, you need to do it during Site
Recovery deployment.
Note that storage accounts used by Site Recovery can't be moved within the same, or across different,
subscriptions.
Prepare the VMM server
Make sure that the VMM server complies with the prerequisites.
During Site Recovery deployment, you can specify that all clouds on a VMM server should be available in the
Azure portal. If you only want specific clouds to appear in the portal, you can enable that setting on the cloud in
the VMM admin console.
Prepare for network mapping
You must set up network mapping during Site Recovery deployment. Network mapping maps between source
VMM VM networks and target Azure networks, to enable the following:
Machines that fail over on the same network can connect to each other, even if they're not failed over in the
same way or in the same recovery plan.
If a network gateway is set up on the target Azure network, Azure virtual machines can connect to on-premises
virtual machines.
To set up network mapping, here's what you need:
Make sure that VMs on the source Hyper-V host server are connected to a VMM VM network. That
network should be linked to a logical network that is associated with the cloud.
An Azure network as described above
Create a Recovery Services vault
1. Sign in to the Azure portal.
2. Click New > Monitoring + Management > Backup and Site Recovery (OMS).
3. In Name, specify a friendly name to identify the vault. If you have more than one subscription, select one of
them.
4. Create a resource group, or select an existing one. Specify an Azure region. Machines will be replicated to this
region. To check supported regions see Geographic Availability in Azure Site Recovery Pricing Details
5. If you want to quickly access the vault from the Dashboard, click Pin to dashboard > Create vault.
The new vault appears on the Dashboard > All resources, and on the main Recovery Services vaults blade.
Select the protection goal
Select what you want to replicate, and where you want to replicate to.
1. In Recovery Services vaults, select the vault.
2. In Getting Started, click Site Recovery > Prepare Infrastructure > Protection goal.
3. In Protection goal select To Azure, and select Yes, with Hyper-V. Select Yes to confirm you're using VMM
to manage Hyper-V hosts and the recovery site. Then click OK.
Set up the source environment
Install the Azure Site Recovery Provider on the VMM server, and register the server in the vault. Install the Azure
Recovery Services agent on Hyper-V hosts.
1. Click Prepare Infrastructure > Source.
2. In Prepare source, click + VMM to add a VMM server.
3. In Add Server, check that System Center VMM server appears in Server type and that the VMM server
meets the prerequisites and URL requirements.
4. Download the Azure Site Recovery Provider installation file.
5. Download the registration key. You need this when you run setup. The key is valid for five days after you
generate it.
Install the Provider on the VMM server
1. Run the Provider setup file on the VMM server.
2. In Microsoft Update, you can opt in for updates so that Provider updates are installed in accordance with
your Microsoft Update policy.
3. In Installation, accept or modify the default Provider installation location and click Install.
4. When installation finishes, click Register to register the VMM server in the vault.
5. In the Vault Settings page, click Browse to select the vault key file. Specify the Azure Site Recovery
subscription and the vault name.
6. In Internet Connection, specify how the Provider running on the VMM server will connect to Site
Recovery over the internet.
If you want the Provider to connect directly, select Connect directly to Azure Site Recovery without
a proxy.
If your existing proxy requires authentication, or you want to use a custom proxy, select Connect to
Azure Site Recovery using a proxy server.
If you use a custom proxy, specify the address, port, and credentials.
If you're using a proxy, you should have already allowed the URLs described in prerequisites.
If you use a custom proxy, a VMM RunAs account (DRAProxyAccount) will be created automatically
using the specified proxy credentials. Configure the proxy server so that this account can
authenticate successfully. The VMM RunAs account settings can be modified in the VMM console. In
Settings, expand Security > Run As Accounts, and then modify the password for
DRAProxyAccount. You’ll need to restart the VMM service so that this setting takes effect.
7. Accept or modify the location of an SSL certificate that’s automatically generated for data encryption. This
certificate is used if you enable data encryption for a cloud protected by Azure in the Azure Site Recovery
portal. Keep this certificate safe. When you run a failover to Azure you’ll need it to decrypt, if data encryption is
enabled.
8. In Server name, specify a friendly name to identify the VMM server in the vault. In a cluster configuration,
specify the VMM cluster role name.
9. Enable Sync cloud metadata, if you want to synchronize metadata for all clouds on the VMM server with
the vault. This action only needs to happen once on each server. If you don't want to synchronize all clouds,
you can leave this setting unchecked and synchronize each cloud individually in the cloud properties in the
VMM console. Click Register to complete the process.
10. Registration starts. After registration finishes, the server is displayed in Site Recovery Infrastructure > VMM
Servers.
Install the Azure Recovery Services agent on Hyper-V hosts
1. After you've set up the Provider, you need to download the installation file for the Azure Recovery Services
agent. Run setup on each Hyper-V server in the VMM cloud.
2. In Prerequisites Check, click Next. Any missing prerequisites will be automatically installed.
3. In Installation Settings, accept or modify the installation location, and the cache location. You can configure
the cache on a drive that has at least 5 GB of storage available but we recommend a cache drive with 600 GB
or more of free space. Then click Install.
4. After installation is complete, click Close to finish.
Command line installation
You can install the Microsoft Azure Recovery Services Agent from command line using the following command:
marsagentinstaller.exe /q /nu
Set up internet proxy access to Site Recovery from Hyper-V hosts
The Recovery Services agent running on Hyper-V hosts needs internet access to Azure for VM replication. If you're
accessing the internet through a proxy, set it up as follows:
1. Open the Microsoft Azure Backup MMC snap-in on the Hyper-V host. By default, a shortcut for Microsoft Azure
Backup is available on the desktop or in C:\Program Files\Microsoft Azure Recovery Services
Agent\bin\wabadmin.
2. In the snap-in, click Change Properties.
3. On the Proxy Configuration tab, specify proxy server information.
4. Check that the agent can reach the URLs described in the prerequisites.
Set up the target environment
Specify the Azure storage account to be used for replication, and the Azure network to which Azure VMs will
connect after failover.
1. Click Prepare infrastructure > Target, select the subscription and the resource group where you want to
create the failed over virtual machines. Choose the deployment model that you want to use in Azure
(classic or resource management) for the failed over virtual machines.
2. Site Recovery checks that you have one or more compatible Azure storage accounts and networks.
3. If you haven't created a storage account, and you want to create one using Resource Manager, click
+Storage account to do that inline. On the Create storage account blade specify an account name, type,
subscription, and location. The account should be in the same location as the Recovery Services vault.
If you want to create a storage account using the classic model, do that in the Azure portal. Learn more
If you’re using a premium storage account for replicated data, set up an additional standard storage
account, to store replication logs that capture ongoing changes to on-premises data.
1. If you haven't created an Azure network, and you want to create one using Resource Manager, click
+Network to do that inline. On the Create virtual network blade specify a network name, address
range, subnet details, subscription, and location. The network should be in the same location as the
Recovery Services vault.
If you want to create a network using the classic model, do that in the Azure portal. Learn more.
Configure network mapping
Read a quick overview of what network mapping does.
Verify that virtual machines on the VMM server are connected to a VM network, and that you've created at
least one Azure virtual network. Multiple VM networks can be mapped to a single Azure network.
Configure mapping as follows:
1. In Site Recovery Infrastructure > Network mappings > Network Mapping, click the +Network
Mapping icon.
2. In Add network mapping, select the source VMM server, and Azure as the target.
3. Verify the subscription and the deployment model after failover.
4. In Source network, select the source on-premises VM network you want to map from the list associated with
the VMM server.
5. In Target network, select the Azure network in which replica Azure VMs will be located when they're
created. Then click OK.
Here's what happens when network mapping begins:
Existing VMs on the source VM network are connected to the target network when mapping begins. New VMs
connected to the source VM network are connected to the mapped Azure network when replication occurs.
If you modify an existing network mapping, replica virtual machines connect using the new settings.
If the target network has multiple subnets, and one of those subnets has the same name as subnet on which
the source virtual machine is located, then the replica virtual machine connects to that target subnet after
failover.
If there’s no target subnet with a matching name, the virtual machine connects to the first subnet in the
network.
Configure replication settings
1. To create a new replication policy, click Prepare infrastructure > Replication Settings > +Create and
associate.
2. In Create and associate policy, specify a policy name.
3. In Copy frequency, specify how often you want to replicate delta data after the initial replication (every 30
seconds, 5 or 15 minutes).
NOTE
A 30 second frequency isn't supported when replicating to premium storage. The limitation is determined by the
number of snapshots per blob (100) supported by premium storage. Learn more
4. In Recovery point retention, specify in hours how long the retention window will be for each recovery
point. Protected machines can be recovered to any point within a window.
5. In App-consistent snapshot frequency, specify how frequently (1-12 hours) recovery points containing
application-consistent snapshots will be created. Hyper-V uses two types of snapshots — a standard snapshot
that provides an incremental snapshot of the entire virtual machine, and an application-consistent snapshot
that takes a point-in-time snapshot of the application data inside the virtual machine. Application-consistent
snapshots use Volume Shadow Copy Service (VSS) to ensure that applications are in a consistent state when
the snapshot is taken. Note that if you enable application-consistent snapshots, it will affect the performance of
applications running on source virtual machines. Ensure that the value you set is less than the number of
additional recovery points you configure.
6. In Initial replication start time, indicate when to start the initial replication. The replication occurs over your
internet bandwidth so you might want to schedule it outside your busy hours.
7. In Encrypt data stored on Azure, specify whether to encrypt at rest data in Azure storage. Then click OK.
8. When you create a new policy it's automatically associated with the VMM cloud. Click OK. You can
associate additional VMM clouds (and the VMs in them) with this replication policy in Replication > policy
name > Associate VMM Cloud.
Capacity planning
Now that you have your basic infrastructure set up, think about capacity planning, and figure out whether you
need additional resources.
Site Recovery provides a capacity planner to help you allocate the right resources for your source environment,
Site Recovery components, networking, and storage. You can run the planner in quick mode for estimations based
on an average number of VMs, disks, and storage, or in detailed mode in which you input figures at the workload
level. Before you start:
Gather information about your replication environment, including VMs, disks per VMs, and storage per disk.
Estimate the daily change (churn) rate you’ll have for replicated data. You can use the Capacity planner for
Hyper-V Replica to help you do this.
1. Click Download, to download the tool and then run it. Read the article that accompanies the tool.
2. When you’re done, select Yes in Have you run the Capacity Planner?
Learn more about controlling network bandwidth
Enable replication
Now enable replication as follows:
1. Click Step 2: Replicate application > Source. After you've enabled replication for the first time, click
+Replicate in the vault to enable replication for additional machines.
2. In the Source blade, select the VMM server, and the cloud in which the Hyper-V hosts are located. Then
click OK.
3. In Target, select the subscription, post-failover deployment model, and the storage account you're using
for replicated data.
4. Select the storage account you want to use. If you want to use a different storage account than those you have,
you can create one. If you’re using a premium storage account for replicated data, you need to select an
additional standard storage account to store replication logs that capture ongoing changes to on-premises
data.To create a storage account using the Resource Manager model click Create new. If you want to create a
storage account using the classic model, do that in the Azure portal. Then click OK.
5. Select the Azure network and subnet to which Azure VMs will connect, when they're created after failover.
Select Configure now for selected machines, to apply the network setting to all machines you select for
protection. Select Configure later, to select the Azure network per machine. If you want to use a different
network from those you have, you can create one. To create a network using the Resource Manager model
click Create new. If you want to create a network using the classic model, do that in the Azure portal. Select a
subnet if applicable. Then click OK.
6. In Virtual Machines > Select virtual machines, click and select each machine you want to replicate. You
can only select machines for which replication can be enabled. Then click OK.
7. In Properties > Configure properties, select the operating system for the selected VMs, and the OS disk.
Verify that the Azure VM name (target name) complies with Azure virtual machine requirements.
By default all the disks of the VM are selected for replication, but you can clear disks to exclude them.
You might want to exclude disks to reduce replication bandwidth. For example, you might not
want to replicate disks with temporary data, or data that's refreshed each time a machine or apps
restarts (such as pagefile.sys or Microsoft SQL Server tempdb). You can exclude the disk from
replication by unselecting the disk.
Only basic disks can be exclude. You can't exclude OS disks.
We recommend that you don't exclude dynamic disks. Site Recovery can't identify whether a
virtual hard disk inside a guest VM is basic or dynamic. If all dependent dynamic volume disks
aren't excluded, the protected dynamic disk will show as a failed disk when the VM fails over, and
the data on that disk won't be accessible.
After replication is enabled, you can't add or remove disks for replication. If you want to add or
exclude a disk, you need to disable protection for the VM, and then re-enable it.
Disks you create manually in Azure aren't failed back. For example, if you fail over three disks,
and create two directly in Azure VM, only the three disks which were failed over will be failed
back from Azure to Hyper-V. You can't include disks created manually in failback, or in reverse
replication from Hyper-V to Azure.
If you exclude a disk that's needed for an application to operate, after failover to Azure you need
to create it manually in Azure, so that the replicated application can run. Alternatively, you could
integrate Azure automation into a recovery plan, to create the disk during failover of the machine.
Click OK to save changes. You can set additional properties later.
8. In Replication settings > Configure replication settings, select the replication policy you want to apply
for the protected VMs. Then click OK. You can modify the replication policy in Replication policies >
policy name > Edit Settings. Changes you apply are used for machines that are already replicating, and
new machines.
You can track progress of the Enable Protection job in Jobs > Site Recovery jobs. After the Finalize
Protection job runs, the machine is ready for failover.
View and manage VM properties
We recommend that you verify the properties of the source machine. Remember that the Azure VM name should
conform with Azure virtual machine requirements.
1. In Protected Items, click Replicated Items, and select the machine to see its details.
2. In Properties, you can view replication and failover information for the VM.
3. In Compute and Network > Compute properties, you can specify the Azure VM name and target size.
Modify the name to comply with Azure requirements if you need to. You can also view and modify
information about the target network, subnet, and the IP address that's assigned to the Azure VM. Note
that:
You can set the target IP address. If you don't provide an address, the failed over machine will use
DHCP. If you set an address that isn't available at failover, the failover will fail. The same target IP
address can be used for test failover if the address is available in the test failover network.
The number of network adapters is dictated by the size you specify for the target virtual machine, as
follows:
If the number of network adapters on the source machine is less than or equal to the number of
adapters allowed for the target machine size, then the target will have the same number of
adapters as the source.
If the number of adapters for the source virtual machine exceeds the number allowed for the
target size, then the target size maximum is used.
For example if a source machine has two network adapters and the target machine size supports
four, the target machine will have two adapters. If the source machine has two adapters but the
supported target size only supports one, then the target machine will have only one adapter.
If the VM has multiple network adapters, they will all connect to the same network.
4. In Disks you can see the operating system and data disks on the VM that will be replicated.
Test the deployment
To test the deployment you can run a test failover for a single virtual machine or a recovery plan that contains one
or more virtual machines.
Before you start
If you want to connect to Azure VMs using RDP after failover, learn about preparing to connect.
To fully test you need to copy of Active Directory and DNS in your test environment. Learn more.
Run a test failover
1. To fail over a single VM, in Replicated Items, click the VM > +Test Failover.
2. To fail over a recovery plan, in Recovery Plans, right-click the plan > Test Failover. To create a recovery plan,
follow these instructions.
3. In Test Failover, select the Azure network to which Azure VMs connect after failover occurs.
4. Click OK to begin the failover. You can track progress by clicking on the VM to open its properties, or on the
Test Failover job in Site Recovery jobs.
5. After the failover completes, you should also be able to see the replica Azure machine appear in the Azure
portal > Virtual Machines. You should make sure that the VM is the appropriate size, that it's connected to
the appropriate network, and is running.
6. If you prepared for connections after failover, you should be able to connect to the Azure VM.
7. Once you're done, click on Cleanup test failover on the recovery plan. In Notes record and save any
observations associated with the test failover. This will delete the virtual machines that were created during test
failover.
For more details, read the Test failover to Azure article.
Monitor the deployment
Here's how you can monitor configuration settings, status, and health for the Site Recovery deployment:
1. Click on the vault name to access the Essentials dashboard. In this dashboard you can Site Recovery jobs,
replication status, recovery plans, server health, and events. You can customize Essentials to show the tiles
and layouts that are most useful to you, including the status of other Site Recovery and Backup vaults.
2. In Health, you can monitor issues on on-premises servers (VMM or configuration servers), and the events
raised by Site Recovery in the last 24 hours.
3. In the Replicated Items, Recovery Plans, and Site Recovery Jobs tiles you can manage and monitor
replication. You can drill into jobs in Jobs > Site Recovery Jobs.
Command-line installation for the Azure Site Recovery Provider
The Azure Site Recovery Provider can be installed from the command-line. This method can be used to install the
Provider on Server Core for Windows Server 2012 R2.
1. Download the Provider installation file and registration key to a folder. For example, C:\ASR.
2. From an elevated command prompt, run these commands to extract the Provider installer:
C:\Windows\System32> CD C:\ASR
C:\ASR> AzureSiteRecoveryProvider.exe /x:. /q
3. Run this command to install the components:
C:\ASR> setupdr.exe /i
4. Then run these commands, to register the server in the vault:
CD C:\Program Files\Microsoft System Center 2012 R2\Virtual Machine Manager\bin
C:\Program Files\Microsoft System Center 2012 R2\Virtual Machine Manager\bin\> DRConfigurator.exe /r
/Friendlyname <friendly name of the server> /Credentials <path of the credentials file>
/EncryptionEnabled <full file name to save the encryption certificate>
Where:
/Credentials: Mandatory parameter that specifies where the registration key file is located.
/FriendlyName: Mandatory parameter for the name of the Hyper-V host server that appears in the Azure Site
Recovery portal.
/EncryptionEnabled: Optional parameter when you're replicating Hyper-V VMs in VMM clouds to
Azure. Specify if you want to encrypt virtual machines in Azure (at rest encryption). Ensure that the
name of the file has a .pfx extension. Encryption is off by default.
/proxyAddress: Optional parameter that specifies the address of the proxy server.
/proxyport: Optional parameter that specifies the port of the proxy server.
/proxyUsername: Optional parameter that specifies the proxy user name (if proxy requires authentication).
/proxyPassword: Optional parameter that specifies the password to authenticate with proxy server (if the
proxy requires authentication).
Network bandwidth considerations
You can use the capacity planner tool to calculate the bandwidth you need for replication (initial replication and
then delta). To control the amount of bandwidth use for replication, you have a few options:
Throttle bandwidth: Hyper-V traffic that replicates to a secondary site goes through a specific Hyper-V host.
You can throttle bandwidth on the host server.
Tweak bandwidth: You can influence the bandwidth used for replication using a couple of registry keys.
Throttle bandwidth
1. Open the Microsoft Azure Backup MMC snap-in on the Hyper-V host server. By default, a shortcut for
Microsoft Azure Backup is available on the desktop or in C:\Program Files\Microsoft Azure Recovery Services
Agent\bin\wabadmin.
2. In the snap-in, click Change Properties.
3. On the Throttling tab, select Enable internet bandwidth usage throttling for backup operations, and
set the limits for work and non-work hours. Valid ranges are from 512 Kbps to 102 Mbps per second.
You can also use the Set-OBMachineSetting cmdlet to set throttling. Here's a sample:
$mon = [System.DayOfWeek]::Monday
$tue = [System.DayOfWeek]::Tuesday
Set-OBMachineSetting -WorkDay $mon, $tue -StartWorkHour "9:00:00" -EndWorkHour "18:00:00" -WorkHourBandwidth
(512*1024) -NonWorkHourBandwidth (2048*1024)
Set-OBMachineSetting -NoThrottle indicates that no throttling is required.
Influence network bandwidth
The UploadThreadsPerVM registry value controls the number of threads that are used for data transfer (initial
or delta replication) of a disk. A higher value increases the network bandwidth used for replication. The
DownloadThreadsPerVM registry value specifies the number of threads used for data transfer during failback.
1. In the registry, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure
Backup\Replication.
Modify the value UploadThreadsPerVM (or create the key if it doesn't exist) to control threads used
for disk replication.
Modify the value DownloadThreadsPerVM (or create the key if it doesn't exist) to control threads used
for failback traffic from Azure.
2. The default value is 4. In an “overprovisioned” network, these registry keys should be changed from the default
values. The maximum is 32. Monitor traffic to optimize the value.
Next steps
After initial replication is complete, and you've tested the deployment, you can invoke failovers as the need arises.
Learn more about different types of failovers and how to run them.
Replicate Hyper-V virtual machines (without VMM)
to Azure using Azure Site Recovery with the Azure
portal
4/6/2017 • 18 min to read • Edit Online
This article describes how to replicate on-premises Hyper-V virtual machines to Azure, using Azure Site Recovery
in the Azure portal. In this deployment Hyper-V VMs aren't managed by System Center Virtual Machine Manager
(VMM).
After reading this article, post any comments at the bottom, or ask technical questions on the Azure Recovery
Services Forum.
If you want to migrate machines to Azure (without failback), learn more in this article.
Deployment steps
Follow the article to complete these deployment steps:
1. Learn more about the architecture for this deployment. In addition, learn about how Hyper-V replication works
in Site Recovery.
2. Verify prerequisites and limitations.
3. Set up Azure network and storage accounts.
4. Prepare Hyper-V hosts.
5. Create a Recovery Services vault. The vault contains configuration settings, and orchestrates replication.
6. Specify source settings. Create a Hyper-V site that contains the Hyper-V hosts, and register the site in the vault.
Install the Azure Site Recovery Provider, and the Microsoft Recovery Services agent, on the Hyper-V hosts.
7. Set up target and replication settings.
8. Enable replication for the VMs.
9. Run a test failover to make sure everything's working as expected.
Prerequisites
REQUIREMENT
DETAILS
Azure
Learn about Azure requirements.
On-premises servers
Learn more about requirements for the on-premises Hyper-V
hosts.
On-premises Hyper-V VMs
VMs you want to replicate should be running a supported
operating system, and conform with Azure prerequisites.
REQUIREMENT
DETAILS
Azure URLs
Hyper-V hosts need access to these URLs:
*.accesscontrol.windows.net
: Used for access control and
identity management
\*.backup.windowsazure.com
: Used for replication data
transfer and orchestration
: Used for access to the storage
account that stores replicated data
\*.blob.core.windows.net
\*.hypervrecoverymanager.windowsazure.com : Used for
replication management operations and orchestration
time.nist.gov and time.windows.com : Used to check
time synchronization between system and global time
URLs for Azure Government Cloud: *.ugv.hypervrecoverymanager.windowsazure.us *.ugv.backup.windowsazure.us *.ugi.hypervrecoverymanager.windowsazure.us *.ugi.backup.windowsazure.us
If you have IP address-based firewall rules, ensure they allow
communication to Azure.
Allow the Azure Datacenter IP Ranges, and the HTTPS (443)
port.
Allow IP address ranges for the Azure region of your
subscription, and for West US (used for Access Control and
Identity Management).
Prepare for deployment
To prepare for deployment you need to:
1. Set up an Azure network in which Azure VMs will be located when they're created after failover.
2. Set up an Azure storage account for replicated data.
3. Prepare the Hyper-V hosts to ensure they can access the required URLs.
Set up an Azure network
Set up an Azure network. You’ll need this so that the Azure VMs created after failover are connected to a network.
The network should be in the same region as the Recovery Services vault.
Depending on the resource model you want to use for failed over Azure VMs, you set up the Azure network in
Resource Manager mode, or classic mode.
We recommend you set up a network before you begin. If you don't, you need to do it during Site Recovery
deployment.
Storage accounts used by Site Recovery can't be moved within the same, or across different, subscriptions.
Set up an Azure storage account
You need a standard/premium Azure storage account to hold data replicated to Azure.Premium storage is
typically used for virtual machines that need a consistently high IO performance, and low latency to host IO
intensive workloads.
If you want to use a premium account to store replicated data, you also need a standard storage account to
store replication logs that capture ongoing changes to on-premises data.
Depending on the resource model you want to use for failed over Azure VMs, you set up an account in
Resource Manager mode, or classic mode.
We recommend that you set up a storage account before you begin. If you don't you need to do it during Site
Recovery deployment. The accounts must be in the same region as the Recovery Services vault.
You can't move storage accounts used by Site Recovery across resource groups within the same subscription,
or across different subscriptions.
Prepare the Hyper-V hosts
Make sure that the Hyper-V hosts meet the prerequisites.
Make sure that the hosts can access the required URLs.
Create a Recovery Services vault
1. Sign in to the Azure portal.
2. Click New > Monitoring + Management > Backup and Site Recovery (OMS).
3. In Name, specify a friendly name to identify the vault. If you have more than one subscription, select one
of them.
4. Create a new resource group or select an existing one, and specify an Azure region. Machines will be
replicated to this region. To check supported regions, see Geographic Availability in Azure Site Recovery
Pricing Details.
5. If you want to quickly access the vault from the Dashboard, click Pin to dashboard, and then click Create.
The new vault appears in the Dashboard > All resources list, and on the main Recovery Services vaults blade.
Select the protection goal
Select what you want to replicate, and where you want to replicate to.
1. In the Recovery Services vaults, select the vault.
2. In Getting Started, click Site Recovery > Prepare Infrastructure > Protection goal.
3. In Protection goal, select To Azure, and select Yes, with Hyper-V. Select No to confirm you're not using
VMM. Then click OK.
Set up the source environment
Set up the Hyper-V site, install the Azure Site Recovery Provider and the Azure Recovery Services agent on HyperV hosts, and register the site in the vault.
1. In Prepare Infrastructure, click Source. To add a new Hyper-V site as a container for your Hyper-V hosts
or clusters, click +Hyper-V Site.
2. In Create Hyper-V site, specify a name for the site. Then click OK. Now, select the site you created, and
click +Hyper-V Server to add a server to the site.
3. In Add Server > Server type, check that Hyper-V server is displayed.
Make sure that the Hyper-V server you want to add complies with the prerequisites, and is able to
access the specified URLs.
Download the Azure Site Recovery Provider installation file. You run this file to install the Provider
and the Recovery Services agent on each Hyper-V host.
Install the Provider and agent
1. Run the Provider setup file on each host you added to the Hyper-V site. If you're installing on a Hyper-V
cluster, run setup on each cluster node. Installing and registering each Hyper-V cluster node ensures that VMs
are protected, even if they migrate across nodes.
2. In Microsoft Update, you can opt in for updates so that Provider updates are installed in accordance with
your Microsoft Update policy.
3. In Installation, accept or modify the default Provider installation location and click Install.
4. In Vault Settings, click Browse to select the vault key file that you downloaded. Specify the Azure Site
Recovery subscription, the vault name, and the Hyper-V site to which the Hyper-V server belongs.
5. In Proxy Settings, specify how the Provider running on Hyper-V hosts connects to Azure Site Recovery
over the internet.
If you want the Provider to connect directly select Connect directly to Azure Site Recovery without
a proxy.
If your existing proxy requires authentication, or you want to use a custom proxy for the Provider
connection, select Connect to Azure Site Recovery using a proxy server.
If you use a proxy:
Specify the address, port, and credentials
Make sure the URLs described in the prerequisites are allowed through the proxy.
6. After installation finishes, click Register to register the server in the vault.
7. After registration finishes, metadata from the Hyper-V server is retrieved by Azure Site Recovery, and the
server is displayed in Site Recovery Infrastructure > Hyper-V Hosts.
Set up the target environment
Specify the Azure storage account for replication, and the Azure network to which Azure VMs will connect after
failover.
1. Click Prepare infrastructure > Target.
2. Select the subscription and the resource group in which you want to create the Azure VMs after failover.
Choose the deployment model that you want to use in Azure (classic or resource management) for the
VMs.
3. Site Recovery checks that you have one or more compatible Azure storage accounts and networks.
If you don't have a storage account, click +Storage to create a Resource Manager-based account inline.
Read about storage requirements.
If you don't have a Azure network, click +Network to create a Resource Manager-based network
inline.
Configure replication settings
1. To create a new replication policy, click Prepare infrastructure > Replication Settings > +Create and
associate.
2. In Create and associate policy, specify a policy name.
3. In Copy frequency, specify how often you want to replicate delta data after the initial replication (every 30
seconds, 5 or 15 minutes).
NOTE
A 30 second frequency isn't supported when replicating to premium storage. The limitation is determined by the
number of snapshots per blob (100) supported by premium storage. Learn more.
4. In Recovery point retention, specify in hours how long the retention window is for each recovery point.
VMs can be recovered to any point within a window.
5. In App-consistent snapshot frequency, specify how frequently (1-12 hours) recovery points containing
application-consistent snapshots are created.
Hyper-V uses two types of snapshots — a standard snapshot that provides an incremental snapshot of
the entire virtual machine, and an application-consistent snapshot that takes a point-in-time snapshot
of the application data inside the virtual machine.
Application-consistent snapshots use Volume Shadow Copy Service (VSS) to ensure that applications
are in a consistent state when the snapshot is taken.
If you enable application-consistent snapshots, it will affect the performance of applications running on
source virtual machines. Ensure that the value you set is less than the number of additional recovery
points you configure.
6. In Initial replication start time, specify when to start the initial replication. The replication occurs over
your internet bandwidth so you might want to schedule it outside your busy hours. Then click OK.
When you create a new policy, it's automatically associated with the Hyper-V site. You can associate a Hyper-V
site (and the VMs in it) with multiple replication policies in Replication > policy-name > Associate Hyper-V
Site.
Capacity planning
Now that you have your basic infrastructure set up, you can think about capacity planning, and figure out whether
you need additional resources.
Site Recovery provides a capacity planner to help you allocate the right resources for compute, networking, and
storage. You can run the planner in quick mode for estimations based on an average number of VMs, disks, and
storage, or in detailed mode with customized numbers at the workload level. Before you start you need to:
Gather information about your replication environment, including VMs, disks per VMs, and storage per disk.
Estimate the daily change (churn) rate for your replicated data. You can use the Capacity Planner for Hyper-V
Replica to help you do this.
1. Click Download to download the tool, and then run it. Read the article that accompanies the tool.
2. When you’re done, select Yes in Have you run the Capacity Planner?
Learn more about controlling network bandwidth
Enable replication
Enable replication for VMs as follows:
1. Click Replicate application > Source. After you've set up replication for the first time, you can click
+Replicate to enable replication for additional machines.
2. In Source, select the Hyper-V site. Then click OK.
3. In Target, select the vault subscription, and the failover model you want to use in Azure (classic or resource
management) after failover.
4. Select the storage account you want to use. If you don't have an account you want to use, you can create one.
Then click OK.
5. Select the Azure network and subnet to which Azure VMs will connect when they're created failover.
To apply the network settings to all machines you enable for replication, select Configure now for
selected machines.
Select Configure later to select the Azure network per machine.
If you don't have a network you want to use, you can create one. Select a subnet if applicable. Then click
OK.
6. In Virtual Machines > Select virtual machines, click and select each machine you want to replicate. You
can only select machines for which replication can be enabled. Then click OK.
7. In Properties > Configure properties, select the operating system for the selected VMs, and the OS disk.
8. Verify that the Azure VM name (target name) complies with Azure virtual machine requirements.
9. By default all the disks of the VM are selected for replication, but you can clear disks to exclude them.
You might want to exclude disks to reduce replication bandwidth. For example, you might not want to
replicate disks with temporary data, or data that's refreshed each time a machine or apps restarts (such
as pagefile.sys or Microsoft SQL Server tempdb). You can exclude the disk from replication by
unselecting the disk.
Only basic disks can be exclude. You can't exclude OS disks.
We recommend that you don't exclude dynamic disks. Site Recovery can't identify whether a virtual
hard disk inside a guest VM is basic or dynamic. If all dependent dynamic volume disks aren't excluded,
the protected dynamic disk will show as a failed disk when the VM fails over, and the data on that disk
won't be accessible.
After replication is enabled, you can't add or remove disks for replication. If you want to add or
exclude a disk, you need to disable protection for the VM, and then re-enable it.
Disks you create manually in Azure aren't failed back. For example, if you fail over three disks,
and create two directly in Azure VM, only the three disks which were failed over will be failed
back from Azure to Hyper-V. You can't include disks created manually in failback, or in reverse
replication from Hyper-V to Azure.
If you exclude a disk that's needed for an application to operate, after failover to Azure you need
to create it manually in Azure, so that the replicated application can run. Alternatively, you could
integrate Azure automation into a recovery plan, to create the disk during failover of the
machine.
10. Click OK to save changes. You can set additional properties later.
11. In Replication settings > Configure replication settings, select the replication policy you want to apply
for the protected VMs. Then click OK. You can modify the replication policy in Replication policies >
policy-name > Edit Settings. Changes you apply will be used for machines that are already replicating,
and new machines.
You can track progress of the Enable Protection job in Jobs > Site Recovery jobs. After the Finalize
Protection job runs the machine is ready for failover.
View and manage VM properties
We recommend that you verify the properties of the source machine.
1. In Protected Items, click Replicated Items, and select the machine.
2. In Properties, you can view replication and failover information for the VM.
3. In Compute and Network > Compute properties, you can specify the Azure VM name and target size.
Modify the name to comply with Azure requirements if you need to. You can also view and modify
information about the target network, subnet, and IP address that will be assigned to the Azure VM. Note
the following:
You can set the target IP address. If you don't provide an address, the failed over machine will use
DHCP. If you set an address that isn't available at failover, the failover will fail. The same target IP
address can be used for test failover if the address is available in the test failover network.
The number of network adapters is dictated by the size you specify for the target virtual machine, as
follows:
If the number of network adapters on the source machine is less than or equal to the number of
adapters allowed for the target machine size, then the target will have the same number of
adapters as the source.
If the number of adapters for the source virtual machine exceeds the number allowed for the
target size then the target size maximum will be used.
For example if a source machine has two network adapters and the target machine size supports
four, the target machine will have two adapters. If the source machine has two adapters but the
supported target size only supports one then the target machine will have only one adapter.
If the VM has multiple network adapters they will all connect to the same network.
If the virtual machine has multiple network adapters then the first one shown in the list becomes
the Default network adapter in the Azure virtual machine.
4. In Disks, you can see the operating system and data disks on the VM that will be replicated.
Test the deployment
To test the deployment you can run a test failover for a single virtual machine or a recovery plan that contains
one or more virtual machines.
Before you start
If you want to connect to Azure VMs using RDP after failover, learn about preparing to connect.
To fully test you need to copy of Active Directory and DNS in your test environment. Learn more.
Run a test failover
1. To fail over a single machine, in Replicated Items, click the VM > +Test Failover icon.
2. To fail over a recovery plan, in Recovery Plans, right-click the plan > Test Failover. To create a recovery plan,
follow these instructions.
3. In Test Failover, select the Azure network to which Azure VMs will be connected after failover occurs.
4. Click OK to begin the failover. You can track progress by clicking on the VM to open its properties, or on the
Test Failover job in vault name > Jobs > Site Recovery jobs.
5. After the failover completes, you should also be able to see the replica Azure machine appear in the Azure
portal > Virtual Machines. You should make sure that the VM is the appropriate size, that it's connected to
the appropriate network, and that it's running.
6. If you prepared for connections after failover, you should be able to connect to the Azure VM.
7. Once you're done, click on Cleanup test failover on the recovery plan. In Notes record and save any
observations associated with the test failover. This will delete the virtual machines that were created during
test failover.
For more details, read the Test failover to Azure article.
Monitor the deployment
Monitor the configuration settings, status, and health for your Site Recovery deployment:
1. Click on the vault name to access the Essentials dashboard. In this dashboard you can track Site Recovery
jobs, replication status, recovery plans, server health, and events.
2. In the Health tile you can monitor site servers that are experiencing issue, and the events raised by Site
Recovery in the last 24 hours. You can customize Essentials to show the tiles and layouts that are most useful
to you, including the status of other Site Recovery and Backup vaults.
3. You can manage and monitor replication in the Replicated Items, Recovery Plans, and Site Recovery Jobs
tiles. You can drill into jobs for more details in Jobs > Site Recovery Jobs.
Command-line Provider and agent installation
The Azure Site Recovery Provider and agent can also be installed using the following command line. This method
can be used to install the provider on a Server Core for Windows Server 2012 R2.
1. Download the Provider installation file and registration key to a folder. For example C:\ASR.
2. From an elevated command prompt, run these commands to extract the Provider installer:
C:\Windows\System32> CD C:\ASR
C:\ASR> AzureSiteRecoveryProvider.exe /x:. /q
3. Run this command to install the components:
C:\ASR> setupdr.exe /i
4. Then run these commands to register the server in the vault:
CD C:\Program Files\Microsoft Azure Site Recovery Provider\
C:\Program Files\Microsoft Azure Site Recovery Provider\> DRConfigurator.exe /r /Friendlyname
<friendly name of the server> /Credentials <path of the credentials file>
Where:
/Credentials: Mandatory parameter that specifies the location in which the registration key file is located
/FriendlyName: Mandatory parameter for the name of the Hyper-V host server that appears in the Azure Site
Recovery portal.
/proxyAddress: Optional parameter that specifies the address of the proxy server.
/proxyport : Optional parameter that specifies the port of the proxy server.
/proxyUsername: Optional parameter that specifies the Proxy user name (if proxy requires authentication).
/proxyPassword: Optional parameter that specifies the Password for authenticating with the proxy server (if
proxy requires authentication).
Network bandwidth considerations
You can use the Hyper-V capacity planner tool to calculate the bandwidth you need for replication (initial
replication and then delta). To control the amount of bandwidth use for replication you have a few options:
Throttle bandwidth: Hyper-V traffic that replicates to Azure goes through a specific Hyper-V host. You can
throttle bandwidth on the host server.
Tweak bandwidth: You can influence the bandwidth used for replication using a couple of registry keys.
Throttle bandwidth
1. Open the Microsoft Azure Backup MMC snap-in on the Hyper-V host server. By default a shortcut for
Microsoft Azure Backup is available on the desktop or in C:\Program Files\Microsoft Azure Recovery Services
Agent\bin\wabadmin.
2. In the snap-in click Change Properties.
3. On the Throttling tab select Enable internet bandwidth usage throttling for backup operations, and
set the limits for work and non-work hours. Valid ranges are from 512 Kbps to 102 Mbps per second.
You can also use the Set-OBMachineSetting cmdlet to set throttling. Here's a sample:
$mon = [System.DayOfWeek]::Monday
$tue = [System.DayOfWeek]::Tuesday
Set-OBMachineSetting -WorkDay $mon, $tue -StartWorkHour "9:00:00" -EndWorkHour "18:00:00" -WorkHourBandwidth
(512*1024) -NonWorkHourBandwidth (2048*1024)
Set-OBMachineSetting -NoThrottle indicates that no throttling is required.
Influence network bandwidth
1. In the registry navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure
Backup\Replication.
To influence the bandwidth traffic on a replicating disk, modify the value the UploadThreadsPerVM,
or create the key if it doesn't exist.
To influence the bandwidth for failback traffic from Azure, modify the value DownloadThreadsPerVM.
2. The default value is 4. In an “overprovisioned” network, these registry keys should be changed from the
default values. The maximum is 32. Monitor traffic to optimize the value.
Next steps
After initial replication is complete, and you've tested the deployment, you can invoke failovers as the need arises.
Learn more about different types of failovers and how to run them.
Replicate Hyper-V virtual machines in VMM clouds
to a secondary VMM site using the Azure portal
3/14/2017 • 27 min to read • Edit Online
This article describes how to replicate on-premises Hyper-V virtual machines managed in System Center Virtual
Machine Manager (VMM) clouds, to a secondary site using Azure Site Recovery in the Azure portal. Learn more
about this scenario architecture.
After reading this article, post any comments at the bottom, or on the Azure Recovery Services Forum.
Prerequisites
PREREQUISITE
DETAILS
Azure
You need a Microsoft Azure account. You can start with a free
trial. Learn more about Site Recovery pricing.
On-premises VMM
We recommend you have two VMM servers, one in the
primary site, and one in the secondary.
You can replicate between clouds on a single VMM server.
VMM servers should be running at least System Center 2012
SP1 with the latest updates.
VMM servers need internet access.
VMM clouds
Each VMM server must have at one or more clouds, and all
clouds must have the Hyper-V Capacity profile set.
Clouds must contain one or more VMM host groups.
If you only have one VMM server, it needs at least two
clouds, to act as primary and secondary.
Hyper-V
Hyper-V servers must be running at least Windows Server
2012 with the Hyper-V role, and have the latest updates
installed.
A Hyper-V server should contain one or more VMs.
Hyper-V host servers should be located in host groups in the
primary and secondary VMM clouds.
If you run Hyper-V in a cluster on Windows Server 2012 R2,
install update 2961977
If you run Hyper-V in a cluster on Windows Server 2012,
cluster broker isn't created automatically if you have a static
IP address-based cluster. Configure the cluster broker
manually. Read more.
Hyper-V servers need internet access.
PREREQUISITE
DETAILS
URLs
VMM servers and Hyper-V hosts should be able to reach
these URLs:
*.accesscontrol.windows.net
: Used for access control and
identity management
\*.backup.windowsazure.com
: Used for replication data
transfer and orchestration
: Used for access to the storage
account that stores replicated data
\*.blob.core.windows.net
\*.hypervrecoverymanager.windowsazure.com : Used for
replication management operations and orchestration
time.nist.gov and time.windows.com : Used to check
time synchronization between system and global time
URLs for Azure Government Cloud: *.ugv.hypervrecoverymanager.windowsazure.us *.ugv.backup.windowsazure.us *.ugi.hypervrecoverymanager.windowsazure.us *.ugi.backup.windowsazure.us
Deployment steps
Here's what you do:
1.
2.
3.
4.
5.
6.
7.
Verify prerequisites.
Prepare the VMM server and Hyper-V hosts.
Create a Recovery Services vault. The vault contains configuration settings, and orchestrates replication.
Specify source, target, and replication settings.
Deploying the Mobility service on VMs you want to replicate.
Prepare for replication, and enable replication for Hyper-V VMs.
Run a test failover to make sure everything's working as expected.
Prepare VMM servers and Hyper-V hosts
To prepare for deployment:
1. Make sure the VMM server and Hyper-V hosts comply with the prerequisites described above, and can reach
the required URLs.
2. Set up VMM networks so that you can configure network mapping.
Make sure that VMs on the source Hyper-V host server are connected to a VMM VM network. That
network should be linked to a logical network that is associated with the cloud. Verify that the secondary
cloud that you use for recovery has a corresponding VM network configured. That VM network should
be linked to a logical network that's associated with the secondary cloud.
3. Prepare for a single server deployment, if you want to replicate VMs between clouds on the same VMM
server.
Create a Recovery Services vault
1. Sign in to the Azure portal.
2. Click New > Management > Recovery Services.
3. In Name, specify a friendly name to identify the vault. If you have more than one subscription, select one of
them.
4. Create a resource group, or select an existing one. Specify an Azure region. Machines are replicated to this
region. To check supported regions see Geographic Availability in Azure Site Recovery Pricing Details
5. If you want to quickly access the vault from the Dashboard, click Pin to dashboard > Create vault.
The new vault appears on the Dashboard, in All resources, and on the main Recovery Services vaults blade.
Choose a protection goal
Select what you want to replicate and where you want to replicate to.
1.
2.
3.
4.
Click Site Recovery > Step 1: Prepare Infrastructure > Protection goal.
Select To recovery site, and select Yes, with Hyper-V.
Select Yes to indicate you're using VMM to manage the Hyper-V hosts.
Select Yes if you have a secondary VMM server. If you're deploying replication between clouds on a single
VMM server, click No. Then click OK.
Set up the source environment
Install the Azure Site Recovery Provider on VMM servers, and discover and register servers in the vault.
1. Click Step 1: Prepare Infrastructure > Source.
2. In Prepare source, click + VMM to add a VMM server.
3. In Add Server, check that System Center VMM server appears in Server type and that the VMM server
meets the prerequisites.
4. Download the Azure Site Recovery Provider installation file.
5. Download the registration key. You need this when you run setup. The key is valid for five days after you
generate it.
6. Install the Azure Site Recovery Provider on the VMM server. You don't need to explicitly install anything on
Hyper-V host servers.
Install the Azure Site Recovery Provider
1. Run the Provider setup file on each VMM server. If VMM is deployed in a cluster, do the following the first time
you install:
Install the provider on an active node, and finish the installation to register the VMM server in the vault.
Then, install the Provider on the other nodes. Cluster nodes should all run the same version of the
Provider.
2. Setup runs a few prerequisite checks, and requests permission to stop the VMM service. The VMM service will
be restarted automatically when setup finishes. If you install on a VMM cluster, you're prompted to stop the
Cluster role.
3. In Microsoft Update, you can opt in to specify that provider updates are installed in accordance with your
Microsoft Update policy.
4. In Installation, accept or modify the default installation location, and click Install.
5. After installation is complete, click Register to register the server in the vault.
6. In Vault name, verify the name of the vault in which the server will be registered. Click Next.
7. In Internet Connection, specify how the provider running on the VMM server connects to Azure.
You can specify that the provider should connect directly to the internet, or via a proxy.
Specify proxy settings if needed.
If you use a proxy, a VMM RunAs account (DRAProxyAccount) is created automatically using the
specified proxy credentials. Configure the proxy server so that this account can authenticate successfully.
The RunAs account settings can be modified in the VMM console > Settings > Security > Run As
Accounts. Restart the VMM service to update changes.
8. In Registration Key, select the key that you downloaded from Azure Site Recovery and copied to the VMM
server.
9. The encryption setting is only used when you're replicating Hyper-V VMs in VMM clouds to Azure. If you're
replicating to a secondary site it's not used.
10. In Server name, specify a friendly name to identify the VMM server in the vault. In a cluster configuration
specify the VMM cluster role name.
11. In Synchronize cloud metadata, select whether you want to synchronize metadata for all clouds on the VMM
server with the vault. This action only needs to happen once on each server. If you don't want to synchronize all
clouds, you can leave this setting unchecked, and synchronize each cloud individually in the cloud properties in
the VMM console.
12. Click Next to complete the process. After registration, metadata from the VMM server is retrieved by Azure
Site Recovery. The server is displayed on the VMM Servers tab on the Servers page in the vault.
13. After the server is available in the Site Recovery console, in Source > Prepare source select the VMM server,
and select the cloud in which the Hyper-V host is located. Then click OK.
You can also install the provider from the command line:
UnifiedSetup.exe [/ServerMode ] [/InstallDrive ] [/MySQLCredsFilePath ] [/VaultCredsFilePath ] [/EnvType ] [/PSIP ]
[/PassphraseFilePath ]
Parameters:
/ServerMode: Mandatory. Specifies whether both the configuration and process servers should be installed, or
the process server only. Input values: CS, PS.
InstallLocation: Mandatory. The folder in which the components are installed.
/MySQLCredsFilePath. Mandatory. The file path in which the MySQL server credentials are stored. The file
should be in this format:
[MySQLCredentials]
MySQLRootPassword = ""
MySQLUserPassword = ""
/VaultCredsFilePath. Mandatory. The location of the vault credentials file
/EnvType. Mandatory. The type of installation. Values: VMware, NonVMware
/PSIP and /CSIP. Mandatory. The IP address of the process server and configuration server.
/PassphraseFilePath. Mandatory. The location of the passphrase file.
/BypassProxy. Optional. Specifies that the configuration server connects to Azure without a proxy.
/ProxySettingsFilePath. Optional. Proxy settings (The default proxy requires authentication, or a custom proxy).
The file should be in this format:
[ProxySettings]
ProxyAuthentication = "Yes/No"
Proxy IP = "IP Address>"
ProxyPort = ""
ProxyUserName=""
ProxyPassword=""
DataTransferSecurePort. Optional. The port number for replication data.
SkipSpaceCheck. Optional. Skip space checking for cache.
AcceptThirdpartyEULA. Mandatory. Accepts the third-party EULA.
ShowThirdpartyEULA. Mandatory. Displays third-party EULA. If provided as input, all other parameters are
ignored.
Set up the target environment
Select the target VMM server and cloud.
1. Click Prepare infrastructure > Target, and select the target VMM server you want to use.
2. Clouds on the server that are synchronized with Site Recovery will be displayed. Select the target cloud.
Set up replication settings
When you create a replication policy, all host using the policy must have the same operating system. The VMM
cloud can contain Hyper-V hosts running different versions of Windows Server, but in this case, you need
multiple replication policies.
You can perform the initial replication offline. Learn more
1. To create a new replication policy click Prepare infrastructure > Replication Settings > +Create and
associate.
2. In Create and associate policy, specify a policy name. The source and target type should be Hyper-V.
3. In Hyper-V host version, select which operating system is running on the host.
4. In Authentication type and Authentication port, specify how traffic is authenticated between the primary
and recovery Hyper-V host servers. Select Certificate unless you have a working Kerberos environment. Azure
Site Recovery will automatically configure certificates for HTTPS authentication. You don't need to do anything
manually. By default, port 8083 and 8084 (for certificates) will be opened in the Windows Firewall on the
Hyper-V host servers. If you do select Kerberos, a Kerberos ticket will be used for mutual authentication of the
host servers. Note that this setting is only relevant for Hyper-V host servers running on Windows Server 2012
R2.
5. In Copy frequency, specify how often you want to replicate delta data after the initial replication (every 30
seconds, 5 or 15 minutes).
6. In Recovery point retention, specify in hours how long the retention window will be for each recovery point.
Protected machines can be recovered to any point within a window.
7. In App-consistent snapshot frequency, specify how frequently (1-12 hours) recovery points containing
application-consistent snapshots are created. Hyper-V uses two types of snapshots — a standard snapshot that
provides an incremental snapshot of the entire virtual machine, and an application-consistent snapshot that
takes a point-in-time snapshot of the application data inside the virtual machine. Application-consistent
snapshots use Volume Shadow Copy Service (VSS) to ensure that applications are in a consistent state when
the snapshot is taken. If you enable application-consistent snapshots, it will affect the performance of
applications running on source virtual machines. Ensure that the value you set is less than the number of
additional recovery points you configure.
8. In Data transfer compression, specify whether replicated data that is transferred should be compressed.
9. Select Delete replica VM, to specify that the replica virtual machine should be deleted if you disable
protection for the source VM. If you enable this setting, when you disable protection for the source VM it's
removed from the Site Recovery console, Site Recovery settings for the VMM are removed from the VMM
console, and the replica is deleted.
10. In Initial replication method, if you're replicating over the network, specify whether to start the initial
replication or schedule it. To save network bandwidth, you might want to schedule it outside your busy
hours. Then click OK.
11. When you create a new policy it's automatically associated with the VMM cloud. In Replication policy,
click OK. You can associate additional VMM Clouds (and the VMs in them) with this replication policy in
Replication > policy name > Associate VMM Cloud.
Configure network mapping
Learn about network mapping before you start.
Verify that virtual machines on VMM servers are connected to a VM network.
1. In Site Recovery Infrastructure > Network Mapping > Network mappings, click +Network
Mapping.
2. In Add network mapping tab, select the source and target VMM servers. The VM networks associated with
the VMM servers are retrieved.
3. In Source network, select the network you want to use from the list of VM networks associated with the
primary VMM server.
4. In Target network, select the network you want to use on the secondary VMM server. Then click OK.
Here's what happens when network mapping begins:
Any existing replica virtual machines that correspond to the source VM network will be connected to the target
VM network.
New virtual machines that are connected to the source VM network will be connected to the target mapped
network after replication.
If you modify an existing mapping with a new network, replica virtual machines will be connected using the
new settings.
If the target network has multiple subnets and one of those subnets has the same name as subnet on which the
source virtual machine is located, then the replica virtual machine will be connected to that target subnet after
failover. If there’s no target subnet with a matching name, the virtual machine will be connected to the first
subnet in the network.
Configure storage mapping.
Storage mapping isn't supported in the new Azure portal. However, it can be enabled using Powershell. Learn
more.
Step 5: Capacity planning
Now that you have your basic infrastructure set up, think about capacity planning, and figure out whether you
need additional resources.
Download and run the Azure Site Recovery Capacity planner, to gather information about your replication
environment, including VMs, disks per VM, and storage per disk.
After you've collected real-time replication information, you can modify the NetQos policy to control replication
bandwidth for VMs. Read more about Throttling Hyper-V Replica Traffic, on Thomas Maurer's blog. Get more
information about the New-NetQosPolicy cmdlet.
Enable replication
1. Click Step 2: Replicate application > Source. After you've enabled replication for the first time, you click
+Replicate in the vault to enable replication for additional machines.
2. In Source, select the VMM server, and the cloud in which the Hyper-V hosts you want to replicate are
located. Then click OK.
3. In Target, verify the secondary VMM server and cloud.
4. In Virtual machines, select the VMs you want to protect from the list.
You can track progress of the Enable Protection action in Jobs > Site Recovery jobs. After the Finalize
Protection job completes, the virtual machine is ready for failover.
Note that:
You can also enable protection for virtual machines in the VMM console. Click Enable Protection on the
toolbar in the virtual machine properties > Azure Site Recovery tab.
After you've enabled replication, you can view properties for the VM in Replicated Items. On the Essentials
dashboard, you can see information about the replication policy for the VM and its status. Click Properties for
more details.
Onboard existing virtual machines
If you have existing virtual machines in VMM that are replicating with Hyper-V Replica, you can onboard them for
Azure Site Recovery replication as follows:
1. Ensure that the Hyper-V server hosting the existing VM is located in the primary cloud, and that the Hyper-V
server hosting the replica virtual machine is located in the secondary cloud.
2. Make sure a replication policy is configured for the primary VMM cloud.
3. Enable replication for the primary virtual machine. Azure Site Recovery and VMM ensure that the same replica
host and virtual machine is detected, and Azure Site Recovery will reuse and reestablish replication using the
specified settings.
Test your deployment
To test your deployment, you can run a test failover for a single virtual machine, or create a recovery plan that
contains one or more virtual machines.
Prepare for offline initial replication
You can do offline replication for the initial data copy. You can prepare this as follows:
On the source server, you specify a path location from which the data export will take place. Assign Full Control
for NTFS and, Share permissions to the VMM service on the export path. On the target server, you specify a
path location from which the data import will occur. Assign the same permissions on this import path.
If the import or export path is shared, assign Administrator, Power User, Print Operator, or Server Operator
group membership for the VMM service account on the remote computer on which the shared is located.
If you're using any Run As accounts to add hosts, on the import and export paths, assign read and write
permissions to the Run As accounts in VMM.
The import and export shares should not be located on any computer used as a Hyper-V host server, because
loopback configuration is not supported by Hyper-V.
In Active Directory, on each Hyper-V host server that contains virtual machines you want to protect, enable and
configure constrained delegation to trust the remote computers on which the import and export paths are
located, as follows:
1. On the domain controller, open Active Directory Users and Computers.
2. In the console tree, click DomainName > Computers.
3. Right-click the Hyper-V host server name > Properties.
4. On the Delegation tab, click Trust this computer for delegation to specified services only.
5. Click Use any authentication protocol.
6. Click Add > Users and Computers.
7. Type the name of the computer that hosts the export path > OK. From the list of available services, hold
down the CTRL key and click cifs > OK. Repeat for the name of the computer that hosts the import path.
Repeat as necessary for additional Hyper-V host servers.
Prepare for network mapping
Network mapping maps between VMM VM networks on the primary and secondary VMM servers to:
Optimally place replica VMs on secondary Hyper-V hosts after failover.
Connect replica VMs to appropriate VM networks after failover.
Note that:
Network mapping can be configured between VM networks on two VMM servers, or on a single VMM server if
two sites are managed by the same server.
When mapping is configured correctly and replication is enabled, a VM at the primary location will be
connected to a network, and its replica at the target location will be connected to its mapped network.
If networks have been set up correctly in VMM, when you select a target VM network during network mapping,
the VMM source clouds that use the source VM network will be displayed, along with the available target VM
networks on the target clouds that are used for protection.
If the target network has multiple subnets and one of those subnets has the same name as the subnet on which
the source virtual machine is located, then the replica virtual machine will be connected to that target subnet
after failover. If there’s no target subnet with a matching name, the virtual machine will be connected to the
first subnet in the network.
Here’s an example to illustrate this mechanism. Let’s take an organization with two locations in New York and
Chicago.
LOCATION
VMM SERVER
VM NETWORKS
MAPPED TO
New York
VMM-NewYork
VMNetwork1-NewYork
Mapped to VMNetwork1Chicago
VMNetwork2-NewYork
Not mapped
Chicago
VMM-Chicago
VMNetwork1-Chicago
Mapped to VMNetwork1NewYork
VMNetwork2-Chicago
Not mapped
With this example:
When a replica virtual machine is created for any virtual machine that is connected to VMNetwork1-NewYork,
it will be connected to VMNetwork1-Chicago.
When a replica virtual machine is created for VMNetwork2-NewYork or VMNetwork2-Chicago, it will not be
connected to any network.
Here's how VMM clouds are set up in our example organization, and the logical networks associated with the
clouds.
Cloud protection settings
PROTECTED CLOUD
PROTECTING CLOUD
GoldCloud1
GoldCloud2
SilverCloud1
SilverCloud2
GoldCloud2
NA
LOGICAL NETWORK (NEW YORK)
LogicalNetwork1-NewYork
LogicalNetwork1-Chicago
SilverCloud2
NA
LogicalNetwork1-NewYork
LogicalNetwork1-Chicago
Logical and VM network settings
LOCATION
LOGICAL NETWORK
ASSOCIATED VM NETWORK
New York
LogicalNetwork1-NewYork
VMNetwork1-NewYork
Chicago
LogicalNetwork1-Chicago
VMNetwork1-Chicago
LogicalNetwork2Chicago
VMNetwork2-Chicago
Target networks
Based on these settings, when you select the target VM network, the following table shows the choices that will be
available.
SELECT
PROTECTED CLOUD
PROTECTING CLOUD
TARGET NETWORK AVAILABLE
VMNetwork1-Chicago
SilverCloud1
SilverCloud2
Available
GoldCloud1
GoldCloud2
Available
VMNetwork2-Chicago
SilverCloud1
SilverCloud2
GoldCloud1
GoldCloud2
Available
Not available
Failback
To see what happens in the case of failback (reverse replication), let’s assume that VMNetwork1-NewYork is
mapped to VMNetwork1-Chicago, with the following settings.
VIRTUAL MACHINE
CONNECTED TO VM NETWORK
VM1
VMNetwork1-Network
VM2 (replica of VM1)
VMNetwork1-Chicago
With these settings, let's review what happens in a couple of possible scenarios.
SCENARIO
OUTCOME
No change in the network properties of VM-2 after failover.
VM-1 remains connected to the source network.
Network properties of VM-2 are changed after failover and is
disconnected.
VM-1 is disconnected.
Network properties of VM-2 are changed after failover and is
connected to VMNetwork2-Chicago.
If VMNetwork2-Chicago isn’t mapped, VM-1 will be
disconnected.
Network mapping of VMNetwork1-Chicago is changed.
VM-1 will be connected to the network now mapped to
VMNetwork1-Chicago.
Prepare for single server deployment
If you only have a single VMM server, you can replicate VMs in Hyper-V hosts in the VMM cloud to Azure or to a
secondary VMM cloud. We recommend the first option because replicating between clouds isn't seamless. If you
do want to replicate between clouds, you can replicate with a single standalone VMM server, or with a single VMM
server deployed in a stretched Windows cluster
Standalone VMM server
In this scenario, you deploy the single VMM server as a virtual machine in the primary site, and replicate this VM to
a secondary site using Site Recovery and Hyper-V Replica.
1. Set up VMM on a Hyper-V VM. We suggest that you colocate the SQL Server instance used by VMM on the
same VM. This saves time as only one VM has to be created. If you want to use remote instance of SQL Server
and an outage occurs, you need to recover that instance before you can recover VMM.
2. Ensure the VMM server has at least two clouds configured. One cloud will contain the VMs you want to
replicate and the other cloud will serve as the secondary location. The cloud that contains the VMs you want to
protect should comply with prerequisites.
3. Set up Site Recovery as described in this article. Create and register the VMM server in a vault, set up a
replication policy, and enable replication. The source and target VMM names will be the same. Specify that
initial replication takes place over the network.
4. When you set up network mapping you map the VM network for the primary cloud to the VM network for the
secondary cloud.
5. In the Hyper-V Manager console, enable Hyper-V Replica on the Hyper-V host that contains the VMM VM, and
enable replication on the VM. Make sure you don't add the VMM virtual machine to clouds that are protected
by Site Recovery, to ensure that Hyper-V Replica settings aren't overridden by Site Recovery.
6. If you create recovery plans for failover you use the same VMM server for source and target.
7. In a complete outage, you fail over and recover as follows:
a. Run an unplanned failover in the Hyper-V Manager console in the secondary site, to fail over the
primary VMM VM to the secondary site.
b. Verify that the VMM VM is up and running, and in the vault, run an unplanned failover to fail over the
VMs from primary to secondary clouds. Commit the failover, and select an alternate recovery point if
required.
c. After the unplanned failover is complete, all resources can be accessed from the primary site again.
d. When the primary site is available again, in the Hyper-V Manager console in the secondary site, enable
reverse replication for the VMM VM. This starts replication for the VM from secondary to primary.
e. Run a planned failover in the Hyper-V Manager console in the secondary site, to fail over the VMM VM
to the primary site. Commit the failover. Then enable reverse replication, so that the VMM VM is again
replicating from primary to secondary.
f. In the Recovery Services vault, enable reverse replication for the workload VMs, to start replicating them
from secondary to primary.
g. In the Recovery Services vault, run a planned failover to fail back the workload VMs to the primary site.
Commit the failover to complete it. Then enable reverse replication to start replicating the workload VMs
from primary to secondary.
Stretched VMM cluster
Instead of deploying a standalone VMM server as a VM that replicates to a secondary site, you can make VMM
highly available by deploying it as a VM in a Windows failover cluster. This provides workload resilience and
protection against hardware failure. To deploy with Site Recovery the VMM VM should be deployed in a stretch
cluster across geographically separate sites. To do this:
1. Install VMM on a virtual machine in a Windows failover cluster, and select the option to run the server as highly
available during setup.
2. The SQL Server instance that's used by VMM should be replicated with SQL Server AlwaysOn availability
groups, so that there's a replica of the database in the secondary site.
3. Follow the instructions in this article to create a vault, register the server, and set up protection. You need to
register each VMM server in the cluster in the Recovery Services vault. To do this, you install the Provider on an
active node, and register the VMM server. Then you install the Provider on other nodes.
4. When an outage occurs, the VMM server and its corresponding SQL Server database are failed over, and
accessed from the secondary site.
Prepare for storage mapping
You set up storage mapping by mapping storage classifications on a source and target VMM servers to do the
following:
Identify target storage for replica virtual machines—A source VM hard disk will replicate to the storage
that you specified (SMB share or cluster shared volumes (CSVs)) in the target location.
Replica virtual machine placement—Storage mapping is used to optimally place replica virtual machines
on Hyper-V host servers. Replica virtual machines will be placed on hosts that can access the mapped storage
classification.
No storage mapping—If you don’t configure storage mapping, virtual machines will be replicated to the
default storage location specified on the Hyper-V host server associated with the replica virtual machine.
Note that:
You can set up mapping between two VMM clouds on a single server.
Storage classifications must be available to the host groups located in source and target clouds.
Classifications don’t need to have the same type of storage. For example, you can map a source classification
that contains SMB shares to a target classification that contains CSVs.
Example
If classifications are configured correctly in VMM when you select the source and target VMM server during
storage mapping, the source and target classifications will be displayed. Here’s an example of storage files shares
and classifications for an organization with two locations in New York and Chicago.
LOCATION
VMM SERVER
FILE SHARE
(SOURCE)
CLASSIFICATION
(SOURCE)
MAPPED TO
FILE SHARE
(TARGET)
New York
VMM_Source
SourceShare1
GOLD
GOLD_TARGET
TargetShare1
SourceShare2
SILVER
SILVER_TARGET
TargetShare2
SourceShare3
BRONZE
BRONZE_TARGET
TargetShare3
Chicago
VMM_Target
GOLD_TARGET
SILVER_TARGET
Not mapped
BRONZE_TARGET
Not mapped
Not mapped
With this example:
When a replica virtual machine is created for any virtual machine on GOLD storage (SourceShare1), it will be
replicated to a GOLD_TARGET storage (TargetShare1).
When a replica virtual machine is created for any virtual machine on SILVER storage (SourceShare2), it will be
replicated to a SILVER_TARGET (TargetShare2) storage, and so on.
Multiple storage locations
If the target classification is assigned to multiple SMB shares or CSVs, the optimal storage location will be selected
automatically when the virtual machine is protected. If no suitable target storage is available with the specified
classification, the default storage location specified on the Hyper-V host is used to place the replica virtual hard
disks.
The following table show how storage classification and cluster shared volumes are set up in our example.
LOCATION
CLASSIFICATION
ASSOCIATED STORAGE
New York
GOLD
C:\ClusterStorage\SourceVolume1
\FileServer\SourceShare1
SILVER
C:\ClusterStorage\SourceVolume2
\FileServer\SourceShare2
Chicago
GOLD_TARGET
C:\ClusterStorage\TargetVolume1
\FileServer\TargetShare1
SILVER_TARGET
C:\ClusterStorage\TargetVolume2
\FileServer\TargetShare2
This table summarizes the behavior when you enable protection for virtual machines (VM1 - VM5) in this example
environment.
VIRTUAL MACHINE
SOURCE STORAGE
SOURCE CLASSIFICATION
MAPPED TARGET STORAGE
VM1
C:\ClusterStorage\SourceVol
ume1
GOLD
C:\ClusterStorage\Sourc
eVolume1
\\FileServer\SourceShare
1
Both GOLD_TARGET
VM2
\FileServer\SourceShare1
GOLD
C:\ClusterStorage\Sourc
eVolume1
\FileServer\SourceShare1
Both GOLD_TARGET
VM3
C:\ClusterStorage\SourceVol
ume2
SILVER
C:\ClusterStorage\Sourc
eVolume2
\FileServer\SourceShare2
VM4
\FileServer\SourceShare2
SILVER
C:\ClusterStorage\Sourc
eVolume2
\FileServer\SourceShare2
Both SILVER_TARGET
VM5
C:\ClusterStorage\SourceVol
ume3
N/A
No mapping, so the default
storage location of the
Hyper-V host is used
Data privacy overview
This table summarizes how data is stored in this scenario:
ACTION
DETAILS
COLLECTED DATA
USE
REQUIRED
Registration
You register a VMM
server in a Recovery
Services vault. If you
later want to
unregister a server,
you can do so by
deleting the server
information from the
Azure portal.
After a VMM server is
registered Site
Recovery collects,
processes, and
transfers metadata
about the VMM
server and the names
of the VMM clouds
detected by Site
Recovery.
The data is used to
identify and
communicate with
the appropriate VMM
server and configure
settings for
appropriate VMM
clouds.
This feature is
required. If you don't
want to send this
information to Site
Recovery you
shouldn't use the Site
Recovery service.
Enable replication
The Azure Site
Recovery Provider is
installed on the VMM
server and is the
conduit for
communication with
the Site Recovery
service. The Provider
is a dynamic-link
library (DLL) hosted in
the VMM process.
After the Provider is
installed, the
"Datacenter
Recovery" feature
gets enabled in the
VMM administrator
console. New and
existing VMs can
enable this feature to
enable protection for
a VM.
With this property
set, the Provider
sends the name and
ID of the VM to Site
Recovery. Replication
is enabled by
Windows Server 2012
or Windows Server
2012 R2 Hyper-V
Replica. The virtual
machine data gets
replicated from one
Hyper-V host to
another (typically
located in a different
“recovery” data
center).
Site Recovery uses
the metadata to
populate the VM
information in the
Azure portal.
This feature is an
essential part of the
service and can't be
turned off. If you
don't want to send
this information, don't
enable Site Recovery
protection for VMs.
Note that all data
sent by the Provider
to Site Recovery is
sent over HTTPS.
Recovery plan
Recovery plans help
you build an
orchestration plan for
the recovery data
center. You can define
the order in which
VMs or a group of
virtual machines
should be started at
the recovery site. You
can also specify any
automated scripts to
be run, or any manual
action to be taken, at
the time of recovery
for each VM. Failover
is typically triggered
at the recovery plan
level for coordinated
recovery.
Site Recovery collects,
processes, and
transmits metadata
for the recovery plan,
including virtual
machine metadata,
and metadata of any
automation scripts
and manual action
notes.
The metadata is used
to build the recovery
plan in the Azure
portal.
This feature is an
essential part of the
service and can't be
turned off. If you
don't want to send
this information to
Site Recovery, don't
create recovery plans.
ACTION
DETAILS
COLLECTED DATA
USE
REQUIRED
Network mapping
Maps network
information from the
primary data center
to the recovery data
center. When VMs
are recovered on the
recovery site, network
mapping helps in
establishing network
connectivity.
Site Recovery collects,
processes, and
transmits the
metadata of the
logical networks for
each site (primary and
datacenter).
The metadata is used
to populate network
settings so that you
can map the network
information.
This feature is an
essential part of the
service and can't be
turned off. If you
don't want to send
this information to
Site Recovery, don't
use network mapping.
Failover
(planned/unplanned
/test)
Failover fails over
VMs from one VMMmanaged data center
to another. The
failover action is
triggered manually in
the Azure portal.
The Provider on the
VMM server is
notified of the failover
event by Site
Recovery and runs a
failover action on the
Hyper-V host
through VMM
interfaces. Actual
failover of a VM is
from one Hyper-V
host to another and
handled by Windows
Server 2012 or
Windows Server 2012
R2 Hyper-V Replica.
Aft Site Recovery uses
the information sent
to populate the
status of the failover
action information in
the Azure portal.
This feature is an
essential part of the
service and can't be
turned off. If you
don't want to send
this information to
Site Recovery, don't
use failover.
Next steps
After you've tested the deployment, learn more about other types of failover
Replicate on-premises VMware virtual machines or
physical servers to a secondary site in the classic
Azure portal
5/4/2017 • 11 min to read • Edit Online
Overview
InMage Scout in Azure Site Recovery provides real-time replication between on-premises VMware sites. InMage
Scout is included in Azure Site Recovery service subscriptions.
Prerequisites
Azure account: You'll need a Microsoft Azure account. You can start with a free trial. Learn more about Site
Recovery pricing.
Step 1: Create a vault
1. Sign in to the Azure portal.
2. Click New > Management > Backup and Site Recovery (OMS). Alternatively, you can click Browse > Recovery
Services Vault > Add.
3. In Name specify a friendly name to identify the vault. If you have more than one subscription, select one of
them.
4. In Resource group Create a new resource group or select an existing one. Specify an Azure region to complete
required fields.
5. In Location, select the geographic region for the vault. To check supported regions, see Azure Site Recovery
Pricing.
6. If you want to quickly access the vault from the Dashboard click Pin to dashboard and then click Create.
7. The new vault will appear on the Dashboard > All resources, and on the main Recovery Services vaults blade.
Step 2: Configure the vault and download InMage Scout components
1.
2.
3.
4.
In the Recovery Services vaults blade select your vault and click Settings.
In Settings > Getting Started click Site Recovery > Step 1: Prepare Infrastructure > Protection goal.
In Protection goal select To recovery site, and select Yes, with VMware vSphere Hypervisor. Then click OK.
In Scout setup, click download to download InMage Scout 8.0.1 GA software and registration key. The setup
files for all of the required components are in the downloaded .zip file.
Step 3: Install component updates
Read about the latest updates. You'll install the update files on servers in the following order:
1.
2.
3.
4.
5.
6.
RX server if there is one
Configuration servers
Process servers
Master target servers
vContinuum servers
Source server (both Windows and Linux Server)
Install the updates as follows:
1. Download the update .zip file. This .zip file contains the following files:
2.
3.
4.
5.
6.
7.
8.
9.
RX_8.0.4.0_GA_Update_4_8725872_16Sep16.tar.gz
CX_Windows_8.0.4.0_GA_Update_4_8725865_14Sep16.exe
UA_Windows_8.0.5.0_GA_Update_5_11525802_20Apr17.exe
UA_RHEL6-64_8.0.4.0_GA_Update_4_9035261_26Sep16.tar.gz
vCon_Windows_8.0.5.0_GA_Update_5_11525767_20Apr17.exe
UA update4 bits for RHEL5, OL5, OL6, SUSE 10, SUSE 11:
UA__8.0.4.0_GA_Update_4_9035261_26Sep16.tar.gz
Extract the .zip files.
For the RX server: Copy RX_8.0.4.0_GA_Update_4_8725872_16Sep16.tar.gz to the RX server and extract it.
In the extracted folder, run /Install.
For the configuration server/process server: Copy
CX_Windows_8.0.4.0_GA_Update_4_8725865_14Sep16.exe to the configuration server and process server.
Double-click to run it.
For the Windows master target server: To update the unified agent, copy
UA_Windows_8.0.5.0_GA_Update_5_11525802_20Apr17.exe to the master target server. Double-click it to
run it. Note that the unified agent is also applicable to the source server if source is not updated till Update4.
You should install it on the source server as well, as mentioned later in this list.
For the vContinuum server: Copy vCon_Windows_8.0.5.0_GA_Update_5_11525767_20Apr17.exe to the
vContinuum server. Make sure that you've closed the vContinuum wizard. Double-click on the file to run it.
For the Linux master target server: To update the unified agent, copy UA_RHEL664_8.0.4.0_GA_Update_4_9035261_26Sep16.tar.gz to the master target server and extract it. In the extracted
folder, run /Install.
For the Windows source server: You do not need to install Update 5 agent on source if soruce is already on
update4. If it is less than update4, apply the update 5 agent. To update the unified agent, copy
UA_Windows_8.0.5.0_GA_Update_5_11525802_20Apr17.exe to the source server. Double-click it to run it.
For the Linux source server: To update the unified agent, copy corresponding version of UA file to the Linux
server and extract it. In the extracted folder, run /Install. Example: For RHEL 6.7 64 bit server, copy UA_RHEL664_8.0.4.0_GA_Update_4_9035261_26Sep16.tar.gz to the server and extract it. In the extracted folder, run
/Install.
Step 4: Set up replication
1. Set up replication between the source and target VMware sites.
2. For guidance, use the InMage Scout documentation that's downloaded with the product. Alternatively, you
can access the documentation as follows:
Release notes
Compatibility matrix
User guide
RX user guide
Quick installation guide
Updates
Azure Site Recovery Scout 8.0.1 Update 5
Scout Update 5 is a cumulative update. It has all the fixes of update1 till update4 and following new bug fixes and
enhancements. Fixes that are added from ASR Scout update4 to update5 are specific to Master Target and
vContinuum components. If all your source servers, Master Target, Configuration Server, Process Server and RX
are already on ASR Scout update4 then you need to apply update 5 only on Master Target server.
New platform support
SUSE Linux Enterprise Server 11 Service Pack 4(SP4)
NOTE
SLES 11 SP4 64 bit InMage_UA_8.0.1.0_SLES11-SP4-64_GA_13Apr2017_release.tar.gz is packaged with base Scout GA
package InMage_Scout_Standard_8.0.1 GA.zip. Download Scout GA package from portal as mentioned in step 1.
Bug fixes and enhancements
Increase Windows Cluster support reliability
Fixed- Sometime some of the P2V MSCS cluster disks become RAW after recovery
Fixed- P2V MSCS cluster recovery fails due to disk order mismatch
Fixed- MSCS cluster add disks operation fails with disk size mismatch
Fixed- Source MSCS cluster with RDM LUNs mapping readiness check fails in size verification
Fixed- Single node cluster protection fails due to SCSI mismatch issue
Fixed- Re-protect of the P2V Windows cluster server fails if target cluster disks are present.
During failback protection, if selected MT is not on the same ESXi server as that of the protected source
machine (during forward protection), then vContinuum picks up the wrong MT during Failback Recovery
and subsequently recovery operation fails.
NOTE
Above P2V cluster fixes are applicable to only those physical MSCS cluster that are freshly protected with ASR Scout
update5. To avail the cluster fixes on the already protected P2V MSCS cluster with older updates, you need to follow
the upgrade steps that are mentioned in the section 12, Upgrade protected P2V MSCS cluster to Scout Update5 of
ASR Scout Release Notes.
Re-protect of physical MSCS cluster can reuse existing target disks only if at the time of re-protection, the same set of
disks are active on each of the cluster nodes as they were when initially protected. If not, then there are manual steps
as mentioned in section 12 of ASR Scout Release Notes to move the target side disks to the correct datastore path to
re-use them during re-protection. If you reprotect the MSCS cluster in P2V mode without following upgrade steps
then it will create new disk on the target ESXi server. You need to manually delete the old disks from the datastore.
Whenever source SLES11 or SLES11 with any service pack server is rebooted gracefully, then one should manually
mark the root disk replication pairs for re-sync as it will not be notified in CX UI. If you dont' mark the root disk for
resync, you may see data integrity (DI) issues.
Azure Site Recovery Scout 8.0.1 Update 4
Scout Update 4 is a cumulative update. It has all the fixes of update1 till update3 and following new bug fixes and
enhancements.
New platform support
Support has been added for vCenter/vSphere 6.0, 6.1 and 6.2
Support has been added for following Linux operating systems
Red Hat Enterprise Linux (RHEL)7.0, 7.1 and 7.2
CentOS 7.0, 7.1 and 7.2
Red Hat Enterprise Linux (RHEL) 6.8
CentOS 6.8
NOTE
RHEL/CentOS 7 64 bit InMage_UA_8.0.1.0_RHEL7-64_GA_06Oct2016_release.tar.gz is packaged with base Scout GA
package InMage_Scout_Standard_8.0.1 GA.zip. Download Scout GA package from portal as mentioned in step 1.
Bug fixes and enhancements
Improved shutdown handling for following Linux OSes and clones to prevent unwanted re-sync issues.
Red Hat Enterprise Linux (RHEL) 6.x
Oracle Linux (OL) 6.x
For Linux, complete folder access permissions in unified agent installation directory are now restricted only to
the local user.
On Windows timing out issue while issuing common distributed consistency book mark on heavily loaded
distributed applications like SQL and Share Point clusters.
Added log related fix in CX base installer.
VMware vCLI 6.0 download link is added to Windows Master Target base installer.
Added more checks and logs for network configurations changes during failover and DR drills.
Sometime retention information is not reported to the CX.
For physical cluster, volume Re-size operation through vContinuum wizard is failing when source volume
shrink happened.
Cluster protection failed with error "Failed to find the disk signature" when cluster disk is PRDM disk.
cxps transport server crash because of out-of-range exception.
Server name and IP columns are now resizable in push install page of vContinuum wizard.
RX API Enhancements
Provides Five latest available common consistency points (Only Guaranteed tags).
Provides capacity and free space details for all the protected devices.
Provides Scout driver state on source server.
NOTE
InMage_Scout_Standard_8.0.1_GA.zip base package now has updated CX base installer
InMage_CX_8.0.1.0_Windows_GA_26Feb2015_release.exe and Windows Master Target base installer
InMage_Scout_vContinuum_MT_8.0.1.0_Windows_GA_26Feb2015_release.exe. For all new installation use new CX
and Windows Master Target GA bits.
Update 4 can be directly applied on 8.0.1 GA.
The configuration server and RX updates can’t be rolled back after they're applied on the system.
Azure Site Recovery Scout 8.0.1 Update 3
Update 3 includes the following bug fixes and enhancements:
The configuration server and RX fail to register to the Site Recovery vault when they're behind the proxy.
The number of hours that the recovery point objective (RPO) is not met is not getting updated in the health
report.
The configuration server is not syncing with RX when the ESX hardware details or network details contain any
UTF-8 characters.
Windows Server 2008 R2 domain controllers fail to boot after recovery.
Offline sync is not working as expected.
After virtual machine (VM) failover, replication-pair deletion gets stuck in the CX UI for a long time, and users
cannot complete the failback or resume operation.
Overall snapshot operations that are done by the consistency job have been optimized to help reduce
application disconnects like SQL clients.
The performance of the consistency tool (VACP.exe) has been improved by reducing the memory usage that is
required for creating snapshots on Windows.
The push install service crashes when the password is greater than 16 characters.
vContinuum is not checking and prompting for new vCenter credentials when the credentials are changed.
On Linux, the master target cache manager (cachemgr) is not downloading files from the process server, which
results in replication pair throttling.
When the physical failover cluster (MSCS) disk order is not the same on all the nodes, replication is not set for
some of the cluster volumes.
Note that the cluster needs to be reprotected to take advantage of this fix.
SMTP functionality is not working as expected after RX is upgraded from Scout 7.1 to Scout 8.0.1.
More stats have been added in the log for the rollback operation to track the time it has taken to complete it.
Support has been added for Linux operating systems on the source server:
Red Hat Enterprise Linux (RHEL) 6 update 7
CentOS 6 update 7
The CX and RX UI can now show the notification for the pair, which goes into bitmap mode.
The following security fixes have been added in RX:
ISSUE DESCRIPTION
IMPLEMENTATION PROCEDURES
Authorization bypass via parameter tampering
Restricted access to non-applicable users.
Cross-site request forgery
Implemented the page-token concept, which generates
randomly for every page.
With this, you will see:
There is only a single sign-in instance for the same user.
Page refresh does not work--it will redirect to the
dashboard.
Malicious file upload
Restricted files to certain extensions. Allowed extensions are:
7z, aiff, asf, avi, bmp, csv, doc, docx, fla, flv, gif, gz, gzip, jpeg,
jpg, log, mid, mov, mp3, mp4, mpc, mpeg, mpg, ods, odt, pdf,
png, ppt, pptx, pxd, qt, ram, rar, rm, rmi, rmvb, rtf, sdc, sitd,
swf, sxc, sxw, tar, tgz, tif, tiff, txt, vsd, wav, wma, wmv, xls, xlsx,
xml, and zip.
Persistent cross-site scripting
Added input validations.
NOTE
All Site Recovery updates are cumulative. Update 3 has all the fixes of Update 1 and Update 2. Update 3 can be directly
applied on 8.0.1 GA.
The configuration server and RX updates can’t be rolled back after they're applied on the system.
Azure Site Recovery Scout 8.0.1 Update 2 (Update 03Dec15)
Fixes in Update 2 include:
Configuration server: Fix for an issue that prevented the 31-day free metering feature from working as
expected when the configuration server was registered in Site Recovery.
Unified agent: Fix for an issue in Update 1 that resulted in the update not being installed on the master target
server when it was upgraded from version 8.0 to 8.0.1.
Azure Site Recovery Scout 8.0.1 Update 1
Update 1 includes the following bug fixes and new features:
31 days of free protection per server instance. This enables you to test functionality or set up a proof-ofconcept.
All operations on the server, including failover and failback, are free for the first 31 days, starting from
the time that a server is first protected with Site Recovery Scout.
From the 32nd day onwards, each protected server will be charged at the standard instance rate for
Azure Site Recovery protection to a customer-owned site.
At any time, the number of protected servers that are currently being charged is available on the
Dashboard page of the Azure Site Recovery vault.
Support added for vSphere Command-Line Interface (vCLI) 5.5 Update 2.
Support added for Linux operating systems on the source server:
RHEL 6 Update 6
RHEL 5 Update 11
CentOS 6 Update 6
CentOS 5 Update 11
Bug fixes to address the following issues:
Vault registration fails for the configuration server or RX server.
Cluster volumes don't appear as expected when clustered virtual machines are reprotected when they
resume.
Failback fails when the master target server is hosted on a different ESXi server from the on-premises
production virtual machines.
Configuration file permissions are changed when you upgrade to 8.0.1, which affects protection and
operations.
The resynchronization threshold isn't enforced as expected, which leads to inconsistent replication
behavior.
The RPO settings are not appearing correctly in the configuration server interface. The uncompressed
data value incorrectly shows the compressed value.
The Remove operation doesn't delete as expected in the vContinuum wizard, and replication isn't deleted
from the configuration server interface.
In the vContinuum wizard, the disk is automatically unselected when you click Details in the disk view
during protection of MSCS virtual machines.
During the physical-to-virtual (P2V) scenario, required HP services, such as CIMnotify and CqMgHost,
aren't moved to manual in virtual machine recovery. This results in additional boot time.
Linux virtual machine protection fails when there are more than 26 disks on the master target server.
Next steps
Post any questions that you have on the Azure Recovery Services forum.
Multi-tenant support in Azure Site Recovery for
replicating VMware virtual machines to Azure
through the CSP Program
3/21/2017 • 11 min to read • Edit Online
Azure Site Recovery supports multi-tenant environments for tenant subscriptions. Multi-tenancy is also supported
for tenant subscriptions created and managed through the CSP program. This article details the guidance for
implementing and managing multi-tenant VMware-to-Azure scenarios. Creating and managing tenant
subscriptions through CSP is also detailed.
Note that this guidance draws heavily from the existing documentation for replicating VMware virtual machines to
Azure. This guidance should be used in conjunction with that documentation.
Multi-tenant environments
There are three major multi-tenant models:
1. Shared Hosting Services Provider (HSP) – Here the partner owns the physical infrastructure and uses shared
resources (vCenter, datacenters, physical storage, etc.) to host multiple tenants’ VMs on the same infrastructure.
DR management can be provided by partner as a managed service or be owned by the tenant as a self-service
DR solution.
2. Dedicated Hosting Services Provider – Here the partner owns the physical infrastructure but uses dedicated
resources (multiple vCenters, physical datastores, etc) to host each tenant’s VMs on separate infrastructure. DR
management can again be managed by partner or self-service by the tenant.
3. Managed Services Provider (MSP) – Here the customer owns the physical infrastructure that hosts the VMs
and the partners provides DR enablement and management.
Shared hosting multi-tenant guidance
This guidance covers the shared hosting scenario in detail. The other two scenarios are subsets of the shared
hosting scenario and use the same principles. The differences are described at the end of the shared hosting
guidance.
The basic requirement in a multi-tenant scenario is isolating the different tenants that is, one tenant should not be
able to observe what another tenant has hosted. In a completely partner-managed environment, this requirement is
not as important as it for a self-service environment, where it can be critical. This guidance assumes that tenant
isolation is required.
The architecture looks as follows:
Figure 1: Shared hosting scenario with one vCenter
As seen from the above representation, each customer will have a separate Management Server. This is done to
limit tenant access to tenant-specific VMs to enable tenant isolation. VMware virtual machine replication scenario
uses the configuration server to manage accounts to discover VMs and install agents. We follow the same
principles for multi-tenant environments, with the addition of restricting VM discovery through vCenter access
control.
The data isolation requirement necessitates that all sensitive infrastructure information (such as access credentials)
remains disclosed from tenants. For this reason, we recommend that all the components of the management server
(Configuration Server (CS), Process Server (PS) and Master Target Server (MT)) remain under the exclusive control
of the partner. This includes scale-out PS.
Every CS under the multi-tenant scenario uses two accounts:
vCenter access account: This account is used to discover tenant VMs and is the account has the vCenter access
permissions assigned to it (described in the next section). It is recommended that the partner enters these
credentials him/herself on the config tool to avoid accidental access leaks.
Virtual machine access account: This account is used to install the mobility agent on the tenant VMs through
automatic push. This is usually a domain account that a tenant might provide to partner or can alternatively be
managed by partner directly. In case the tenant doesn’t wish to share the details to partner directly, the tenant
can be allowed to enter the credentials through a limited-time access to CS, or alternatively the tenant can install
mobility agents manually with the partner’s assistance.
Requirements for vCenter access account
As detailed in the earlier section, the CS requires to be configured with an account that has a special role assigned
to it. It is important to note that this role assignment needs to be done to the vCenter access account for each
vCenter object and not propagated to the child objects. This is done to ensure tenant isolation since access
propagation can result in accidental access to other objects also
The alternative is to assign the user account and role at the Datacenter object and propagate to child objects;
following which that account has to be given a ‘No access’ role for every object (such as other tenants’ VMs) that
should not be accessible to a particular tenant. This is both cumbersome and exposes accidental access controls, as
every new child object created is also automatically granted access inherited from parent. It is hence suggested to
go with the first approach.
The vCenter account access procedure is as follows:
1. Create a new role by cloning the pre-defined ‘Read-only’ role and give it a convenient name (such as
Azure_Site_Recovery used in this example).
2. Assign the following permissions to this role:
Datastore -> Allocate space, browse datastore, low-level file operations, remove file, update virtual
machine files
Network -> Network assign
Resource -> Assign VM to resource pool, migrate powered off VM, migrate powered on VM
Tasks -> Create task, update task
Virtual machine -> Configuration
Virtual machine -> Interact -> Answer question, device connection, configure CD media, configure floppy
media, power off, power on, VMware tools install
Virtual machine -> Inventory -> Create, register, unregister
Virtual machine -> Provisioning -> Allow virtual machine download, allow virtual machine files upload
Virtual machine -> Snapshots -> Remove snapshots.
3. Assign access level to the vCenter account (used in the tenant CS) for different objects as follows:
OBJECT
ROLE
REMARKS
vCenter
Read-Only
This is needed only to allow vCenter
access for managing different objects.
This permission can be removed if the
account is never going to be provided
to a tenant or used for any
management operations on the
vCenter.
Datacenter
Azure_Site_Recovery
Host and Host Cluster
Azure_Site_Recovery
Ensure again that access is at object
level so only those hosts are accessible
that will have tenant VMs before
failover and after failback.
Datastore and Datastore Cluster
Azure_Site_Recovery
Same as above
Network
Azure_Site_Recovery
Management Server
Azure_Site_Recovery
This includes access to all components –
CS, PS, and MT – if any are outside the
CS machine.
OBJECT
ROLE
REMARKS
Tenant VMs
Azure_Site_Recovery
Ensure that any new tenant VMs of a
particular tenant also get this access
else they will not be discoverable
through the Azure portal.
The vCenter account access is now complete. This fulfills the minimum permissions requirement to complete
failback operations. Note that these access permissions can also be used with your existing policies. Just modify
your existing permissions set to include role permissions from point 2 detailed above.
To restrict DR operations till the failover state that is, without failback capabilities, follow the above procedure but
instead of assigning 'Azure_Site_Recovery' role to the vCenter access account, assign just a 'Read-Only' role to that
account. This permission-set allows VM replication and failover and does not allow failback. Note that everything
else in the above process remains as-is. Every permission is still assigned at the object level only and not
propagated to child objects, to ensure tenant-isolation and restrict VM discovery.
Other multi-tenant environments
The above guidance described in detail how to set up a multi-tenant environment for a shared hosting solution. The
other two major solutions are dedicated hosting and managed service. The architecture for these is as below:
Dedicated hosting solution
Figure 2: Dedicated hosting scenario with multiple vCenters
The architectural difference here is that each tenant’s infrastructure is provisioned for that tenant only. The hosting
provider still needs to follow the CSP steps detailed for shared hosting but does not need to worry about tenant
isolation since tenants are isolated through separate vCenters. CSP provisioning remains unchanged.
Managed service solution
Figure 3: Managed service scenario with multiple vCenters
The architectural difference here is that each tenant’s infrastructure is also physically separate from other tenants.
This scenario usually exists when the tenant owns the infrastructure and just wants a solution provider to manage
DR. The partner again needs to follow the CSP steps detailed for shared hosting but does not need to worry about
tenant isolation since tenants are physically isolated through different infrastructures. CSP provisioning remains
unchanged.
CSP program overview
Microsoft’s Cloud Solution Provider (CSP) program fosters better-together stories with partners for offering all
Microsoft cloud services including O365, EMS, and Microsoft Azure. It enables our partners to own the end-to-end
relationship with customers and become the primary relationship contact point. Through CSP, a partner can deploy
Azure subscriptions for customers, and combine these subscriptions with their own value-added customized
offerings.
In the case of Azure Site Recovery, partners can manage the complete Disaster Recovery solution for customers
directly through CSP or use CSP to set up the Azure Site Recovery environments and let customers manage their
own DR needs in a self-service manner. In both scenarios, the partner is the liaison between Azure Site Recovery
and final customers, and the partner services the customer relationship and bills customers for Azure Site Recovery
usage.
Creating and managing tenant accounts
Step 0: Prerequisite check
The VM prerequisites are the same as described in the Azure Site Recovery documentation. In addition to those
prerequisites, the above access controls should be in place before proceeding with tenant management through
CSP. Create a separate Management Server for each tenant that can communicate with the tenant VMs and
partner’s vCenter. Only the partner has access rights to this server.
Step 1: Create tenant account
1. Through partner center login to your CSP account. From the Dashboard menu on the left, select the
‘Customers’ option.
2. On the page that opens click on the ‘Add customer’ button.
3. On the New Customer page, fill in all the account information details for the tenant and click on
‘Next:Subscriptions’.
4. On the subscriptions selection page, scroll down to add the ‘Microsoft Azure’ subscription. Other
subscriptions can be added now or at any other time in the future.
5. Continue forward and on the next page review all the details entered for the tenant and click on the Submit
button.
6. After the customer is created you get a confirmation page with the details of the default account and
password for that subscription. Save the information and change the password later as necessary through
the Azure portal login. This information can be shared as-is with the tenant or a separate account can be also
created and shared if required.
Step 2: Access tenant account
1. You can access the tenant’s subscription from the ‘Customers’ page through your Dashboard as described in
step 1. Navigate here and click on the name of the tenant account just created.
2. This opens the Subscriptions section of the tenant account and from here you can monitor the existing
subscriptions for the account and add more subscriptions as required. To manage the tenant’s DR
operations, select the ‘All resources (Azure portal) option on the right side of the page.
3. Clicking the ‘All resources’ button grants you access to the tenant’s Azure subscriptions and you can verify
the same by checking the AAD displayed on the top right corner of the Azure portal.
You can now perform all Site Recovery operations for the tenant through the Azure portal and manage the DR
operations. The process detailed above must be followed every time to access the tenant subscription through CSP
for managed DR.
Step 3: Deploy resources to tenant subscription
1. On the Azure portal, create a Resource Group and deploy a Recovery Services vault per the usual process.
Download the vault registration key.
2. Register the CS for the tenant using the vault registration key.
3. Enter the credentials for the two access accounts – vCenter access account and VM access account.
Step 4: Register site recovery infrastructure to Recovery Services vault
1. Open the Azure portal and on the vault created earlier register the vCenter server to CS registered in the
previous step. Use the vCenter access account for this purpose.
2. Finish the ‘Prepare infrastructure’ process for Site Recovery per the usual process.
3. The VMs are now ready to be replicated. Verify that only the tenant’s VMs are visible on the VM selection
blade under the Replicate option.
Step 5: Assign tenant access to subscription
For the case of self-service DR the account details as mentioned in item 6 of Step 1 must be provided to the tenant.
This should be done after the partner sets up the DR infrastructure. Irrespective of DR type (managed or selfservice) the partner is required to access tenant subscriptions through CSP portal only and setup the vault and
register infrastructure owned by the partner to the tenant subscriptions.
A partner can also add a new user to the tenant subscription through the CSP portal as follows:
1. Go to the particular tenant’s CSP subscription page and select the ‘Users and licenses’ option.
You can now create a new user by entering the relevant details and selecting permissions, or alternatively
uploading the list of users though a CSV file.
2. Once the users are created, go back to the Azure portal and under the Subscription blade select the relevant
subscription.
3. On the new blade that opens select Access Control (IAM) and click on +Add to add a user with the relevant
access level. The users created through CSP portal will automatically be displayed on the blade that opens
after clicking an access level.
For most management operations, the Contributor role is sufficient. A user with this access level can do
everything on a subscription except change access levels (for which an Owner level access is required). You
can also fine-tune the access levels as required.
Prerequisites for replication to Azure by using Azure
Site Recovery
4/17/2017 • 11 min to read • Edit Online
The Azure Site Recovery service contributes to your business continuity and disaster recovery (BCDR) strategy by
orchestrating replication of on-premises physical servers and virtual machines to the cloud (Azure), or to a
secondary datacenter. When outages occur in your primary location, you can fail over to a secondary location to
keep apps and workloads available. You can fail back to your primary location when it returns to normal
operations. For more about Site Recovery, see What is Site Recovery?.
This article summarizes the prerequisites required to begin Site Recovery replication to Azure.
Post any comments at the bottom of the article, or ask technical questions on the Azure Recovery Services
Forum.
Azure requirements
REQUIREMENT
DETAILS
Azure account
A Microsoft Azure account.
You can start with a free trial.
Site Recovery service
For more about Site Recovery pricing, see Site Recovery
pricing.
Azure storage
You need an Azure storage account to store replicated data,
and it must be in the same region as the Recovery Services
vault. Replicated data is stored in Azure storage, and Azure
VMs are created when failover occurs.
Depending on the resource model you want to use for failed
over Azure VMs, you can set up an account in the Azure
Resource Manager model or in the classic model.
You can use geo-redundant storage or locally redundant
storage. We recommend geo-redundant storage so that data
is resilient if a regional outage occurs, or if the primary region
can't be recovered.
You can use standard or premium storage. Premium storage
is typically used for virtual machines that need a consistently
high IO performance and low latency to host IO intensive
workloads. If you use premium storage for replicated data,
you also need a standard storage account to store replication
logs that capture ongoing changes to on-premises data.
Storage limitations
You can't move storage accounts used in Site Recovery
across resource groups, or within or across subscriptions.
Replicating to premium storage accounts in Central India and
South India isn't currently supported.
REQUIREMENT
DETAILS
Azure network
You need an Azure network to which Azure VMs will connect
after failover, and it must be in the same region as the
Recovery Services vault.
In the Azure portal, you can create networks in the Resource
Manager model or in the classic model.
If you replicate from System Center Virtual Machine Manager
to Azure, you will set up network mapping between Virtual
Machine Manager VM networks and Azure networks to
ensure that Azure VMs connect to appropriate networks
after failover.
Network limitations
You can't move network accounts used in Site Recovery
across resource groups, or within or across subscriptions.
Network mapping
If you replicate Hyper-V VMs in Virtual Machine Manager
clouds, you need to set up network mapping so that Azure
VMs are connected to appropriate networks when they're
created after failover.
NOTE
The following sections describe the prerequisites for various components in the customer environment. For more about
support for specific configurations, read the support matrix.
Disaster recovery of VMware virtual machines or physical Windows or
Linux servers to Azure
Following are the required components for disaster recovery of VMware virtual machines or physical Windows
or Linux servers in addition to the ones mentioned in Azure requirements.
Configuration server or additional process server: You will need to set up an on-premises machine as the
configuration server to coordinate communications between the on-premises site and Azure, and to manage
data replication.
1. VMware vCenter or vSphere host
COMPONENT
REQUIREMENTS
vSphere
One or more VMware vSphere hypervisors.
Hypervisors should be running vSphere version 6.0, 5.5, or
5.1 with the latest updates.
We recommend that vSphere hosts and vCenter servers are
located in the same network as the process server. This is the
network in which the configuration server is located, unless
you’ve set up a dedicated process server.
COMPONENT
REQUIREMENTS
vCenter
We recommend that you deploy a VMware vCenter server to
manage your vSphere hosts. It should be running vCenter
version 6.0 or 5.5, with the latest updates.
Limitation: Site Recovery does not support cross vCenter
vMotion. Storage DRS and Storage vMotion is also not
supported on Master target virtual machine post a reprotect
operation.
1. Replicated machine prerequisites
COMPONENT
REQUIREMENTS
On-premises (VMware VMs)
Replicated VMs should have VMware tools installed and
running.
VMs should conform with Azure prerequisites for creating
Azure VMs.
Individual disk capacity on protected machines shouldn’t be
more than 1,023 GB.
A minimum 2 GB of available space on the installation drive is
required for component installation.
Port 20004 should be opened on the VM local firewall if you
want to enable multi-VM consistency.
Machine names should contain between 1 and 63 characters
(letters, numbers, and hyphens). The name must start with a
letter or number and end with a letter or number. After
you've enabled replication for a machine, you can modify the
Azure name.
Windows machines (physical or VMware)
The machine should be running a supported 64-bit operating
system: Windows Server 2012 R2, Windows Server 2012, or
Windows Server 2008 R2 with at least SP1.
The operating system should be installed on drive C. The OS
disk should be a Windows basic disk and not dynamic. The
data disk can be dynamic.
COMPONENT
REQUIREMENTS
Linux machines (physical or VMware)
You need a supported 64-bit operating system: Red Hat
Enterprise Linux 6.7, 6.8, 7.1, or 7.2; Centos 6.5, 6.6, 6.7, 6.8,
7.0, 7.1, or 7.2; Oracle Enterprise Linux 6.4 or 6.5 running
either the Red Hat compatible kernel or Unbreakable
Enterprise Kernel Release 3 (UEK3), SUSE Linux Enterprise
Server 11 SP3, SUSE Linux Enterprise Server 11 SP4.
Your /etc/hosts files on protected machines should contain
entries that map the local host name to IP addresses
associated with all network adapters.
If you want to connect to an Azure virtual machine running
Linux after failover by using a Secure Shell client (ssh), ensure
that the Secure Shell service on the protected machine is set
to start automatically on system boot and that firewall rules
allow an ssh connection to it.
The host name, mount points, device names, and Linux
system paths and file names (for example, /etc/; /usr) should
be in English only.
The following directories (if set up as separate partitions/filesystems) must all be on the same disk (the OS disk) on the
source server: / (root), /boot, /usr, /usr/local, /var, /etc
XFS v5 features such as metadata checksum are currently not
supported by ASR on XFS filesystems. Ensure that your XFS
filesystems aren't using any v5 features. You can use the
xfs_info utility to check the XFS superblock for the partition. If
ftype is set to 1, then XFSv5 features are being used.
On Red Hat Enterprise Linux 7 and CentOS 7 servers, the lsof
utility must be installed and available.
Disaster recovery of Hyper-V virtual machines to Azure (no Virtual
Machine Manager)
Following are the required components for disaster recovery of Hyper-V virtual machines in Virtual Machine
Manager clouds, in addition to the ones mentioned in Azure requirements.
PREREQUISITE
DETAILS
Hyper-V host
One or more on-premises servers running Windows Server
2012 R2 with the latest updates and the Hyper-V role
enabled, or Microsoft Hyper-V Server 2012 R2.
The Hyper-V servers should contain one or more virtual
machines.
Hyper-V servers should be connected to the Internet, either
directly or via a proxy.
Hyper-V servers should have fixes mentioned in KB2961977
installed.
PREREQUISITE
DETAILS
Provider and agent
During Azure Site Recovery deployment, you’ll install Azure
Site Recovery Provider. The Provider installation will also
install Azure Recovery Services Agent on each Hyper-V server
running virtual machines you want to protect.
All Hyper-V servers in a Site Recovery vault should have the
same versions of the Provider and agent.
The Provider will need to connect to Azure Site Recovery over
the Internet. Traffic can be sent directly or through a proxy.
HTTPS-based proxy is not supported. The proxy server
should allow access to:
*.accesscontrol.windows.net
: Used for access control and
identity management
\*.backup.windowsazure.com
: Used for replication data
transfer and orchestration
: Used for access to the storage
account that stores replicated data
\*.blob.core.windows.net
\*.hypervrecoverymanager.windowsazure.com : Used for
replication management operations and orchestration
time.nist.gov and time.windows.com : Used to check
time synchronization between system and global time
URLs for Azure Government Cloud: *.ugv.hypervrecoverymanager.windowsazure.us *.ugv.backup.windowsazure.us *.ugi.hypervrecoverymanager.windowsazure.us *.ugi.backup.windowsazure.us
If you have IP address-based firewall rules on the server,
ensure that the rules allow communication to Azure.
Allow the Azure datacenter IP ranges, and the HTTPS (443)
port.
Allow IP address ranges for the Azure region of your
subscription, and for the western US (used for access control
and identity management).
Disaster recovery of Hyper-V virtual machines in Virtual Machine
Manager clouds to Azure
Following are the required components for disaster recovery of Hyper-V virtual machines in Virtual Machine
Manager clouds, in addition to the ones mentioned in Azure requirements.
PREREQUISITE
DETAILS
PREREQUISITE
DETAILS
Virtual Machine Manager
One or more Virtual Machine Manager servers running on
System Center 2012 R2 or later. Each Virtual Machine
Manager server should have one or more clouds configured.
A cloud should contain:
- One or more Virtual Machine Manager host groups.
- One or more Hyper-V host servers or clusters in each host
group.
For more about setting up Virtual Machine Manager clouds,
see How to create a cloud in VMM 2012.
Hyper-V
Hyper-V host servers must be running at least Windows
Server 2012 R2 with Hyper-V role or Microsoft Hyper-V
Server 2012 R2 and have the latest updates installed.
A Hyper-V server should contain one or more VMs.
A Hyper-V host server or cluster that includes VMs you want
to replicate must be managed in a Virtual Machine Manager
cloud.
Hyper-V servers must be connected to the Internet, either
directly or via a proxy.
Hyper-V servers must have the fixes mentioned in article
2961977 installed.
Hyper-V host servers need Internet access for data
replication to Azure.
PREREQUISITE
DETAILS
Provider and agent
During Azure Site Recovery deployment, install Azure Site
Recovery Provider on the Virtual Machine Manager server,
and install Recovery Services Agent on Hyper-V hosts. The
Provider and agent need to connect to Azure over the
Internet directly or through a proxy. An HTTPS-based proxy
isn't supported. The proxy server on the Virtual Machine
Manager server and Hyper-V hosts should allow access to:
*.accesscontrol.windows.net
: Used for access control and
identity management
\*.backup.windowsazure.com
: Used for replication data
transfer and orchestration
: Used for access to the storage
account that stores replicated data
\*.blob.core.windows.net
\*.hypervrecoverymanager.windowsazure.com : Used for
replication management operations and orchestration
time.nist.gov and time.windows.com : Used to check
time synchronization between system and global time
URLs for Azure Government Cloud: *.ugv.hypervrecoverymanager.windowsazure.us *.ugv.backup.windowsazure.us *.ugi.hypervrecoverymanager.windowsazure.us *.ugi.backup.windowsazure.us
If you have IP address-based firewall rules on the Virtual
Machine Manager server, ensure that the rules allow
communication to Azure.
Allow the Azure datacenter IP ranges and the HTTPS (443)
port.
Allow IP address ranges for the Azure region of your
subscription, and for the western US (used for access control
and identity management).
Replicated machine prerequisites
COMPONENT
DETAILS
COMPONENT
DETAILS
Protected VMs
Site Recovery supports all operating systems that are
supported by Azure.
VMs should conform with Azure prerequisites for creating
Azure VMs. Machine names should contain between 1 and
63 characters (letters, numbers, and hyphens). The name
must start with a letter or number and end with a letter or
number.
You can modify the name after you've enabled replication for
the VM.
Individual disk capacity on protected machines shouldn’t be
more than 1,023 GB. A VM can have up to 16 disks (thus up
to 16 TB).
Disaster recovery of Hyper-V virtual machines in Virtual Machine
Manager clouds to a customer-owned site
Following are the required components for disaster recovery of Hyper-V virtual machines in Virtual Machine
Manager clouds to a customer-owned site, in addition to the ones mentioned in Azure requirements.
COMPONENTS
DETAILS
Virtual Machine Manager
We recommend that you deploy a Virtual Machine Manager
server in the primary site and a Virtual Machine Manager
server in the secondary site.
You can replicate between clouds on a single VMM server. To
do this, you need at least two clouds configured on the
Virtual Machine Manager server.
Virtual Machine Manager servers should be running at least
System Center 2012 SP1 with the latest updates.
Each Virtual Machine Manager server must have at least one
or more clouds. All clouds must have the Hyper-V Capacity
profile set.
Clouds must contain one or more Virtual Machine Manager
host groups. For more about setting up Virtual Machine
Manager clouds, see Prepare for Azure Site Recovery
deployment.
COMPONENTS
DETAILS
Hyper-V
Hyper-V servers must be running at least Windows Server
2012 with the Hyper-V role, and have the latest updates
installed.
A Hyper-V server should contain one or more VMs.
Hyper-V host servers should be located in host groups in the
primary and secondary VMM clouds.
If you run Hyper-V in a cluster on Windows Server 2012 R2,
we recommend installing update 2961977.
If you run Hyper-V in a cluster on Windows Server 2012 and
have a static IP address-based cluster, cluster broker isn't
created automatically. You must configure the cluster broker
manually. For more about the cluster broker, see Configure
replica broker role cluster to cluster replication.
Provider
During Site Recovery deployment, install Azure Site Recovery
Provider on Virtual Machine Manager servers. The Provider
communicates with Site Recovery over HTTPS 443 to
orchestrate replication. Data replication occurs between the
primary and secondary Hyper-V servers over the LAN or a
VPN connection.
The Provider running on the Virtual Machine Manager server
needs access to these URLs:
*.accesscontrol.windows.net
: Used for access control and
identity management
\*.backup.windowsazure.com
: Used for replication data
transfer and orchestration
\*.blob.core.windows.net : Used for access to the storage
account that stores replicated data
\*.hypervrecoverymanager.windowsazure.com : Used for
replication management operations and orchestration
and time.windows.com : Used to check
time synchronization between system and global time
time.nist.gov
URLs for Azure Government Cloud: *.ugv.hypervrecoverymanager.windowsazure.us *.ugv.backup.windowsazure.us *.ugi.hypervrecoverymanager.windowsazure.us *.ugi.backup.windowsazure.us
The Provider must allow firewall communication from the
Virtual Machine Manager servers to the Azure datacenter IP
ranges and allow the HTTPS (443) protocol.
URL access
These URLs should be available from VMware, VMM, and Hyper-V host servers.
URL
VMM TO VMM
VMM TO AZURE
HYPER-V TO AZURE
VMWARE TO AZURE
*.accesscontrol.windows.net
Allow
Allow
Allow
Allow
*.backup.windowsazure.com
Not required
Allow
Allow
Allow
*.hypervrecoverymanager.windowsazure.com
Allow
Allow
Allow
Allow
*.store.core.windows.net
Allow
Allow
Allow
Allow
*.blob.core.windows.netNot required
Allow
Allow
Allow
https://dev.mysql.com/get/archives/mysqlNot required
5.5/mysql-5.5.37-win32.msi
Not required
Not required
Allow for SQL
download
time.windows.com
Allow
Allow
Allow
Allow
time.nist.gov
Allow
Allow
Allow
Allow
Designing your network for disaster recovery
3/27/2017 • 14 min to read • Edit Online
This article is directed to IT professionals who are responsible for architecting, implementing, and supporting
business continuity and disaster recovery (BCDR) infrastructure, and who want to leverage Microsoft Azure Site
Recovery (ASR) to support and enhance their BCDR services. This paper discusses practical considerations for
System Center Virtual Machine Manager server deployment, the pros and cons of stretched subnets vs. subnet
failover, and how to structure disaster recovery to virtual sites in Microsoft Azure.
Overview
Azure Site Recovery (ASR) is a Microsoft Azure service that orchestrates the protection and recovery of your
virtualized applications for business continuity disaster recovery (BCDR) purposes. This document is intended to
guide the reader through the process of designing the networks, focusing on architecting IP ranges and subnets on
the disaster recovery site, when replicating virtual machines (VMs) using Site Recovery.
Furthermore, this article demonstrates how Site Recovery enables architecting and implementing a multisite virtual
datacenter to support BCDR services at time of test or disaster.
In a world where everyone expects 24/7 connectivity, it is more important than ever to keep your infrastructure and
applications up and running. The purpose of Business Continuity and Disaster Recovery (BCDR) is to restore failed
components so the organization can quickly resume normal operations. Developing disaster recovery strategies to
deal with unlikely, devastating events is very challenging. This is due to the inherent difficulty of predicting the
future, particularly as it relates to improbable events, and the high cost to provide adequate measures of protection
against far-reaching catastrophes.
Crucial for BCDR planning, Recovery Time Objective (RTO) and Recovery Point Objective (RPO) must be defined as
part of a disaster recovery plan. When a disaster strikes the customer’s data center, using Azure Site Recovery,
customers can quickly (low RTO) bring online their replicated virtual machines located in either the secondary data
center or Microsoft Azure with minimum data loss (low RPO).
Failover is made possible by ASR which initially copies designated virtual machines from the primary data center to
the secondary data center or to Azure (depending on the scenario), and then periodically refreshes the replicas.
During infrastructure planning, network design should be considered as potential bottleneck that can prevent you
from meeting company RTO and RPO objectives.
When administrators are planning to deploy a disaster recovery solution, one of the key questions in their minds is
how the virtual machine would be reachable after the failover is completed. ASR allows the administrator to choose
the network to which a virtual machine would be connected to after failover. If the primary site is managed by a
VMM server then this is achieved using Network Mapping. See Prepare for network mapping for more details.
While designing the network for the recovery site, the administrator has two choices:
Use a different IP address range for the network at recovery site. In this scenario the virtual machine after
failover will get a new IP address and the administrator would have to do a DNS update. Read more here
Use same IP address range for the network at the recovery site. In certain scenarios administrators prefer to
retain the IP addresses that they have on the primary site even after the failover. In a normal scenario an
administrator would have to update the routes to indicate the new location of the IP addresses. But in the
scenario where a stretched VLAN is deployed between the primary and the recovery sites, retaining the IP
addresses for the virtual machines becomes an attractive option. Keeping the same IP addresses simplifies the
recovery process by taking away any network related post-failover steps.
When administrators are planning to deploy a disaster recovery solution, one of the key questions in their mind is
how the applications will be reachable after the failover is completed. Modern applications are almost always
dependent on networking to some degree, so physically moving a service from one site to another represents a
networking challenge. There are two main ways that this problem is dealt with in disaster recovery solutions. The
first approach is to maintain fixed IP addresses. Despite the services moving and the hosting servers being in
different physical locations, applications take the IP address configuration with them to the new location. The
second approach involves completely changing the IP address during the transition into the recovered site. Each
approach has several implementation variations which are summarized below.
While designing the network for the recovery site, the administrator has two choices:
Option 1: Retain IP addresses
From a disaster recovery process perspective, using fixed IP addresses appears to be the easiest method to
implement, but it has a number of potential challenges which in practice make it the least popular approach. Azure
Site Recovery provides the capability to retain the IP addresses in all scenarios. Before one decides to retain IP,
appropriate thought should be given to the constraints it imposes on the failover capabilities. Let us look at the
factors that can help you to make a decision to retain IP addresses, or not. This can be achieved in two ways, by
using a stretched subnet or by doing a full subnet failover.
Stretched subnet
Here the subnet is made available simultaneously in both primary and DR locations. In simple terms this means
you can move a server and its IP (Layer 3) configuration to the second site and the network will route the traffic to
the new location automatically. This is trivial to deal with from a server perspective but it has a number of
challenges:
From a Layer 2 (data link layer) perspective, it will require networking equipment that can manage a stretched
VLAN, but this has become less of a problem as it is now widely available. The second and more difficult
problem is that by stretching the VLAN the potential fault domain is extended to both sites, essentially
becoming a single point of failure. While this is an unlikely occurrence, it has happened that a broadcast storm
started but could not be isolated. We have found mixed opinions about this last issue and have seen many
successful implementations as well as “we will never implement this technology here”.
Stretched subnet is not possible if you are using Microsoft Azure as the DR site.
Subnet failover
It is possible to implement subnet failover to obtain the benefits of the stretched subnet solution described above
without stretching the subnet across multiple sites. Here any given subnet would be present at Site 1 or Site 2, but
never at both sites simultaneously. In order to maintain the IP address space in the event of a failover, it is possible
to programmatically arrange for the router infrastructure to move the subnets from one site to another. In a
failover scenario the subnets would move with the associated protected VMs. The main drawback to this approach
is in the event of a failure you have to move the whole subnet, which may be OK but it may affect the failover
granularity considerations.
Let’s examine how a fictional enterprise named Contoso is able to replicate its VMs to a recovery location while
failing over the entire subnet. We will first look at how Contoso is able to manage their subnets while replicating
VMs between two on-premises locations, and then we will discuss how subnet failover works when Azure is used
as the disaster recovery site.
Failover to a secondary on-premises site
Let us look at a scenario where we want retain the IP of each of the VMs and fail-over the complete subnet
together. The primary site has applications running in subnet 192.168.1.0/24. When the failover happens, all the
virtual machines that are part of this subnet will be failed over to the recovery site and retain their IP addresses.
Routes will have to be appropriately modified to reflect the fact that all the virtual machines belonging to subnet
192.168.1.0/24 have now moved to the recovery site.
In the following illustration the routes between primary site and recovery site, third site and primary site, and third
site and recovery site will have to be appropriately modified.
The following pictures shows the subnets before the failover. Subnet 192.168.0.1/24 is active on the Primary Site
before the failover and becomes active of the Recovery Site after the failover
Before failover
The picture below shows networks and subnets after failover.
After failover
In your secondary site is on-premises and you are using a VMM server to manage it then when enabling protection
for a specific virtual machine, ASR will allocate networking resources according to the following workflow:
ASR allocates an IP address for each network interface on the virtual machine from the static IP address pool
defined on the relevant network for each System Center VMM instance.
If the administrator defines the same IP address pool for the network on the recovery site as that of the IP
address pool of the network on the primary site, while allocating the IP address to the replica virtual machine
ASR would allocate the same IP address as that of the primary virtual machine. The IP is reserved in VMM but
not set as failover IP. Failover IP is set just before the failover.
The picture above shows the Failover TCP/IP settings for the replica virtual machine (on the Hyper-V console).
These settings would be populated just before the virtual machine is started after a failover
If the same IP is not available, ASR would allocate some other available IP address from the defined IP address pool.
After the VM is enabled for protection you can use following sample script to verify the IP that has been allocated
to the virtual machine. The same IP would be set as Failover IP and assigned to the VM at the time of failover:
$vm = Get-SCVirtualMachine -Name <VM_NAME>
$na = $vm[0].VirtualNetworkAdapters>
$ip = Get-SCIPAddress -GrantToObjectID $na[0].id
$ip.address
NOTE
In the scenario where virtual machines use DHCP, the management of IP addresses is completely outside the control of ASR.
An administrator has to ensure that the DHCP server serving the IP addresses on the recovery site can serve from the same
range as that of the primary site.
Failover to Azure
Azure Site Recovery (ASR) allows Microsoft Azure to be used as a disaster recovery site for your virtual machines.
In this case, you will need to deal with one more constraint.
Let’s examine a scenario where a fictional company named Woodgrove Bank has on-premises infrastructure
hosting their line of business applications, and they are hosting their mobile applications on Azure. Connectivity
between Woodgrove Bank VMs in Azure and on-premises servers is provided by a site-to-site (S2S) Virtual Private
Network (VPN). S2S VPN allows Woodgrove Bank’s virtual network in Azure to be seen as an extension of
Woodgrove Bank’s on-premises network. This communication is enabled by S2S VPN between Woodgrove Bank
edge and Azure virtual network. Now Woodgrove wants to use ASR to replicate its workloads running in its
datacenter to Azure. This option meets the needs of Woodgrove, which wants an economical DR option and is able
to store data in public cloud environments. Woodgrove has to deal with applications and configurations which
depend on hard-coded IP addresses, hence they have a requirement to retain IP addresses for their applications
after failing over to Azure.
Woodgrove has decided to assign IP addresses from IP address range (172.16.1.0/24, 172.16.2.0/24) to its
resources running in Azure.
For Woodgrove to be able to replicate its virtual machines to Azure while retaining the IP addresses, an Azure
Virtual Network needs to be created. It should be an extension of the on-premises network so that applications can
failover from the on-premises site to Azure seamlessly. Azure allows you to add site-to-site as well as point-to-site
VPN connectivity to the virtual networks created in Azure. When setting up your site-to-site connection, Azure
network allows you to route traffic to the on-premises location (Azure calls it local-network) only if the IP address
range is different from the on-premises IP address range, because Azure doesn’t support stretching subnets. This
means that if you have a subnet 192.168.1.0/24 on-premises, you can’t add a local-network 192.168.1.0/24 in the
Azure network. This is expected because Azure doesn’t know that there are no active VMs in the subnet and that the
subnet is being created only for DR purposes. To be able to correctly route network traffic out of an Azure network
the subnets in the network and the local-network must not conflict.
Before failover
To help Woodgrove fulfill their business requirements, we need to implement the following workflows:
Create an additional network, let us call it Recovery Network, where the failed-over virtual machines would be
created.
To ensure that the IP for a VM is retained after a failover, go to the Configure tab under VM properties, specify
the same IP that the VM has on-premises, and then click Save. When the VM is failed over, Azure Site Recovery
will assign the provided IP to the virtual machine.
Once the failover is triggered and the virtual machines are created in the Recovery Network with the desired IP,
connectivity to this network can be established using a Vnet to Vnet Connection. If required this action can be
scripted. As we discussed in the previous section about subnet failover, even in the case of failover to Azure, routes
would have to be appropriately modified to reflect that 192.168.1.0/24 has now moved to Azure.
After failover
If you don't have a 'Azure Network' as shown in the picture above. You can create a site to site vpn connection
between your 'Primary Site' and 'Recovery Network' after the failover.
Option 2: Changing IP addresses
This approach seems to be the most prevalent based on what we have seen. It takes the form of changing the IP
address of every VM that is involved in the failover. A drawback of this approach requires the incoming network to
‘learn’ that the application that was at IPx is now at IPy. Even if IPx and IPy are logical names, DNS entries typically
have to be changed or flushed throughout the network, and cached entries in network tables have to be updated or
flushed, therefore a downtime could be seen depending upon how the DNS infrastructure has been setup. These
issues can be mitigated by using low TTL values in the case of intranet applications and using Azure Traffic Manger
with ASR for internet based applications
Changing the IP addresses - Illustration
Let us look at the scenario where you are planning to use different IPs across the primary and the recovery sites. In
the following example we also have a third site from where the applications hosted on primary or recovery site can
be accessed.
In the picture above there are some applications hosted in subnet 192.168.1.0/24 subnet on the primary site, and
they have been configured to come up on the recovery site in subnet 172.16.1.0/24 after a failover. VPN
connections/network routes have been configured appropriately so that all three sites can access each other.
As the picture below shows, after failing over one or more applications, they will be restored in the recovery subnet.
In this case we are not constrained to failover the entire subnet at the same time. No changes are required to
reconfigure VPN or network routes. A failover and some DNS updates will make sure that applications remain
accessible. If the DNS is configured to allow dynamic updates then the virtual machines would register themselves
using the new IP once they start after a failover.
After failing-over the replica virtual machine might have an IP address that isn’t the same as the IP address of the
primary virtual machine. Virtual machines will update the DNS server that they are using after they start. DNS
entries typically have to be changed or flushed throughout the network, and cached entries in network tables have
to be updated or flushed, so it is not uncommon to be faced with downtime while these state changes take place.
This issue can be mitigated by:
Using low TTL values for intranet applications.
Using Azure Traffic Manger with ASR for internet based applications.
Using the following script within your recovery plan to update the DNS Server to ensure a timely update
(The script is not required if the Dynamic DNS registration is configured)
string]$Zone,
[string]$name,
[string]$IP
)
$Record = Get-DnsServerResourceRecord -ZoneName $zone -Name $name
$newrecord = $record.clone()
$newrecord.RecordData[0].IPv4Address = $IP
Set-DnsServerResourceRecord -zonename $zone -OldInputObject $record -NewInputObject $Newrecord
Changing the IP addresses – DR to Azure
The Networking Infrastructure Setup for Microsoft Azure as a Disaster Recovery Site blog post explains how to
setup the required Azure networking infrastructure when retaining IP addresses isn’t a requirement. It starts with
describing the application and then look at how to setup networking on-premises and on Azure and then
concluding with how to do a test failover and a planned failover.
Next steps
Learn how Site Recovery maps source and target networks when a VMM server is being used to manage the
primary site.
Plan capacity and scaling for VMware replication with
Azure Site Recovery
3/22/2017 • 7 min to read • Edit Online
Use this article to figure out how to plan capacity and scaling when replicating on-premises VMware VMs and
physical servers to Azure, with Azure Site Recovery.
How do I start capacity planning?
Gather information about your replication environment by using the Azure Site Recovery Deployment Planner.
This includes information about the number of virtual machines that are compatible and incompatible, disks per
VM, and data churn per disk. It also covers the network bandwidth requirement, and required Azure infrastructure
for successful replication and test failover.
Capacity considerations
COMPONENT
DETAILS
Replication
Maximum daily change rate: A protected machine can only
use one process server, and a single process server can handle
a daily change rate up to 2 TB. Thus 2 TB is the maximum
daily data change rate that’s supported for a protected
machine.
Maximum throughput: A replicated machine can belong to
one storage account in Azure. A standard storage account can
handle a maximum of 20,000 requests per second, and we
recommend that you keep the number of input/output
operations per second (IOPS) across a source machine to
20,000. For example, if you have a source machine with 5
disks, and each disk generates 120 IOPS (8K size) on the
source machine, then it will be within the Azure per disk IOPS
limit of 500. (The number of storage accounts required is
equal to the total source machine IOPS, divided by 20,000.)
Configuration server
The configuration server should be able to handle the daily
change rate capacity across all workloads running on
protected machines, and needs sufficient bandwidth to
continuously replicate data to Azure Storage.
As a best practice, locate the configuration server on the same
network and LAN segment as the machines you want to
protect. It can be located on a different network, but
machines you want to protect should have layer 3 network
visibility to it.
Size recommendations for the configuration server are
summarized in the table in the following section.
COMPONENT
DETAILS
Process server
The first process server is installed by default on the
configuration server. You can deploy additional process
servers to scale your environment.
The process server receives replication data from protected
machines, and optimizes it with caching, compression, and
encryption. Then it sends the data to Azure. The process
server machine should have sufficient resources to perform
these tasks.
The process server uses a disk-based cache. Use a separate
cache disk of 600 GB or more to handle data changes stored
in the event of a network bottleneck or outage.
Size recommendations for the configuration server
CPU
MEMORY
CACHE DISK SIZE
DATA CHANGE RATE
PROTECTED MACHINES
8 vCPUs (2 sockets *
4 cores @ 2.5
gigahertz [GHz])
16 GB
300 GB
500 GB or less
Replicate less than
100 machines.
12 vCPUs (2 sockets *
6 cores @ 2.5 GHz)
18 GB
600 GB
500 GB to 1 TB
Replicate between
100-150 machines.
16 vCPUs (2 sockets *
8 cores @ 2.5 GHz)
32 GB
1 TB
1 TB to 2 TB
Replicate between
150-200 machines.
> 2 TB
Deploy additional
process servers if
you're replicating
more than 200
machines, or if the
daily data change rate
exceeds 2 TB.
Deploy another
process server
Where:
Each source machine is configured with 3 disks of 100 GB each.
We used benchmarking storage of 8 SAS drives of 10 K RPM, with RAID 10, for cache disk measurements.
Size recommendations for the process server
If you need to protect more than 200 machines, or the daily change rate is greater than 2 TB, you can add process
servers to handle the replication load. To scale out, you can:
Increase the number of configuration servers. For example, you can protect up to 400 machines with two
configuration servers.
Add more process servers, and use these to handle traffic instead of (or in addition to) the configuration server.
The following table describes a scenario in which:
You're not planning to use the configuration server as a process server.
You've set up an additional process server.
You've configured protected virtual machines to use the additional process server.
Each protected source machine is configured with three disks of 100 GB each.
CONFIGURATION
SERVER
ADDITIONAL PROCESS
SERVER
8 vCPUs (2 sockets *
4 cores @ 2.5 GHz),
16 GB memory
CACHE DISK SIZE
DATA CHANGE RATE
PROTECTED MACHINES
4 vCPUs (2 sockets *
2 cores @ 2.5 GHz), 8
GB memory
300 GB
250 GB or less
Replicate 85 or fewer
machines.
8 vCPUs (2 sockets *
4 cores @ 2.5 GHz),
16 GB memory
8 vCPUs (2 sockets *
4 cores @ 2.5 GHz),
12 GB memory
600 GB
250 GB to 1 TB
Replicate between 85150 machines.
12 vCPUs (2 sockets *
6 cores @ 2.5 GHz),
18 GB memory
12 vCPUs (2 sockets *
6 cores @ 2.5 GHz)
24 GB memory
1 TB
1 TB to 2 TB
Replicate between
150-225 machines.
The way in which you scale your servers depends on your preference for a scale-up or scale-out model. You scale
up by deploying a few high-end configuration and process servers, or scale out by deploying more servers with
fewer resources. For example, if you need to protect 220 machines, you could do either of the following:
Set up the configuration server with 12 vCPU, 18 GB of memory, and an additional process server with 12
vCPU, 24 GB of memory. Configure protected machines to use the additional process server only.
Set up two configuration servers (2 x 8 vCPU, 16 GB RAM) and two additional process servers (1 x 8 vCPU and
4 vCPU x 1 to handle 135 + 85 [220] machines). Configure protected machines to use the additional process
servers only.
Control network bandwidth
You can use the deployment planner tool to calculate the bandwidth you need for replication (including the initial
replication, and then the delta). To control the amount of bandwidth used for replication, you have a few options:
Throttle bandwidth: VMware traffic that replicates to Azure goes through a specific process server. You can
throttle bandwidth on the machines running as process servers.
Influence bandwidth: You can influence the bandwidth used for replication by using a couple of registry keys:
The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure
Backup\UploadThreadsPerVM registry value specifies the number of threads that are used for data
transfer (initial or delta replication) of a disk. A higher value increases the network bandwidth used for
replication.
The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure
Backup\DownloadThreadsPerVM specifies the number of threads used for data transfer during
failback.
Throttle bandwidth
1. Open the Azure Backup MMC snap-in on the machine acting as the process server. By default, a shortcut for
Backup is available on the desktop, or in the following folder: C:\Program Files\Microsoft Azure Recovery
Services Agent\bin\wabadmin.
2. In the snap-in, click Change Properties.
3. On the Throttling tab, select Enable internet bandwidth usage throttling for backup operations. Set
the limits for work and non-work hours. Valid ranges are from 512 Kbps to 102 Mbps per second.
You can also use the Set-OBMachineSetting cmdlet to set throttling. Here's a sample:
$mon = [System.DayOfWeek]::Monday
$tue = [System.DayOfWeek]::Tuesday
Set-OBMachineSetting -WorkDay $mon, $tue -StartWorkHour "9:00:00" -EndWorkHour "18:00:00" -WorkHourBandwidth
(512*1024) -NonWorkHourBandwidth (2048*1024)
Set-OBMachineSetting -NoThrottle indicates that no throttling is required.
Influence network bandwidth for a VM
1. In the VM's registry, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure
Backup\Replication.
To influence the bandwidth traffic on a replicating disk, modify the value of UploadThreadsPerVM, or
create the key if it doesn't exist.
To influence the bandwidth for failback traffic from Azure, modify the value of
DownloadThreadsPerVM.
2. The default value is 4. In an “overprovisioned” network, these registry keys should be changed from the default
values. The maximum is 32. Monitor traffic to optimize the value.
Deploy additional process servers
If you have to scale out your deployment beyond 200 source machines, or you have a total daily churn rate of
more than 2 TB, you need additional process servers to handle the traffic volume. Follow these instructions to set
up the process server. After setting up the server, you migrate source machines to use it.
1. In Site Recovery servers, click the configuration server, and then click Process Server.
2. In Server type, click Process server (on-premises).
3. Download the Site Recovery Unified Setup file, and run it to install the process server. This also registers it in
the vault.
4. In Before you begin, select Add additional process servers to scale out deployment.
5. Complete the wizard in the same way you did when you set up the configuration server.
6. In Configuration Server Details, specify the IP address of the configuration server, and the passphrase. To
obtain the passphrase, run
[SiteRecoveryInstallationFolder]\home\sysystems\bin\genpassphrase.exe –n on the configuration
server.
Migrate machines to use the new process server
1. In Settings > Site Recovery servers, click the configuration server, and then expand Process servers.
2. Right-click the process server currently in use, and click Switch.
3. In Select target process server, select the new process server you want to use, and then select the virtual
machines that the server will handle. Click the information icon to get information about the server. To help you
make load decisions, the average space that's needed to replicate each selected virtual machine to the new
process server is displayed. Click the check mark to start replicating to the new process server.
Azure Site Recovery deployment planner
5/4/2017 • 39 min to read • Edit Online
This article is the Azure Site Recovery Deployment Planner user guide for VMware-to-Azure production
deployments.
Overview
Before you begin protecting any VMware virtual machines (VMs) by using Site Recovery, allocate sufficient
bandwidth, based on your daily data-change rate, to meet your desired recovery point objective (RPO). Be sure to
deploy the right number of configuration servers and process servers on-premises.
You also need to create the right type and number of target Azure storage accounts. You create either standard or
premium storage accounts, factoring in growth on your source production servers because of increased usage over
time. You choose the storage type per VM, based on workload characteristics (for example, read/write I/O
operations per second [IOPS], or data churn) and Site Recovery limits.
The Site Recovery deployment planner public preview is a command-line tool that's currently available only for the
VMware-to-Azure scenario. You can remotely profile your VMware VMs by using this tool (with no production
impact whatsoever) to understand the bandwidth and Azure Storage requirements for successful replication and
test failover. You can run the tool without installing any Site Recovery components on-premises. However, to get
accurate achieved throughput results, we recommend that you run the planner on a Windows Server that meets
the minimum requirements of the Site Recovery configuration server that you would eventually need to deploy as
one of the first steps in production deployment.
The tool provides the following details:
Compatibility assessment
A VM eligibility assessment, based on number of disks, disk size, IOPS, churn and boot type(EFI/BIOS)
The estimated network bandwidth that's required for delta replication
Network bandwidth need versus RPO assessment
The estimated network bandwidth that's required for delta replication
The throughput that Site Recovery can get from on-premises to Azure
The number of VMs to batch, based on the estimated bandwidth to complete initial replication in a given
amount of time
Azure infrastructure requirements
The storage type (standard or premium storage account) requirement for each VM
The total number of standard and premium storage accounts to be set up for replication
Storage-account naming suggestions, based on Azure Storage guidance
The storage-account placement for all VMs
The number of Azure cores to be set up before test failover or failover on the subscription
The Azure VM-recommended size for each on-premises VM
On-premises infrastructure requirements
The required number of configuration servers and process servers to be deployed on-premises
IMPORTANT
Because usage is likely to increase over time, all the preceding tool calculations are performed assuming a 30 percent growth
factor in workload characteristics, and using a 95th percentile value of all the profiling metrics (read/write IOPS, churn, and so
forth). Both of these elements (growth factor and percentile calculation) are configurable. To learn more about growth factor,
see the "Growth-factor considerations" section. To learn more about percentile value, see the "Percentile value used for the
calculation" section.
Requirements
The tool has two main phases: profiling and report generation. There is also a third option to calculate throughput
only. The requirements for the server from which the profiling and throughput measurement is initiated are
presented in the following table:
SERVER REQUIREMENT
Profiling and throughput measurement
DESCRIPTION
Operating system: Microsoft Windows Server 2012 R2
(ideally matching at least the size recommendations for
the configuration server)
Machine configuration: 8 vCPUs, 16 GB RAM, 300 GB
HDD
Microsoft .NET Framework 4.5
VMware vSphere PowerCLI 6.0 R3
Microsoft Visual C++ Redistributable for Visual Studio
2012
Internet access to Azure from this server
Azure storage account
Administrator access on the server
Minimum 100 GB of free disk space (assuming 1000
VMs with an average of three disks each, profiled for
30 days)
VMware vCenter statistics level settings should be set
to 2 or high level
Report generation
A Windows PC or Windows Server with Microsoft Excel 2013
or later
User permissions
Read-only permission for the user account that's used to
access the VMware vCenter server/VMware vSphere ESXi host
during profiling
NOTE
The tool can profile only VMs with VMDK and RDM disks. It cannot profile VMs with iSCSI or NFS disks. Site Recovery does
support iSCSI and NFS disks for VMware servers but, because the deployment planner is not inside the guest and it profiles
only by using vCenter performance counters, the tool does not have visibility into these disk types.
Download and extract the public preview
1. Download the latest version of the Site Recovery deployment planner public preview.
The tool is packaged in a .zip folder. The current version of the tool supports only the VMware-to-Azure
scenario.
2. Copy the .zip folder to the Windows server from which you want to run the tool.
You can run the tool from Windows Server 2012 R2 if the server has network access to connect to the
vCenter server/vSphere ESXi host that holds the VMs to be profiled. However, we recommend that you run
the tool on a server whose hardware configuration meets the configuration server sizing guideline. If you
have already deployed Site Recovery components on-premises, run the tool from the configuration server.
We recommend that you have the same hardware configuration as the configuration server (which has an
in-built process server) on the server where you run the tool. Such a configuration ensures that the achieved
throughput that the tool reports matches the actual throughput that Site Recovery can achieve during
replication. The throughput calculation depends on available network bandwidth on the server and
hardware configuration (CPU, storage, and so forth) of the server. If you run the tool from any other server,
the throughput is calculated from that server to Microsoft Azure. Also, because the hardware configuration
of the server might differ from that of the configuration server, the achieved throughput that the tool
reports might be inaccurate.
3. Extract the .zip folder.
The folder contains multiple files and subfolders. The executable file is ASRDeploymentPlanner.exe in the
parent folder.
Example:
Copy the .zip file to E:\ drive and extract it. E:\ASR Deployment Planner-Preview_v1.2.zip
E:\ASR Deployment Planner-Preview_v1.2\ ASR Deployment Planner-Preview_v1.2\
ASRDeploymentPlanner.exe
Capabilities
You can run the command-line tool (ASRDeploymentPlanner.exe) in any of the following three modes:
1. Profiling
2. Report generation
3. Get throughput
First, run the tool in profiling mode to gather VM data churn and IOPS. Next, run the tool to generate the report to
find the network bandwidth and storage requirements.
Profiling
In profiling mode, the deployment planner tool connects to the vCenter server/vSphere ESXi host to collect
performance data about the VM.
Profiling does not affect the performance of the production VMs, because no direct connection is made to them.
All performance data is collected from the vCenter server/vSphere ESXi host.
To ensure that there is a negligible impact on the server because of profiling, the tool queries the vCenter
server/vSphere ESXi host once every 15 minutes. This query interval does not compromise profiling accuracy,
because the tool stores every minute’s performance counter data.
Create a list of VMs to profile
First, you need a list of the VMs to be profiled. You can get all the names of VMs on a vCenter server/vSphere ESXi
host by using the VMware vSphere PowerCLI commands in the following procedure. Alternatively, you can list in a
file the friendly names or IP addresses of the VMs that you want to profile manually.
1. Sign in to the VM that VMware vSphere PowerCLI is installed in.
2. Open the VMware vSphere PowerCLI console.
3. Ensure that the execution policy is enabled for the script. If it is disabled, launch the VMware vSphere
PowerCLI console in administrator mode, and then enable it by running the following command:
Set-ExecutionPolicy –ExecutionPolicy AllSigned
4. To get all the names of VMs on a vCenter server/vSphere ESXi host and store the list in a .txt file, run the two
commands listed here. Replace ‹server name›, ‹user name›, ‹password›, ‹outputfile.txt›; with your inputs.
Connect-VIServer -Server <server name> -User <user name> -Password <password>
Get-VM | Select Name | Sort-Object -Property Name > <outputfile.txt>
5. Open the output file in Notepad, and then copy the names of all VMs that you want to profile to another file
(for example, ProfileVMList.txt), one VM name per line. This file is used as input to the -VMListFile parameter
of the command-line tool.
Start profiling
After you have the list of VMs to be profiled, you can run the tool in profiling mode. Here is the list of mandatory
and optional parameters of the tool to run in profiling mode.
ASRDeploymentPlanner.exe -Operation StartProfiling /?
PARAMETER NAME
DESCRIPTION
-Operation
StartProfiling
-Server
The fully qualified domain name or IP address of the vCenter
server/vSphere ESXi host whose VMs are to be profiled.
-User
The user name to connect to the vCenter server/vSphere ESXi
host. The user needs to have read-only access, at minimum.
-VMListFile
The file that contains the list of VMs to be profiled. The file
path can be absolute or relative. The file should contain one
VM name/IP address per line. Virtual machine name specified
in the file should be the same as the VM name on the vCenter
server/vSphere ESXi host.
For example, the file VMList.txt contains the following VMs:
virtual_machine_A
10.150.29.110
virtual_machine_B
-NoOfDaysToProfile
The number of days for which profiling is to be run. We
recommend that you run profiling for more than 15 days to
ensure that the workload pattern in your environment over
the specified period is observed and used to provide an
accurate recommendation.
PARAMETER NAME
DESCRIPTION
-Directory
(Optional) The universal naming convention (UNC) or local
directory path to store profiling data generated during
profiling. If a directory name is not given, the directory named
‘ProfiledData’ under the current path will be used as the
default directory.
-Password
(Optional) The password to use to connect to the vCenter
server/vSphere ESXi host. If you do not specify one now, you
will be prompted for it when the command is executed.
-StorageAccountName
(Optional) The storage-account name that's used to find the
throughput achievable for replication of data from onpremises to Azure. The tool uploads test data to this storage
account to calculate throughput.
-StorageAccountKey
(Optional) The storage-account key that's used to access the
storage account. Go to the Azure portal > Storage accounts >
<Storage account name> > Settings > Access Keys > Key1
(or primary access key for classic storage account).
-Environment
(optional) This is your target Azure Storage account
environment. This can be one of three values AzureCloud,AzureUSGovernment, AzureChinaCloud. Default is
AzureCloud. Use the parameter when your target Azure
region is either Azure US Government or Azure China clouds.
We recommend that you profile your VMs for at least 15 to 30 days. During the profiling period,
ASRDeploymentPlanner.exe keeps running. The tool takes profiling time input in days. If you want to profile for few
hours or minutes for a quick test of the tool, in the public preview, you will need to convert the time into the
equivalent measure of days. For example, to profile for 30 minutes, the input must be 30/(60*24) = 0.021 days. The
minimum allowed profiling time is 30 minutes.
During profiling, you can optionally pass a storage-account name and key to find the throughput that Site
Recovery can achieve at the time of replication from the configuration server or process server to Azure. If the
storage-account name and key are not passed during profiling, the tool does not calculate achievable throughput.
You can run multiple instances of the tool for various sets of VMs. Ensure that the VM names are not repeated in
any of the profiling sets. For example, if you have profiled ten VMs (VM1 through VM10) and after few days you
want to profile another five VMs (VM11 through VM15), you can run the tool from another command-line console
for the second set of VMs (VM11 through VM15). Ensure that the second set of VMs do not have any VM names
from the first profiling instance or you use a different output directory for the second run. If two instances of the
tool are used for profiling the same VMs and use the same output directory, the generated report will be incorrect.
VM configurations are captured once at the beginning of the profiling operation and stored in a file called
VMDetailList.xml. This information is used when the report is generated. Any change in VM configuration (for
example, an increased number of cores, disks, or NICs) from the beginning to the end of profiling is not captured. If
a profiled VM configuration has changed during the course of profiling, in the public preview, here is the
workaround to get latest VM details when generating the report:
Back up VMdetailList.xml, and delete the file from its current location.
Pass -User and -Password arguments at the time of report generation.
The profiling command generates several files in the profiling directory. Do not delete any of the files, because
doing so affects report generation.
Example 1: Profile VMs for 30 days, and find the throughput from on-premises to Azure
ASRDeploymentPlanner.exe -Operation StartProfiling -Directory “E:\vCenter1_ProfiledData” -Server
vCenter1.contoso.com -VMListFile “E:\vCenter1_ProfiledData\ProfileVMList1.txt” -NoOfDaysToProfile 30 -User
vCenterUser1 -StorageAccountName asrspfarm1 -StorageAccountKey
Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
Example 2: Profile VMs for 15 days
ASRDeploymentPlanner.exe -Operation StartProfiling -Directory “E:\vCenter1_ProfiledData” -Server
vCenter1.contoso.com -VMListFile “E:\vCenter1_ProfiledData\ProfileVMList1.txt” -NoOfDaysToProfile 15 -User
vCenterUser1
Example 3: Profile VMs for 1 hour for a quick test of the tool
ASRDeploymentPlanner.exe -Operation StartProfiling -Directory “E:\vCenter1_ProfiledData” -Server
vCenter1.contoso.com -VMListFile “E:\vCenter1_ProfiledData\ProfileVMList1.txt” -NoOfDaysToProfile 0.04 User vCenterUser1
NOTE
If the server that the tool is running on is rebooted or has crashed, or if you close the tool by using Ctrl + C, the profiled
data is preserved. However, there is a chance of missing the last 15 minutes of profiled data. In such an instance, rerun
the tool in profiling mode after the server restarts.
When the storage-account name and key are passed, the tool measures the throughput at the last step of profiling. If the
tool is closed before profiling is completed, the throughput is not calculated. To find the throughput before generating
the report, you can run the GetThroughput operation from the command-line console. Otherwise, the generated report
will not contain the throughput information.
Generate a report
The tool generates a macro-enabled Microsoft Excel file (XLSM file) as the report output, which summarizes all the
deployment recommendations. The report is named DeploymentPlannerReport_<unique numeric identifier>.xlsm
and placed in the specified directory.
After profiling is complete, you can run the tool in report-generation mode. The following table contains a list of
mandatory and optional tool parameters to run in report-generation mode.
ASRDeploymentPlanner.exe -Operation GenerateReport /?
PARAMETER NAME
DESCRIPTION
-Operation
GenerateReport
-Server
The vCenter/vSphere server fully qualified domain name or IP
address (use the same name or IP address that you used at
the time of profiling) where the profiled VMs whose report is
to be generated are located. Note that if you used a vCenter
server at the time of profiling, you cannot use a vSphere
server for report generation, and vice-versa.
-VMListFile
The file that contains the list of profiled VMs that the report is
to be generated for. The file path can be absolute or relative.
The file should contain one VM name or IP address per line.
The VM names that are specified in the file should be the
same as the VM names on the vCenter server/vSphere ESXi
host, and match what was used during profiling.
PARAMETER NAME
DESCRIPTION
-Directory
(Optional) The UNC or local directory path where the profiled
data (files generated during profiling) is stored. This data is
required for generating the report. If a name isn't specified,
‘ProfiledData’ directory will be used.
-GoalToCompleteIR
(Optional) The number of hours in which the initial replication
of the profiled VMs needs to be completed. The generated
report provides the number of VMs for which initial replication
can be completed in the specified time. The default is 72
hours.
-User
(Optional) The user name to use to connect to the
vCenter/vSphere server. The name is used to fetch the latest
configuration information of the VMs, such as the number of
disks, number of cores, and number of NICs, to use in the
report. If the name isn't provided, the configuration
information collected at the beginning of the profiling kickoff
is used.
-Password
(Optional) The password to use to connect to the vCenter
server/vSphere ESXi host. If the password isn't specified as a
parameter, you will be prompted for it later when the
command is executed.
-DesiredRPO
(Optional) The desired recovery point objective, in minutes.
The default is 15 minutes.
-Bandwidth
Bandwidth in Mbps. The parameter to use to calculate the
RPO that can be achieved for the specified bandwidth.
-StartDate
(Optional) The start date and time in MM-DD-YYYY:HH:MM
(24-hour format). StartDate must be specified along with
EndDate. When StartDate is specified, the report is generated
for the profiled data that's collected between StartDate and
EndDate.
-EndDate
(Optional) The end date and time in MM-DD-YYYY:HH:MM
(24-hour format). EndDate must be specified along with
StartDate. When EndDate is specified, the report is generated
for the profiled data that's collected between StartDate and
EndDate.
-GrowthFactor
(Optional) The growth factor, expressed as a percentage. The
default is 30 percent.
to a single storage account placement is caculated considering Failover/Test Test failover of virtual machines is
done on Managed Disk instead of Unmanaged disk. |
Example 1: Generate a report with default values when the profiled data is on the local drive
ASRDeploymentPlanner.exe -Operation GenerateReport -Server vCenter1.contoso.com -Directory “\\PS1W2K12R2\vCenter1_ProfiledData” -VMListFile “\\PS1-W2K12R2\vCenter1_ProfiledData\ProfileVMList1.txt”
Example 2: Generate a report when the profiled data is on a remote server
You should have read/write access on the remote directory.
ASRDeploymentPlanner.exe -Operation GenerateReport -Server vCenter1.contoso.com -Directory “\\PS1W2K12R2\vCenter1_ProfiledData” -VMListFile “\\PS1-W2K12R2\vCenter1_ProfiledData\ProfileVMList1.txt”
Example 3: Generate a report with a specific bandwidth and goal to complete IR within specified time
ASRDeploymentPlanner.exe -Operation GenerateReport -Server vCenter1.contoso.com -Directory
“E:\vCenter1_ProfiledData” -VMListFile “E:\vCenter1_ProfiledData\ProfileVMList1.txt” -Bandwidth 100 GoalToCompleteIR 24
Example 4: Generate a report with a 5 percent growth factor instead of the default 30 percent
ASRDeploymentPlanner.exe -Operation GenerateReport -Server vCenter1.contoso.com -Directory
“E:\vCenter1_ProfiledData” -VMListFile “E:\vCenter1_ProfiledData\ProfileVMList1.txt” -GrowthFactor 5
Example 5: Generate a report with a subset of profiled data
For example, you have 30 days of profiled data and want to generate a report for only 20 days.
ASRDeploymentPlanner.exe -Operation GenerateReport -Server vCenter1.contoso.com -Directory
“E:\vCenter1_ProfiledData” -VMListFile “E:\vCenter1_ProfiledData\ProfileVMList1.txt” -StartDate 01-102017:12:30 -EndDate 01-19-2017:12:30
Example 6: Generate a report for 5-minute RPO
ASRDeploymentPlanner.exe -Operation GenerateReport -Server vCenter1.contoso.com -Directory
“E:\vCenter1_ProfiledData” -VMListFile “E:\vCenter1_ProfiledData\ProfileVMList1.txt” -DesiredRPO 5
Percentile value used for the calculation
What default percentile value of the performance metrics collected during profiling does the tool use
when it generates a report?
The tool defaults to the 95th percentile values of read/write IOPS, write IOPS, and data churn that are collected
during profiling of all the VMs. This metric ensures that the 100th percentile spike your VMs might see because of
temporary events is not used to determine your target storage-account and source-bandwidth requirements. For
example, a temporary event might be a backup job running once a day, a periodic database indexing or analytics
report-generation activity, or other similar short-lived, point-in-time events.
Using 95th percentile values gives a true picture of real workload characteristics, and it gives you the best
performance when the workloads are running on Azure. We do not anticipate that you would need to change this
number. If you do change the value (to the 90th percentile, for example), you can update the configuration file
ASRDeploymentPlanner.exe.config in the default folder and save it to generate a new report on the existing profiled
data.
<add key="WriteIOPSPercentile" value="95" />
<add key="ReadWriteIOPSPercentile" value="95" />
<add key="DataChurnPercentile" value="95" />
Growth-factor considerations
Why should I consider growth factor when I plan deployments?
It is critical to account for growth in your workload characteristics, assuming a potential increase in usage over
time. After protection is in place, if your workload characteristics change, you cannot switch to a different storage
account for protection without disabling and re-enabling the protection.
For example, let's say that today your VM fits in a standard storage replication account. Over the next three months,
several changes are likely to occur:
The number of users of the application that runs on the VM will increase.
The resulting increased churn on the VM will require the VM to go to premium storage so that Site Recovery
replication can keep pace.
Consequently, you will have to disable and re-enable protection to a premium storage account.
We strongly recommend that you plan for growth during deployment planning and while the default value is 30
percent. You are the expert on your application usage pattern and growth projections, and you can change this
number accordingly while generating a report. Moreover, you can generate multiple reports with various growth
factors with the same profiled data and determine what target storage and source bandwidth recommendations
work best for you.
The generated Microsoft Excel report contains the following information:
Input
Recommendations
Recommendations-Bandwidth Input
VM<->Storage Placement
Compatible VMs
Incompatible VMs
Get throughput
To estimate the throughput that Site Recovery can achieve from on-premises to Azure during replication, run the
tool in GetThroughput mode. The tool calculates the throughput from the server that the tool is running on. Ideally,
this server is based on the configuration server sizing guide. If you have already deployed Site Recovery
infrastructure components on-premises, run the tool on the configuration server.
Open a command-line console, and go to the Site Recovery deployment planning tool folder. Run
ASRDeploymentPlanner.exe with following parameters.
ASRDeploymentPlanner.exe -Operation GetThroughput /?
PARAMETER NAME
DESCRIPTION
-Operation
GetThroughput
-Directory
(Optional) The UNC or local directory path where the profiled
data (files generated during profiling) is stored. This data is
required for generating the report. If a directory name is not
specified, ‘ProfiledData’ directory is used.
-StorageAccountName
The storage-account name that's used to find the bandwidth
consumed for replication of data from on-premises to Azure.
The tool uploads test data to this storage account to find the
bandwidth consumed.
-StorageAccountKey
The storage-account key that's used to access the storage
account. Go to the Azure portal > Storage accounts >
<Storage account name> > Settings > Access Keys > Key1
(or a primary access key for a classic storage account).
-VMListFile
The file that contains the list of VMs to be profiled for
calculating the bandwidth consumed. The file path can be
absolute or relative. The file should contain one VM name/IP
address per line. The VM names specified in the file should be
the same as the VM names on the vCenter server/vSphere
ESXi host.
For example, the file VMList.txt contains the following VMs:
VM_A
10.150.29.110
VM_B
-Environment
(optional) This is your target Azure Storage account
environment. This can be one of three values AzureCloud,AzureUSGovernment, AzureChinaCloud. Default is
AzureCloud. Use the parameter when your target Azure
region is either Azure US Government or Azure China clouds.
The tool creates several 64-MB asrvhdfile<#>.vhd files (where "#" is the number of files) on the specified directory.
The tool uploads the files to the storage account to find the throughput. After the throughput is measured, the tool
deletes all the files from the storage account and from the local server. If the tool is terminated for any reason while
it is calculating throughput, it doesn't delete the files from the storage or from the local server. You will have to
delete them manually.
The throughput is measured at a specified point in time, and it is the maximum throughput that Site Recovery can
achieve during replication, provided that all other factors remain the same. For example, if any application starts
consuming more bandwidth on the same network, the actual throughput varies during replication. If you are
running the GetThroughput command from a configuration server, the tool is unaware of any protected VMs and
ongoing replication. The result of the measured throughput is different if the GetThroughput operation is run when
the protected VMs have high data churn. We recommend that you run the tool at various points in time during
profiling to understand what throughput levels can be achieved at various times. In the report, the tool shows the
last measured throughput.
Example
ASRDeploymentPlanner.exe -Operation GetThroughput -Directory E:\vCenter1_ProfiledData -VMListFile
E:\vCenter1_ProfiledData\ProfileVMList1.txt -StorageAccountName asrspfarm1 -StorageAccountKey
by8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
NOTE
Run the tool on a server that has the same storage and CPU characteristics as the configuration server.
For replication, set the recommended bandwidth to meet the RPO 100 percent of the time. After you set the right
bandwidth, if you don’t see an increase in the achieved throughput reported by the tool, do the following:
1. Check to determine whether there is any network Quality of Service (QoS) that is limiting Site Recovery throughput.
2. Check to determine whether your Site Recovery vault is in the nearest physically supported Microsoft Azure region to
minimize network latency.
3. Check your local storage characteristics to determine whether you can improve the hardware (for example, HDD to
SSD).
4. Change the Site Recovery settings in the process server to increase the amount of network bandwidth used for
replication.
Recommendations with desired RPO as input
Profiled data
Profiled data period: The period during which the profiling was run. By default, the tool includes all profiled data
in the calculation, unless it generates the report for a specific period by using StartDate and EndDate options
during report generation.
Server Name: The name or IP address of the VMware vCenter or ESXi host whose VMs’ report is generated.
Desired RPO: The recovery point objective for your deployment. By default, the required network bandwidth is
calculated for RPO values of 15, 30, and 60 minutes. Based on the selection, the affected values are updated on the
sheet. If you have used the DesiredRPOinMin parameter while generating the report, that value is shown in the
Desired RPO result.
Profiling overview
Total Profiled Virtual Machines: The total number of VMs whose profiled data is available. If the VMListFile has
names of any VMs which were not profiled, those VMs are not considered in the report generation and are
excluded from the total profiled VMs count.
Compatible Virtual Machines: The number of VMs that can be protected to Azure by using Site Recovery. It is
the total number of compatible VMs for which the required network bandwidth, number of storage accounts,
number of Azure cores, and number of configuration servers and additional process servers are calculated. The
details of every compatible VM are available in the "Compatible VMs" section.
Incompatible Virtual Machines: The number of profiled VMs that are incompatible for protection with Site
Recovery. The reasons for incompatibility are noted in the "Incompatible VMs" section. If the VMListFile has names
of any VMs that were not profiled, those VMs are excluded from the incompatible VMs count. These VMs are listed
as "Data not found" at the end of the "Incompatible VMs" section.
Desired RPO: Your desired recovery point objective, in minutes. The report is generated for three RPO values: 15
(default), 30, and 60 minutes. The bandwidth recommendation in the report is changed based on your selection in
the Desired RPO drop-down list at the top right of the sheet. If you have generated the report by using the DesiredRPO parameter with a custom value, this custom value will show as the default in the Desired RPO dropdown list.
Required network bandwidth (Mbps)
To meet RPO 100 percent of the time: The recommended bandwidth in Mbps to be allocated to meet your
desired RPO 100 percent of the time. This amount of bandwidth must be dedicated for steady-state delta
replication of all your compatible VMs to avoid any RPO violations.
To meet RPO 90 percent of the time: Because of broadband pricing or for any other reason, if you cannot set the
bandwidth needed to meet your desired RPO 100 percent of the time, you can choose to go with a lower
bandwidth setting that can meet your desired RPO 90 percent of the time. To understand the implications of
setting this lower bandwidth, the report provides a what-if analysis on the number and duration of RPO violations
to expect.
Achieved Throughput: The throughput from the server on which you have run the GetThroughput command to
the Microsoft Azure region where the storage account is located. This throughput number indicates the estimated
level that you can achieve when you protect the compatible VMs by using Site Recovery, provided that your
configuration server or process server storage and network characteristics remain the same as that of the server
from which you have run the tool.
For replication, you should set the recommended bandwidth to meet the RPO 100 percent of the time. After you
set the bandwidth, if you don’t see any increase in the achieved throughput, as reported by the tool, do the
following:
1. Check to see whether there is any network Quality of Service (QoS) that is limiting Site Recovery
throughput.
2. Check to see whether your Site Recovery vault is in the nearest physically supported Microsoft Azure region
to minimize network latency.
3. Check your local storage characteristics to determine whether you can improve the hardware (for example,
HDD to SSD).
4. Change the Site Recovery settings in the process server to increase the amount network bandwidth used for
replication.
If you are running the tool on a configuration server or process server that already has protected VMs, run the tool
a few times. The achieved throughput number changes depending on the amount of churn being processed at that
point in time.
For all enterprise Site Recovery deployments, we recommend that you use ExpressRoute.
Required storage accounts
The following chart shows the total number of storage accounts (standard and premium) that are required to
protect all the compatible VMs. To learn which storage account to use for each VM, see the "VM-storage
placement" section.
Required number of Azure cores
This result is the total number of cores to be set up before failover or test failover of all the compatible VMs. If too
few cores are available in the subscription, Site Recovery fails to create VMs at the time of test failover or failover.
Required on-premises infrastructure
This figure is the total number of configuration servers and additional process servers to be configured that would
suffice to protect all the compatible VMs. Depending on the supported size recommendations for the configuration
server, the tool might recommend additional servers. The recommendation is based on the larger of either the perday churn or the maximum number of protected VMs (assuming an average of three disks per VM), whichever is
hit first on the configuration server or the additional process server. You'll find the details of total churn per day
and total number of protected disks in the "Input" section.
What-if analysis
This analysis outlines how many violations could occur during the profiling period when you set a lower bandwidth
for the desired RPO to be met only 90 percent of the time. One or more RPO violations can occur on any given day.
The graph shows the peak RPO of the day. Based on this analysis, you can decide if the number of RPO violations
across all days and peak RPO hit per day is acceptable with the specified lower bandwidth. If it is acceptable, you
can allocate the lower bandwidth for replication, else allocate the higher bandwidth as suggested to meet the
desired RPO 100 percent of the time.
Recommended VM batch size for initial replication
In this section, we recommend the number of VMs that can be protected in parallel to complete the initial
replication within 72 hours with the suggested bandwidth to meet desired RPO 100 percent of the time being set.
This value is configurable value. To change it at report-generation time, use the GoalToCompleteIR parameter.
The graph here shows a range of bandwidth values and a calculated VM batch size count to complete initial
replication in 72 hours, based on the average detected VM size across all the compatible VMs.
In the public preview, the report does not specify which VMs should be included in a batch. You can use the disk
size shown in the "Compatible VMs" section to find each VM’s size and select them for a batch, or you can select
the VMs based on known workload characteristics. The completion time of the initial replication changes
proportionally, based on the actual VM disk size, used disk space, and available network throughput.
Growth factor and percentile values used
This section at the bottom of the sheet shows the percentile value used for all the performance counters of the
profiled VMs (default is 95th percentile), and the growth factor (default is 30 percent) that's used in all the
calculations.
Recommendations with available bandwidth as input
You might have a situation where you know that you cannot set a bandwidth of more than x Mbps for Site
Recovery replication. The tool allows you to input available bandwidth (using the -Bandwidth parameter during
report generation) and get the achievable RPO in minutes. With this achievable RPO value, you can decide whether
you need to set up additional bandwidth or you are OK with having a disaster recovery solution with this RPO.
Input
The Input worksheet provides an overview of the profiled VMware environment.
Start Date and End Date: The start and end dates of the profiling data considered for report generation. By
default, the start date is the date when profiling starts, and the end date is the date when profiling stops. This can
be the ‘StartDate’ and ‘EndDate’ values if the report is generated with these parameters.
Total number of profiling days: The total number of days of profiling between the start and end dates for which
the report is generated.
Number of compatible virtual machines: The total number of compatible VMs for which the required network
bandwidth, required number of storage accounts, Microsoft Azure cores, configuration servers and additional
process servers are calculated.
Total number of disks across all compatible virtual machines: The number that's used as one of the inputs to
decide the number of configuration servers and additional process servers to be used in the deployment.
Average number of disks per compatible virtual machine: The average number of disks calculated across all
compatible VMs.
Average disk size (GB): The average disk size calculated across all compatible VMs.
Desired RPO (minutes): Either the default recovery point objective or the value passed for the ‘DesiredRPO’
parameter at the time of report generation to estimate required bandwidth.
Desired bandwidth (Mbps): The value that you have passed for the ‘Bandwidth’ parameter at the time of report
generation to estimate achievable RPO.
Observed typical data churn per day (GB): The average data churn observed across all profiling days. This
number is used as one of the inputs to decide the number of configuration servers and additional process servers
to be used in the deployment.
VM-storage placement
Disk Storage Type: Either a standard or premium storage account, which is used to replicate all the corresponding
VMs mentioned in the VMs to Place column.
Suggested Prefix: The suggested three-character prefix that can be used for naming the storage account. You can
use your own prefix, but the tool's suggestion follows the partition naming convention for storage accounts.
Suggested Account Name: The storage-account name after you include the suggested prefix. Replace the name
within the angle brackets (< and >) with your custom input.
Log Storage Account: All the replication logs are stored in a standard storage account. For VMs that replicate to a
premium storage account, set up an additional standard storage account for log storage. A single standard logstorage account can be used by multiple premium replication storage accounts. VMs that are replicated to standard
storage accounts use the same storage account for logs.
Suggested Log Account Name: Your storage log account name after you include the suggested prefix. Replace
the name within the angle brackets (< and >) with your custom input.
Placement Summary: A summary of the total VMs' load on the storage account at the time of replication and test
failover or failover. It includes the total number of VMs mapped to the storage account, total read/write IOPS
across all VMs being placed in this storage account, total write (replication) IOPS, total setup size across all disks,
and total number of disks.
Virtual Machines to Place: A list of all the VMs that should be placed on the given storage account for optimal
performance and use.
Compatible VMs
VM Name: The VM name or IP address that's used in the VMListFile when a report is generated. This column also
lists the disks (VMDKs) that are attached to the VMs. To distinguish vCenter VMs with duplicate names or IP
addresses, the names include the ESXi host name. The listed ESXi host is the one where the VM was placed when
the tool discovered during the profiling period.
VM Compatibility: Values are Yes and Yes*. Yes* is for instances in which the VM is a fit for Azure Premium
Storage. Here, the profiled high-churn or IOPS disk fits in the P20 or P30 category, but the size of the disk causes it
to be mapped down to a P10 or P20. The storage account decides which premium storage disk type to map a disk
to, based on its size. For example:
<128 GB is a P10.
128 GB to 512 GB is a P20.
512 GB to 1023 GB is a P30.
If the workload characteristics of a disk put it in the P20 or P30 category, but the size maps it down to a lower
premium storage disk type, the tool marks that VM as Yes*. The tool also recommends that you either change the
source disk size to fit into the recommended premium storage disk type or change the target disk type postfailover.
Storage Type: Standard or premium.
Suggested Prefix: The three-character storage-account prefix.
Storage Account: The name that uses the suggested storage-account prefix.
R/W IOPS (with Growth Factor): The peak workload read/write IOPS on the disk (default is 95th percentile),
including the future growth factor (default is 30 percent). Note that the total read/write IOPS of a VM is not always
the sum of the VM’s individual disks’ read/write IOPS, because the peak read/write IOPS of the VM is the peak of
the sum of its individual disks' read/write IOPS during every minute of the profiling period.
Data Churn in Mbps (with Growth Factor): The peak churn rate on the disk (default is 95th percentile), including
the future growth factor (default is 30 percent). Note that the total data churn of the VM is not always the sum of
the VM’s individual disks’ data churn, because the peak data churn of the VM is the peak of the sum of its
individual disks' churn during every minute of the profiling period.
Azure VM Size: The ideal mapped Azure Cloud Services virtual-machine size for this on-premises VM. The
mapping is based on the on-premises VM’s memory, number of disks/cores/NICs, and read/write IOPS. The
recommendation is always the lowest Azure VM size that matches all of the on-premises VM characteristics.
Number of Disks: The total number of virtual machine disks (VMDKs) on the VM.
Disk size (GB): The total setup size of all disks of the VM. The tool also shows the disk size for the individual disks
in the VM.
Cores: The number of CPU cores on the VM.
Memory (MB): The RAM on the VM.
NICs: The number of NICs on the VM.
Boot Type: It is boot type of the VM. It can be either BIOS or EFI. Currently Azure Site Recovery supports only BIOS
boot type. All the virtual machines of EFI boot type are listed in Incompatible VMs worksheet.
OS Type: The is OS type of the VM. It can be either Windows or Linux or other.
Incompatible VMs
VM Name: The VM name or IP address that's used in the VMListFile when a report is generated. This column also
lists the VMDKs that are attached to the VMs. To distinguish vCenter VMs with duplicate names or IP addresses, the
names include the ESXi host name. The listed ESXi host is the one where the VM was placed when the tool
discovered during the profiling period.
VM Compatibility: Indicates why the given VM is incompatible for use with Site Recovery. The reasons are
described for each incompatible disk of the VM and, based on published storage limits, can be any of the following:
Disk size is >1023 GB. Azure Storage currently does not support disk sizes greater than 1 TB.
Boot type is EFI. Azure Site Recovery currently supports only BIOS boot type virtual machine.
Total VM size (replication + TFO) exceeds the supported storage-account size limit (35 TB). This
incompatibility usually occurs when a single disk in the VM has a performance characteristic that exceeds
the maximum supported Azure or Site Recovery limits for standard storage. Such an instance pushes the
VM into the premium storage zone. However, the maximum supported size of a premium storage account is
35 TB, and a single protected VM cannot be protected across multiple storage accounts. Also note that when
a test failover is executed on a protected VM, it runs in the same storage account where replication is
progressing. In this instance, set up 2x the size of the disk for replication to progress and test failover to
succeed in parallel.
Source IOPS exceeds supported storage IOPS limit of 5000 per disk.
Source IOPS exceeds supported storage IOPS limit of 80,000 per VM.
Average data churn exceeds supported Site Recovery data churn limit of 10 MBps for average I/O size for the
disk.
Total data churn across all disks on the VM exceeds the maximum supported Site Recovery data churn limit of
54 MBps per VM.
Average effective write IOPS exceeds the supported Site Recovery IOPS limit of 840 for disk.
Calculated snapshot storage exceeds the supported snapshot storage limit of 10 TB.
R/W IOPS (with Growth Factor): The peak workload IOPS on the disk (default is 95th percentile), including the
future growth factor (default is 30 percent). Note that the total read/write IOPS of the VM is not always the sum of
the VM’s individual disks’ read/write IOPS, because the peak read/write IOPS of the VM is the peak of the sum of
its individual disks' read/write IOPS during every minute of the profiling period.
Data Churn in Mbps (with Growth Factor): The peak churn rate on the disk (default 95th percentile) including
the future growth factor (default 30 percent). Note that the total data churn of the VM is not always the sum of the
VM’s individual disks’ data churn, because the peak data churn of the VM is the peak of the sum of its individual
disks' churn during every minute of the profiling period.
Number of Disks: The total number of VMDKs on the VM.
Disk size (GB): The total setup size of all disks of the VM. The tool also shows the disk size for the individual disks
in the VM.
Cores: The number of CPU cores on the VM.
Memory (MB): The amount of RAM on the VM.
NICs: The number of NICs on the VM.
Boot Type: It is boot type of the VM. It can be either BIOS or EFI. Currently Azure Site Recovery supports only BIOS
boot type. All the virtual machines of EFI boot type are listed in Incompatible VMs worksheet.
OS Type: The is OS type of the VM. It can be either Windows or Linux or other.
Site Recovery limits
REPLICATION STORAGE
TARGET
AVERAGE SOURCE DISK I/O
SIZE
AVERAGE SOURCE DISK DATA
CHURN
TOTAL SOURCE DISK DATA
CHURN PER DAY
Standard storage
8 KB
2 MBps
168 GB per disk
Premium P10 disk
8 KB
2 MBps
168 GB per disk
Premium P10 disk
16 KB
4 MBps
336 GB per disk
Premium P10 disk
32 KB or greater
8 MBps
672 GB per disk
Premium P20 or P30 disk
8 KB
5 MBps
421 GB per disk
Premium P20 or P30 disk
16 KB or greater
10 MBps
842 GB per disk
These are average numbers assuming a 30 percent I/O overlap. Site Recovery is capable of handling higher
throughput based on overlap ratio, larger write sizes, and actual workload I/O behavior. The preceding numbers
assume a typical backlog of approximately five minutes. That is, after data is uploaded, it is processed and a
recovery point is created within five minutes.
These limits are based on our tests, but they cannot cover all possible application I/O combinations. Actual results
can vary based on your application I/O mix. For best results, even after deployment planning, we always
recommend that you perform extensive application testing by using a test failover to get the true performance
picture.
Updating the deployment planner
To update the deployment planner, do the following:
1. Download the latest version of the Azure Site Recovery deployment planner.
2. Copy the .zip folder to a server that you want to run it on.
3. Extract the .zip folder.
4. Do either of the following:
If the latest version doesn't contain a profiling fix and profiling is already in progress on your current
version of the planner, continue the profiling.
If the latest version does contain a profiling fix, we recommended that you stop profiling on your current
version and restart the profiling with the new version.
NOTE
When you start profiling with the new version, pass the same output directory path so that the tool appends profile
data on the existing files. A complete set of profiled data will be used to generate the report. If you pass a different
output directory, new files are created, and old profiled data is not used to generate the report.
Each new deployment planner is a cumulative update of the .zip file. You don't need to copy the newest files to the
previous folder. You can create and use a new folder.
Version history
1.2
Updated: April 7, 2017
Added following fixes:
Added boot type( BIOS or EFI) check for each virtual machine to determine if the virtual machine is compatible
or incompatible for the protection.
Added OS type information for each virtual machine in the Compatible VMs and Incompatible VMs worksheets.
The GetThroughput operation is now supported in the US Government and China Microsoft Azure regions.
Added few more prerequisite checks for vCenter and ESXi Server.
Incorrect report was getting generated when locale settings is set to non-English.
1.1
Updated: March 9, 2017
Fixed the following issues:
The tool cannot profile VMs if the vCenter has two or more VMs with the same name or IP address across
various ESXi hosts.
Copy and search is disabled for the Compatible VMs and Incompatible VMs worksheets.
1.0
Updated: February 23, 2017
Azure Site Recovery Deployment Planner public preview 1.0 has the following known issues (to be addressed in
upcoming updates):
The tool works only for VMware-to-Azure scenarios, not for Hyper-V-to-Azure deployments. For Hyper-V-toAzure scenarios, use the Hyper-V capacity planner tool.
The GetThroughput operation is not supported in the US Government and China Microsoft Azure regions.
The tool cannot profile VMs if the vCenter server has two or more VMs with the same name or IP address
across various ESXi hosts. In this version, the tool skips profiling for duplicate VM names or IP addresses in the
VMListFile. The workaround is to profile the VMs by using an ESXi host instead of the vCenter server. You must
run one instance for each ESXi host.
Plan capacity for protecting virtual machines and
physical servers in Azure Site Recovery
2/28/2017 • 7 min to read • Edit Online
The Azure Site Recovery Capacity Planner tool helps you to figure out your capacity requirements when
replicating Hyper-V VMs, VMware VMs, and Windows/Linux physical servers, with Azure Site Recovery.
Use the Site Recovery Capacity Planner to analyze your source environment and workloads, estimate bandwidth
needs and server resources you'll need for the source location, and the resources (virtual machines and storage
etc), that you need in the target location.
You can run the tool in a couple of modes:
Quick planning: Run the tool in this mode to get network and server projections based on an average
number of VMs, disks, storage, and change rate.
Detailed planning: Run the tool in this mode, and provide details of each workload at VM level. Analyze VM
compatibility and get network and server projections.
Before you start
1. Gather information about your environment, including VMs, disks per VM, storage per disk.
2. Identify your daily change (churn) rate for replicated data. To do this:
If you're replicating Hyper-V VMs, then download the Hyper-V capacity planning tool to get the change
rate. Learn more about this tool. We recommend you run this tool over a week to capture averages.
If you're replicating VMware virtual machines, use the Azure Site Recovery Deployment Planner to
figure out the churn rate.
If you're replicating physical servers, you need to estimate manually.
Run the Quick Planner
1. Download and open the Azure Site Recovery Capacity Planner tool. You need to run macros, so select to enable
editing and enable content when prompted.
2. In Select a planner type select Quick Planner from the list box.
3. In the Capacity Planner worksheet, enter the required information. You must fill in all the fields circled in
red in the screenshot below.
In Select your scenario, choose Hyper-V to Azure or VMware/Physical to Azure.
In Average daily data change rate (%), put in the information you gather using the Hyper-V capacity
planning tool or the Azure Site Recovery Deployment Planner.
Compression only applies to compression offered when replicating VMware VMs or physical servers to
Azure. We estimate 30% or more, but you can modify the setting as required. For replicating Hyper-V
VMs to Azure compression, you can use a third-party appliance such as Riverbed.
In Retention Inputs, specify how long replicas should be retained. If you're replicating VMware or
physical servers, input the value in days. If you're replicating Hyper-V, specify the time in hours.
In Number of hours in which initial replication for the batch of virtual machines should
complete and Number of virtual machines per initial replication batch, you input settings that
are used to compute initial replication requirements. When Site Recovery is deployed, the entire initial
data set should be uploaded.
4. After you've put in the values for the source environment, displayed output includes:
Bandwidth required for delta replication (MB/sec). Network bandwidth for delta replication is
calculated on the average daily data change rate.
Bandwidth required for initial replication (MB/sec). Network bandwidth for initial replication is
calculated on the initial replication values you put in.
Storage required (in GBs) is the total Azure storage required.
Total IOPS on standard storage accounts is calculated based on 8K IOPS unit size on the total
standard storage accounts. For the Quick Planner, the number is calculated based on all the source VMs
disks and daily data change rate. For the Detailed Planner, the number is calculated based on total
number of VMs that are mapped to standard Azure VMs, and data change rate on those VMs.
Number of standard storage accounts provides the total number of standard storage accounts
needed to protect the VMs. A standard storage account can hold up to 20000 IOPS across all the VMs in
a standard storage, and a maximum of 500 IOPS is supported per disk.
Number of blob disks required gives the number of disks that will be created on Azure storage.
Number of premium storage accounts required provides the total number of premium storage
accounts needed to protect the VMs. A source VM with high IOPS (greater than 20000) needs a
premium storage account. A premium storage account can hold up to 80000 IOPS.
Total IOPS on premium storage is calculated based on 256K IOPS unit size on the total premium
storage accounts. For the Quick Planner, the number is calculated based on all the source VMs disks and
daily data change rate. For the Detailed Planner, the number is calculated based on the total number of
VMs that are mapped to premium Azure VM (DS and GS series), and the data change rate on those VMs.
Number of configuration servers required shows how many configuration servers are required for
the deployment.
Number of additional process servers required shows whether additional process servers are
required, in addition to the process server that's running on the configuration server by default.
100% additional storage on the source shows whether additional storage is required in the source
location.
Run the Detailed Planner
1. Download and open the Azure Site Recovery Capacity Planner tool. You need to run macros, so select to enable
editing and enable content when prompted.
2. In Select a planner type, select Detailed Planner from the list box.
3. In the Workload Qualification worksheet, enter the required information. You must fill in all the marked
fields.
In Processor cores, specify the total number of cores on a source server.
In Memory allocation in MB, specify the RAM size of a source server.
The Number of NICs, specify the number of network adapters on a source server.
In Total storage (in GB), specify the total size of the VM storage. For example, if the source server has 3
disks with 500 GB each, then total storage size is 1500 GB.
In Number of disks attached, specify the total number of disks of a source server.
In Disk capacity utilization, specify the average utilization.
In Daily change rate (%), specify the daily data change rate of a source server.
In Mapping Azure size, enter the Azure VM size that you want to map. If you don't want to do this
manually, click Compute IaaS VMs.If you input a manual setting, and then click Compute IaaS VMs, the
manual setting might be overwritten because the compute process automatically identifies the best
match on Azure VM size.
4. If you click Compute IaaS VMs here's what it does:
Validates the mandatory inputs.
Calculates IOPS and suggests the best Azure VM aize match for each VMs that's eligible for replication
to Azure. If an appropriate size of Azure VM can't be detected an error is issued. For example, if the
number of disks attached in 65, an error is issued because the highest size Azure VM is 64.
Suggests a storage account that can be used for an Azure VM.
Calculates the total number of standard storage accounts and premium storage accounts required for
the workload. Scroll down to view the Azure storage type, and the storage account that can be used for
a source server.
Completes and sorts the rest of the table based on required storage type (standard or premium)
assigned for a VM, and the number of disks attached. For all VMs that meet the requirements for Azure,
the column Is VM qualified? shows Yes. If a VM can't be backed up to Azure, an error is shown.
Columns AA to AE are output, and provide information for each VM.
Example
As an example, for six VMs with the values shown in the table, the tool calculates and assigns the best Azure VM
match, and the Azure storage requirements.
In the example output, note the following:
The first column is a validation column for the VMs, disks and churn.
Two standard storage accounts and one premium storage account are needed for five VMs.
VM3 doesn't qualify for protection, because one or more disks are more than 1 TB.
VM1 and VM2 can use the first standard storage account
VM4 can use the second standard storage account.
VM5 and VM6 need a premium storage account, and can both use a single account.
NOTE
IOPS on standard and premium storage are calculated at the VM level, and not at disk level. A standard
virtual machine can handle up to 500 IOPS per disk. If IOPS for a disk are greater than 500, you need
premium storage. However, if IOPS for a disk are more than 500, but IOPS for the total VM disks are within
the support standard Azure VM limits (VM size, number of disks, number of adapters, CPU, memory), then
the planner picks a standard VM and not the DS or GS series. You need to manually update the mapping
Azure size cell with appropriate DS or GS series VM.
After all the details are in place, click Submit data to the planner tool to open the Capacity Planner Workloads
are highlighted, to show whether they're eligible for protection or not.
Submit data in the Capacity Planner
1. When you open the Capacity Planner worksheet it's populated based on the settings you've specified. The
word 'Workload' appears in the Infra inputs source cell, to show that the input is the Workload
Qualification worksheet.
2. If you want to make changes, you need to modify the Workload Qualification worksheet, and click
Submit data to the planner tool again.
Set up the source environment (VMware to Azure)
2/21/2017 • 6 min to read • Edit Online
This article describes how to set up your on-premises environment to start replicating virtual machines running on
VMware to Azure.
Prerequisites
The article assumes that you have already created:
A Recovery Services Vault in the Azure portal.
A dedicated account in your VMware vCenter that can be used for automatic discovery.
A virtual machine on which to install the configuration server.
Configuration server minimum requirements
The configuration server software should be deployed on a highly available VMware virtual machine. The following
table lists the minimum hardware, software, and network requirements for a configuration server.
HARDWARE
Number of CPU cores
8
RAM
12 GB
Number of disks
3
- OS disk
- Process server cache disk
- Retention drive (for failback)
Disk free space (process server cache)
600 GB
Disk free space (retention disk)
600 GB
Software
Operating system version
Windows Server 2012 R2
Operating system locale
English (en-us)
VMware vSphere PowerCLI version
PowerCLI 6.0
Windows Server roles
Do not enable the following roles:
- Active Directory Domain Services
- Internet Information Services
- Hyper-V
Network
HARDWARE
Network interface card type
VMXNET3
IP address type
Static
Internet access
The server should be able to access the following URLs either
directly or through a proxy server:
- *.accesscontrol.windows.net
- *.backup.windowsazure.com
- *.store.core.windows.net
- *.blob.core.windows.net
- *.hypervrecoverymanager.windowsazure.com
- https://cdn.mysql.com/archives/mysql-5.5/mysql-5.5.37win32.msi (not required for Scale-out Process Servers)
- time.nist.gov
- time.windows.com
Ports
443 (Control channel orchestration)
9443 (Data transport)
NOTE
HTTPS-based proxy servers are not supported by the configuration server.
Choose your protection goals
1. In the Azure portal, go to the Recovery Services vault blade and select your vault.
2. On the resource menu of the vault, go to Getting Started > Site Recovery > Step 1: Prepare
Infrastructure > Protection goal.
3. In Protection goal, select To Azure, and choose Yes, with VMware vSphere Hypervisor. Then click OK.
Set up the source environment
Setting up the source environment involves two main activities:
Install and register a configuration server with Site Recovery.
Discover your on-premises virtual machines by connecting Site Recovery to your on-premises VMware vCenter
or vSphere EXSi hosts.
Step 1: Install and register a configuration server
1. Click Step 1: Prepare Infrastructure > Source. In Prepare source, if you don’t have a configuration
server, click +Configuration server to add one.
2. On the Add Server blade, check that Configuration Server appears in Server type.
3. Download the Site Recovery Unified Setup installation file.
4. Download the vault registration key. You need the registration key when you run Unified Setup. The key is
valid for five days after you generate it.
5. On the machine you’re using as the configuration server, run Azure Site Recovery Unified Setup to install
the configuration server, the process server, and the master target server.
Run Azure Site Recovery Unified Setup
TIP
Configuration server registration fails if the time on your computer's system clock differs from local time by more than five
minutes. Synchronize your system clock with a Time Server before starting the installation.
1. Run the Unified Setup installation file.
2. In Before you begin, select Install the configuration server and process server.
3. In Third Party Software License, click I Accept to download and install MySQL.
4. In Registration, select the registration key you downloaded from the vault.
5. In Internet Settings, specify how the Provider running on the configuration server connects to Azure Site
Recovery over the Internet.
If you want to connect with the proxy that's currently set up on the machine, select Connect with
existing proxy settings.
If you want the Provider to connect directly, select Connect directly without a proxy.
If the existing proxy requires authentication, or if you want to use a custom proxy for the Provider
connection, select Connect with custom proxy settings.
If you use a custom proxy, you need to specify the address, port, and credentials.
If you're using a proxy, you should have already allowed the URLs described in prerequisites.
6. In Prerequisites Check, Setup runs a check to make sure that installation can run. If a warning appears
about the Global time sync check, verify that the time on the system clock (Date and Time settings) is the
same as the time zone.
7. In MySQL Configuration, create credentials for logging on to the MySQL server instance that is installed.
8. In Environment Details, select whether you're going to replicate VMware VMs. If you are, then setup
checks that PowerCLI 6.0 is installed.
9. In Install Location, select where you want to install the binaries and store the cache. The drive you select
must have at least 5 GB of disk space available, but we recommend a cache drive with at least 600 GB of free
space.
10. In Network Selection, specify the listener (network adapter and SSL port) on which the configuration
server sends and receives replication data. Port 9443 is the default port used for sending and receiving
replication traffic, but you can modify this port number to suit your environment's requirements. In addition
to the port 9443, we also open port 443, which is used by a web server to orchestrate replication operations.
Do not use Port 443 for sending or receiving replication traffic.
11. In Summary, review the information and click Install. When installation finishes, a passphrase is generated.
You will need this when you enable replication, so copy it and keep it in a secure location.
After registration finishes, the server is displayed on the Settings > Servers blade in the vault.
NOTE
The configuration server can be installed via command line. For more information, see Installing the configuration server
using Command-line tools.
Add the VMware account for automatic discovery
1. On your configuration server, launch CSPSConfigtool.exe. It is available as a shortcut on the desktop and
located in the install location\home\svsystems\bin folder.
2. Click Manage Accounts > Add Account.
3. In Account Details, add the account that will be used for automatic discovery.
NOTE
It can take 15 minutes or more for the account name to appear in the portal. To update immediately, click
Configuration Servers > server name > Refresh Server.
Step 2: Add a vCenter
To allow Azure Site Recovery to discover virtual machines running in your on-premises environment, you need to
connect your VMware vCenter Server or vSphere ESXi hosts with Site Recovery.
Select +vCenter to start connecting a VMware vCenter server or a VMware vSphere ESXi host.
In Add vCenter, specify a friendly name for the vSphere host or vCenter server, and then specify the IP
address or FQDN of the server. Leave the port as 443 unless your VMware servers are configured to listen
for requests on a different port. Select the account that is to connect to the VMware vCenter or vSphere ESXi
server. Click OK.
NOTE
If you're adding the VMware vCenter server or VMware vSphere host with an account that doesn't have
administrator privileges on the vCenter or host server, make sure that the account has these privileges enabled:
Datacenter, Datastore, Folder, Host, Network, Resource, Virtual machine, and vSphere Distributed Switch. In addition,
the VMware vCenter server needs the Storage views privilege enabled.
Common issues
Installation failures
SAMPLE ERROR MESSAGE
RECOMMENDED ACTION
ERROR Failed to load Accounts. Error: System.IO.IOException:
Unable to read data from the transport connection when
installing and registering the CS server.
Ensure that TLS 1.0 is enabled on the computer.
Registration failures
Registration failures can be debugged by reviewing the logs in the %ProgramData%\ASRLogs folder.
SAMPLE ERROR MESSAGE
RECOMMENDED ACTION
09:20:06:InnerException.Type:
SrsRestApiClientLib.AcsException,InnerException.
Message: ACS50008: SAML token is invalid.
Trace ID: 1921ea5b-4723-4be7-8087-a75d3f9e1072
Correlation ID: 62fea7e6-2197-4be4-a2c0-71ceb7aa2d97>
Timestamp: 2016-12-12 14:50:08Z
Ensure that the time on your system clock is not more than
15 minutes off the local time. Rerun the installer to complete
the registration.
09:35:27 :DRRegistrationException while trying to get all
disaster recovery vault for the selected certificate: : Threw
Exception.Type:Microsoft.DisasterRecovery.Registration.DRRegi
strationException, Exception.Message: ACS50008: SAML token
is invalid.
Trace ID: e5ad1af1-2d39-4970-8eef-096e325c9950
Correlation ID: abe9deb8-3e64-464d-8375-36db9816427a
Timestamp: 2016-05-19 01:35:39Z
Ensure that the time on your system clock is not more than
15 minutes off the local time. Rerun the installer to complete
the registration.
06:28:45:Failed to create certificate
06:28:45:Setup cannot proceed. A certificate required to
authenticate to Site Recovery cannot be created. Rerun Setup
Ensure you are running setup as a local administrator.
Next steps
Set up your target environment in Azure.
Prepare target (VMware to Azure)
2/13/2017 • 1 min to read • Edit Online
This article describes how to prepare your Azure environment to start replicating VMware virtual machines to
Azure.
Prerequisites
The article assumes the following:
You have created a Recovery Services Vault to protect your VMware virtual machines. You can create a
Recovery Services Vault from the Azure portal.
You have setup your on-premises environment to replicate VMware virtual machines to Azure.
Prepare target
After completing the Step 1:Select Protection goal and Step 2:Prepare Source, you are taken to Step 3: Target
1. Subscription: From the drop down menu, select the Subscription that you want to replicate your virtual
machines to.
2. Deployment Model: Select the deployment model (Classic or Resource Manager)
Based on the chosen deployment model, a validation is run to ensure that you have at least one compatible
storage account and virtual network in the target subscription to replicate and failover your virtual machine to.
Once the validations complete successfully, click OK to go to the next step.
If you don't have a compatible Resource Manager storage account or virtual network, or would like to add more,
you can do so by clicking the + Storage Account or + Network buttons on the top of the blade.
Next steps
Configure replication settings.
Manage replication policy for VMware to Azure
2/21/2017 • 1 min to read • Edit Online
Create a replication policy
1. Select Manage > Site Recovery Infrastructure.
2. Select Replication policies under For VMware and Physical machines.
3. Select +Replication policy.
4. Enter the policy name.
5. In RPO threshold, specify the RPO limit. Alerts will be generated when continuous replication exceeds this
limit.
6. In Recovery point retention, specify (in hours) the duration of the retention window for each recovery
point. Protected machines can be recovered to any point within a retention window.
NOTE
Up to 24 hours of retention is supported for machines replicated to premium storage. Up to 72 hours of retention is
supported for machines replicated to standard storage.
NOTE
A replication policy for failback is automatically created.
7. In App-consistent snapshot frequency, specify how often (in minutes) recovery points that contain
application-consistent snapshots will be created.
8. Click OK. The policy should be created in 30 to 60 seconds.
Associate a configuration server with a replication policy
1. Choose the replication policy to which you want to associate the configuration server.
2. Click Associate.
3. Select the configuration server from the list of servers.
4. Click OK. The configuration server should be associated in one to two minutes.
Edit a replication policy
1. Choose the replication policy for which you want to edit replication settings.
2. Click Edit Settings.
3. Change the settings based on your need.
4. Click Save. The policy should be saved in two to five minutes, depending on how many VMs are using that
replication policy.
Dissociate a configuration server from a replication policy
1.
2.
3.
4.
Choose the replication policy to which you want to associate the configuration server.
Click Dissociate.
Select the configuration server from the list of servers.
Click OK. The configuration server should be dissociated in one to two minutes.
NOTE
You cannot dissociate a configuration server if there is at least one replicated item using the policy. Make sure there
are no replicated items using the policy before you dissociate the configuration server.
Delete a replication policy
1. Choose the replication policy that you want to delete.
2. Click Delete. The policy should be deleted in 30 to 60 seconds.
NOTE
You cannot delete a replication policy if it has at least one configuration server associated to it. Make sure there are
no replicated items using the policy and delete all the associated configuration servers before you delete the policy.
Install Mobility Service (VMware or physical to Azure)
3/30/2017 • 6 min to read • Edit Online
Azure Site Recovery Mobility Service captures data writes on a computer, and then forwards them to the process
server. Deploy Mobility Service to every computer (VMware VM or physical server) that you want to replicate to
Azure. You can deploy Mobility Service to the servers that you want to protect by using the following methods:
Install Mobility Service by using software deployment tools like System Center Configuration Manager
Install Mobility Service by using Azure Automation and Desired State Configuration (Automation DSC)
Install Mobility Service manually by using the graphical user interface (GUI)
Install Mobility Service manually at a command prompt
Install Mobility Service by push installation from Azure Site Recovery
IMPORTANT
Beginning with version 9.7.0.0, on Windows virtual machines (VMs), the Mobility Service installer also installs the latest
available Azure VM agent. When a computer fails over to Azure, the computer meets the agent installation prerequisite for
using any VM extension.
Prerequisites
Complete these prerequisite steps before you manually install Mobility Service on your server:
1. Sign in to your configuration server, and then open a Command Prompt window as an administrator.
2. Change the directory to the bin folder, and then create a passphrase file:
cd %ProgramData%\ASR\home\svsystems\bin
genpassphrase.exe -v > MobSvc.passphrase
3. Store the passphrase file in a secure location. You use the file during the Mobility Service installation.
4. Mobility Service installers for all supported operating systems are in the
%ProgramData%\ASR\home\svsystems\pushinstallsvc\repository folder.
Mobility Service installer-to -operating system mapping
INSTALLER FILE TEMPLATE NAME
OPERATING SYSTEM
Microsoft-ASR_UA*Windows*release.exe
Windows Server 2008 R2 SP1 (64-bit)
Windows Server 2012 (64-bit)
Windows Server 2012 R2 (64-bit)
Microsoft-ASR_UA*RHEL6-64*release.tar.gz
Red Hat Enterprise Linux (RHEL) 6.4, 6.5, 6.6, 6.7, 6.8 (64-bit
only)
CentOS 6.4, 6.5, 6.6, 6.7, 6.8 (64-bit only)
Microsoft-ASR_UA*SLES11-SP3-64*release.tar.gz
SUSE Linux Enterprise Server 11 SP3 (64-bit only)
Microsoft-ASR_UA*OL6-64*release.tar.gz
Oracle Enterprise Linux 6.4, 6.5 (64-bit only)
Install Mobility Service manually by using the GUI
NOTE
The GUI-based installation works only with Windows operating systems.
1. Copy the installation to the server, and then open the installer.
2. On the Before You Begin blade, select Install Mobility Service.
3. On the Configuration Server Details blade, enter the IP address and passphrase of the configuration
server.
4. On the Install Location blade, keep the default settings, and then select Next to begin the installation.
5. On the Installation Progress blade, monitor the installation. If prompted, restart the computer. After the
service is installed, it can take about 15 minutes for the status to update in the Azure portal.
Install Mobility Service manually at a command prompt
Command-line installation on a Windows computer
1. Copy the installer to a local folder (for example, C:\Temp) on the server that you want to protect. Run the
following commands as an administrator at a command prompt:
cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted.
2. To install Mobility Service, run the following command:
UnifiedAgent.exe /Role "Agent" /CSEndpoint "IP address of the configuration server" /PassphraseFilePath
<Full path to the passphrase file>``
Mobility Service installer command-line arguments
Usage :
UnifiedAgent.exe [/Role <Agent/MasterTarget>] [/InstallLocation <Installation directory>] [/CSIP <IP address>]
[/PassphraseFilePath <Passphrase file path>] [/LogFilePath <Log file path>]<br/>
PARAMETER
TYPE
DESCRIPTION
POSSIBLE VALUES
/Role
Mandatory
Specifies whether Mobility
Service should be installed
Agent
MasterTarget
/InstallLocation
Mandatory
Location where Mobility
Service is installed
Any folder on the computer
/CSIP
Mandatory
IP address of the
configuration server
Any valid IP address
/PassphraseFilePath
Mandatory
Location of the passphrase
Any valid UNC or local file
path
/LogFilePath
Optional
Location of the installation
log
Any valid folder on the
computer
Example
UnifiedAgent.exe /Role "Agent" /CSEndpoint "I192.168.2.35" /PassphraseFilePath "C:\Temp\MobSvc.passphrase"
Command-line installation on a Linux computer
1. Copy the installer to a local folder (for example, /tmp) on the server that you want to protect. In a terminal, run
the following commands: cd /tmp tar -xvzf Microsoft-ASR_UA*release.tar.gz
2. To install Mobility Service, run the following command:
sudo ./install -t both -a host -R Agent -d /usr/local/ASR -i <IP address> -p <port> -s y -c https -P
MobSvc.passphrase
Mobility Service installer command-line arguments
PARAMETER
TYPE
DESCRIPTION
POSSIBLE VALUES
-t
Mandatory
Agent type
(deprecated in an upcoming
release)
both
-a
Mandatory
Agent configuration
(deprecated in an upcoming
release)
host
-R
Optional
Role of the agent
Agent
MasterTarget
-d
Optional
Location where Mobility
Service will be installed
/usr/local/ASR
-i
Mandatory
IP address of the
configuration server
Any valid IP address
-p
Mandatory
Port on which the
configuration server listens
for incoming connections
443
-s
Mandatory
Starts the service after a
successful installation
(deprecated in an upcoming
release)
y
-c
Mandatory
Communication mode
between the agent and
process server
(deprecated in an upcoming
release)
https
-P
Mandatory
Configuration server
passphrase
Any valid UNC or local file
path
Example
sudo ./install -t both -a host -R Agent -d /usr/local/ASR -i 192.168.2.53 -p 443 -s y -c https -P
/tmp/MobSvc.passphrase
Install Mobility Service by push installation from Azure Site Recovery
To do a push installation of Mobility Service by using Site Recovery, all target computers must meet the following
prerequisites.
Prepare for a push installation on a Windows computer
1. Ensure that there’s network connectivity between the Windows computer and the process server.
2. Create an account that the process server can use to access the computer. The account should have
administrator rights (local or domain). (Use this account only for the push installation and for agent
updates.)
NOTE
If you're not using a domain account, disable Remote User Access control on the local computer. To disable Remote
User Access control, under the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System registry key, add a new
DWORD: LocalAccountTokenFilterPolicy. Set the value to 1. To do this at a command prompt, run the following
command:
REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v
LocalAccountTokenFilterPolicy /t REG_DWORD /d 1
3. In Windows Firewall on the computer you want to protect, select Allow an app or feature through
Firewall. Enable File and Printer Sharing and Windows Management Instrumentation (WMI). For
computers that belong to a domain, you can configure the firewall settings by using a Group Policy object
(GPO).
4. Add the account that you created in CSPSConfigtool.
a. Sign in to your configuration server.
b. Open cspsconfigtool.exe. (It's available as a shortcut on the desktop and in the
%ProgramData%\home\svsystems\bin folder.)
c. On the Manage Accounts tab, select Add Account.
d. Add the account you created.
e. Enter the credentials you use when you enable replication for a computer.
Prepare for a push installation on a Linux server
1. Ensure that there’s network connectivity between the Linux computer and the process server.
2. Create an account that the process server can use to access the computer. The account should be a root user on
the source Linux server. (Use this account only for the push installation and for updates.)
3. Check that the /etc/hosts file on the source Linux server has entries that map the local hostname to IP addresses
associated with all network adapters.
4. Install the latest openssh, openssh-server, and openssl packages on the computer that you want to replicate.
5. Ensure that Secure Shell (SSH) is enabled and running on port 22.
6. Enable SFTP subsystem and password authentication in the sshd_config file:
a.
b.
c.
d.
Sign in as root.
In the file /etc/ssh/sshd_config file, find the line that begins with PasswordAuthentication.
Uncomment the line and change the value to yes.
Find the line that begins with Subsystem and uncomment the line.
7. Add the account that you created in CSPSConfigtool.
a. Sign in to your configuration server.
b. Open cspsconfigtool.exe. (It's available as a shortcut on the desktop and in the
%ProgramData%\home\svsystems\bin folder.)
c. On the Manage Accounts tab, click Add Account.
d. Add the account you created.
e. Enter the credentials you use when you enable replication for a computer.
NOTE
After Mobility Service is installed, in the Azure portal, select the Replicate button to start protecting these VMs.
Uninstall Mobility Service on a Windows Server computer
Use one of the following methods to uninstall Mobility Service on a Windows Server computer.
Uninstall by using the GUI
1. In Control Panel, select Programs.
2. Select Microsoft Azure Site Recovery Mobility Service/Master Target server, and then select Uninstall.
Uninstall at a command prompt
1. Open a Command Prompt window as an administrator.
2. To uninstall Mobility Service, run the following command:
MsiExec.exe /qn /x {275197FC-14FD-4560-A5EB-38217F80CBD1} /L+*V
"C:\ProgramData\ASRSetupLogs\UnifiedAgentMSIUninstall.log"
Uninstall Mobility Service on a Linux computer
1. On your Linux server, sign in as a root user.
2. In a terminal, go to /user/local/ASR.
3. To uninstall Mobility Service, run the following command:
uninstall.sh -Y
Automate Mobility Service installation by using
software deployment tools
4/3/2017 • 8 min to read • Edit Online
This article provides you an example of how you can use System Center Configuration Manager to deploy the
Azure Site Recovery Mobility Service in your datacenter. Using a software deployment tool like Configuration
Manager has the following advantages:
Scheduling deployment of fresh installations and upgrades, during your planned maintenance window for
software updates
Scaling deployment to hundreds of servers simultaneously
NOTE
This article uses System Center Configuration Manager 2012 R2 to demonstrate the deployment activity. You could also
automate Mobility Service installation by using Azure Automation and Desired State Configuration.
Prerequisites
1. A software deployment tool, like Configuration Manager, that is already deployed in your environment. Create
two device collections, one for all Windows servers, and another for all Linux servers, that you want to protect
by using Site Recovery.
2. A configuration server that is already registered with Site Recovery.
3. A secure network file share (Server Message Block share) that can be accessed by the Configuration Manager
server.
Deploy Mobility Service on computers running Windows
NOTE
This article assumes that the IP address of the configuration server is 192.168.3.121, and that the secure network file share is
\\ContosoSecureFS\MobilityServiceInstallers.
Step 1: Prepare for deployment
1. Create a folder on the network share, and name it MobSvcWindows.
2. Sign in to your configuration server, and open an administrative command prompt.
3. Run the following commands to generate a passphrase file:
cd %ProgramData%\ASR\home\svsystems\bin
genpassphrase.exe -v > MobSvc.passphrase
4. Copy the MobSvc.passphrase file into the MobSvcWindows folder on your network share.
5. Browse to the installer repository on the configuration server by running the following command:
cd %ProgramData%\ASR\home\svsystems\puhsinstallsvc\repository
6. Copy the Microsoft-ASR_UA_version_Windows_GA_date_Release.exe to the MobSvcWindows folder
on your network share.
7. Copy the following code, and save it as install.bat into the MobSvcWindows folder.
NOTE
Replace the [CSIP] placeholders in this script with the actual values of the IP address of your configuration server.
Time /t >> C:\Temp\logfile.log
REM ==================================================
REM ==== Clean up the folders ========================
RMDIR /S /q %temp%\MobSvc
MKDIR %Temp%\MobSvc
REM ==================================================
REM ==== Copy new files ==============================
COPY M*.* %Temp%\MobSvc
CD %Temp%\MobSvc
REN Micro*.exe MobSvcInstaller.exe
REM ==================================================
REM ==== Extract the installer =======================
MobSvcInstaller.exe /q /x:%Temp%\MobSvc\Extracted
REM ==== Wait 10s for extraction to complete =========
TIMEOUT /t 10
REM =================================================
REM ==== Extract the installer ======================
CD %Temp%\MobSvc\Extracted
REM ==================================================
REM ==== Check if Mob Svc is already installed =======
REM ==== If not installed run install command ========
REM ==== Else run upgrade command =====================
REM ==== {275197FC-14FD-4560-A5EB-38217F80CBD1} is ====
REM ==== guid for Mob Svc Installer ====================
whoami >> C:\temp\logfile.log
REM SET PRODKEY=HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
REM REG QUERY %PRODKEY%\{275197FC-14FD-4560-A5EB-38217F80CBD1} >> C:\Temp\logfile.log 2>&1
REM REG QUERY %PRODKEY%\{275197FC-14FD-4560-A5EB-38217F80CBD1}
REM IF NOT %ERRORLEVEL% EQU 0 (GOTO :INSTALL) ELSE GOTO :UPDATE
NET START | FIND "InMage Scout Application Service"
IF %ERRORLEVEL% EQU 1 (GOTO :INSTALL) ELSE GOTO :UPDATE
:INSTALL
echo "Install" >> c:\Temp\logfile.log
UnifiedAgent.exe /Role "Agent" /CSEndpoint "10.10.20.168" /PassphraseFilePath
%Temp%\MobSvc\MobSvc.passphrase
GOTO :ENDSCRIPT
:UPDATE
echo "Update" >> C:\Temp\logfile.log
UnifiedAgent.exe /upgrade
:ENDSCRIPT
Step 2: Create a package
1. Sign in to your Configuration Manager console.
2. Browse to Software Library > Application Management > Packages.
3. Right-click Packages, and select Create Package.
4. Provide values for the name, description, manufacturer, language, and version.
5. Select the This package contains source files check box.
6. Click Browse, and select the network share where the installer is stored
(\\ContosoSecureFS\MobilityServiceInstaller\MobSvcWindows).
7. On the Choose the program type that you want to create page, select Standard Program, and click
Next.
8. On the Specify information about this standard program page, provide the following inputs, and click
Next. (The other inputs can use their default values.)
PARAMETER NAME
VALUE
Name
Install Microsoft Azure Mobility Service (Windows)
Command line
install.bat
Program can run
Whether or not a user is logged on
9. On the next page, select the target operating systems. Mobility Service can be installed only on Windows
Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2.
10. To complete the wizard, click Next twice.
NOTE
The script supports both new installations of Mobility Service agents and updates to agents that are already installed.
Step 3: Deploy the package
1. In the Configuration Manager console, right-click your package, and select Distribute Content.
2. Select the distribution points on to which the packages should be copied.
3. Complete the wizard. The package then starts replicating to the specified distribution points.
4. After the package distribution is done, right-click the package, and select Deploy.
5. Select the Windows Server device collection you created in the prerequisites section as the target collection
for deployment.
6. On the Specify the content destination page, select your Distribution Points.
7. On the Specify settings to control how this software is deployed page, ensure that the purpose is
Required.
8. On the Specify the schedule for this deployment page, specify a schedule. For more information, see
scheduling packages.
9. On the Distribution Points page, configure the properties according to the needs of your datacenter. Then
complete the wizard.
TIP
To avoid unnecessary reboots, schedule the package installation during your monthly maintenance window or software
updates window.
You can monitor the deployment progress by using the Configuration Manager console. Go to Monitoring >
Deployments > [your package name].
Deploy Mobility Service on computers running Linux
NOTE
This article assumes that the IP address of the configuration server is 192.168.3.121, and that the secure network file share is
\\ContosoSecureFS\MobilityServiceInstallers.
Step 1: Prepare for deployment
1. Create a folder on the network share, and name it as MobSvcLinux.
2. Sign in to your configuration server, and open an administrative command prompt.
3. Run the following commands to generate a passphrase file:
cd %ProgramData%\ASR\home\svsystems\bin
genpassphrase.exe -v > MobSvc.passphrase
4. Copy the MobSvc.passphrase file into the MobSvcLinux folder on your network share.
5. Browse to the installer repository on the configuration server by running the command:
cd %ProgramData%\ASR\home\svsystems\puhsinstallsvc\repository
6. Copy the following files to the MobSvcLinux folder on your network share:
Microsoft-ASR_UA_version_OEL-64_GA_date_Release.tar.gz
Microsoft-ASR_UA_version_RHEL6-64_GA_date_Release.tar.gz
Microsoft-ASR_UA_version_RHEL7-64_GA_date_Release.tar.gz
Microsoft-ASR_UA_version_SLES11-SP3-64_GA_date_Release.tar.gz
7. Copy the following code, and save it as install_linux.sh into the MobSvcLinux folder.
NOTE
Replace the [CSIP] placeholders in this script with the actual values of the IP address of your configuration server.
#!/bin/sh
rm -rf /tmp/MobSvc
mkdir -p /tmp/MobSvc
if [ -f /etc/oracle-release ] && [ -f /etc/redhat-release ]; then
if grep -q 'Oracle Linux Server release 6.*' /etc/oracle-release; then
if uname -a | grep -q x86_64; then
OS="OL6-64"
cp *OL6*.tar.gz /tmp/MobSvc
fi
fi
elif [ -f /etc/redhat-release ]; then
if grep -q 'Red Hat Enterprise Linux Server release 6.* (Santiago)' /etc/redhat-release || \
grep -q 'CentOS Linux release 6.* (Final)' /etc/redhat-release || \
grep -q 'CentOS release 6.* (Final)' /etc/redhat-release; then
if uname -a | grep -q x86_64; then
OS="RHEL6-64"
cp *RHEL6*.tar.gz /tmp/MobSvc
fi
elif grep -q 'Red Hat Enterprise Linux Server release 7.* (Maipo)' /etc/redhat-release || \
grep -q 'CentOS Linux release 7.* (Core)' /etc/redhat-release; then
if uname -a | grep -q x86_64; then
OS="RHEL7-64"
cp *RHEL7*.tar.gz /tmp/MobSvc
fi
fi
elif [ -f /etc/SuSE-release ] && grep -q 'VERSION = 11' /etc/SuSE-release; then
if grep -q "SUSE Linux Enterprise Server 11" /etc/SuSE-release && grep -q 'PATCHLEVEL = 3' /etc/SuSErelease; then
if uname -a | grep -q x86_64; then
OS="SLES11-SP3-64"
echo $OS >> /tmp/MobSvc/sccm.log
cp *SLES11*.tar.gz /tmp/MobSvc
fi
fi
elif [ -f /etc/lsb-release ] ; then
if grep -q 'DISTRIB_RELEASE=14.04' /etc/lsb-release ; then
if uname -a | grep -q x86_64; then
OS="UBUNTU-14.04-64"
cp *UBUNTU*.tar.gz /tmp/MobSvc
fi
fi
else
exit 1
fi
if [ "${OS}" == "" ]; then
exit 1
fi
cp MobSvc.passphrase /tmp/MobSvc
cd /tmp/MobSvc
tar -zxvf *.tar.gz
if [ -e /usr/local/.vx_version ];
then
./install -A u
echo "Errorcode:$?"
Error=$?
else
./install -t both -a host -R Agent -d /usr/local/ASR -i [CS IP] -p 443 -s y -c https -P MobSvc.passphrase
>> /tmp/MobSvc/sccm.log 2>&1 && echo "Install Progress"
Error=$?
fi
cd /tmp
rm -rf /tm/MobSvc
exit ${Error}
Step 2: Create a package
1. Sign in to your Configuration Manager console.
2. Browse to Software Library > Application Management > Packages.
3. Right-click Packages, and select Create Package.
4. Provide values for the name, description, manufacturer, language, and version.
5. Select the This package contains source files check box.
6. Click Browse, and select the network share where the installer is stored
(\\ContosoSecureFS\MobilityServiceInstaller\MobSvcLinux).
7. On the Choose the program type that you want to create page, select Standard Program, and click
Next.
8. On the Specify information about this standard program page, provide the following inputs, and click
Next. (The other inputs can use their default values.)
PARAMETER NAME
VALUE
Name
Install Microsoft Azure Mobility Service (Linux)
Command line
./install_linux.sh
Program can run
Whether or not a user is logged on
9. On the next page, select This program can run on any platform.
10. To complete the wizard, click Next twice.
NOTE
The script supports both new installations of Mobility Service agents and updates to agents that are already installed.
Step 3: Deploy the package
1. In the Configuration Manager console, right-click your package, and select Distribute Content.
2. Select the distribution points on to which the packages should be copied.
3. Complete the wizard. The package then starts replicating to the specified distribution points.
4. After the package distribution is done, right-click the package, and select Deploy.
5. Select the Linux Server device collection you created in the prerequisites section as the target collection for
deployment.
6. On the Specify the content destination page, select your Distribution Points.
7. On the Specify settings to control how this software is deployed page, ensure that the purpose is
Required.
8. On the Specify the schedule for this deployment page, specify a schedule. For more information, see
scheduling packages.
9. On the Distribution Points page, configure the properties according to the needs of your datacenter. Then
complete the wizard.
Mobility Service gets installed on the Linux Server Device Collection, according to the schedule you configured.
Other methods to install Mobility Service
Here are some other options for installing Mobility Service:
Manual Installation using GUI
Manual Installation using command-line
Push Installation using configuration server
Automated Installation using Azure Automation & Desired State Configuration
Uninstall Mobility Service
You can create Configuration Manager packages to uninstall Mobility Service. Use the following script to do so:
Time /t >> C:\logfile.log
REM ==================================================
REM ==== Check if Mob Svc is already installed =======
REM ==== If not installed no operation required ========
REM ==== Else run uninstall command =====================
REM ==== {275197FC-14FD-4560-A5EB-38217F80CBD1} is ====
REM ==== guid for Mob Svc Installer ====================
whoami >> C:\logfile.log
NET START | FIND "InMage Scout Application Service"
IF %ERRORLEVEL% EQU 1 (GOTO :INSTALL) ELSE GOTO :UNINSTALL
:NOOPERATION
echo "No Operation Required." >> c:\logfile.log
GOTO :ENDSCRIPT
:UNINSTALL
echo "Uninstall" >> C:\logfile.log
MsiExec.exe /qn /x {275197FC-14FD-4560-A5EB-38217F80CBD1} /L+*V
"C:\ProgramData\ASRSetupLogs\UnifiedAgentMSIUninstall.log"
:ENDSCRIPT
Next steps
You are now ready to enable protection for your virtual machines.
Deploy the Mobility service with Azure Automation
DSC for replication of VM
2/22/2017 • 13 min to read • Edit Online
In Operations Management Suite, we provide you with a comprehensive backup and disaster recovery solution
that you can use as part of your business continuity plan.
We started this journey together with Hyper-V by using Hyper-V Replica. But we have expanded to support a
heterogeneous setup because customers have multiple hypervisors and platforms in their clouds.
If you are running VMware workloads and/or physical servers today, a management server runs all of the Azure
Site Recovery components in your environment to handle the communication and data replication with Azure,
when Azure is your destination.
Deploy the Site Recovery Mobility service by using Automation DSC
Let's start by doing a quick breakdown of what this management server does.
The management server runs several server roles. One of these roles is configuration, which coordinates
communication and manages data replication and recovery processes.
In addition, the process role acts as a replication gateway. This role receives replication data from protected source
machines, optimizes it with caching, compression, and encryption, and then sends it to an Azure storage account.
One of the functions for the process role is also to push installation of the Mobility service to protected machines
and perform automatic discovery of VMware VMs.
If there's a failback from Azure, the master target role will handle the replication data as part of this operation.
For the protected machines, we rely on the Mobility service. This component is deployed to every machine
(VMware VM or physical server) that you want to replicate to Azure. It captures data writes on the machine and
forwards them to the management server (process role).
When you're dealing with business continuity, it's important to understand your workloads, your infrastructure,
and the components involved. You can then meet the requirements for your recovery time objective (RTO) and
recovery point objective (RPO). In this context, the Mobility service is key to ensuring that your workloads are
protected as you would expect.
So how can you, in an optimized way, ensure that you have a reliable protected setup with help from some
Operations Management Suite components?
This article provides an example of how you can use Azure Automation Desired State Configuration (DSC), together
with Site Recovery, to ensure that:
The Mobility service and Azure VM agent are deployed to the Windows machines that you want to protect.
The Mobility service and Azure VM agent are always running when Azure is the replication target.
Prerequisites
A repository to store the required setup
A repository to store the required passphrase to register with the management server
NOTE
A unique passphrase is generated for each management server. If you are going to deploy multiple management
servers, you have to ensure that the correct passphrase is stored in the passphrase.txt file.
Windows Management Framework (WMF) 5.0 installed on the machines that you want to enable for
protection (a requirement for Automation DSC)
NOTE
If you want to use DSC for Windows machines that have WMF 4.0 installed, see the section Use DSC in disconnected
environments.
The Mobility service can be installed through the command line and accepts several arguments. That’s why you
need to have the binaries (after extracting them from your setup) and store them in a place where you can retrieve
them by using a DSC configuration.
Step 1: Extract binaries
1. To extract the files that you need for this setup, browse to the following directory on your management
server:
\Microsoft Azure Site Recovery\home\svsystems\pushinstallsvc\repository
In this folder, you should see an MSI file named:
Microsoft-ASR_UA_version_Windows_GA_date_Release.exe
Use the following command to extract the installer:
.\Microsoft-ASR_UA_9.1.0.0_Windows_GA_02May2016_release.exe /q
/x:C:\Users\Administrator\Desktop\Mobility_Service\Extract
2. Select all files and send them to a compressed (zipped) folder.
You now have the binaries that you need to automate the setup of the Mobility service by using Automation DSC.
Passphrase
Next, you need to determine where you want to place this zipped folder. You can use an Azure storage account, as
shown later, to store the passphrase that you need for the setup. The agent will then register with the management
server as part of the process.
The passphrase that you got when you deployed the management server can be saved to a text file as
passphrase.txt.
Place both the zipped folder and the passphrase in a dedicated container in the Azure storage account.
If you prefer to keep these files on a share on your network, you can do so. You just need to ensure that the DSC
resource that you will be using later has access and can get the setup and passphrase.
Step 2: Create the DSC configuration
The setup depends on WMF 5.0. For the machine to successfully apply the configuration through Automation DSC,
WMF 5.0 needs to be present.
The environment uses the following example DSC configuration:
configuration ASRMobilityService {
$RemoteFile = 'https://knrecstor01.blob.core.windows.net/asr/ASR.zip'
$RemotePassphrase = 'https://knrecstor01.blob.core.windows.net/asr/passphrase.txt'
$RemoteAzureAgent = 'http://go.microsoft.com/fwlink/p/?LinkId=394789'
$LocalAzureAgent = 'C:\Temp\AzureVmAgent.msi'
$TempDestination = 'C:\Temp\asr.zip'
$LocalPassphrase = 'C:\Temp\Mobility_service\passphrase.txt'
$Role = 'Agent'
$Install = 'C:\Program Files (x86)\Microsoft Azure Site Recovery'
$CSEndpoint = '10.0.0.115'
$Arguments = '/Role "{0}" /InstallLocation "{1}" /CSEndpoint "{2}" /PassphraseFilePath "{3}"' -f
$Role,$Install,$CSEndpoint,$LocalPassphrase
Import-DscResource -ModuleName xPSDesiredStateConfiguration
node localhost {
File Directory {
DestinationPath = 'C:\Temp\ASRSetup\'
Type = 'Directory'
}
xRemoteFile Setup {
URI = $RemoteFile
DestinationPath = $TempDestination
DependsOn = '[File]Directory'
}
xRemoteFile Passphrase {
URI = $RemotePassphrase
DestinationPath = $LocalPassphrase
DependsOn = '[File]Directory'
}
xRemoteFile AzureAgent {
URI = $RemoteAzureAgent
DestinationPath = $LocalAzureAgent
DependsOn = '[File]Directory'
}
Archive ASRzip {
Path = $TempDestination
Destination = 'C:\Temp\ASRSetup'
DependsOn = '[xRemotefile]Setup'
}
Package Install {
Path = 'C:\temp\ASRSetup\ASR\UNIFIEDAGENT.EXE'
Ensure = 'Present'
Name = 'Microsoft Azure Site Recovery mobility Service/Master Target Server'
ProductId = '275197FC-14FD-4560-A5EB-38217F80CBD1'
Arguments = $Arguments
DependsOn = '[Archive]ASRzip'
}
Package AzureAgent {
Path = 'C:\Temp\AzureVmAgent.msi'
Ensure = 'Present'
Name = 'Windows Azure VM Agent - 2.7.1198.735'
ProductId = '5CF4D04A-F16C-4892-9196-6025EA61F964'
Arguments = '/q /l "c:\temp\agentlog.txt'
DependsOn = '[Package]Install'
}
Service ASRvx {
Name = 'svagents'
Ensure = 'Present'
State = 'Running'
DependsOn = '[Package]Install'
}
Service ASR {
Name = 'InMage Scout Application Service'
Ensure = 'Present'
State = 'Running'
DependsOn = '[Package]Install'
}
Service AzureAgentService {
Name = 'WindowsAzureGuestAgent'
Ensure = 'Present'
State = 'Running'
DependsOn = '[Package]AzureAgent'
}
Service AzureTelemetry {
Name = 'WindowsAzureTelemetryService'
Ensure = 'Present'
State = 'Running'
DependsOn = '[Package]AzureAgent'
}
}
}
The configuration will do the following:
The variables will tell the configuration where to get the binaries for the Mobility service and the Azure VM
agent, where to get the passphrase, and where to store the output.
The configuration will import the xPSDesiredStateConfiguration DSC resource, so that you can use xRemoteFile
to download the files from the repository.
The configuration will create a directory where you want to store the binaries.
The archive resource will extract the files from the zipped folder.
The package Install resource will install the Mobility service from the UNIFIEDAGENT.EXE installer with the
specific arguments. (The variables that construct the arguments need to be changed to reflect your
environment.)
The package AzureAgent resource will install the Azure VM agent, which is recommended on every VM that
runs in Azure. The Azure VM agent also makes it possible to add extensions to the VM after failover.
The service resource or resources will ensure that the related Mobility services and the Azure services are
always running.
Save the configuration as ASRMobilityService.
NOTE
Remember to replace the CSIP in your configuration to reflect the actual management server, so that the agent will be
connected correctly and will use the correct passphrase.
Step 3: Upload to Automation DSC
Because the DSC configuration that you made will import a required DSC resource module
(xPSDesiredStateConfiguration), you need to import that module in Automation before you upload the DSC
configuration.
Sign in to your Automation account, browse to Assets > Modules, and click Browse Gallery.
Here you can search for the module and import it to your account.
When you finish this, go to your machine where you have the Azure Resource Manager modules installed and
proceed to import the newly created DSC configuration.
Import cmdlets
In PowerShell, sign in to your Azure subscription. Modify the cmdlets to reflect your environment and capture your
Automation account information in a variable:
$AAAccount = Get-AzureRmAutomationAccount -ResourceGroupName 'KNOMS' -Name 'KNOMSAA'
Upload the configuration to Automation DSC by using the following cmdlet:
$ImportArgs = @{
SourcePath = 'C:\ASR\ASRMobilityService.ps1'
Published = $true
Description = 'DSC Config for Mobility Service'
}
$AAAccount | Import-AzureRmAutomationDscConfiguration @ImportArgs
Compile the configuration in Automation DSC
Next, you need to compile the configuration in Automation DSC, so that you can start to register nodes to it. You
achieve that by running the following cmdlet:
$AAAccount | Start-AzureRmAutomationDscCompilationJob -ConfigurationName ASRMobilityService
This can take a few minutes, because you're basically deploying the configuration to the hosted DSC pull service.
After you compile the configuration, you can retrieve the job information by using PowerShell (GetAzureRmAutomationDscCompilationJob) or by using the Azure portal.
You have now successfully published and uploaded your DSC configuration to Automation DSC.
Step 4: Onboard machines to Automation DSC
NOTE
One of the prerequisites for completing this scenario is that your Windows machines are updated with the latest version of
WMF. You can download and install the correct version for your platform from the Download Center.
You will now create a metaconfig for DSC that you will apply to your nodes. To succeed with this, you need to
retrieve the endpoint URL and the primary key for your selected Automation account in Azure. You can find these
values under Keys on the All settings blade for the Automation account.
In this example, you have a Windows Server 2012 R2 physical server that you want to protect by using Site
Recovery.
Check for any pending file rename operations in the registry
Before you start to associate the server with the Automation DSC endpoint, we recommend that you check for any
pending file rename operations in the registry. They might prohibit the setup from finishing due to a pending
reboot.
Run the following cmdlet to verify that there’s no pending reboot on the server:
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\' | Select-Object -Property
PendingFileRenameOperations
If this shows empty, you are OK to proceed. If not, you should address this by rebooting the server during a
maintenance window.
To apply the configuration on the server, start the PowerShell Integrated Scripting Environment (ISE) and run the
following script. This is essentially a DSC local configuration that will instruct the Local Configuration Manager
engine to register with the Automation DSC service and retrieve the specific configuration
(ASRMobilityService.localhost).
[DSCLocalConfigurationManager()]
configuration metaconfig {
param (
$URL,
$Key
)
node localhost {
Settings {
RefreshFrequencyMins = '30'
RebootNodeIfNeeded = $true
RefreshMode = 'PULL'
ActionAfterReboot = 'ContinueConfiguration'
ConfigurationMode = 'ApplyAndMonitor'
AllowModuleOverwrite = $true
}
ResourceRepositoryWeb AzureAutomationDSC {
ServerURL = $URL
RegistrationKey = $Key
}
ConfigurationRepositoryWeb AzureAutomationDSC {
ServerURL = $URL
RegistrationKey = $Key
ConfigurationNames = 'ASRMobilityService.localhost'
}
ReportServerWeb AzureAutomationDSC {
ServerURL = $URL
RegistrationKey = $Key
}
}
}
metaconfig -URL 'https://we-agentservice-prod-1.azure-automation.net/accounts/<YOURAAAccountID>' -Key
'<YOURAAAccountKey>'
Set-DscLocalConfigurationManager .\metaconfig -Force -Verbose
This configuration will cause the Local Configuration Manager engine to register itself with Automation DSC. It will
also determine how the engine should operate, what it should do if there's a configuration drift
(ApplyAndAutoCorrect), and how it should proceed with the configuration if a reboot is required.
After you run this script, the node should start to register with Automation DSC.
If you go back to the Azure portal, you can see that the newly registered node has now appeared in the portal.
On the server, you can run the following PowerShell cmdlet to verify that the node has been registered correctly:
Get-DscLocalConfigurationManager
After the configuration has been pulled and applied to the server, you can verify this by running the following
cmdlet:
Get-DscConfigurationStatus
The output shows that the server has successfully pulled its configuration:
In addition, the Mobility service setup has its own log that can be found at
SystemDrive\ProgramData\ASRSetupLogs.
That’s it. You have now successfully deployed and registered the Mobility service on the machine that you want to
protect by using Site Recovery. DSC will make sure that the required services are always running.
After the management server detects the successful deployment, you can configure protection and enable
replication on the machine by using Site Recovery.
Use DSC in disconnected environments
If your machines aren’t connected to the Internet, you can still rely on DSC to deploy and configure the Mobility
service on the workloads that you want to protect.
You can instantiate your own DSC pull server in your environment to essentially provide the same capabilities that
you get from Automation DSC. That is, the clients will pull the configuration (after it's registered) to the DSC
endpoint. However, another option is to manually push the DSC configuration to your machines, either locally or
remotely.
Note that in this example, there's an added parameter for the computer name. The remote files are now located on
a remote share that should be accessible by the machines that you want to protect. The end of the script enacts the
configuration and then starts to apply the DSC configuration to the target computer.
Prerequisites
Make sure that the xPSDesiredStateConfiguration PowerShell module is installed. For Windows machines where
WMF 5.0 is installed, you can install the xPSDesiredStateConfiguration module by running the following cmdlet on
the target machines:
Find-Module -Name xPSDesiredStateConfiguration | Install-Module
You can also download and save the module in case you need to distribute it to Windows machines that have WMF
4.0. Run this cmdlet on a machine where PowerShellGet (WMF 5.0) is present:
Save-Module -Name xPSDesiredStateConfiguration -Path <location>
Also for WMF 4.0, ensure that the Windows 8.1 update KB2883200 is installed on the machines.
The following configuration can be pushed to Windows machines that have WMF 5.0 and WMF 4.0:
configuration ASRMobilityService {
param (
[Parameter(Mandatory=$true)]
[ValidateNotNullOrEmpty()]
[System.String] $ComputerName
)
$RemoteFile = '\\myfileserver\share\asr.zip'
$RemotePassphrase = '\\myfileserver\share\passphrase.txt'
$RemoteAzureAgent = '\\myfileserver\share\AzureVmAgent.msi'
$LocalAzureAgent = 'C:\Temp\AzureVmAgent.msi'
$TempDestination = 'C:\Temp\asr.zip'
$LocalPassphrase = 'C:\Temp\Mobility_service\passphrase.txt'
$Role = 'Agent'
$Install = 'C:\Program Files (x86)\Microsoft Azure Site Recovery'
$CSEndpoint = '10.0.0.115'
$Arguments = '/Role "{0}" /InstallLocation "{1}" /CSEndpoint "{2}" /PassphraseFilePath "{3}"' -f
$Role,$Install,$CSEndpoint,$LocalPassphrase
Import-DscResource -ModuleName xPSDesiredStateConfiguration
node $ComputerName {
File Directory {
DestinationPath = 'C:\Temp\ASRSetup\'
Type = 'Directory'
}
xRemoteFile Setup {
URI = $RemoteFile
DestinationPath = $TempDestination
DependsOn = '[File]Directory'
}
xRemoteFile Passphrase {
URI = $RemotePassphrase
DestinationPath = $LocalPassphrase
DependsOn = '[File]Directory'
}
xRemoteFile AzureAgent {
URI = $RemoteAzureAgent
DestinationPath = $LocalAzureAgent
DependsOn = '[File]Directory'
}
Archive ASRzip {
Path = $TempDestination
Destination = 'C:\Temp\ASRSetup'
DependsOn = '[xRemotefile]Setup'
}
Package Install {
Path = 'C:\temp\ASRSetup\ASR\UNIFIEDAGENT.EXE'
Path = 'C:\temp\ASRSetup\ASR\UNIFIEDAGENT.EXE'
Ensure = 'Present'
Name = 'Microsoft Azure Site Recovery mobility Service/Master Target Server'
ProductId = '275197FC-14FD-4560-A5EB-38217F80CBD1'
Arguments = $Arguments
DependsOn = '[Archive]ASRzip'
}
Package AzureAgent {
Path = 'C:\Temp\AzureVmAgent.msi'
Ensure = 'Present'
Name = 'Windows Azure VM Agent - 2.7.1198.735'
ProductId = '5CF4D04A-F16C-4892-9196-6025EA61F964'
Arguments = '/q /l "c:\temp\agentlog.txt'
DependsOn = '[Package]Install'
}
Service ASRvx {
Name = 'svagents'
State = 'Running'
DependsOn = '[Package]Install'
}
Service ASR {
Name = 'InMage Scout Application Service'
State = 'Running'
DependsOn = '[Package]Install'
}
Service AzureAgentService {
Name = 'WindowsAzureGuestAgent'
State = 'Running'
DependsOn = '[Package]AzureAgent'
}
Service AzureTelemetry {
Name = 'WindowsAzureTelemetryService'
State = 'Running'
DependsOn = '[Package]AzureAgent'
}
}
}
ASRMobilityService -ComputerName 'MyTargetComputerName'
Start-DscConfiguration .\ASRMobilityService -Wait -Force -Verbose
If you want to instantiate your own DSC pull server on your corporate network to mimic the capabilities that you
can get from Automation DSC, see Setting up a DSC web pull server.
Optional: Deploy a DSC configuration by using an Azure Resource
Manager template
This article has focused on how you can create your own DSC configuration to automatically deploy the Mobility
service and the Azure VM Agent--and ensure that they are running on the machines that you want to protect. We
also have an Azure Resource Manager template that will deploy this DSC configuration to a new or existing Azure
Automation account. The template will use input parameters to create Automation assets that will contain the
variables for your environment.
After you deploy the template, you can simply refer to step 4 in this guide to onboard your machines.
The template will do the following:
1. Use an existing Automation account or create a new one
2. Take input parameters for:
ASRRemoteFile--the location where you have stored the Mobility service setup
ASRPassphrase--the location where you have stored the passphrase.txt file
ASRCSEndpoint--the IP address of your management server
3. Import the xPSDesiredStateConfiguration PowerShell module
4. Create and compile the DSC configuration
All the preceding steps will happen in the right order, so that you can start onboarding your machines for
protection.
The template, with instructions for deployment, is located on GitHub.
Deploy the template by using PowerShell:
$RGDeployArgs = @{
Name = 'DSC3'
ResourceGroupName = 'KNOMS'
TemplateFile =
'https://raw.githubusercontent.com/krnese/AzureDeploy/master/OMS/MSOMS/DSC/azuredeploy.json'
OMSAutomationAccountName = 'KNOMSAA'
ASRRemoteFile = 'https://knrecstor01.blob.core.windows.net/asr/ASR.zip'
ASRRemotePassphrase = 'https://knrecstor01.blob.core.windows.net/asr/passphrase.txt'
ASRCSEndpoint = '10.0.0.115'
DSCJobGuid = [System.Guid]::NewGuid().ToString()
}
New-AzureRmResourceGroupDeployment @RGDeployArgs -Verbose
Next steps
After you deploy the Mobility service agents, you can enable replication for the virtual machines.
Replicate applications
4/12/2017 • 7 min to read • Edit Online
This article describes how to set up replication of virtual machines running on VMware into Azure.
Prerequisites
The article assumes that you have already
1. Setup on-premise source environment
2. Setup target environment in Azure
Enable replication
Before you start
If you're replicating VMware virtual machines, note that:
VMware VMs are discovered every 15 minutes. It might take 15 minutes or longer for them to appear in the
portal after discovery. Likewise discovery can take 15 minutes or more when you add a new vCenter server or
vSphere host.
Environment changes on the virtual machine (such as VMware tools installation) can take 15 minutes or more
to be updated in the portal.
You can check the last discovered time for VMware VMs in the Last Contact At field for the vCenter
server/vSphere host, on the Configuration Servers blade.
To add machines for replication without waiting for the scheduled discovery, highlight the configuration server
(don’t click it), and click the Refresh button.
When you enable replication, if the machine is prepared, the process server automatically installs the Mobility
service on it.
Now enable replication as follows:
1. Click Step 2: Replicate application > Source. After you've enabled replication for the first time, click
+Replicate in the vault to enable replication for additional machines.
2. In the Source blade > Source, select the configuration server.
3. In Machine type, select Virtual Machines or Physical Machines.
4. In vCenter/vSphere Hypervisor, select the vCenter server that manages the vSphere host, or select the host.
This setting isn't relevant if you're replicating physical machines.
5. Select the process server. If you haven't created any additional process servers this will be the name of the
configuration server. Then click OK.
6. In Target select the subscription and the resource group where you want to create the failed over virtual
machines. Choose the deployment model that you want to use in Azure (classic or resource management)
for the failed over virtual machines.
7. Select the Azure storage account you want to use for replicating data. Note that:
You can select a premium or standard storage account. If you select a premium account, you'll need to
specify an additional standard storage account for ongoing replication logs. Accounts must be in the
same region as the Recovery Services vault.
If you want to use a different storage account than those you have, you can create onePLaceholder LInk
for creating storage account using resource manager which will be covered in getting started. To create a
storage account using Resource Manager, click Create new. If you want to create a storage account
using the classic model, you do that in the Azure portal.
8. Select the Azure network and subnet to which Azure VMs will connect, when they're spun up after failover.
The network must be in the same region as the Recovery Services vault. Select Configure now for selected
machines, to apply the network setting to all machines you select for protection. Select Configure later to
select the Azure network per machine. If you don't have a network, you need to create one. To create a
network using Resource Manager, click Create new. If you want to create a network using the classic model,
do that in the Azure portal. Select a subnet if applicable. Then click OK.
9. In Virtual Machines > Select virtual machines, click and select each machine you want to replicate. You
can only select machines for which replication can be enabled. Then click OK.
10. In Properties > Configure properties, select the account that will be used by the process server to
automatically install the Mobility service on the machine. By default all disks are replicated. Click All Disks
and clear any disks you don't want to replicate. Then click OK. You can set additional properties later.
NOTE
By default all disks on a machine are replicated. You can exclude disks from replication. For example you might not want to
replicate disks with temporary data, or data that's refreshed each time a machine or application restarts (for example
pagefile.sys or SQL Server tempdb).
1. In Replication settings > Configure replication settings, verify that the correct replication policy is selected.
You can modify replication policy settings in Settings > Replication policies > policy name > Edit Settings.
Changes you apply to a policy will be applied to replicating and new machines.
2. Enable Multi-VM consistency if you want to gather machines into a replication group, and specify a name
for the group. Then click OK. Note that:
Machines in replication group replicate together and have shared crash-consistent and app-consistent
recovery points when they fail over.
We recommend that you gather VMs and physical servers together so that they mirror your workloads.
Enabling multi-VM consistency can impact workload performance and should only be used if machines
are running the same workload and you need consistency.
3. Click Enable Replication. You can track progress of the Enable Protection job in Settings > Jobs > Site
Recovery Jobs. After the Finalize Protection job runs the machine is ready for failover.
NOTE
If the machine is prepared for push installation the Mobility service component will be installed when protection is enabled.
After the component is installed on the machine a protection job starts and fails. After the failure you need to manually
restart each machine. After the restart the protection job begins again and initial replication occurs.
View and manage VM properties
We recommend that you verify the properties of the source machine. Remember that the Azure VM name should
conform with Azure virtual machine requirements.
1. Click Settings > Replicated items >, and select the machine. The Essentials blade shows information about
machines settings and status.
2. In Properties, you can view replication and failover information for the VM.
3. In Compute and Network > Compute properties, you can specify the Azure VM name and target size.
Modify the name to comply with Azure requirements if you need to.
Resource Group
You can select a resource group of which machine will become part of post fail over. You can change this setting
any time before fail over.
NOTE
Post fail over, if you migrate the machine to a different resource group then protection settings of a machine will break.
Availability Sets
You can select an availability set if your machine required to be be a part of one post fail over. While selecting
availability set, please keep in mind that:
Only availability sets belonging to the specified resource group will be listed
Machines with different virtual networks cannot be a part of same availability set
Only virtual machines of same size can be a part of same availability set
Network Properties
You can also view and add information about the target network, subnet, and IP address that will be assigned to the
Azure VM. Note the following:
You can set the target IP address. If you don't provide an address, the failed over machine will use DHCP. If you
set an address that isn't available at failover, the failover won't work. The same target IP address can be used for
test failover if the address is available in the test failover network.
The number of network adapters is dictated by the size you specify for the target virtual machine, as follows:
If the number of network adapters on the source machine is less than or equal to the number of adapters
allowed for the target machine size, then the target will have the same number of adapters as the source.
If the number of adapters for the source virtual machine exceeds the number allowed for the target size
then the target size maximum will be used.
For example if a source machine has two network adapters and the target machine size supports four, the
target machine will have two adapters. If the source machine has two adapters but the supported target
size only supports one then the target machine will have only one adapter.
If the virtual machine has multiple network adapters they will all connect to the same network.
If the virtual machine has multiple network adapters then the first one shown in the list becomes the Default
network adapter in the Azure virtual machine.
1. In Disks, you can see the operating system and data disks on the VM that will be replicated.
Common issues
Each disk should be less than 1TB in size.
The OS disk should be a basic disk and not dynamic disk
For generation 2/UEFI enabled virtual machines, the operating system family should be Windows and boot disk
should be less than 300GB
Next steps
Once the protection is completed, you can try fail over to check whether your application comes up in Azure or not.
In case you want to disable protection, check how to clean registration and protection settings
Failover in Site Recovery
5/2/2017 • 5 min to read • Edit Online
This article describes how to failover virtual machines and physical servers protected by Site Recovery.
Prerequisites
1. Before you do a failover, do a test failover to ensure that everything is working as expected.
2. Prepare the network at target location before you do a failover.
Run a failover
This procedure describes how to run a failover for a recovery plan. Alternatively you can run the failover for a
single virtual machine or physical server from the Replicated items page
1. Select Recovery Plans > recoveryplan_name. Click Failover
2. On the Failover screen, select a Recovery Point to failover to. You can use one of the following options:
a. Latest (default): This option first processes all the data that has been sent to Site Recovery service to
create a recovery point for each virtual machine before failing them over to it. This option provides the
lowest RPO (Recovery Point Objective) as the virtual machine created after failover has all the data
that has been replicated to Site Recovery service when the failover was triggered.
b. Latest processed: This option fails over all virtual machines of the recovery plan to the latest recovery
point that has already been processed by Site Recovery service. When you are doing test failover of a
virtual machine, time stamp of the latest processed recovery point is also shown. If you are doing
failover of a recovery plan, you can go to individual virtual machine and look at Latest Recovery
Points tile to get this information. As no time is spent to process the unprocessed data, this option
provides a low RTO (Recovery Time Objective) failover option.
c. Latest app-consistent: This option fails over all virtual machines of the recovery plan to the latest
application consistent recovery point that has already been processed by Site Recovery service. When
you are doing test failover of a virtual machine, time stamp of the latest app-consistent recovery point
is also shown. If you are doing failover of a recovery plan, you can go to individual virtual machine
and look at Latest Recovery Points tile to get this information.
d. Custom: If you are doing test failover of a virtual machine, then you can use this option to failover
to a particular recovery point.
NOTE
The option to choose a recovery point is only available when you are failing over to Azure.
3. If some of the virtual machines in the recovery plan were failed over in a previous run and now the virtual
machines are active on both source and target location, you can use Change direction option to decide
the direction in which the failover should happen.
4. If you're failing over to Azure and data encryption is enabled for the cloud (applies only when you have
protected Hyper-v virtual machines from a VMM Server), in Encryption Key select the certificate that was
issued when you enabled data encryption during setup on the VMM server.
5. Select Shut down machine before beginning failover if you want Site Recovery to attempt do a
shutdown of source virtual machines before triggering the failover. Failover continues even if shutdown
fails.
NOTE
In case of Hyper-v virtual machines, this option also tries to synchronize the on-premises data that has not yet
been sent to the service before triggering the failover.
6. You can follow the failover progress on the Jobs page. Even if errors occur during an unplanned failover,
the recovery plan runs until it is complete.
7. After the failover, validate the virtual machine by logging into it. If you want to go another recovery point for
the virtual machine, then you can use Change recovery point option.
8. Once you are satisfied with the failed over virtual machine, you can Commit the failover. This deletes all the
recovery points available with the service and Change recovery point option will no longer be available.
Planned failover
Apart from, Failover, Hyper-V virtual machines protected using Site Recovery also support Planned failover.
This is a zero data loss failover option. When a planned failover is triggered, first the source virtual machines are
shutdown, the data yet to be synchronized is synchronized and then a failover is triggered.
NOTE
When you failover Hyper-v virtual machines from one on-premises site to another on-premises site, to come back to the
primary on-premises site you have to first reverse replicate the virtual machine back to primary site and then trigger a
failover. If the primary virtual machine is not available, then before starting to reverse replicate you have to restore the
virtual machine from a backup.
Failover job
When a failover is triggered, it involves following steps:
1. Prerequisites check: This step ensures that all conditions required for failover are met
2. Failover: This step processes the data and makes it ready so that an Azure virtual machine can be created out
of it. If you have chosen Latest recovery point, this step creates a recovery point from the data that has been
sent to the service.
3. Start: This step creates an Azure virtual machine using the data processed in the previous step.
WARNING
Don't Cancel an in progress failover: Before failover is started, replication for the virtual machine is stopped. If you
Cancel an in progress job, failover stops but the virtual machine will not start to replicate. Replication cannot be started
again.
Time taken for failover to Azure
In certain cases, failover of virtual machines requires an extra intermediate step that usually takes around 8 to
10 minutes to complete. These cases are as following:
VMware virtual machines using mobility service of version older than 9.8
Physical servers
VMware Linux virtual machines
Hyper-V virtual machines protected as physical servers
VMware virtual machines where following drivers are not present as boot drivers
storvsc
vmbus
storflt
intelide
atapi
VMware virtual machines that don't have DHCP service enabled irrespective of whether they are using DHCP
or static IP addresses
In all the other cases this intermediate step is not required and the time taken for the failover is significantly
lower.
Using scripts in Failover
You might want to automate certain actions while doing a failover. You can use scripts or Azure automation
runbooks in recovery plans to do that.
Other considerations
Drive letter — To retain the drive letter on virtual machines after failover you can set the SAN Policy for
the virtual machine to OnlineAll. Read more.
Next steps
Once you have failed over virtual machines and the on-premises data center is available, you should Re-protect
VMware virtual machines back to the on-premises data center.
Use Planned failover option to Failback Hyper-v virtual machines back to on-premises from Azure.
If you have failed over a Hyper-v virtual machine to another on-premises data center managed by a VMM server
and the primary data center is available, then use Reverse replicate option to start the replication back to the
primary data center.
Create recovery plans
2/14/2017 • 5 min to read • Edit Online
This article provides information about creating and customizing recovery plans in Azure Site Recovery?.
Post any comments or questions at the bottom of this article, or on the Azure Recovery Services Forum.
Recovery plans do the following:
Define groups of machines that fail over together, and then start up together.
Model dependencies between machines, by grouping them together into a recovery plan group. For
example, to fail over and bring up a specific application, you group all of the VMs for that application into the
same recovery plan group.
Fail over. You can run a test, planned, or unplanned failover on a recovery plan.
Create a recovery plan
1. Click Recovery Plans > Create Recovery Plan. Specify a name for the recovery plan, and a source and
target. The source location must have virtual machines that are enabled for failover and recovery.
For VMM to VMM replication, select Source Type > VMM, and the source and target VMM servers.
Click Hyper-V to see clouds that are protected.
For VMM to Azure, select Source Type > VMM. Select the source VMM server, and Azure as the
target.
For Hyper-V replication to Azure (without VMM), select Source Type > Hyper-V site. Select the site
as the source, and Azure as the target.
For a VMware VM or a physical on-premises server to Azure, select a configuration server as the
source, and Azure as the target.
2. In Select virtual machines, select the virtual machines (or replication group) that you want to add to the
default group (Group 1) in the recovery plan.
Customize and extend recovery plans
You can customize and extend recovery plans:
Add new groups—Add additional recovery plan groups (up to seven) to the default group, and then add
more machines or replication groups to those recovery plan groups. Groups are numbered in the order in
which you add them. A virtual machine, or replication group, can only be included in one recovery plan
group.
Add a manual action—You can add manual actions that run before or after a recovery plan group. When
the recovery plan runs, it stops at the point at which you inserted the manual action. A dialog box prompts
you to specify that the manual action was completed.
Add a script—You can add scripts that run before or after a recovery plan group. When you add a script, it
adds a new set of actions for the group. For example, a set of pre-steps for Group 1 will be created with the
name: Group 1: pre-steps. All pre-steps will be listed inside this set. You can only add a script on the primary
site if you have a VMM server deployed.
Add Azure runbooks—You can extend recovery plans with Azure runbooks. For example, to automate
tasks, or to create single-step recovery. Learn more.
Add scripts
You can use PowerShell scripts in your recovery plans.
Ensure that scripts use try-catch blocks so that the exceptions are handled gracefully.
If there is an exception in the script, it stops running and the task shows as failed.
If an error occurs, any remaining part of the script doesn't run.
If an error occurs when you run an unplanned failover, the recovery plan continues.
If an error occurs when you run a planned failover, the recovery plan stops. You need to fix the script,
check that it runs as expected, and then run the recovery plan again.
The Write-Host command doesn’t work in a recovery plan script, and the script will fail. To
create output, create a proxy script that in turn runs your main script. Make sure that all output
is piped out using the >> command.
The script times out if it doesn't return within 600 seconds.
If anything is written out to STDERR, the script is classified as failed. This information is
displayed in the script execution details.
If you're using VMM in your deployment:
Scripts in a recovery plan run in the context of the VMM Service account. Make sure this account has Read
permissions for the remote share on which the script is located. Test the script to run at the VMM service
account privilege level.
VMM cmdlets are delivered in a Windows PowerShell module. The module is installed when you install the
VMM console. It can be loaded into your script, using the following command in the script:
Import-Module -Name virtualmachinemanager. Learn more.
Ensure you have at least one library server in your VMM deployment. By default, the library share path for a
VMM server is located locally on the VMM server, with the folder name MSCVMMLibrary.
If your library share path is remote (or local but not shared with MSCVMMLibrary), configure the
share as follows (using \libserver2.contoso.com\share\ as an example):
Open the Registry Editor and navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\Azure Site Recovery\Registration.
Edit the value ScriptLibraryPath and place it as \libserver2.contoso.com\share. Specify the full
FQDN. Provide permissions to the share location.
Ensure that you test the script with a user account that has the same permissions as the VMM
service account. This checks that standalone tested scripts run in the same way as they will in
recovery plans. On the VMM server, set the execution policy to bypass as follows:
Open the 64-bit Windows PowerShell console using elevated privileges.
Type: Set-executionpolicy bypass. Learn more.
Add a script or manual action to a plan
You can add a script to the default recovery plan group after you've added VMs or replication groups to it, and
created the plan.
1. Open the recovery plan.
2. Click an item in the Step list, and then click Script or Manual Action.
3. Specify whether to want to add the script or action before or after the selected item. Use the Move Up and
Move Down buttons, to move the position of the script up or down.
4. If you add a VMM script, select Failover to VMM script. In Script Path, type the relative path to the share.
In the VMM example below, you specify the path: \RPScripts\RPScript.PS1.
5. If you add an Azure automation run book, specify the Azure Automation account in which the runbook is
located, and select the appropriate Azure runbook script.
6. Do a failover of the recovery plan, to make sure the script works as expected.
VMM script
If you have a VMM source site, you can create a script on the VMM server, and include it in your recovery plan.
1. Create a new folder in the library share. For example, <VMMServerName>\MSSCVMMLibrary\RPScripts.
Place it on the source and target VMM servers.
2. Create the script (for example RPScript), and check it works as expected.
3. Place the script in the location <VMMServerName>\MSSCVMMLibrary, on the source and target VMM
servers.
Next steps
Learn more about running failovers.
Add Azure automation runbooks to recovery plans
3/30/2017 • 7 min to read • Edit Online
This tutorial describes how Azure Site Recovery integrates with Azure Automation to provide extensibility to
recovery plans. Recovery plans can orchestrate recovery of your virtual machines protected using Azure Site
Recovery for both replication to secondary cloud and replication to Azure scenarios. They also help in making the
recovery consistently accurate, repeatable, and automated. If you are failing over your virtual machines to
Azure, integration with Azure Automation extends the recovery plans and gives you capability to execute runbooks,
thus allowing powerful automation tasks.
If you have not heard about Azure Automation yet, sign up here and download their sample scripts here. Read
more about Azure Site Recovery and how to orchestrate recovery to Azure using recovery plans here.
In this tutorial, we look at how you can integrate Azure Automation runbooks into recovery plans. We automate
simple tasks that earlier required manual intervention and see how to convert a multi-step recovery into a singleclick recovery action.
Customize the recovery plan
1. Let us begin by operning the resource blade of the recovery plan. You can see the recovery plan has two
virtual machines added to it for recovery.
1. Click the customize button to begin adding a runbook.
2. Right-click on the start group 1 and select to add a 'Add post action'.
3. Select to choose a script in the new blade.
4. Name the script 'Hello World'.
5. Choose an Automation Account name.
NOTE
Automation account can be in any Azure geography but has to be in the same subscription as the Site Recovery
vault.
6. Select a runbook from the Automation Account. This runbook is the script that will run during the execution
of the recovery plan after the recovery of first group.
7. Select OK to save the script. Script is added to the post action group of Group 1: Start.
Salient points of adding a script
1. You can right click the script and choose to 'delete step' or 'update script'.
2. A script can run on the Azure while failover from On-premises to Azure, and can run on Azure as a primary side
script before shutdown, during failback from Azure to on-premises.
3. When a script runs, it injects a recovery plan context.
Following is an example of how the context variable looks.
{"RecoveryPlanName":"hrweb-recovery",
"FailoverType":"Test",
"FailoverDirection":"PrimaryToSecondary",
"GroupId":"1",
"VmMap":{"7a1069c6-c1d6-49c5-8c5d-33bfce8dd183":
{ "SubscriptionId":"7a1111111-c1d6-49c5-8c5d-111ce8dd183",
"ResourceGroupName":"ContosoRG",
"CloudServiceName":"pod02hrweb-Chicago-test",
"RoleName":"Fabrikam-Hrweb-frontend-test",
"RecoveryPointId":"TimeStamp"}
}
}
The following table contains name and description for each variable in the context.
VARIABLE NAME
DESCRIPTION
RecoveryPlanName
Name of plan being run. This variable helps you to take
different actions based on name and by reusing the script
FailoverType
Specifies whether the failover is test, planned, or unplanned.
FailoverDirection
Specify whether recovery is to primary or secondary
GroupID
Identify the group number within the recovery plan when the
plan is running
VmMap
Array of all the virtual machines in the group
VMMap key
Unique key (GUID) for each VM. It's the same as the VMM ID
of the virtual machine where applicable.
SubscriptionId
Azure Subscription ID in which the VM is created.
RoleName
Name of the Azure VM that's being recovered
CloudServiceName
Azure Cloud Service name under which the virtual machine is
created.
ResourceGroupName
Azure Resource Group name under which the virtual machine
is created.
RecoveryPointId
Timestamp to which the VM is recovered.
You also need to ensure that the Automation Account has the following modules added. All the modules should be
of compatible versions. An easy way is to make sure all modules are at the latest version available.
AzureRM.profile
AzureRM.Resources
AzureRM.Automation
AzureRM.Network
AzureRM.Compute
Accessing all VMs of the VmMap in a loop
Use the following snippet to loop across all VMs of the VmMap.
$VMinfo = $RecoveryPlanContext.VmMap | Get-Member | Where-Object MemberType -EQ NoteProperty | select ExpandProperty Name
$vmMap = $RecoveryPlanContext.VmMap
foreach($VMID in $VMinfo)
{
$VM = $vmMap.$VMID
if( !(($VM -eq $Null) -Or ($VM.ResourceGroupName -eq $Null) -Or ($VM.RoleName -eq $Null))) {
#this check is to ensure that we skip when some data is not available else it will fail
Write-output "Resource group name ", $VM.ResourceGroupName
Write-output "Rolename " = $VM.RoleName
}
}
NOTE
The Resource Group name and the Role name values are empty when the script is a pre-action to a boot group. The values
are populated only if the VM of that group succeeds in failover and the script is a post-action of the boot group.
Using the same Automation runbook with multiple recovery plans
A single script can be used across multiple recovery plans by using external variables. You can use the Azure
Automation variables to store parameters that you can pass for a recovery plan execution. By pre-fixing the
variable with the name of the recovery plan, you can create individual variables for every recovery plan and use
them as a parameter. You can change the parameter without changing the script and make the script work
differently.
Using simple string variables in runbook script
Consider script that takes the input of an NSG and applies it to the VMs of a recovery plan.
For the script to understand which recovery plan is executing, you can use the Recovery Plan Context.
workflow AddPublicIPAndNSG {
param (
[parameter(Mandatory=$false)]
[Object]$RecoveryPlanContext
)
$RPName = $RecoveryPlanContext.RecoveryPlanName
To apply an existing NSG, you need the NSG name and the NSG resource group. We provide these variables as an
input for the recovery plan scripts. To do this, create two variables in the Automation accounts assets and prefix it
with the name of the recovery plan for which you are creating the parameters.
1. Create a variable to store the NSG name. Prefix it with the name of the recovery plan.
2. Create a variable to store the NSG's RG name. Prefix it with the name of the recovery plan.
In the script, acquire the variables' values by using the following reference code:
$NSGValue = $RecoveryPlanContext.RecoveryPlanName + "-NSG"
$NSGRGValue = $RecoveryPlanContext.RecoveryPlanName + "-NSGRG"
$NSGnameVar = Get-AutomationVariable -Name $NSGValue
$RGnameVar = Get-AutomationVariable -Name $NSGRGValue
Next you can use the variables in the runbook and apply the NSG to the Network Interface of the failed over virtual
machine.
InlineScript {
if (($Using:NSGname -ne $Null) -And ($Using:NSGRGname -ne $Null)) {
$NSG = Get-AzureRmNetworkSecurityGroup -Name $Using:NSGname -ResourceGroupName $Using:NSGRGname
Write-output $NSG.Id
#Apply the NSG to a network interface
#$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName TestRG -Name TestVNet
#Set-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name FrontEnd `
# -AddressPrefix 192.168.1.0/24 -NetworkSecurityGroup $NSG
}
}
For each recovery plan, create independent variables so that you can reuse the script and prefix it wih the recovery
plan name. A complete end to end script for this example is given here.
Using complex variable to store more information
Consider a scenario where you want just one script to turn on a public IP on specific VMs Another example would
be to apply different NSGs on different virtual machines (not all). This script should be reusable for any other
recovery plan. Each recovery plan can have variable number of virtual machines (example, a sharepoint recovery
has two front ends, a simple LOB application has only one front end). To achieve this result, it is impossible to
create separate variables per recovery plan. Here we use a new technique and create a complex variable in the
Azure Automation account assets, by specifying multiple values. You need the Azure powershell to execute the
following steps.
1. On the Azure powershell login to your subscription.
login-azurermaccount
$sub = Get-AzureRmSubscription -Name <SubscriptionName>
$sub | Select-AzureRmSubscription
2. To store the parameters, create the complex variable with the same name as the recovery plan.
$VMDetails =
@{"VMGUID"=@{"ResourceGroupName"="RGNameOfNSG";"NSGName"="NameOfNSG"};"VMGUID2"=@{"ResourceGroupName"="R
GNameOfNSG";"NSGName"="NameOfNSG"}}
New-AzureRmAutomationVariable -ResourceGroupName <RG of Automation Account> -AutomationAccountName
<AA Name> -Name <RecoveryPlanName> -Value $VMDetails -Encrypted $false
In this complex variable, *VMDetails is the VM ID for the protected virtual machine. You can find this in the
properties of the virtual machine on the portal. Here we have created a variable to store the details of two
virtual machines.
3. Use this variable in your runbook and apply the NSG on the virtual machine if any of the given VMGUID is
found in the recovery plan context.
$VMDetailsObj = Get-AutomationVariable -Name $RecoveryPlanContext.RecoveryPlanName
4. In your runbook, loop through the VMs of the recovery plan context and check if the VM also exists in
$VMDetailsObj. If it exists, apply the NSG by accessing the properties of the variable.
$VMinfo = $RecoveryPlanContext.VmMap | Get-Member | Where-Object MemberType -EQ NoteProperty |
select -ExpandProperty Name
$vmMap = $RecoveryPlanContext.VmMap
foreach($VMID in $VMinfo) {
Write-output $VMDetailsObj.value.$VMID
if ($VMDetailsObj.value.$VMID -ne $Null) { #If the VM exists in the context, this will not b
Null
$VM = $vmMap.$VMID
# Access the properties of the variable
$NSGname = $VMDetailsObj.value.$VMID.'NSGName'
$NSGRGname = $VMDetailsObj.value.$VMID.'NSGResourceGroupName'
# Add code to apply the NSG properties to the VM
}
}
You can use the same script with different recovery plans and provide different parameters by storing the value
corresponding to different recovery plans in different variable.
Sample scripts
Deploy sample scripts into your Automation account using the Deploy to Azure button below.
Also view a quick video about recovering a two tier WordPress application to Azure.
Additional Resources
Azure Automation Service Run as Account
Azure Automation Overview
Sample Azure Automation Scripts
Test Failover to Azure in Site Recovery
5/2/2017 • 9 min to read • Edit Online
This article provides information and instructions for doing a test failover or a DR drill of virtual machines and
physical servers that are protected with Site Recovery using Azure as the recovery site.
Post any comments or questions at the bottom of this article, or on the Azure Recovery Services Forum.
Test failover is run to validate your replication strategy or perform a disaster recovery drill without any data loss
or downtime. Doing a test failover doesn't have any impact on the ongoing replication or on your production
environment. Test failover can be done either on a virtual machine or a recovery plan. When triggering a test
failover, you need to specify the network to which test virtual machines would connect to. Once a test failover is
triggered, you can track progress in the Jobs page.
Supported scenarios
Test failover is supported in all deployment scenarios other than legacy VMware site to Azure. Test failover is also
not supported when virtual machine has been failed over to Azure.
Run a test failover
This procedure describes how to run a test failover for a recovery plan. Alternatively you can also run test failover
for a single machine by using the appropriate option on it.
1. Select Recovery Plans > recoveryplan_name. Click Test Failover.
2. Select a Recovery Point to failover to. You can use one of the following options:
a. Latest processed: This option fails over all virtual machines of the recovery plan to the latest recovery
point that has already been processed by Site Recovery service. When you are doing test failover of a
virtual machine, time stamp of the latest processed recovery point is also shown. If you are doing
failover of a recovery plan, you can go to individual virtual machine and look at Latest Recovery
3.
4.
5.
6.
7.
Points tile to get this information. As no time is spent to process the unprocessed data, this option
provides a low RTO (Recovery Time Objective) failover option.
b. Latest app-consistent: This option fails over all virtual machines of the recovery plan to the latest
application consistent recovery point that has already been processed by Site Recovery service. When
you are doing test failover of a virtual machine, time stamp of the latest app-consistent recovery point
is also shown. If you are doing failover of a recovery plan, you can go to individual virtual machine and
look at Latest Recovery Points tile to get this information.
c. Latest: This option first processes all the data that has been sent to Site Recovery service to create a
recovery point for each virtual machine before failing them over to it. This option provides the lowest
RPO (Recovery Point Objective) as the virtual machine created after failover will have all the data that
has been replicated to Site Recovery service when the failover was triggered.
d. Custom: If you are doing test failover of a virtual machine, then you can use this option to failover to a
particular recovery point.
Select an Azure virtual network: Provide an Azure virtual network where the test virtual machines would be
created. Site Recovery attempts to create test virtual machines in a subnet of same name and using the same
IP as that provided in Compute and Network settings of the virtual machine. If subnet of same name is not
available in the Azure virtual network provided for test failover, then test virtual machine is created in the first
subnet alphabetically. If same IP is not available in the subnet, then virtual machine gets another IP address
available in the subnet. Read this section for more details
If you're failing over to Azure and data encryption is enabled, in Encryption Key select the certificate that was
issued when you enabled data encryption during Provider installation. You can ignore this step if you have not
enabled encryption on the virtual machine.
Track failover progress on the Jobs tab. You should be able to see the test replica machine in the Azure portal.
To initiate an RDP connection on the virtual machine, you will need to add a public ip on the network interface
of the failed over virtual machine. If you are failing over to a Classic virtual machine, then you need to add an
endpoint on port 3389
Once you're done, click Cleanup test failover on the recovery plan. In Notes record and save any
observations associated with the test failover. This deletes the virtual machines that were created during test
failover.
TIP
Site Recovery attempts to create test virtual machines in a subnet of same name and using the same IP as that provided in
Compute and Network settings of the virtual machine. If subnet of same name is not available in the Azure virtual
network provided for test failover, then test virtual machine is created in the first subnet alphabetically. If the target IP is
part of the chosen subnet, then site recovery tries to create the test failover virtual machine using the target IP. If the
target IP is not part of the chosen subnet then test failover virtual machine gets created using any available IP in the
chosen subnet.
Test failover job
When a test failover is triggered, it involves following steps:
1. Prerequisites check: This step ensures that all conditions required for failover are met
2. Failover: This step processes the data and makes it ready so that an Azure virtual machine can be created out
of it. If you have chosen Latest recovery point, this step creates a recovery point from the data that has been
sent to the service.
3. Start: This step creates an Azure virtual machine using the data processed in the previous step.
Time taken for failover
In certain cases, failover of virtual machines requires an extra intermediate step that usually takes around 8 to 10
minutes to complete. These cases are as following:
VMware virtual machines using mobility service of version older than 9.8
Physical servers
VMware Linux virtual machines
Hyper-V virtual machines protected as physical servers
VMware virtual machines where following drivers are not present as boot drivers
storvsc
vmbus
storflt
intelide
atapi
VMware virtual machines that don't have DHCP service enabled irrespective of whether they are using DHCP
or static IP addresses
In all the other cases this intermediate step is not required and the time taken for the failover is significantly
lower.
Creating a network for test failover
It is recommended that when you are doing a test failover you choose a network that is isolated from your
production recovery site network that you provided in Compute and Network settings for the virtual machine.
By default when you create an Azure virtual network, it is isolated from other networks. This network should
mimic your production network:
1. Test network should have same number of subnets as that in your production network and with the same
name as those of the subnets in your production network.
2. Test network should use the same IP range as that of your production network.
3. Update the DNS of the Test Network as the IP that you gave as target IP for the DNS virtual machine under
Compute and Network settings. Go through test failover considerations for active directory section for more
details.
Test failover to a production network on recovery site
It is recommended that when you are doing a test failover you choose a network that is different from your
production recovery site network that you provided in Compute and Network settings for the virtual machine.
But if you really want to validate end to end network connectivity in a failed over virtual machine, note the
following points:
1. Make sure that the primary virtual machine is shutdown when you are doing the test failover. If you don't do
so, there will be two virtual machines with the same identity running in the same network at the same time
and that can lead to undesired consequences.
2. Any changes that you make into the test failover virtual machines would be lost when you cleanup the test
failover virtual machines. These changes will not be replicated back to the primary virtual machine.
3. This way of doing testing leads to a downtime of your production application. Users of the application should
be asked to not use the application when the DR drill is in progress.
Prepare Active Directory and DNS
To run a test failover for application testing, you need a copy of the production Active Directory environment in
your test environment. Go through test failover considerations for active directory section for more details.
Prepare to connect to Azure VMs after failover
If you want to connect to Azure VMs using RDP after failover, make sure you do the actions summarized in the
table.
FAILOVER
LOCATION
ACTIONS
Azure VM running Windows
On on-premises machine before
failover
To access the Azure VM over the
internet, enable RDP, make sure TCP,
and UDP rules are added for the
Public, and that RDP is allowed in
Windows Firewall > Allowed Apps,
for all profiles.
To access over a site-to-site
connection, enable RDP on the
machine, and ensure that RDP is
allowed in the Windows Firewall ->
Allowed apps and features for
Domain and Private networks.
Make sure the operating system's SAN
policy is set to OnlineAll. Learn more.
Make sure there are no Windows
updates pending on the virtual
machine when you trigger a failover.
Windows update might start when you
failover and you will not be able to
login to the virtual machine until the
update completes.
FAILOVER
LOCATION
ACTIONS
Azure VM running Windows
On Azure VM after failover
For a classic virtual machine, add a
public endpoint for the RDP protocol
(port 3389)
For a Resource Manager virtual
machine, add a public IP on it.
The network security group rules on
the failed over VM, and the Azure
subnet to which it is connected, need
to allow incoming connections to the
RDP port.
For a Resource Manager virtual
machine, you can check Boot
diagnostics to look at a screenshot of
the virtual machine
If you can't connect, check that the VM
is running and then look at these
troubleshooting tips.
Azure VM running Linux
On on-premises machine before
failover
Ensure that the Secure Shell service on
the Azure VM is set to start
automatically on system boot.
Check that firewall rules allow an SSH
connection to it.
Azure VM running Linux
Azure VM after failover
The network security group rules on
the failed over VM, and the Azure
subnet to which it is connected, need
to allow incoming connections to the
SSH port.
For a classic virtual machine, add a
public endpoint should be created, to
allow incoming connections on the SSH
port (TCP port 22 by default).
For a Resource Manager virtual
machine, add a public IP on it.
For a Resource Manager virtual
machine, you can check Boot
diagnostics to look at a screenshot of
the virtual machine
Next steps
Once you have successfully tried a test failover you can try doing a failover.
Reprotect from Azure to an on-premises site
4/27/2017 • 13 min to read • Edit Online
Overview
This article describes how to reprotect Azure virtual machines from Azure to the on-premises site. Follow the
instructions in this article when you're ready to fail back your VMware virtual machines or Windows/Linux physical
servers after they've failed over from the on-premises site to Azure by using Replicate VMware virtual machines
and physical servers to Azure with Azure Site Recovery.
WARNING
If you have completed migration, moved the virtual machine to another resource group, or deleted the Azure virtual
machine, you cannot failback after that.
After reprotect finishes and the protected virtual machines are replicating, you can initiate a failback on the virtual
machines to bring them to the on-premises site.
Post comments or questions at the end of this article or on the Azure Recovery Services Forum.
For a quick overview, watch the following video about how to fail over from Azure to an on-premises site.
Prerequisites
Following are the prerequisite steps that you need to take or consider when you prepare for reprotect.
If the virtual machines that you want to fail back to are managed by a vCenter server, you need to make sure
that you have the required permissions for discovery of virtual machines on vCenter servers. Read more.
WARNING
If snapshots are present on the on-premises mater target or the virtual machine then reprotection will fail. You can delete
the snapshots on the master target before you proceed to reprotect. The snapshots on the virtual machine wll be
automatically merged during reprotect job.
Before you fail back you willll need to create two additional components:
Create a process server. The process server receives data from the protected virtual machine in Azure
and sends data to the on-premises site. A low-latency network is required between the process server
and the protected virtual machine. Thus, you can have an on-premises process server if you are using an
Azure ExpressRoute connection or an Azure process server if you are using a VPN.
Create a master target server: The master target server receives failback data. The on-premises
management server that you created has a master target server installed by default. However, depending
on the volume of failed-back traffic, you might need to create a separate master target server for failback.
A Linux virtual machine needs a Linux master target server.
A Windows virtual machine needs a Windows master target server. You can use the on-premises
process server and master target machines again.
A configuration server is required on premises when you do a failback. During failback, the virtual machine
must exist in the configuration server database. Otherwise, failback won't be successful. Make sure that you take
regularly scheduled backups of your server. If there is a disaster, you need to restore the server with the same IP
address so that failback works.
Ensure that you set the disk.EnableUUID=true setting in configuration parameters of the master target virtual
machine in VMware. If this row does not exist, add it. This setting is required to provide a consistent UUID to the
virtual machine disk (VMDK) so that it mounts correctly.
You cannot use Storage vMotion on master target server. This can cause the failback to fail. The virtual machine
will not start because the disks will not be made available to it. To prevent this, exclude the master target servers
from your vMotion list.
You need add a new drive to the master target server. This drive is called a retention drive. Add a new disk and
format the drive.
Master target has other prerequisites that are listed in Common things to check on a master target before
reprotect.
Why do I need a S2S VPN or an ExpressRoute connection to replicate data back to the on-premises site?
Where replication from on premises to Azure can happen over the Internet or an ExpressRoute connection that has
public peering, reprotect and failback requires a site-to-site (S2S) VPN to replicate data. The network should be
provided so that the failed-over virtual machines in Azure can reach (ping) the on-premises configuration server.
You might also be deploying a process server in the Azure network of the failed-over virtual machine. This process
server should also be able to communicate with the on-premises configuration server.
When should I install a process server in Azure?
The virtual machines on Azure that you want to reprotect send replication data to a process server. Your network
should be set up so that the virtual machines on Azure can reach the process server.
You can deploy a process server in Azure or use the existing process server that you used during failover. The
important point to consider is the latency to send the data from the virtual machines on Azure to the process
server.
If you have an ExpressRoute connection set up, an on-premises process server can be used to send data because
the latency between the virtual machine and the process server is low.
However, if you have only an S2S VPN, then we recommend deploying the process server in Azure.
Remember that replication will happen only over the S2S VPN or the private peering of your ExpressRoute
network. Ensure that enough bandwidth is available over that network channel.
Read more about how to install an Azure process server.
TIP
We always recommend using an Azure based process server during failback. The replication performance is higher if the
process server is closer to the replicating virtual machine (the failed over machine in Azure). However, during your proof of
concepts or demonstrations, you can use the on-premises process server along with ExpressRoute with private peering to
complete the POC faster.
What are the ports to be open on different components so that reprotect can work?
Which master target server should be used for reprotect?
An on-premises master target server is required to receive data from the process server and then write to the onpremises virtual machine's VMDK. If you are protecting Windows virtual machines, you need a Windows master
target server. You can reuse the on-premises process server and master target . For Linux virtual machines, you
need to set up an additional on-premises Linux master target.
Click the following links to read about how to install a master target server:
How to install Windows master target server
How to install Linux master target server
Common things to check after completing installation of the master target server
If the virtual machine is present on premises on the vCenter server, the master target server needs access to
the on-premises virtual machine's VMDK. Access is needed to write the replicated data to the virtual
machine's disks. Ensure that the on-premises virtual machine's datastore is mounted on the master target's
host with read/write access.
If the virtual machine is not present on premises on the vCenter server, Site recovery service needs to create
a new virtual machine during reprotect. This virtual machine will be created on the ESX host on which you
create the master target. Choose the ESX host carefully, so that the failback virtual machine is created on the
host that you want.
You cannot use Storage vMotion for the master target server. This can cause the failback to fail. The virtual
machine will not start because the disks will not be made available to it.
WARNING
In case a master target undergoes a storage vMotion post reprotect, the protected virtual machines disks that are attached
to the master target will migrate to the target of the vMotion. If you try to failback after this, detach of the disk fails citing
that the disks are not found. After this, it becomes very hard to find the disks in your storage accounts. You will need to find
them manually and attach them to the virtual machine. After that the on-premises virtual machine can be booted.
You need to add a new drive to your existing Windows master target server. This drive is called a retention
drive. Add a new disk and format the drive. The retention drive is used to stop the points in time when the
virtual machine replicates back to the on-premises site. Following are some criteria of a retention drive
without which the drive will not be listed for the master target server.
The volume shouldn't be used for any other purpose, such as a target of replication, etc.
The volume shouldn't be in lock mode.
The volume shouldn't be cache volume. The master target installation shouldn't exist on that volume.
The process server and master target custom installation volume is not eligible for a retention
volume. When the process server and master target are installed on a volume, the volume is a cache
volume of the master target.
The file system type of the volume shouldn't be FAT or FAT32.
The volume capacity should be non-zero.
The default retention volume for Windows is R volume.
The default retention volume for Linux is /mnt/retention.
IMPORTANT
You need to add a new drive in case you are using an existing CS+PS machine or a scale or PS+MT machine.
The new drive should meet the above requirements. If the retention drive is not present, none will be listed in
the selection drop down on the portal. After you add a drive to the on-premises master target, it takes upto
fifteen minutes for the drive to reflect in the selection on the portal. You can also refresh the configuration
server if the drive does not appear after fifteen minutes.
A Linux failed-over virtual machine needs a Linux master target server. A Windows failed-over virtual
machine requires a Windows master target server.
Install VMware tools on the master target server. Without the VMware tools, the datastores on the master
target's ESXi host cannot be detected.
Enable the disk.EnableUUID=true parameter on the master target virtual machine by using the vCenter
properties.
The master target should have at least one virtual machine file system (VMFS) datastore attached. If there is
none, the Datastore input on the reprotect page will be empty, and you will not be able to proceed.
The master target server cannot have snapshots on the disks. If there are snapshots, reprotect and failback
will fail.
The master target cannot have a Paravirtual SCSI controller. The controller can only be an LSI Logic
controller. Without an LSI Logic controller, reprotect will fail.
Steps to reprotect
Before reprotection, make sure that you install the process server in Azure and the on-premises Windows or Linux
master target.
NOTE
After a virtual machine boots up in Azure, it takes some time for the agent to register back to the configuration server (up to
15 minutes). During this time, reprotect will fail, and an error message indicates that the agent is not installed. Wait for a few
minutes, and then try reprotect again.
1. In Vault > Replicated items, right-click the virtual machine that's been failed over, and then select Re-Protect.
You can also click the machine and select Re-Protect from the command buttons.
2. In the blade, notice that the direction of protection, Azure to On-premises, is already selected.
3. In Master Target Server and Process Server, select the on-premises master target server and the process
server.
4. Select the Datastore to which you want to recover the disks on premises. This option is used when the onpremises virtual machine is deleted, and you need to create new disks. This option is ignored if the disks already
exist, but you still need to specify a value.
5. Choose the retention drive.
6. The failback policy will be auto-selected.
7. After you click OK to begin reprotection, a job begins to replicate the virtual machine from Azure to the onpremises site. You can track the progress on the Jobs tab.
If you want to recover to an alternate location (when the on-premises virtual machine is deleted), select the
retention drive and datastore that's configured for the master target server. When you fail back to the on-premises
site, the VMware virtual machine's in the failback protection plan will use the same datastore as the master target
server. A new virtual machine will be created in vCenter. If you want to recover the virtual machine on Azure to an
existing on-premises virtual machine, the on-premises virtual machine's datastores should be mounted with
read/write access on the master target server's ESXi host.
You can also reprotect at the level of a recovery plan. A replication group can only be reprotected by using a
recovery plan. When you reprotect by using a recovery plan, you will need to provide the values for every
protected machine.
NOTE
A replication group should be protected back by using the same master target. If they are protected back by using a
different master target server, the server cannot provide a common point in time.
NOTE
The on-premises virtual machine will be turned off during reprotect. This is to ensure the data consistency during replication.
Do not turn on the virtual machine after reprotect completes.
After the reprotect succeed, the virtual machine will enter a protected state.
Next steps
After the virtual machine has entered a protected state, you can initiate a failback. The failback will shut down the
virtual machine in Azure and boot the on-premises virtual machine. Hence there is a small downtime for the
application. So, choose the time for failback when your application can tolerate a downtime.
Steps to initiate failback of the virtual machine
Common issues
If you used a template to create your virtual machines, ensure that each virtual machine has a unique UUID for
the disks. If the on-premises virtual machine's UUID clashes with that of the master target because both were
created from the same template, reprotection will fail. You need to deploy another master target that has not
been created from the same template.
If you perform a read-only user vCenter discovery and protect virtual machines, protection succeeds, and
failover works. During reprotection, failover fails because the datastores cannot be discovered. As a symptom,
you will not see the datastores listed during reprotection. To resolve this issue, you can update the vCenter
credential with an appropriate account that has permissions, and retry the job. For more information, see
Replicate VMware virtual machines and physical servers to Azure with Azure Site Recovery.
When you fail back a Linux virtual machine and run it on premises, you can see that the Network Manager
package has been uninstalled from the machine. This uninstallation happens because the Network Manager
package is removed when the virtual machine is recovered in Azure.
When a Linux virtual machine is configured with a static IP address and is failed over to Azure, the IP address is
acquired from DHCP. When you fail over to on premises, the virtual machine continues to use DHCP to acquire
the IP address. Manually sign in to the machine, and set the IP address back to a static address if necessary. A
Windows virtual machine can acquire its static IP again.
If you use either ESXi 5.5 free edition or vSphere 6 Hypervisor free edition, failover succeeds, but failback does
not succeed. To enable failback, upgrade to either program's evaluation license.
If you cannot reach the configuration server from the process server, use Telnet to check connectivity to the
configuration server on port 443. You can also try to ping the configuration server from the process server. A
process server should also have a heartbeat when it is connected to the configuration server.
If you are trying to fail back to an alternate vCenter, make sure that your new vCenter is discovered and that the
master target server is also discovered. A typical symptom is that the datastores are not accessible or visible in
the Reprotect dialog box.
A Windows Server 2008 R2 SP1 server that is protected as a physical on-premises server cannot be failed back
from Azure to an on-premises site.
Fail back VMware virtual machines and physical
servers to the on-premises site
4/27/2017 • 16 min to read • Edit Online
This article describes how to failback Azure virtual machines from Azure to the on-premises site. Follow the
instructions here when you're ready to fail back your VMware virtual machines or Windows or Linux physical
servers after you have re-protected your machines using this reference.
NOTE
If you are using the classic Azure portal, please refer to instructions mentioned here for enhanced VMware to Azure
architecture and here for the legacy architecture
Overview
The diagrams in this section show the failback architecture for this scenario.
When the Process Server is on-premises and you are using an Azure ExpressRoute connection, use this
architecture:
When the Process Server is on Azure and you have either a VPN or an ExpressRoute connection, use this
architecture:
For a complete list of ports and the failback architecture diagram, refer to the following image:
After you’ve failed over to Azure, you fail back to your on-premises site in three stages:
Stage 1: You reprotect the Azure VMs so that they start replicating back to the VMware VMs that are running
on your on-premises site.
Stage 2: After your Azure VMs are replicated to your on-premises site, you run a failover to fail back from
Azure.
Stage 3: After your data has failed back, you reprotect the on-premises VMs that you failed back to, so that
they start replicating to Azure.
Fail back to the original location or an alternate location
After you fail over a VMware VM, you can fail back to the same source VM if it still exists on-premises. In this
scenario, only the deltas are failed back.
If you failed over physical servers, failback is always to a new VMware VM. Before failing back a physical machine,
note that:
A protected physical machine will come back as a virtual machine when it is failed over back from Azure to
VMware. A Windows Server 2008 R2 SP1 physical machine, if it is protected and failed over to Azure, cannot
be failed back. A Windows Server 2008 R2 SP1 machine that started as a virtual machine on-premises will be
able to fail back.
Ensure that you discover at least one master target server along with the necessary ESX/ESXi hosts that you
need to fail back to.
If you fail back to the original VM, the following are required:
If the VM is managed by a vCenter server, the master target's ESX host should have access to the VMs
datastore.
If the VM is on an ESX host but isn’t managed by vCenter, the hard disk of the VM must be in a datastore that's
accessible by the MT's host.
If your VM is on an ESX host and doesn't use vCenter, you should complete discovery of the ESX host of the MT
before you reprotect. This applies if you're failing back physical servers too.
Another option (if the on-premises VM exists) is to delete it before you do a failback. Failback then creates a
new VM on the same host as the master target ESX host.
When you fail back to an alternate location, the data is recovered to the same datastore and the same ESX host as
that used by the on-premises master target server.
Prerequisites
To fail back VMware VMs and physical servers, you need a VMware environment. Failing back to a physical
server isn’t supported.
To fail back, you must have created an Azure network when you initially set up protection. Failback needs a
VPN or ExpressRoute connection from the Azure network in which the Azure VMs are located to the onpremises site.
If the VMs that you want to fail back to are managed by a vCenter server, make sure that you have the required
permissions for discovery of VMs on vCenter servers. For more information, see Replicate VMware virtual
machines and physical servers to Azure with Azure Site Recovery.
If snapshots are present on a VM, reprotection fails. You can delete the snapshots or the disks.
Before you fail back, create these components:
Create a Process Server in Azure. This component is an Azure VM that you create and keep running
during failback. You can delete the VM after failback is complete.
Create a master target server: The master target server sends and receives failback data. The
management server that you created on-premises has a master target server that's installed by default.
However, depending on the volume of failed-back traffic, you might need to create a separate master
target server for failback.
To create an additional master target server that runs on Linux, set up the Linux VM before you install
the master target server, as described later.
A configuration server is required on-premises when you do a failback. During failback, the virtual machine
must exist in the configuration server database. If the configuration server database contains no VM, failback
cannot succeed. Therefore, ensure that you make regular scheduled backups of your server. In a disaster, you
need to restore it with the same IP address so that failback works.
Set the disk.enableUUID=true setting in Configuration Parameters of the master target VM in VMware. If this
row does not exist, add it. This setting is required to provide a consistent universally unique identifier (UUID) to
the virtual machine disk (VMDK) file so that it is mounted correctly.
Be aware of a "Master target server cannot be storage vMotioned" condition, which can cause the failback to
fail. The VM cannot come up because the disks aren't made available to it.
Add a drive, called a retention drive, onto the master target server. Add a disk, and format the drive.
Failback policy
To replicate back to on-premises, you need a failback policy. The policy is automatically created when you create a
forward direction policy, and it is automatically associated with the configuration server. It is not editable. The
policy has the following replication settings:
RPO threshold = 15 minutes
Recovery point retention = 24 hours
App consistent snapshot frequency = 60 minutes
Set up a Process Server in Azure
Install a Process Server in Azure so that the Azure VMs can send the data back to the on-premises master target
server.
If you have protected your virtual machines as classic resources (that is, the VM recovered in Azure is a VM that
was created by using the classic deployment model), you need a Process Server in Azure. If you have recovered
the VMs with Azure Resource Manager as the deployment type, the Process Server must have Resource Manager
as the deployment type. The deployment type is selected by the Azure virtual network that you deploy the Process
Server to.
1. In Vault > Settings > Site Recovery Infrastructure (under Manage) > Configuration Servers (under For
VMware and Physical Machines), select the configuration server.
2. Click Process Server.
3. Choose to deploy the Process Server as Deploy a failback Process Server in Azure.
4. Select the subscription that you have recovered the VMs to.
5. Select the Azure network that you have recovered the VMs to. The Process Server needs to be in the same
network so that the recovered VMs and the Process Server can communicate.
6. If you selected a classic deployment model network, create a VM via the Azure Marketplace, and then install
the Process Server in it.
As you're creating the Process Server, pay attention to the following:
The name of the image is Microsoft Azure Site Recovery Process Server V2. Select Classic as the
deployment model.
Install the Process Server according to the instructions in Replicate VMware virtual machines and
physical servers to Azure with Azure Site Recovery.
7. If you select the Resource Manager Azure network, deploy the Process Server by providing the following
information:
The name of the resource group that you want to deploy the server to
The name of the server
A username and password for signing in to the server
The storage account that you want to deploy the server to
The subnet and the network interface that you want to connect to it
NOTE
You must create your own network interface (NIC) and select it while you are deploying the Process Server.
8. Click OK. This action triggers a job that creates a Resource Manager deployment type virtual machine
during the Process Server setup. To register the server to the configuration server, run the setup inside the
VM by following the instructions in Replicate VMware virtual machines and physical servers to Azure with
Azure Site Recovery. A job to deploy the Process Server is also triggered.
The Process Server is listed on the Configuration servers > Associated servers > Process Servers tab.
NOTE
The Process Server isn't visible under VM properties. It's visible only on the Servers tab in the management server
that it's registered to. It can take 10 to 15 minutes for the Process Server to appear.
Set up the master target server on-premises
The master target server receives the failback data. The server is automatically installed on the on-premises
management server, but if you're failing back too much data, you might need to set up an additional master target
server. To set up a master target server on-premises, do the following:
NOTE
To set up a master target server on Linux, skip to the next procedure. Use only CentOS 6.6 minimal operating system as the
master target OS.
1. If you're setting up the master target server on Windows, open the quick-start page from the VM that you're
installing the master target server on.
2. Download the installation file for the Azure Site Recovery Unified Setup wizard.
3. Run the setup and, in Before you begin, select Add additional Process Servers to scale out deployment.
4. Complete the wizard in the same way you did when you set up the management server. On the Configuration
Server Details page, specify the IP address of the master target server, and enter a passphrase to access the
VM.
Set up a Linux VM as the master target server
To set up the management server running the master target server as a Linux VM, install the CentOS 6.6 minimal
operating system. Next, retrieve the SCSI IDs for each SCSI hard disk, install some additional packages, and apply
some custom changes.
Install CentOS 6.6
1. Install the CentOS 6.6 minimal operating system on the management server VM. Keep the ISO on a DVD drive,
and boot the system. Skip the media testing. Select US English as the language, select Basic Storage Devices,
check that the hard drive doesn’t have any important data, click Yes, and discard any data. Enter the host name
of the management server, and select the server network adapter. In the Editing System dialog box, select
Connect automatically, and then add a static IP address, network, and DNS settings. Specify a time zone. To
access the management server, enter the root password.
2. When you're asked what type of installation you want, select Create Custom Layout as the partition. Click
Next. Select Free, and then click Create. Create /, /var/crash, and /home partitions with FS Type: ext4.
Create the swap partition as FS Type: swap.
3. If pre-existing devices are found, a warning message appears. Click Format to format the drive with the
partition settings. Click Write change to disk to apply the partition changes.
4. Select Install boot loader > Next to install the boot loader on the root partition.
5. When the installation is complete, click Reboot.
Retrieve the SCSI IDs
1. After the installation, retrieve the SCSI IDs for each SCSI hard disk in the VM. To do so, shut down the
management server VM. In the VM properties in VMware, right-click the VM entry > Edit Settings > Options.
2. Select Advanced > General item, and then click Configuration Parameters. This option is unavailable when
the machine is running. For the option to be available, the machine must be shut down.
3. Do either of the following:
If the row disk.EnableUUID exists, make sure that the value is set to True (case sensitive). If the value is
already set to True, you can cancel and test the SCSI command inside a guest operating system after it’s
booted.
If the row disk.EnableUUID doesn’t exist, click Add Row, and then add it with the True value. Don’t use
double quotation marks.
Install additional packages
Download and install additional packages.
1. Make sure the master target server is connected to the Internet.
2. To download and install 15 packages from the CentOS repository, run this command:
# yum install –y xfsprogs perl lsscsi rsync wget kexec-tools .
3. If the source machines you’re protecting are running Linux with a Reiser or XFS file system for the root or
boot device, download and install additional packages as follows:
# cd /usr/local
# wget http://elrepo.org/linux/elrepo/el6/x86_64/RPMS/kmod-reiserfs-0.0-1.el6.elrepo.x86_64.rpm
# wget http://elrepo.org/linux/elrepo/el6/x86_64/RPMS/reiserfs-utils-3.6.21-1.el6.elrepo.x86_64.rpm
# rpm –ivh kmod-reiserfs-0.0-1.el6.elrepo.x86_64.rpm reiserfs-utils-3.6.21-1.el6.elrepo.x86_64.rpm
# wget http://mirror.centos.org/centos/6.6/os/x86_64/Packages/xfsprogs-3.1.1-16.el6.x86_65.rpm
# rpm –ivh xfsprogs-3.1.1-16.el6.x86_64.rpm
# yum install device-mapper-multipath (required to enable multipath packages on the master target
server)
Apply custom changes
After you’ve completed the post-installation steps and installed the packages, apply custom changes by doing the
following:
1. Copy the RHEL 6-64 Unified Agent binary to the VM. To untar the binary, run this command:
tar –zxvf <file name> .
2. To give permissions, run this command: # chmod 755 ./ApplyCustomChanges.sh .
3. Run the following script: # ./ApplyCustomChanges.sh . Run it only once. After it runs successfully, reboot the
server.
Run the failback
Reprotect the Azure VMs
1. In Vault, in Replicated items, right-click the VM that has been failed over, and then select Re-Protect.
2. On the blade, you can see that the direction of protection Azure to On-premises is already selected.
3. In Master Target Server and Process Server, select the on-premises master target server and the Azure VM
Process Server.
4. Select the datastore that you want to recover the disks on-premises to. Use this option when the on-premises
VM is deleted and you need to create new disks. Ignore the option if the disks already exist, but you still need to
specify a value.
5. Use a retention drive to stop the points in time when the VM is replicated back to on-premises. Some
criteria of a retention drive are listed here. Without these criteria, the drive is not listed for the master target
server.
Volume shouldn't be in use for any other purpose (target of replication, and so forth).
Volume shouldn't be in lock mode.
Volume shouldn't be cache volume. (The master target installation shouldn't exist on that volume. The
Process Server plus master target custom installation volume is not eligible for retention volume. Here,
the installed Process Server plus master target volume is the cache volume of the master target.)
The volume file system type shouldn't be FAT and FAT32.
The volume capacity should be non-zero.
The default retention volume for Windows is R volume.
The default retention volume for Linux is /mnt/retention.
6. The failback policy is automatically selected.
7. After you click OK to begin reprotection, a job begins to replicate the VM from Azure to the on-premises site.
You can track the progress on the Jobs tab.
If you want to recover to an alternate location, select the retention drive and datastore that are configured for the
master target server. When you fail back to the on-premises site, the VMware VMs in the failback protection plan
use the same datastore as the master target server. If you want to recover the replica Azure VM to the same onpremises VM, the on-premises VM should already be in the same datastore as the master target server. If there's
no VM on-premises, a new one is created during reprotection.
You can also reprotect at a recovery plan level. If you have a replication group, you can reprotect it only by using a
recovery plan. When you reprotect by using a recovery plan, use the previous values for every protected machine.
NOTE
Replication groups should be protected back with the same master target. If they are protected back with different master
target servers, a common point in time cannot be determined for them.
Run a failover to the on-premises site
After you reprotect the VM, you can initiate a failover from Azure to on-premises.
1. On the replicated items page, right-click the virtual machine, and then select Unplanned Failover.
2. In Confirm Failover, verify the failover direction (from Azure), and then select the recovery point that you
want to use for the failover (the latest, or the latest app-consistent recovery point). An app-consistent recovery
point occurs before the most recent point in time, and it will cause some data loss.
3. During failover, Site Recovery shuts down the Azure VMs. After you check that failback has been completed as
expected, you can check to ensure that the Azure VMs have been shut down as expected.
Reprotect the on-premises site
After failback has been completed, commit the virtual machine to ensure that the VMs recovered in Azure are
deleted. To do so, right-click the protected item, and then click Commit. This action triggers a job that removes the
former recovered virtual machines in Azure.
After the commit is completed, your data should be back on the on-premises site, but it won’t be protected. To
start replicating to Azure again, do the following:
1. In Vault, in Setting > Replicated items, select the VMs that have failed back, and then click Re-Protect.
2. Give the value of the Process Server that needs to be used to send data back to Azure.
3. Click OK.
After the reprotection is complete, the VM replicates back to Azure and you can do a failover.
Resolve common failback issues
If you perform a read-only user vCenter discovery and protect virtual machines, it succeeds and failover works.
During reprotection, failover fails because the datastores cannot be discovered. As a symptom, you will not see
the datastores listed during reprotection. To resolve this issue, you can update the vCenter credential with an
appropriate account that has permissions and retry the job. For more information, see Replicate VMware
virtual machines and physical servers to Azure with Azure Site Recovery
When you fail back a Linux VM and run it on-premises, you can see that the Network Manager package has
been uninstalled from the machine. This uninstallation happens because the Network Manager package is
removed when the VM is recovered in Azure.
When a VM is configured with a static IP address and is failed over to Azure, the IP address is acquired via
DHCP. When you fail over back to on-premises, the VM continues to use DHCP to acquire the IP address.
Manually sign in to the machine and set the IP address back to a static address if necessary.
If you are using either ESXi 5.5 free edition or vSphere 6 Hypervisor free edition, failover would succeed, but
failback would not succeed. To enable failback, upgrade to either program's evaluation license.
If you cannot reach the configuration server from the Process Server, check connectivity to the configuration
server by Telnet to the configuration server machine on port 443. You can also try to ping the configuration
server from the Process Server machine. A Process Server should also have a heartbeat when it is connected to
the configuration server.
If you are trying to fail back to an alternate vCenter, make sure that your new vCenter is discovered and that
the master target server is also discovered. A typical symptom is that the datastores are not accessible or
visible in the Reprotect dialog box.
A WS2008R2SP1 machine that is protected as a physical on-premises machine cannot be failed back from
Azure to on-premises.
Fail back with ExpressRoute
You can fail back over a VPN connection or by using an ExpressRoute connection. If you want to use an
ExpressRoute connection, note the following:
The ExpressRoute connection should be set up on the Azure virtual network that the source machines fail over
to and where the Azure VMs are located after the failover occurs.
Data is replicated to an Azure storage account on a public endpoint. To use an ExpressRoute connection, set up
public peering in ExpressRoute with the target data center for Site Recovery replication.
Migrate to Azure with Site Recovery
4/6/2017 • 3 min to read • Edit Online
Read this article for an overview of using the Azure Site Recovery service for migration of virtual machines and
physical servers.
Site Recovery is an Azure service that contributes to your BCDR strategy, by orchestrating replication of onpremises physical servers and virtual machines to the cloud (Azure), or to a secondary datacenter. When outages
occur in your primary location, you fail over to the secondary location to keep apps and workloads available. You
fail back to your primary location when it returns to normal operations. Learn more in What is Site Recovery? You
can also use Site Recovery to migrate your existing on-premises workloads to Azure to expedite your cloud
journey and avail the array of features that Azure offers.
For a quick overview of how to perform migration, please refer to this video.
This article describes deployment in the Azure portal. The Azure classic portal can be used to maintain existing Site
Recovery vaults, but you can't create new vaults.
Post any comments at the bottom of this article. Ask technical questions on the Azure Recovery Services Forum.
What do we mean by migration?
You can deploy Site Recovery for replication of on-premises VMs and physical servers, to Azure or to a secondary
site. You replicate machines, fail them over from the primary site when outages occur, and fail them back to the
primary site when it recovers. In addition to this, you can use Site Recovery to migrate VMs and physical servers to
Azure, so that users can access them as Azure VMs. Migration entails replication, and failover from the primary site
to Azure, and a complete migration gesture.
What can Site Recovery migrate?
You can:
Migrate workloads running on on-premises Hyper-V VMs, VMware VMs, and physical servers, to run on Azure
VMs. You can also do full replication and failback in this scenario.
Migrate Azure IaaS VMs between Azure regions. Currently only migration is supported in this scenario, which
means failback isn't supported.
Migrate AWS Windows instances to Azure IaaS VMs. Currently only migration is supported in this scenario,
which means failback isn't supported.
Migrate on-premises VMs and physical servers
To migrate on-premises Hyper-V VMs, VMware VMs, and physical servers, you follow almost the same steps as
those used for regular replication.
1. Set up a Recovery Services vault
2. Configure the required management servers (VMware, VMM, Hyper-V - depending on what you want to
migrate), add them to the vault, and specify replication settings.
3. Enable replication for the machines you want to migrate
4. After the initial migration, run a quick test failover to ensure that everything's working as it should.
5. After you verify that your replication environment is working, you use a planned or unplanned failover
depending on what's supported for your scenario. We recommend you use a planned failover when possible.
6. For migration, you don't need to commit a failover, or delete it. Instead, you select the Complete Migration
option for each machine you want to migrate.
In Replicated Items, right-click the VM, and click Complete Migration. Click OK to complete. You can
track progress in the VM properties, in by monitoring the Complete Migration job in Site Recovery
jobs.
The Complete Migration action finishes up the migration process, removes replication for the
machine, and stops Site Recovery billing for the machine.
Migrate between Azure regions
You can migrate Azure VMs between regions using Site Recovery. In this scenario only migration is supported. In
other words, you can replicate the Azure VMs and fail them over to another region, but you can't fail back. In this
scenario you set up a Recovery Services vault, deploy an on-premises configuration server to manage replication,
add it to the vault, and specify replication settings. You enable replication for the machines you want to migrate,
and run a quick test failover. Then you run an unplanned failover with the Complete Migration option.
Migrate AWS to Azure
You can migrate AWS instances to Azure VMs. In this scenario only migration is supported. In other words, you
can replicate the AWS instances and fail them over to Azure, but you can't fail back. AWS instances are handled in
the same way as physical servers for migration purposes. You set up a Recovery Services vault, deploy an onpremises configuration server to manage replication, add it to the vault, and specify replication settings. You
enable replication for the machines you want to migrate, and run a quick test failover. Then you run an unplanned
failover with the Complete Migration option.
Next steps
Migrate VMware VMs to Azure
Migrate Hyper-V VMs in VMM clouds to Azure
Migrate Hyper-V VMs without VMM to Azure
Migrate Azure VMs between Azure regions
Migrate AWS instances to Azure
Migrate Azure IaaS virtual machines between Azure
regions with Azure Site Recovery
3/14/2017 • 2 min to read • Edit Online
Overview
Welcome to Azure Site Recovery! Use this article if you want to migrate Azure VMs between Azure regions. Before
you start, note that:
Azure has two different deployment models for creating and working with resources: Azure Resource Manager
and classic. Azure also has two portals – the Azure classic portal that supports the classic deployment model,
and the Azure portal with support for both deployment models. The basic steps for migration are the same
whether you're configuring Site Recovery in Resource Manager or in classic. However the UI instructions and
screenshots in this article are relevant for the Azure portal.
Currently you can only migrate from one region to another. You can fail over VMs from one Azure
region to another, but you can't fail them back again.
The migration instructions in this article are based on the instructions for replicating a physical machine to
Azure. It includes links to the steps in Replicate VMware VMs or physical servers to Azure, which describes how
to replicate a physical server in the Azure portal.
If you're setting up Site Recovery in the classic portal, follow the detailed instructions in this article.
Post any comments or questions at the bottom of this article, or on the Azure Recovery Services Forum.
Prerequisites
Here's what you need for this deployment:
Configuration server: An on-premises VM running Windows Server 2012 R2 that acts as the configuration
server. You install the other Site Recovery components (including the process server and master target server)
on this VM too. Read more in scenario architecture and configuration server prerequisites.
IaaS virtual machines: The VMs you want to migrate. You migrate these VMs by treating them as physical
machines.
Deployment steps
This section describes the deployment steps in the new Azure portal.
1. Create a vault.
2. Deploy a configuration server.
3. After you've deployed the configuration server, check that it can communicate with the VMs that you want to
migrate.
4. Set up replication settings. Create a replication policy and assign to the configuration server.
5. Install the Mobility service. Each VM you want to protect needs the Mobility service installed. This service sends
data to the process server. The Mobility service can be installed manually or pushed and installed automatically
by the process server when protection for the VM is enabled. Firewall rules on the VMs that you want to
migrate should be configured to allow push installation of this service.
6. Enable replication. Enable replication for the VMs you want to migrate. You can discover the IaaS virtual
machines that you want to migrate to Azure using the private IP address of the virtual machines. Find this
address on the virtual machine dashboard in Azure. When you enable replication, you set the machine type for
the VMs as physical machines.
7. Run an unplanned failover. After initial replication is complete, you can run an unplanned failover from one
Azure region to another. Optionally, you can create a recovery plan and run an unplanned failover, to migrate
multiple virtual machines between regions. Learn more about recovery plans.
Next steps
Learn more about other replication scenarios in What is Azure Site Recovery?
Migrate virtual machines in Amazon Web Services
(AWS) to Azure with Azure Site Recovery
3/14/2017 • 2 min to read • Edit Online
This article describes how to migrate AWS Windows instances to Azure virtual machines with the Azure Site
Recovery service.
Migration is effectively a failover from AWS to Azure. You can't failback machines to AWS, and there's no ongoing
replication. This article describes the steps for migration in the Azure portal, and are based on the instructions for
replicating a physical machine to Azure.
Post any comments or questions at the bottom of this article, or on the Azure Recovery Services Forum
Supported operating systems
Site Recovery can be used to migrate EC2 instances running any of the following operating systems:
Windows(64 bit only)
Windows Server 2008 R2 SP1+ (Citrix PV drivers or AWS PV drivers only. Instances running RedHat
PV drivers are not supported) Windows Server 2012 Windows Server 2012 R2
Linux (64 bit only)
Red Hat Enterprise Linux 6.7 (HVM virtualized instances only)
Prerequisites
Here's what you need for this deployment
Configuration server: An Amazon EC2 VM running Windows Server 2012 R2 is deployed as the
configuration server. By default, the other Azure Site Recovery components (process server and master
target server) are installed when you deploy the configuration server. This article describes the steps for
migration in the Azure portal, and are based on the instructions for Learn more
EC2 instances: The Amazon EC2 virtual machines instances that you want to migrate.
Deployment steps
1. Create a Recovery Services vault
2. The Security Group of your EC2 instances should have the following rules configured:
3. On the same Amazon Virtual Private Cloud as your EC2 instances, deploy an ASR configuration server. Refer
the VMware / Physical to Azure prerequisites for configuration server deployment requirements
4. Once your configuration server is deployed in AWS and registered with your Recovery Services vault, you
should see the configuration server and process server under Site Recovery infrastructure as shown below:
NOTE
It may take up to 15 minutes for the configuration server and process server to show up
5. After you've deployed the configuration server, validate that it can communicate with the VMs that you
want to migrate.
6. Set up replication settings
7. Enable replication: Enable replication for the VMs you want to migrate. You can discover the EC2 instances
using the private IP addresses, which you can get from the EC2 console.
8. Once the EC2 instances have been protected and the replication to Azure is complete, run a Test Failover to
validate your application's performance in Azure
9. Run a Failover from AWS to Azure for each VM. Optionally, you can create a recovery plan and run a
Failover, to migrate multiple virtual machines from AWS to Azure. Learn more about recovery plans.
10. For migration, you don't need to commit a failover. Instead, you select the Complete Migration option for
each machine you want to migrate. The Complete Migration action finishes up the migration process,
removes replication for the machine, and stops Site Recovery billing for the machine.
Protect Active Directory and DNS with Azure Site
Recovery
3/17/2017 • 10 min to read • Edit Online
Enterprise applications such as SharePoint, Dynamics AX, and SAP depend on Active Directory and a DNS
infrastructure to function correctly. When you create a disaster recovery solution for applications, it's important to
remember that you need to protect and recover Active Directory and DNS before the other application
components, to ensure that things function correctly when disaster occurs.
Site Recovery is an Azure service that provides disaster recovery by orchestrating replication, failover, and
recovery of virtual machines. Site Recovery supports a number of replication scenarios to consistently protect, and
seamlessly failover virtual machines and applications to private, public, or hoster clouds.
Using Site Recovery, you can create a complete automated disaster recovery plan for Active Directory. When
disruptions occur, you can initiate a failover within seconds from anywhere and get Active Directory up and
running in a few minutes. If you've deployed Active Directory for multiple applications such as SharePoint and
SAP in your primary site, and you want to fail over the complete site, you can fail over Active Directory first using
Site Recovery, and then fail over the other applications using application-specific recovery plans.
This article explains how to create a disaster recovery solution for Active Directory, how to perform planned,
unplanned, and test failovers using a one-click recovery plan, the supported configurations, and prerequisites. You
should be familiar with Active Directory and Azure Site Recovery before you start.
Replicating Domain Controller
You need to setup Site Recovery replication on at least one virtual machine hosting Domain Controller and DNS. If
you have multiple domain controllers in your environment, in addition to replicating the domain controller virtual
machine with Site Recovery you would also have to set up an additional domain controller on the target site
(Azure or a secondary on-premises datacenter).
Single domain controller environment
If you have a few applications and only a single domain controller, and you want to fail over the entire site
together, then we recommend using Site Recovery to replicate the domain controller to the secondary site
(whether you're failing over to Azure or to a secondary site). The same replicated domain controller/DNS virtual
machine can be used for test failover as well.
Environment with multiple domain controllers
If you have many applications and there's more than one domain controller in the environment, or if you plan to
fail over a few applications at a time, we recommend that in addition to replicating the domain controller virtual
machine with Site Recovery you also set up an additional domain controller on the target site (Azure or a
secondary on-premises datacenter). For test failover, you use domain controller replicated by Site Recovery and
for failover, the additional domain controller the on target site.
The following sections explain how to enable protection for a domain controller in Site Recovery, and how to set
up a domain controller in Azure.
Prerequisites
An on-premises deployment of Active Directory and DNS server.
An Azure Site Recovery Services vault in a Microsoft Azure subscription.
If you're replicating to Azure, run the Azure Virtual Machine Readiness Assessment tool on VMs to ensure
they're compatible with Azure VMs and Azure Site Recovery Services.
Enable protection using Site Recovery
Protect the virtual machine
Enable protection of the domain controller/DNS virtual machine in Site Recovery. Configure Site Recovery settings
based on the virtual machine type (Hyper-V or VMware). The domain controller replicated using Site Recovery is
used for test failover. Make sure it meets the following requirements:
1. The domain controller is a global catalog server
2. The domain controller should be the FSMO role owner for roles that will be needed during a test failover (else
these roles will need to be seized after the failover)
Configure virtual machine network settings
For the domain controller/DNS virtual machine, configure network settings in Site Recovery so that the virtual
machine will be attached to the right network after failover.
Protect Active Directory with Active Directory replication
Site -to -site protection
Create a domain controller on the secondary site. When you promote the server to a domain controller role,
specify the name of the same domain that is being used on the primary site. You can use the Active Directory
Sites and Services snap-in to configure settings on the site link object to which the sites are added. By
configuring settings on a site link, you can control when replication occurs between two or more sites, and how
often. For more information, see Scheduling Replication Between Sites.
Site -to -Azure protection
Follow the instructions to create a domain controller in an Azure virtual network. When you promote the server to
a domain controller role, specify the same domain name that's used on the primary site.
Then reconfigure the DNS server for the virtual network, to use the DNS server in Azure.
DNS in Azure Production Network
Test failover considerations
Test failover occurs in a network that's isolated from production network so that there's no impact on production
workloads.
Most applications also require the presence of a domain controller and a DNS server to function. Therefore, before
the application is failed over, a domain controller needs to be created in the isolated network to be used for test
failover. The easiest way to do this is to replicate a domain controller/DNS virtual machine with Site Recovery.
Then run a test failover of the domain controller virtual machine before running a test failover of the recovery plan
for the application. Here's how you do that:
1. Replicate the domain controller/DNS virtual machine using Site Recovery.
2. Create an isolated network. Any virtual network created in Azure by default is isolated from other networks. We
recommend that the IP address range for this network is same as that of your production network. Don't
enable site-to-site connectivity on this network.
3. Provide a DNS IP address in the network created, as the IP address that you expect the DNS virtual machine
to get. If you're replicating to Azure, then provide the IP address for the VM that is used on failover in
Target IP setting in Compute and Network settings.
Target IP
DNS in Azure Test Network
TIP
Site Recovery attempts to create test virtual machines in a subnet of same name and using the same IP as that provided in
Compute and Network settings of the virtual machine. If subnet of same name is not available in the Azure virtual
network provided for test failover, then test virtual machine is created in the first subnet alphabetically. If the target IP is
part of the chosen subnet, then Site Recovery tries to create the test failover virtual machine using the target IP. If the
target IP is not part of the chosen subnet, then test failover virtual machine gets created using any available IP in the
chosen subnet.
1. If you're replicating to another on-premises site and you're using DHCP, follow the instructions to setup DNS
and DHCP for test failover
2. Do a test failover of the domain controller virtual machine run in the isolated network. Use latest available
application consistent recovery point of the domain controller virtual machine to do the test failover.
3. Run a test failover for the recovery plan that contains virtual machines of the application.
4. After testing is complete, Cleanup test failover on the domain controller virtual machine. This step deletes the
domain controller that was created for test failover.
Removing reference to other domain controllers
When you are doing a test failover, you don't bring all the domain controllers in the test network. To remove the
reference of other domain controllers that exist in your production environment, you might need to seize FSMO
Active Directory roles and do metadata cleanup for missing domain controllers.
IMPORTANT
Some of the configurations described in the following section are not the standard/default domain controller configurations.
If you don't want to make these changes to a production domain controller, then you can create a domain controller
dedicated to be used for Site Recovery test failover and make these changes to that.
Issues because of virtualization safeguards
Beginning with Windows Server 2012, additional safeguards have been built into Active Directory Domain
Services. These safeguards help protect virtualized domain controllers against USN Rollbacks, as long as the
underlying hypervisor platform supports VM-GenerationID. Azure supports VM-GenerationID, which means that
domain controllers that run Windows Server 2012 or later on Azure virtual machines have the additional
safeguards.
When the VM-GenerationID is reset, the invocationID of the AD DS database is also reset, the RID pool is
discarded, and SYSVOL is marked as non-authoritative. For more information, see Introduction to Active Directory
Domain Services Virtualization and Safely Virtualizing DFSR
Failing over to Azure may cause resetting of VM-GenerationID and that kicks in the additional safeguards when
the domain controller virtual machine starts in Azure. This may result in a significant delay in user being able to
login to the domain controller virtual machine. Since this domain controller would be used only in a test failover,
virtualization safeguards are not necessary. To ensure that VM-GenerationID for the domain controller virtual
machine doesn't change, then you can change the value of following DWORD to 4 in the on-premises domain
controller.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\gencounter\Start
Symptoms of virtualization safeguards
If virtualization safeguards have kicked in after a test failover, you may see one or more of following symptoms:
Generation ID change
Invocation ID change
Sysvol and Netlogon shares are not available
Any DFSR databases are deleted
IMPORTANT
Some of the configurations described in the following section are not the standard/default domain controller configurations.
If you don't want to make these changes to a production domain controller, then you can create a domain controller
dedicated to be used for Site Recovery test failover and make these changes to that.
Troubleshooting domain controller issues during test failover
On a command prompt, run the following command to check whether SYSVOL and NETLOGON folders are
shared:
NET SHARE
On the command prompt, run the following command to ensure that the domain controller is functioning
properly.
dcdiag /v > dcdiag.txt
In the output log, look for following text to confirm that the domain controller is functioning well.
"passed test Connectivity"
"passed test Advertising"
"passed test MachineAccount"
If the preceding conditions are satisfied, it is likely that the domain controller is functioning well. If not, try
following steps.
Do an authoritative restore of the domain controller.
Although it is not recommended to use FRS replication, but if you are still using it then follow the steps
provided here to do an authoritative restore. You can read more about Burflags talked about in the
previous link here.
If you are using DFSR replication, then follow the steps available here to do an authoritative restore. You
can also use Powershell functions available on this link for this purpose.
Bypass initial synchronization requirement by setting following registry key to 0 in the on-premises domain
controller. If this DWORD doesn't exist, then you can create it under node 'Parameters'. You can read more
about it here
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial
Synchronizations
Disable the requirement that a global catalog server is available to validate user logon by setting following
registry key to 1 in the on-premises domain controller. If this DWORD doesn't exist, then you can create it
under node 'Lsa'. You can read more about it here
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\IgnoreGCFailures
DNS and domain controller on different machines
If DNS isn't on the same virtual machine as the domain controller, you need to create a DNS VM for the test
failover. If they're on the same VM, you can skip this section.
You can use a fresh DNS server and create all the required zones. For example, if your Active Directory domain is
contoso.com, you can create a DNS zone with the name contoso.com. The entries corresponding to Active
Directory must be updated in DNS, as follows:
1. Ensure these settings are in place before any other virtual machine in the recovery plan comes up:
The zone must be named after the forest root name.
The zone must be file-backed.
The zone must be enabled for secure and non-secure updates.
The resolver of the domain controller virtual machine should point to the IP address of the DNS virtual
machine.
2. Run the following command on domain controller virtual machine:
nltest /dsregdns
3. Add a zone on the DNS server, allow non-secure updates, and add an entry for it to DNS:
dnscmd
dnscmd
dnscmd
dnscmd
/zoneadd contoso.com /Primary
/recordadd contoso.com contoso.com. SOA %computername%.contoso.com. hostmaster. 1 15 10 1 1
/recordadd contoso.com %computername% A <IP_OF_DNS_VM>
/config contoso.com /allowupdate 1
Next steps
Read What workloads can I protect? to learn more about protecting enterprise workloads with Azure Site
Recovery.
Protect SQL Server using SQL Server disaster
recovery and Azure Site Recovery
5/5/2017 • 8 min to read • Edit Online
This article describes how to protect the SQL Server back end of an application using a combination of SQL Server
business continuity and disaster recovery (BCDR) technologies, and Azure Site Recovery.
Before you start, make sure you understand SQL Server disaster recovery capabilities, including failover clustering,
Always On availability groups, database mirroring, and log shipping.
SQL Server deployments
Many workloads use SQL Server as a foundation, and it can be integrated with apps such as SharePoint,
Dynamics, and SAP, to implement data services. SQL Server can be deployed in a number of ways:
Standalone SQL Server: SQL Server and all databases are hosted on a single machine (physical or a virtual).
When virtualized, host clustering is used for local high availability. Guest-level high availability isn't
implemented.
SQL Server Failover Clustering Instances (Always On FCI): Two or more nodes running SQL Server
instanced with shared disks are configured in a Windows Failover cluster. If a node is down, the cluster can fail
SQL Server over to another instance. This setup is typically used to implement high availability at a primary
site. This deployment doesn't protect against failure or outage in the shared storage layer. A shared disk can be
implemented using iSCSI, fiber channel or shared vhdx.
SQL Always On Availability Groups: Two or more nodes are set up in a shared nothing cluster, with SQL
Server databases configured in an availability group, with synchronous replication and automatic failover.
This article leverages the following native SQL disaster recovery technologies for recovering databases to a
remote site:
SQL Always On Availability Groups, to provide for disaster recovery for SQL Server 2012 or 2014
Enterprise editions.
SQL database mirroring in high safety mode, for SQL Server Standard edition (any version), or for SQL Server
2008 R2.
Site Recovery support
Supported scenarios
Site Recovery can protect SQL Server as summarized in the table.
SCENARIO
TO A SECONDARY SITE
TO AZURE
Hyper-V
Yes
Yes
VMware
Yes
Yes
Physical server
Yes
Yes
Supported SQL Server versions
These SQL Server versions are supported, for the supported scenarios:
SQL Server 2014 Enterprise and Standard
SQL Server 2012 Enterprise and Standard
SQL Server 2008 R2 Enterprise and Standard
Supported SQL Server integration
Site Recovery can be integrated with native SQL Server BCDR technologies summarized in the table, to provide a
disaster recovery solution.
FEATURE
DETAILS
SQL SERVER
Always On availability group
Multiple standalone instances of SQL
Server each run in a failover cluster that
has multiple nodes.
SQL Server 2014 & 2012 Enterprise
edition
Databases can be grouped into failover
groups that can be copied (mirrored)
on SQL Server instances so that no
shared storage is needed.
Provides disaster recovery between a
primary site and one or more
secondary sites. Two nodes can be set
up in a shared nothing cluster with SQL
Server databases configured in an
availability group with synchronous
replication and automatic failover.
Failover clustering (Always On FCI)
SQL Server leverages Windows failover
clustering for high availability of onpremises SQL Server workloads.
SQL Server Enterprise editions
SQL Server Standard edition (limited to
two nodes only)
Nodes running instances of SQL Server
with shared disks are configured in a
failover cluster. If an instance is down
the cluster fails over to different one.
The cluster doesn't protect against
failure or outages in shared storage.
The shared disk can be implemented
with iSCSI, fiber channel, or shared
VHDXs.
Database mirroring (high safety
mode)
Standalone SQL Server
Protects a single database to a single
secondary copy. Available in both high
safety (synchronous) and high
performance (asynchronous) replication
modes. Doesn’t require a failover
cluster.
SQL Server 2008 R2
The SQL Server and database are
hosted on a single server (physical or
virtual). Host clustering is used for high
availability if the server is virtual. No
guest-level high availability.
Enterprise or Standard edition
SQL Server Enterprise all editions
Deployment recommendations
This table summarizes our recommendations for integrating SQL Server BCDR technologies with Site Recovery.
VERSION
EDITION
DEPLOYMENT
ON-PREM TO ON-PREM
ON-PREM TO AZURE
SQL Server 2014 or
2012
Enterprise
Failover cluster
instance
Always On availability
groups
Always On availability
groups
Enterprise
Always On availability
groups for high
availability
Always On availability
groups
Always On availability
groups
Standard
Failover cluster
instance (FCI)
Site Recovery
replication with local
mirror
Site Recovery
replication with local
mirror
Enterprise or
Standard
Standalone
Site Recovery
replication
Site Recovery
replication
Enterprise or
Standard
Failover cluster
instance (FCI)
Site Recovery
replication with local
mirror
Site Recovery
replication with local
mirror
Enterprise or
Standard
Standalone
Site Recovery
replication
Site Recovery
replication
Enterprise or
Standard
Failover cluster
instance - DTC
application
Site Recovery
replication
Not Supported
SQL Server 2008 R2
or 2008
SQL Server (Any
version)
Deployment prerequisites
An on-premises SQL Server deployment, running a supported SQL Server version. Typically, you also need
Active Directory for your SQL server.
The requirements for the scenario you want to deploy. Learn more about support requirements for replication
to Azure and on-premises, and deployment prerequisites.
To set up recovery in Azure, run the Azure Virtual Machine Readiness Assessment tool on your SQL Server
virtual machines, to make sure they're compatible with Azure and Site Recovery.
Set up Active Directory
Set up Active Directory, in the secondary recovery site, for SQL Server to run properly.
Small enterprise—With a small number of applications, and single domain controller for the on-premises
site, if you want to fail over the entire site, we recommend you use Site Recovery replication to replicate the
domain controller to the secondary datacenter, or to Azure.
Medium to large enterprise—If you have a large number of applications, an Active Directory forest, and you
want to fail over by application or workload, we recommend you set up an additional domain controller in the
secondary datacenter, or in Azure. If you're using Always On availability groups to recover to a remote site, we
recommend you set up another additional domain controller on the secondary site or in Azure, to use for the
recovered SQL Server instance.
The instructions in this article presume that a domain controller is available in the secondary location. Read more
about protecting Active Directory with Site Recovery.
Integrate with SQL Server Always On for replication to Azure
Here's what you need to do:
1. Import scripts into your Azure Automation account. This contains the scripts to failover SQL Availability
Group in a Resource Manager virtual machine and a Classic virtual machine.
2. Add ASR-SQL-FailoverAG as a pre action of the first group of the recovery plan.
3. Follow the instructions available in the script to create an automation variable to provide the name of the
availability groups.
Steps to do a test failover
SQL Always On doesn’t natively support test failover. Therefore, we recommend the following:
1. Set up Azure Backup on the virtual machine that hosts the availability group replica in Azure.
2. Before triggering test failover of the recovery plan, recover the virtual machine from the backup taken in
the previous step.
3. Force a quorum in the virtual machine restored from backup.
4. Update IP of the listener to an IP available in the test failover network.
5. Bring listener online.
6. Create a load balancer with one IP created under frontend IP pool corresponding to each availability group
listener and with the SQL virtual machine added in the backend pool.
7. Do a test failover of the recovery plan.
Steps to do a failover
Once you have added the script in the recovery plan and validated the recovery plan by doing a test failover, you
can do failover of the recovery plan.
Integrate with SQL Server Always On for replication to a secondary
on-premises site
If the SQL Server is using availability groups for high availability (or an FCI), we recommend using availability
groups on the recovery site as well. Note that this applies to apps that don't use distributed transactions.
1.
2.
3.
4.
5.
Configure databases into availability groups.
Create a virtual network on the secondary site.
Set up a site-to-site VPN connection between the virtual network, and the primary site.
Create a virtual machine on the recovery site, and install SQL Server on it.
Extend the existing Always On availability groups to the new SQL Server VM. Configure this SQL Server
instance as an asynchronous replica copy.
6. Create an availability group listener, or update the existing listener to include the asynchronous replica virtual
machine.
7. Make sure that the application farm is set up using the listener. If it's setup up using the database server name,
update it to use the listener, so you don't need to reconfigure it after the failover.
For applications that use distributed transactions, we recommend you deploy Site Recovery with VMware/physical
server site-to-site replication.
Recovery plan considerations
1. Add this sample script to the VMM library, on the primary and secondary sites.
Param(
[string]$SQLAvailabilityGroupPath
)
import-module sqlps
Switch-SqlAvailabilityGroup -Path $SQLAvailabilityGroupPath -AllowDataLoss -force
2. When you create a recovery plan for the application, add a pre action to Group-1 scripted step, that invokes
the script to fail over availability groups.
Protect a standalone SQL Server
In this scenario, we recommend that you use Site Recovery replication to protect the SQL Server machine. The
exact steps will depend whether SQL Server is a VM or a physical server, and whether you want to replicate to
Azure or a secondary on-premises site. Learn about Site Recovery scenarios.
Protect a SQL Server cluster (standard edition/Windows Server 2008
R2)
For a cluster running SQL Server Standard edition, or SQL Server 2008 R2, we recommend you use Site Recovery
replication to protect SQL Server.
On-premises to on-premises
If the app uses distributed transactions we recommend you deploy Site Recovery with SAN replication for a
Hyper-V environment, or VMware/physical server to VMware for a VMware environment.
For non-DTC applications, use the above approach to recover the cluster as a standalone server, by leveraging
a local high safety DB mirror.
On-premises to Azure
Site Recovery doesn't provide guest cluster support when replicating to Azure. SQL Server also doesn't provide a
low-cost disaster recovery solution for Standard edition. In this scenario, we recommend you protect the onpremises SQL Server cluster to a standalone SQL Server, and recover it in Azure.
1. Configure an additional standalone SQL Server instance on the on-premises site.
2. Configure the instance to serve as a mirror for the databases you want to protect. Configure mirroring in high
safety mode.
3. Configure Site Recovery on the on-premises site, for (Hyper-V or VMware VMs/physical servers).
4. Use Site Recovery replication to replicate the new SQL Server instance to Azure. Since it's a high safety mirror
copy, it will be synchronized with the primary cluster, but it will be replicated to Azure using Site Recovery
replication.
Failback considerations
For SQL Server Standard clusters, failback after an unplanned failover requires a SQL server backup and restore,
from the mirror instance to the original cluster, with reestablishment of the mirror.
Next steps
Learn more about Site Recovery architecture.
What workloads can you protect with Azure Site
Recovery?
4/3/2017 • 8 min to read • Edit Online
This article describes workloads and applications you can replicate with the Azure Site Recovery service.
Post any comments or questions at the bottom of this article, or on the Azure Recovery Services Forum.
Overview
Organizations need a business continuity and disaster recovery (BCDR) strategy to keep workloads and data safe
and available during planned and unplanned downtime, and recover to regular working conditions as soon as
possible.
Site Recovery is an Azure service that contributes to your BCDR strategy. Using Site Recovery, you can deploy
application-aware replication to the cloud, or to a secondary site. Whether your apps are Windows or Linux-based,
running on physical servers, VMware or Hyper-V, you can use Site Recovery to orchestrate replication, perform
disaster recovery testing, and run failovers and failback.
Site Recovery integrates with Microsoft applications, including SharePoint, Exchange, Dynamics, SQL Server and
Active Directory. Microsoft also works closely with leading vendors including Oracle, SAP, IBM and Red Hat. You can
customize replication solutions on an app-by-app basis.
Why use Site Recovery for application replication?
Site Recovery contributes to application-level protection and recovery as follows:
App-agnostic, providing replication for any workloads running on a supported machine.
Near-synchronous replication, with RPOs as low as 30 seconds to meet the needs of most critical business apps.
App-consistent snapshots, for single or multi-tier applications.
Integration with SQL Server AlwaysOn, and partnership with other application-level replication technologies,
including AD replication, SQL AlwaysOn, Exchange Database Availability Groups (DAGs) and Oracle Data Guard.
Flexible recovery plans, that enable you to recover an entire application stack with a single click, and include to
include external scripts and manual actions in the plan.
Advanced network management in Site Recovery and Azure to simplify app network requirements, including the
ability to reserve IP addresses, configure load-balancing, and integration with Azure Traffic Manager, for low
RTO network switchovers.
A rich automation library that provides production-ready, application-specific scripts that can be downloaded
and integrated with recovery plans.
Workload summary
Site Recovery can replicate any app running on a supported machine. In addition we've partnered with product
teams to carry out additional app-specific testing.
WORKLOAD
REPLICATE HYPER-V
VMS TO A SECONDARY
SITE
REPLICATE HYPER-V
VMS TO AZURE
REPLICATE VMWARE
VMS TO A SECONDARY
SITE
REPLICATE VMWARE
VMS TO AZURE
Active Directory, DNS
Y
Y
Y
Y
WORKLOAD
REPLICATE HYPER-V
VMS TO A SECONDARY
SITE
REPLICATE HYPER-V
VMS TO AZURE
REPLICATE VMWARE
VMS TO A SECONDARY
SITE
REPLICATE VMWARE
VMS TO AZURE
Web apps (IIS, SQL)
Y
Y
Y
Y
System Center
Operations Manager
Y
Y
Y
Y
Sharepoint
Y
Y
Y
Y
SAP
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Exchange (non-DAG)
Y
Coming soon
Y
Y
Remote Desktop/VDI
Y
Y
Y
N/A
Linux (operating
system and apps)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Dynamics AX
Y
Y
Y
Y
Dynamics CRM
Y
Coming soon
Y
Coming soon
Oracle
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Windows File Server
Y
Y
Y
Y
Citrix XenApp and
XenDesktop
N/A
Y
N/A
Y
Replicate SAP site to
Azure for non-cluster
Replicate Active Directory and DNS
An Active Directory and DNS infrastructure are essential to most enterprise apps. During disaster recovery, you'll
need to protect and recover these infrastructure components, before recovering your workloads and apps.
You can use Site Recovery to create a complete automated disaster recovery plan for Active Directory and DNS. For
example, if you want to fail over SharePoint and SAP from a primary to a secondary site, you can set up a recovery
plan that fails over Active Directory first, and then an additional app-specific recovery plan to fail over the other
apps that rely on Active Directory.
Learn more about protecting Active Directory and DNS.
Protect SQL Server
SQL Server provides a data services foundation for data services for many business apps in an on-premises data
center. Site Recovery can be used together with SQL Server HA/DR technologies, to protect multi-tiered enterprise
apps that use SQL Server. Site Recovery provides:
A simple and cost-effective disaster recovery solution for SQL Server. Replicate multiple versions and editions of
SQL Server standalone servers and clusters, to Azure or to a secondary site.
Integration with SQL AlwaysOn Availability Groups, to manage failover and failback with Azure Site Recovery
recovery plans.
End-to-end recovery plans for the all tiers in an application, including the SQL Server databases.
Scaling of SQL Server for peak loads with Site Recovery, by “bursting” them into larger IaaS virtual machine
sizes in Azure.
Easy testing of SQL Server disaster recovery. You can run test failovers to analyze data and run compliance
checks, without impacting your production environment.
Learn more about protecting SQL server.
Protect SharePoint
Azure Site Recovery helps protect SharePoint deployments, as follows:
Eliminates the need and associated infrastructure costs for a stand-by farm for disaster recovery. Use Site
Recovery to replicate an entire farm (Web, app and database tiers) to Azure or to a secondary site.
Simplifies application deployment and management. Updates deployed to the primary site are automatically
replicated, and are thus available after failover and recovery of a farm in a secondary site. Also lowers the
management complexity and costs associated with keeping a stand-by farm up-to-date.
Simplifies SharePoint application development and testing by creating a production-like copy on-demand
replica environment for testing and debugging.
Simplifies transition to the cloud by using Site Recovery to migrate SharePoint deployments to Azure.
Learn more about protecting SharePoint.
Protect Dynamics AX
Azure Site Recovery helps protect your Dynamics AX ERP solution, by:
Orchestrating replication of your entire Dynamics AX environment (Web and AOS tiers, database tiers,
SharePoint) to Azure, or to a secondary site.
Simplifying migration of Dynamics AX deployments to the cloud (Azure).
Simplifying Dynamics AX application development and testing by creating a production-like copy on-demand,
for testing and debugging.
Learn more about protecting Dynamic AX.
Protect RDS
Remote Desktop Services (RDS) enables virtual desktop infrastructure (VDI), session-based desktops, and
applications, allowing users to work anywhere. With Azure Site Recovery you can:
Replicate managed or unmanaged pooled virtual desktops to a secondary site, and remote applications and
sessions to a secondary site or Azure.
Here's what you can replicate:
REPLICATE
HYPER-V VMS
TO A
SECONDARY
SITE
REPLICATE
HYPER-V VMS
TO AZURE
REPLICATE
VMWARE VMS
TO A
SECONDARY
SITE
Pooled
Virtual
Desktop
(unmanaged)
Yes
No
Pooled
Virtual
Desktop
(managed
and without
UPD)
Yes
Remote
applications
and Desktop
sessions
(without
UPD)
Yes
RDS
REPLICATE
VMWARE VMS
TO AZURE
REPLICATE
PHYSICAL
SERVERS TO A
SECONDARY
SITE
REPLICATE
PHYSICAL
SERVERS TO
AZURE
Yes
No
Yes
No
No
Yes
No
Yes
No
Yes
Yes
Yes
Yes
Yes
Learn more about protecting RDS.
Protect Exchange
Site Recovery helps protect Exchange, as follows:
For small Exchange deployments, such as a single or standalone servers, Site Recovery can replicate and fail over
to Azure or to a secondary site.
For larger deployments, Site Recovery integrates with Exchange DAGS.
Exchange DAGs are the recommended solution for Exchange disaster recovery in an enterprise. Site Recovery
recovery plans can include DAGs, to orchestrate DAG failover across sites.
Learn more about protecting Exchange.
Protect SAP
Use Site Recovery to protect your SAP deployment, as follows:
Enable protection of the entire SAP deployment, by replicating different deployment layers to Azure, or to a
secondary site.
Simplify cloud migration, by using Site Recovery to migrate your SAP deployment to Azure.
Simplify SAP development and testing, by creating a production-like copy on-demand for testing and debugging
applications.
Learn more about protecting SAP.
Protect IIS
Use Site Recovery to protect your IIS deployment, as follows:
Azure Site Recovery provides disaster recovery by replicating the critical components in your environment to a cold
remote site or a public cloud like Microsoft Azure. Since the virtual machine with the web server and the database
are being replicated to the recovery site, there is no requirement to backup configuration files or certificates
separately. The application mappings and bindings dependent on environment variables that are changed post
failover can be updated through scripts integrated into the disaster recovery plans. Virtual Machines are brought up
on the recovery site only in the event of a failover. Not only this, Azure Site Recovery also helps you orchestrate the
end to end failover by providing you the following capabilities:
Sequencing the shutdown and startup of virtual machines in the various tiers.
Adding scripts to allow update of application dependencies and bindings on the virtual machines after they have
been started up. The scripts can also be used to update the DNS server to point to the recovery site.
Allocate IP addresses to virtual machines pre-failover by mapping the primary and recovery networks and hence
use scripts that do not need to be updated post failover.
Ability for a one-click failover for multiple web applications on the web servers, thus eliminating the scope for
confusion in the event of a disaster.
Ability to test the recovery plans in an isolated environment for DR drills.
Learn more about protecting IIS web farm.
Protect Citrix XenApp and XenDesktop
Use Site Recovery to protect your Citrix XenApp and XenDesktop deployments, as follows:
Enable protection of the Citrix XenApp and XenDesktop deployment, by replicating different deployment layers
including (AD DNS server, SQL database server, Citrix Delivery Controller, StoreFront server, XenApp Master
(VDA), Citrix XenApp License Server) to Azure.
Simplify cloud migration, by using Site Recovery to migrate your Citrix XenApp and XenDesktop deployment to
Azure.
Simplify Citrix XenApp/XenDesktop testing, by creating a production-like copy on-demand for testing and
debugging.
This solution is only applicable for Windows Server operating system virtual desktops and not client virtual
desktops as client virtual desktops are not yet supported for licensing in Azure. Learn More about licensing for
client/server desktops in Azure.
Learn more about protecting Citrix XenApp and XenDesktop deployments.
Next steps
Check prerequisites
Replicate a multi-tier Dynamics AX application using
Azure Site Recovery
5/5/2017 • 6 min to read • Edit Online
Overview
Microsoft Dynamics AX is one of the most popular ERP solution among enterprises to standardized process across
locations, manage resources and simplifying compliance. Considering the application is business critical to an
organization it is very important to be sure that in case of any disaster, application should be up and running in
minimum time.
Today, Microsoft Dynamics AX does not provide any out-of-the-box disaster recovery capabilities. Microsoft
Dynamics AX consists of many server components like Application Object Server, Active Directory (AD), SQL
Database Server, SharePoint Server, Reporting Server etc. To manage the disaster recovery of each of these
components manually is not only expensive but also error-prone.
This article explains in detail about how you can create a disaster recovery solution for your Dynamics AX
application using Azure Site Recovery. It will also cover planned/unplanned/test failovers using one-click recovery
plan, supported configurations and prerequisites. Azure Site Recovery based disaster recovery solution is fully
tested, certified and recommended by Microsoft Dynamics AX.
Prerequisites
Implementing disaster recovery for Dynamics AX application using Azure Site Recovery requires the following prerequisites completed.
• An on-premises Dynamics AX deployment has been setup
• Azure Site Recovery Services vault has been created in Microsoft Azure subscription
• If Azure is your recovery site, run the Azure Virtual Machine Readiness Assessment tool on VMs to ensure that
they are compatible with Azure VMs and Azure Site Recovery Services
Site Recovery support
For the purpose of creating this article VMware virtual machines with Dynamics AX 2012R3 on Windows Server
2012 R2 Enterprise were used. As site recovery replication is application agnostic, the recommendations provided
here are expected to hold on following scenarios as well.
Source and target
SCENARIO
TO A SECONDARY SITE
TO AZURE
Hyper-V
Yes
Yes
VMware
Yes
Yes
Physical server
Yes
Yes
Enable DR of Dynamics AX application using ASR
Protect your Dynamics AX application
Each component of the Dynamics AX needs to be protected to enable the complete application replication and
recovery. This section covers:
1. Protection of Active Directory
2. Protection of SQL Tier
3. Protection of App and Web Tiers
4. Networking configuration
5. Recovery Plan
1. Setup AD and DNS replication
Active Directory is required on the DR site for Dynamics AX application to function. There are two recommended
choices based on the complexity of the customer’s on-premises environment.
Option 1
If the customer has a small number of applications and a single domain controller for his entire on-premises site
and will be failing over the entire site together, then we recommend using ASR-Replication to replicate the DC
machine to secondary site (applicable for both Site to Site and Site to Azure).
Option 2
If the customer has a large number of applications and is running an Active Directory forest and will fail-over few
applications at a time, then we recommend setting up an additional domain controller on the DR site (secondary
site or in Azure).
Please refer to companion guide on making a domain controller available on DR site. For remainder of this
document we will assume a DC is available on DR site.
2. Setup SQL Server replication
Please refer to companion guide for detailed technical guidance on the recommended option for protecting SQL
tier.
3. Enable protection for Dynamics AX client and AOS VMs
Perform relevant Azure Site Recovery configuration based on whether the VMs are deployed on Hyper-V or on
VMware.
TIP
Recommended Crash consistent frequency to configure is 15 minutes.
The below snapshot shows the protection status of Dynamics component VMs in ‘VMware site to Azure’ protection
scenario.
4. Configure Networking
Configure VM Compute and Network Settings
For the AX client and AOS VMs configure network settings in ASR so that the VM networks get attached to the right
DR network after failover. Ensure the DR network for these tiers is routable to the SQL tier.
You can select the VM in the replicated items to configure the network settings as shown in the snapshot below.
For AOS servers select the correct availability set.
If you are using a static IP then specify the IP that you want the virtual machine to take in the Target IP field
5. Creating a recovery plan
You can create a recovery plan in ASR to automate the failover process. Add app tier and web tier in the Recovery
Plan. Order them in different groups so that the front-end shutdown before app tier.
1) Select the ASR vault in your subscription and click on ‘Recovery Plans’ tile.
2) Click on ‘+ Recovery plan and specify a name.
3) Select the ‘Source’ and ‘Target’. The target can be Azure or secondary site. In case you choose Azure, you must
specify the deployment model
4) Select the AOS and client VMs to the recovery plan and click ✓.
You can customize the recovery plan for Dynamics AX application by adding various steps as detailed below. The
above snapshot shows the complete recovery plan after adding all the steps.
Steps:
1. SQL Server failover steps
Refer to ‘SQL Server DR Solution’ companion guide for details about recovery steps specific to SQL server.
2. Failover Group 1: Failover the AOS VMs
Make sure that the recovery point selected is as close as possible to the database PIT but not ahead.
3. Script: Add load balancer (Only E-A) Add a script (via Azure automation) after AOS VM group comes up to add a
load balancer to it. You can use a script to do this task. Refer article how to add load balancer for multi-tier
application DR
4. Failover Group 2: Failover the AX client VMs. Failover the web tier VMs as part of the recovery plan.
Doing a test failover
Refer to ‘AD DR Solution ’ and ‘SQL Server DR solution ’ companion guides for considerations specific to AD and
SQL server respectively during Test Failover.
1.
2.
3.
4.
5.
6.
Go to Azure portal and select your Site Recovery vault.
Click on the recovery plan created for Dynamics AX.
Click on ‘Test Failover’.
Select the virtual network to start the test fail-over process.
Once the secondary environment is up, you can perform your validations.
Once the validations are complete, you can select ‘Validations complete’ and the test failover environment will
be cleaned.
Follow this guidance to do a test failover.
Doing a failover
1. Go to Azure portal and select your Site Recovery vault.
2. Click on the recovery plan created for Dynamics AX.
3. Click on ‘Failover’ and select ‘ Failover’.
4. Select the target network and click ✓ to start the failover process.
Follow this guidance when you are doing a failover.
Perform a Failback
Refer to ‘SQL Server DR Solution ’ companion guide for considerations specific to SQL server during Failback.
1.
2.
3.
4.
5.
6.
Go to Azure portal and select your Site Recovery vault.
Click on the recovery plan created for Dynamics AX.
Click on ‘Failover’ and select failover.
Click on ‘Change Direction’.
Select the appropriate options - data synchronization and VM creation options
Click ✓ to start the ‘Failback’ process.
Follow this guidance when you are doing a failback.
Summary
Using Azure Site Recovery, you can create a complete automated disaster recovery plan for your Dynamics AX
application. You can initiate the failover within seconds from anywhere in the event of a disruption and get the
application up and running in minutes.
Next steps
Read What workloads can I protect? to learn more about protecting enterprise workloads with Azure Site Recovery.
What workloads can you protect with Azure Site
Recovery?
4/3/2017 • 8 min to read • Edit Online
This article describes workloads and applications you can replicate with the Azure Site Recovery service.
Post any comments or questions at the bottom of this article, or on the Azure Recovery Services Forum.
Overview
Organizations need a business continuity and disaster recovery (BCDR) strategy to keep workloads and data safe
and available during planned and unplanned downtime, and recover to regular working conditions as soon as
possible.
Site Recovery is an Azure service that contributes to your BCDR strategy. Using Site Recovery, you can deploy
application-aware replication to the cloud, or to a secondary site. Whether your apps are Windows or Linux-based,
running on physical servers, VMware or Hyper-V, you can use Site Recovery to orchestrate replication, perform
disaster recovery testing, and run failovers and failback.
Site Recovery integrates with Microsoft applications, including SharePoint, Exchange, Dynamics, SQL Server and
Active Directory. Microsoft also works closely with leading vendors including Oracle, SAP, IBM and Red Hat. You can
customize replication solutions on an app-by-app basis.
Why use Site Recovery for application replication?
Site Recovery contributes to application-level protection and recovery as follows:
App-agnostic, providing replication for any workloads running on a supported machine.
Near-synchronous replication, with RPOs as low as 30 seconds to meet the needs of most critical business apps.
App-consistent snapshots, for single or multi-tier applications.
Integration with SQL Server AlwaysOn, and partnership with other application-level replication technologies,
including AD replication, SQL AlwaysOn, Exchange Database Availability Groups (DAGs) and Oracle Data Guard.
Flexible recovery plans, that enable you to recover an entire application stack with a single click, and include to
include external scripts and manual actions in the plan.
Advanced network management in Site Recovery and Azure to simplify app network requirements, including the
ability to reserve IP addresses, configure load-balancing, and integration with Azure Traffic Manager, for low
RTO network switchovers.
A rich automation library that provides production-ready, application-specific scripts that can be downloaded
and integrated with recovery plans.
Workload summary
Site Recovery can replicate any app running on a supported machine. In addition we've partnered with product
teams to carry out additional app-specific testing.
WORKLOAD
REPLICATE HYPER-V
VMS TO A SECONDARY
SITE
REPLICATE HYPER-V
VMS TO AZURE
REPLICATE VMWARE
VMS TO A SECONDARY
SITE
REPLICATE VMWARE
VMS TO AZURE
Active Directory, DNS
Y
Y
Y
Y
WORKLOAD
REPLICATE HYPER-V
VMS TO A SECONDARY
SITE
REPLICATE HYPER-V
VMS TO AZURE
REPLICATE VMWARE
VMS TO A SECONDARY
SITE
REPLICATE VMWARE
VMS TO AZURE
Web apps (IIS, SQL)
Y
Y
Y
Y
System Center
Operations Manager
Y
Y
Y
Y
Sharepoint
Y
Y
Y
Y
SAP
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Exchange (non-DAG)
Y
Coming soon
Y
Y
Remote Desktop/VDI
Y
Y
Y
N/A
Linux (operating
system and apps)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Dynamics AX
Y
Y
Y
Y
Dynamics CRM
Y
Coming soon
Y
Coming soon
Oracle
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Windows File Server
Y
Y
Y
Y
Citrix XenApp and
XenDesktop
N/A
Y
N/A
Y
Replicate SAP site to
Azure for non-cluster
Replicate Active Directory and DNS
An Active Directory and DNS infrastructure are essential to most enterprise apps. During disaster recovery, you'll
need to protect and recover these infrastructure components, before recovering your workloads and apps.
You can use Site Recovery to create a complete automated disaster recovery plan for Active Directory and DNS. For
example, if you want to fail over SharePoint and SAP from a primary to a secondary site, you can set up a recovery
plan that fails over Active Directory first, and then an additional app-specific recovery plan to fail over the other
apps that rely on Active Directory.
Learn more about protecting Active Directory and DNS.
Protect SQL Server
SQL Server provides a data services foundation for data services for many business apps in an on-premises data
center. Site Recovery can be used together with SQL Server HA/DR technologies, to protect multi-tiered enterprise
apps that use SQL Server. Site Recovery provides:
A simple and cost-effective disaster recovery solution for SQL Server. Replicate multiple versions and editions of
SQL Server standalone servers and clusters, to Azure or to a secondary site.
Integration with SQL AlwaysOn Availability Groups, to manage failover and failback with Azure Site Recovery
recovery plans.
End-to-end recovery plans for the all tiers in an application, including the SQL Server databases.
Scaling of SQL Server for peak loads with Site Recovery, by “bursting” them into larger IaaS virtual machine
sizes in Azure.
Easy testing of SQL Server disaster recovery. You can run test failovers to analyze data and run compliance
checks, without impacting your production environment.
Learn more about protecting SQL server.
Protect SharePoint
Azure Site Recovery helps protect SharePoint deployments, as follows:
Eliminates the need and associated infrastructure costs for a stand-by farm for disaster recovery. Use Site
Recovery to replicate an entire farm (Web, app and database tiers) to Azure or to a secondary site.
Simplifies application deployment and management. Updates deployed to the primary site are automatically
replicated, and are thus available after failover and recovery of a farm in a secondary site. Also lowers the
management complexity and costs associated with keeping a stand-by farm up-to-date.
Simplifies SharePoint application development and testing by creating a production-like copy on-demand
replica environment for testing and debugging.
Simplifies transition to the cloud by using Site Recovery to migrate SharePoint deployments to Azure.
Learn more about protecting SharePoint.
Protect Dynamics AX
Azure Site Recovery helps protect your Dynamics AX ERP solution, by:
Orchestrating replication of your entire Dynamics AX environment (Web and AOS tiers, database tiers,
SharePoint) to Azure, or to a secondary site.
Simplifying migration of Dynamics AX deployments to the cloud (Azure).
Simplifying Dynamics AX application development and testing by creating a production-like copy on-demand,
for testing and debugging.
Learn more about protecting Dynamic AX.
Protect RDS
Remote Desktop Services (RDS) enables virtual desktop infrastructure (VDI), session-based desktops, and
applications, allowing users to work anywhere. With Azure Site Recovery you can:
Replicate managed or unmanaged pooled virtual desktops to a secondary site, and remote applications and
sessions to a secondary site or Azure.
Here's what you can replicate:
REPLICATE
HYPER-V VMS
TO A
SECONDARY
SITE
REPLICATE
HYPER-V VMS
TO AZURE
REPLICATE
VMWARE VMS
TO A
SECONDARY
SITE
Pooled
Virtual
Desktop
(unmanaged)
Yes
No
Pooled
Virtual
Desktop
(managed
and without
UPD)
Yes
Remote
applications
and Desktop
sessions
(without
UPD)
Yes
RDS
REPLICATE
VMWARE VMS
TO AZURE
REPLICATE
PHYSICAL
SERVERS TO A
SECONDARY
SITE
REPLICATE
PHYSICAL
SERVERS TO
AZURE
Yes
No
Yes
No
No
Yes
No
Yes
No
Yes
Yes
Yes
Yes
Yes
Learn more about protecting RDS.
Protect Exchange
Site Recovery helps protect Exchange, as follows:
For small Exchange deployments, such as a single or standalone servers, Site Recovery can replicate and fail over
to Azure or to a secondary site.
For larger deployments, Site Recovery integrates with Exchange DAGS.
Exchange DAGs are the recommended solution for Exchange disaster recovery in an enterprise. Site Recovery
recovery plans can include DAGs, to orchestrate DAG failover across sites.
Learn more about protecting Exchange.
Protect SAP
Use Site Recovery to protect your SAP deployment, as follows:
Enable protection of the entire SAP deployment, by replicating different deployment layers to Azure, or to a
secondary site.
Simplify cloud migration, by using Site Recovery to migrate your SAP deployment to Azure.
Simplify SAP development and testing, by creating a production-like copy on-demand for testing and debugging
applications.
Learn more about protecting SAP.
Protect IIS
Use Site Recovery to protect your IIS deployment, as follows:
Azure Site Recovery provides disaster recovery by replicating the critical components in your environment to a cold
remote site or a public cloud like Microsoft Azure. Since the virtual machine with the web server and the database
are being replicated to the recovery site, there is no requirement to backup configuration files or certificates
separately. The application mappings and bindings dependent on environment variables that are changed post
failover can be updated through scripts integrated into the disaster recovery plans. Virtual Machines are brought up
on the recovery site only in the event of a failover. Not only this, Azure Site Recovery also helps you orchestrate the
end to end failover by providing you the following capabilities:
Sequencing the shutdown and startup of virtual machines in the various tiers.
Adding scripts to allow update of application dependencies and bindings on the virtual machines after they have
been started up. The scripts can also be used to update the DNS server to point to the recovery site.
Allocate IP addresses to virtual machines pre-failover by mapping the primary and recovery networks and hence
use scripts that do not need to be updated post failover.
Ability for a one-click failover for multiple web applications on the web servers, thus eliminating the scope for
confusion in the event of a disaster.
Ability to test the recovery plans in an isolated environment for DR drills.
Learn more about protecting IIS web farm.
Protect Citrix XenApp and XenDesktop
Use Site Recovery to protect your Citrix XenApp and XenDesktop deployments, as follows:
Enable protection of the Citrix XenApp and XenDesktop deployment, by replicating different deployment layers
including (AD DNS server, SQL database server, Citrix Delivery Controller, StoreFront server, XenApp Master
(VDA), Citrix XenApp License Server) to Azure.
Simplify cloud migration, by using Site Recovery to migrate your Citrix XenApp and XenDesktop deployment to
Azure.
Simplify Citrix XenApp/XenDesktop testing, by creating a production-like copy on-demand for testing and
debugging.
This solution is only applicable for Windows Server operating system virtual desktops and not client virtual
desktops as client virtual desktops are not yet supported for licensing in Azure. Learn More about licensing for
client/server desktops in Azure.
Learn more about protecting Citrix XenApp and XenDesktop deployments.
Next steps
Check prerequisites
What workloads can you protect with Azure Site
Recovery?
4/3/2017 • 8 min to read • Edit Online
This article describes workloads and applications you can replicate with the Azure Site Recovery service.
Post any comments or questions at the bottom of this article, or on the Azure Recovery Services Forum.
Overview
Organizations need a business continuity and disaster recovery (BCDR) strategy to keep workloads and data safe
and available during planned and unplanned downtime, and recover to regular working conditions as soon as
possible.
Site Recovery is an Azure service that contributes to your BCDR strategy. Using Site Recovery, you can deploy
application-aware replication to the cloud, or to a secondary site. Whether your apps are Windows or Linux-based,
running on physical servers, VMware or Hyper-V, you can use Site Recovery to orchestrate replication, perform
disaster recovery testing, and run failovers and failback.
Site Recovery integrates with Microsoft applications, including SharePoint, Exchange, Dynamics, SQL Server and
Active Directory. Microsoft also works closely with leading vendors including Oracle, SAP, IBM and Red Hat. You can
customize replication solutions on an app-by-app basis.
Why use Site Recovery for application replication?
Site Recovery contributes to application-level protection and recovery as follows:
App-agnostic, providing replication for any workloads running on a supported machine.
Near-synchronous replication, with RPOs as low as 30 seconds to meet the needs of most critical business apps.
App-consistent snapshots, for single or multi-tier applications.
Integration with SQL Server AlwaysOn, and partnership with other application-level replication technologies,
including AD replication, SQL AlwaysOn, Exchange Database Availability Groups (DAGs) and Oracle Data Guard.
Flexible recovery plans, that enable you to recover an entire application stack with a single click, and include to
include external scripts and manual actions in the plan.
Advanced network management in Site Recovery and Azure to simplify app network requirements, including the
ability to reserve IP addresses, configure load-balancing, and integration with Azure Traffic Manager, for low
RTO network switchovers.
A rich automation library that provides production-ready, application-specific scripts that can be downloaded
and integrated with recovery plans.
Workload summary
Site Recovery can replicate any app running on a supported machine. In addition we've partnered with product
teams to carry out additional app-specific testing.
WORKLOAD
REPLICATE HYPER-V
VMS TO A SECONDARY
SITE
REPLICATE HYPER-V
VMS TO AZURE
REPLICATE VMWARE
VMS TO A SECONDARY
SITE
REPLICATE VMWARE
VMS TO AZURE
Active Directory, DNS
Y
Y
Y
Y
WORKLOAD
REPLICATE HYPER-V
VMS TO A SECONDARY
SITE
REPLICATE HYPER-V
VMS TO AZURE
REPLICATE VMWARE
VMS TO A SECONDARY
SITE
REPLICATE VMWARE
VMS TO AZURE
Web apps (IIS, SQL)
Y
Y
Y
Y
System Center
Operations Manager
Y
Y
Y
Y
Sharepoint
Y
Y
Y
Y
SAP
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Exchange (non-DAG)
Y
Coming soon
Y
Y
Remote Desktop/VDI
Y
Y
Y
N/A
Linux (operating
system and apps)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Dynamics AX
Y
Y
Y
Y
Dynamics CRM
Y
Coming soon
Y
Coming soon
Oracle
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Windows File Server
Y
Y
Y
Y
Citrix XenApp and
XenDesktop
N/A
Y
N/A
Y
Replicate SAP site to
Azure for non-cluster
Replicate Active Directory and DNS
An Active Directory and DNS infrastructure are essential to most enterprise apps. During disaster recovery, you'll
need to protect and recover these infrastructure components, before recovering your workloads and apps.
You can use Site Recovery to create a complete automated disaster recovery plan for Active Directory and DNS. For
example, if you want to fail over SharePoint and SAP from a primary to a secondary site, you can set up a recovery
plan that fails over Active Directory first, and then an additional app-specific recovery plan to fail over the other
apps that rely on Active Directory.
Learn more about protecting Active Directory and DNS.
Protect SQL Server
SQL Server provides a data services foundation for data services for many business apps in an on-premises data
center. Site Recovery can be used together with SQL Server HA/DR technologies, to protect multi-tiered enterprise
apps that use SQL Server. Site Recovery provides:
A simple and cost-effective disaster recovery solution for SQL Server. Replicate multiple versions and editions of
SQL Server standalone servers and clusters, to Azure or to a secondary site.
Integration with SQL AlwaysOn Availability Groups, to manage failover and failback with Azure Site Recovery
recovery plans.
End-to-end recovery plans for the all tiers in an application, including the SQL Server databases.
Scaling of SQL Server for peak loads with Site Recovery, by “bursting” them into larger IaaS virtual machine
sizes in Azure.
Easy testing of SQL Server disaster recovery. You can run test failovers to analyze data and run compliance
checks, without impacting your production environment.
Learn more about protecting SQL server.
Protect SharePoint
Azure Site Recovery helps protect SharePoint deployments, as follows:
Eliminates the need and associated infrastructure costs for a stand-by farm for disaster recovery. Use Site
Recovery to replicate an entire farm (Web, app and database tiers) to Azure or to a secondary site.
Simplifies application deployment and management. Updates deployed to the primary site are automatically
replicated, and are thus available after failover and recovery of a farm in a secondary site. Also lowers the
management complexity and costs associated with keeping a stand-by farm up-to-date.
Simplifies SharePoint application development and testing by creating a production-like copy on-demand
replica environment for testing and debugging.
Simplifies transition to the cloud by using Site Recovery to migrate SharePoint deployments to Azure.
Learn more about protecting SharePoint.
Protect Dynamics AX
Azure Site Recovery helps protect your Dynamics AX ERP solution, by:
Orchestrating replication of your entire Dynamics AX environment (Web and AOS tiers, database tiers,
SharePoint) to Azure, or to a secondary site.
Simplifying migration of Dynamics AX deployments to the cloud (Azure).
Simplifying Dynamics AX application development and testing by creating a production-like copy on-demand,
for testing and debugging.
Learn more about protecting Dynamic AX.
Protect RDS
Remote Desktop Services (RDS) enables virtual desktop infrastructure (VDI), session-based desktops, and
applications, allowing users to work anywhere. With Azure Site Recovery you can:
Replicate managed or unmanaged pooled virtual desktops to a secondary site, and remote applications and
sessions to a secondary site or Azure.
Here's what you can replicate:
REPLICATE
HYPER-V VMS
TO A
SECONDARY
SITE
REPLICATE
HYPER-V VMS
TO AZURE
REPLICATE
VMWARE VMS
TO A
SECONDARY
SITE
Pooled
Virtual
Desktop
(unmanaged)
Yes
No
Pooled
Virtual
Desktop
(managed
and without
UPD)
Yes
Remote
applications
and Desktop
sessions
(without
UPD)
Yes
RDS
REPLICATE
VMWARE VMS
TO AZURE
REPLICATE
PHYSICAL
SERVERS TO A
SECONDARY
SITE
REPLICATE
PHYSICAL
SERVERS TO
AZURE
Yes
No
Yes
No
No
Yes
No
Yes
No
Yes
Yes
Yes
Yes
Yes
Learn more about protecting RDS.
Protect Exchange
Site Recovery helps protect Exchange, as follows:
For small Exchange deployments, such as a single or standalone servers, Site Recovery can replicate and fail over
to Azure or to a secondary site.
For larger deployments, Site Recovery integrates with Exchange DAGS.
Exchange DAGs are the recommended solution for Exchange disaster recovery in an enterprise. Site Recovery
recovery plans can include DAGs, to orchestrate DAG failover across sites.
Learn more about protecting Exchange.
Protect SAP
Use Site Recovery to protect your SAP deployment, as follows:
Enable protection of the entire SAP deployment, by replicating different deployment layers to Azure, or to a
secondary site.
Simplify cloud migration, by using Site Recovery to migrate your SAP deployment to Azure.
Simplify SAP development and testing, by creating a production-like copy on-demand for testing and debugging
applications.
Learn more about protecting SAP.
Protect IIS
Use Site Recovery to protect your IIS deployment, as follows:
Azure Site Recovery provides disaster recovery by replicating the critical components in your environment to a cold
remote site or a public cloud like Microsoft Azure. Since the virtual machine with the web server and the database
are being replicated to the recovery site, there is no requirement to backup configuration files or certificates
separately. The application mappings and bindings dependent on environment variables that are changed post
failover can be updated through scripts integrated into the disaster recovery plans. Virtual Machines are brought up
on the recovery site only in the event of a failover. Not only this, Azure Site Recovery also helps you orchestrate the
end to end failover by providing you the following capabilities:
Sequencing the shutdown and startup of virtual machines in the various tiers.
Adding scripts to allow update of application dependencies and bindings on the virtual machines after they have
been started up. The scripts can also be used to update the DNS server to point to the recovery site.
Allocate IP addresses to virtual machines pre-failover by mapping the primary and recovery networks and hence
use scripts that do not need to be updated post failover.
Ability for a one-click failover for multiple web applications on the web servers, thus eliminating the scope for
confusion in the event of a disaster.
Ability to test the recovery plans in an isolated environment for DR drills.
Learn more about protecting IIS web farm.
Protect Citrix XenApp and XenDesktop
Use Site Recovery to protect your Citrix XenApp and XenDesktop deployments, as follows:
Enable protection of the Citrix XenApp and XenDesktop deployment, by replicating different deployment layers
including (AD DNS server, SQL database server, Citrix Delivery Controller, StoreFront server, XenApp Master
(VDA), Citrix XenApp License Server) to Azure.
Simplify cloud migration, by using Site Recovery to migrate your Citrix XenApp and XenDesktop deployment to
Azure.
Simplify Citrix XenApp/XenDesktop testing, by creating a production-like copy on-demand for testing and
debugging.
This solution is only applicable for Windows Server operating system virtual desktops and not client virtual
desktops as client virtual desktops are not yet supported for licensing in Azure. Learn More about licensing for
client/server desktops in Azure.
Learn more about protecting Citrix XenApp and XenDesktop deployments.
Next steps
Check prerequisites
What workloads can you protect with Azure Site
Recovery?
4/3/2017 • 8 min to read • Edit Online
This article describes workloads and applications you can replicate with the Azure Site Recovery service.
Post any comments or questions at the bottom of this article, or on the Azure Recovery Services Forum.
Overview
Organizations need a business continuity and disaster recovery (BCDR) strategy to keep workloads and data safe
and available during planned and unplanned downtime, and recover to regular working conditions as soon as
possible.
Site Recovery is an Azure service that contributes to your BCDR strategy. Using Site Recovery, you can deploy
application-aware replication to the cloud, or to a secondary site. Whether your apps are Windows or Linux-based,
running on physical servers, VMware or Hyper-V, you can use Site Recovery to orchestrate replication, perform
disaster recovery testing, and run failovers and failback.
Site Recovery integrates with Microsoft applications, including SharePoint, Exchange, Dynamics, SQL Server and
Active Directory. Microsoft also works closely with leading vendors including Oracle, SAP, IBM and Red Hat. You can
customize replication solutions on an app-by-app basis.
Why use Site Recovery for application replication?
Site Recovery contributes to application-level protection and recovery as follows:
App-agnostic, providing replication for any workloads running on a supported machine.
Near-synchronous replication, with RPOs as low as 30 seconds to meet the needs of most critical business apps.
App-consistent snapshots, for single or multi-tier applications.
Integration with SQL Server AlwaysOn, and partnership with other application-level replication technologies,
including AD replication, SQL AlwaysOn, Exchange Database Availability Groups (DAGs) and Oracle Data Guard.
Flexible recovery plans, that enable you to recover an entire application stack with a single click, and include to
include external scripts and manual actions in the plan.
Advanced network management in Site Recovery and Azure to simplify app network requirements, including the
ability to reserve IP addresses, configure load-balancing, and integration with Azure Traffic Manager, for low
RTO network switchovers.
A rich automation library that provides production-ready, application-specific scripts that can be downloaded
and integrated with recovery plans.
Workload summary
Site Recovery can replicate any app running on a supported machine. In addition we've partnered with product
teams to carry out additional app-specific testing.
WORKLOAD
REPLICATE HYPER-V
VMS TO A SECONDARY
SITE
REPLICATE HYPER-V
VMS TO AZURE
REPLICATE VMWARE
VMS TO A SECONDARY
SITE
REPLICATE VMWARE
VMS TO AZURE
Active Directory, DNS
Y
Y
Y
Y
WORKLOAD
REPLICATE HYPER-V
VMS TO A SECONDARY
SITE
REPLICATE HYPER-V
VMS TO AZURE
REPLICATE VMWARE
VMS TO A SECONDARY
SITE
REPLICATE VMWARE
VMS TO AZURE
Web apps (IIS, SQL)
Y
Y
Y
Y
System Center
Operations Manager
Y
Y
Y
Y
Sharepoint
Y
Y
Y
Y
SAP
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Exchange (non-DAG)
Y
Coming soon
Y
Y
Remote Desktop/VDI
Y
Y
Y
N/A
Linux (operating
system and apps)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Dynamics AX
Y
Y
Y
Y
Dynamics CRM
Y
Coming soon
Y
Coming soon
Oracle
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Windows File Server
Y
Y
Y
Y
Citrix XenApp and
XenDesktop
N/A
Y
N/A
Y
Replicate SAP site to
Azure for non-cluster
Replicate Active Directory and DNS
An Active Directory and DNS infrastructure are essential to most enterprise apps. During disaster recovery, you'll
need to protect and recover these infrastructure components, before recovering your workloads and apps.
You can use Site Recovery to create a complete automated disaster recovery plan for Active Directory and DNS. For
example, if you want to fail over SharePoint and SAP from a primary to a secondary site, you can set up a recovery
plan that fails over Active Directory first, and then an additional app-specific recovery plan to fail over the other
apps that rely on Active Directory.
Learn more about protecting Active Directory and DNS.
Protect SQL Server
SQL Server provides a data services foundation for data services for many business apps in an on-premises data
center. Site Recovery can be used together with SQL Server HA/DR technologies, to protect multi-tiered enterprise
apps that use SQL Server. Site Recovery provides:
A simple and cost-effective disaster recovery solution for SQL Server. Replicate multiple versions and editions of
SQL Server standalone servers and clusters, to Azure or to a secondary site.
Integration with SQL AlwaysOn Availability Groups, to manage failover and failback with Azure Site Recovery
recovery plans.
End-to-end recovery plans for the all tiers in an application, including the SQL Server databases.
Scaling of SQL Server for peak loads with Site Recovery, by “bursting” them into larger IaaS virtual machine
sizes in Azure.
Easy testing of SQL Server disaster recovery. You can run test failovers to analyze data and run compliance
checks, without impacting your production environment.
Learn more about protecting SQL server.
Protect SharePoint
Azure Site Recovery helps protect SharePoint deployments, as follows:
Eliminates the need and associated infrastructure costs for a stand-by farm for disaster recovery. Use Site
Recovery to replicate an entire farm (Web, app and database tiers) to Azure or to a secondary site.
Simplifies application deployment and management. Updates deployed to the primary site are automatically
replicated, and are thus available after failover and recovery of a farm in a secondary site. Also lowers the
management complexity and costs associated with keeping a stand-by farm up-to-date.
Simplifies SharePoint application development and testing by creating a production-like copy on-demand
replica environment for testing and debugging.
Simplifies transition to the cloud by using Site Recovery to migrate SharePoint deployments to Azure.
Learn more about protecting SharePoint.
Protect Dynamics AX
Azure Site Recovery helps protect your Dynamics AX ERP solution, by:
Orchestrating replication of your entire Dynamics AX environment (Web and AOS tiers, database tiers,
SharePoint) to Azure, or to a secondary site.
Simplifying migration of Dynamics AX deployments to the cloud (Azure).
Simplifying Dynamics AX application development and testing by creating a production-like copy on-demand,
for testing and debugging.
Learn more about protecting Dynamic AX.
Protect RDS
Remote Desktop Services (RDS) enables virtual desktop infrastructure (VDI), session-based desktops, and
applications, allowing users to work anywhere. With Azure Site Recovery you can:
Replicate managed or unmanaged pooled virtual desktops to a secondary site, and remote applications and
sessions to a secondary site or Azure.
Here's what you can replicate:
REPLICATE
HYPER-V VMS
TO A
SECONDARY
SITE
REPLICATE
HYPER-V VMS
TO AZURE
REPLICATE
VMWARE VMS
TO A
SECONDARY
SITE
Pooled
Virtual
Desktop
(unmanaged)
Yes
No
Pooled
Virtual
Desktop
(managed
and without
UPD)
Yes
Remote
applications
and Desktop
sessions
(without
UPD)
Yes
RDS
REPLICATE
VMWARE VMS
TO AZURE
REPLICATE
PHYSICAL
SERVERS TO A
SECONDARY
SITE
REPLICATE
PHYSICAL
SERVERS TO
AZURE
Yes
No
Yes
No
No
Yes
No
Yes
No
Yes
Yes
Yes
Yes
Yes
Learn more about protecting RDS.
Protect Exchange
Site Recovery helps protect Exchange, as follows:
For small Exchange deployments, such as a single or standalone servers, Site Recovery can replicate and fail over
to Azure or to a secondary site.
For larger deployments, Site Recovery integrates with Exchange DAGS.
Exchange DAGs are the recommended solution for Exchange disaster recovery in an enterprise. Site Recovery
recovery plans can include DAGs, to orchestrate DAG failover across sites.
Learn more about protecting Exchange.
Protect SAP
Use Site Recovery to protect your SAP deployment, as follows:
Enable protection of the entire SAP deployment, by replicating different deployment layers to Azure, or to a
secondary site.
Simplify cloud migration, by using Site Recovery to migrate your SAP deployment to Azure.
Simplify SAP development and testing, by creating a production-like copy on-demand for testing and debugging
applications.
Learn more about protecting SAP.
Protect IIS
Use Site Recovery to protect your IIS deployment, as follows:
Azure Site Recovery provides disaster recovery by replicating the critical components in your environment to a cold
remote site or a public cloud like Microsoft Azure. Since the virtual machine with the web server and the database
are being replicated to the recovery site, there is no requirement to backup configuration files or certificates
separately. The application mappings and bindings dependent on environment variables that are changed post
failover can be updated through scripts integrated into the disaster recovery plans. Virtual Machines are brought up
on the recovery site only in the event of a failover. Not only this, Azure Site Recovery also helps you orchestrate the
end to end failover by providing you the following capabilities:
Sequencing the shutdown and startup of virtual machines in the various tiers.
Adding scripts to allow update of application dependencies and bindings on the virtual machines after they have
been started up. The scripts can also be used to update the DNS server to point to the recovery site.
Allocate IP addresses to virtual machines pre-failover by mapping the primary and recovery networks and hence
use scripts that do not need to be updated post failover.
Ability for a one-click failover for multiple web applications on the web servers, thus eliminating the scope for
confusion in the event of a disaster.
Ability to test the recovery plans in an isolated environment for DR drills.
Learn more about protecting IIS web farm.
Protect Citrix XenApp and XenDesktop
Use Site Recovery to protect your Citrix XenApp and XenDesktop deployments, as follows:
Enable protection of the Citrix XenApp and XenDesktop deployment, by replicating different deployment layers
including (AD DNS server, SQL database server, Citrix Delivery Controller, StoreFront server, XenApp Master
(VDA), Citrix XenApp License Server) to Azure.
Simplify cloud migration, by using Site Recovery to migrate your Citrix XenApp and XenDesktop deployment to
Azure.
Simplify Citrix XenApp/XenDesktop testing, by creating a production-like copy on-demand for testing and
debugging.
This solution is only applicable for Windows Server operating system virtual desktops and not client virtual
desktops as client virtual desktops are not yet supported for licensing in Azure. Learn More about licensing for
client/server desktops in Azure.
Learn more about protecting Citrix XenApp and XenDesktop deployments.
Next steps
Check prerequisites
What workloads can you protect with Azure Site
Recovery?
4/3/2017 • 8 min to read • Edit Online
This article describes workloads and applications you can replicate with the Azure Site Recovery service.
Post any comments or questions at the bottom of this article, or on the Azure Recovery Services Forum.
Overview
Organizations need a business continuity and disaster recovery (BCDR) strategy to keep workloads and data safe
and available during planned and unplanned downtime, and recover to regular working conditions as soon as
possible.
Site Recovery is an Azure service that contributes to your BCDR strategy. Using Site Recovery, you can deploy
application-aware replication to the cloud, or to a secondary site. Whether your apps are Windows or Linux-based,
running on physical servers, VMware or Hyper-V, you can use Site Recovery to orchestrate replication, perform
disaster recovery testing, and run failovers and failback.
Site Recovery integrates with Microsoft applications, including SharePoint, Exchange, Dynamics, SQL Server and
Active Directory. Microsoft also works closely with leading vendors including Oracle, SAP, IBM and Red Hat. You
can customize replication solutions on an app-by-app basis.
Why use Site Recovery for application replication?
Site Recovery contributes to application-level protection and recovery as follows:
App-agnostic, providing replication for any workloads running on a supported machine.
Near-synchronous replication, with RPOs as low as 30 seconds to meet the needs of most critical business
apps.
App-consistent snapshots, for single or multi-tier applications.
Integration with SQL Server AlwaysOn, and partnership with other application-level replication technologies,
including AD replication, SQL AlwaysOn, Exchange Database Availability Groups (DAGs) and Oracle Data
Guard.
Flexible recovery plans, that enable you to recover an entire application stack with a single click, and include to
include external scripts and manual actions in the plan.
Advanced network management in Site Recovery and Azure to simplify app network requirements, including
the ability to reserve IP addresses, configure load-balancing, and integration with Azure Traffic Manager, for
low RTO network switchovers.
A rich automation library that provides production-ready, application-specific scripts that can be downloaded
and integrated with recovery plans.
Workload summary
Site Recovery can replicate any app running on a supported machine. In addition we've partnered with product
teams to carry out additional app-specific testing.
WORKLOAD
REPLICATE HYPER-V
VMS TO A SECONDARY
SITE
REPLICATE HYPER-V
VMS TO AZURE
REPLICATE VMWARE
VMS TO A SECONDARY
SITE
REPLICATE VMWARE
VMS TO AZURE
Active Directory, DNS
Y
Y
Y
Y
Web apps (IIS, SQL)
Y
Y
Y
Y
System Center
Operations Manager
Y
Y
Y
Y
Sharepoint
Y
Y
Y
Y
SAP
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Exchange (non-DAG)
Y
Coming soon
Y
Y
Remote Desktop/VDI
Y
Y
Y
N/A
Linux (operating
system and apps)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Dynamics AX
Y
Y
Y
Y
Dynamics CRM
Y
Coming soon
Y
Coming soon
Oracle
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Y (tested by
Microsoft)
Windows File Server
Y
Y
Y
Y
Citrix XenApp and
XenDesktop
N/A
Y
N/A
Y
Replicate SAP site to
Azure for non-cluster
Replicate Active Directory and DNS
An Active Directory and DNS infrastructure are essential to most enterprise apps. During disaster recovery, you'll
need to protect and recover these infrastructure components, before recovering your workloads and apps.
You can use Site Recovery to create a complete automated disaster recovery plan for Active Directory and DNS.
For example, if you want to fail over SharePoint and SAP from a primary to a secondary site, you can set up a
recovery plan that fails over Active Directory first, and then an additional app-specific recovery plan to fail over the
other apps that rely on Active Directory.
Learn more about protecting Active Directory and DNS.
Protect SQL Server
SQL Server provides a data services foundation for data services for many business apps in an on-premises data
center. Site Recovery can be used together with SQL Server HA/DR technologies, to protect multi-tiered enterprise
apps that use SQL Server. Site Recovery provides:
A simple and cost-effective disaster recovery solution for SQL Server. Replicate multiple versions and editions
of SQL Server standalone servers and clusters, to Azure or to a secondary site.
Integration with SQL AlwaysOn Availability Groups, to manage failover and failback with Azure Site Recovery
recovery plans.
End-to-end recovery plans for the all tiers in an application, including the SQL Server databases.
Scaling of SQL Server for peak loads with Site Recovery, by “bursting” them into larger IaaS virtual machine
sizes in Azure.
Easy testing of SQL Server disaster recovery. You can run test failovers to analyze data and run compliance
checks, without impacting your production environment.
Learn more about protecting SQL server.
Protect SharePoint
Azure Site Recovery helps protect SharePoint deployments, as follows:
Eliminates the need and associated infrastructure costs for a stand-by farm for disaster recovery. Use Site
Recovery to replicate an entire farm (Web, app and database tiers) to Azure or to a secondary site.
Simplifies application deployment and management. Updates deployed to the primary site are automatically
replicated, and are thus available after failover and recovery of a farm in a secondary site. Also lowers the
management complexity and costs associated with keeping a stand-by farm up-to-date.
Simplifies SharePoint application development and testing by creating a production-like copy on-demand
replica environment for testing and debugging.
Simplifies transition to the cloud by using Site Recovery to migrate SharePoint deployments to Azure.
Learn more about protecting SharePoint.
Protect Dynamics AX
Azure Site Recovery helps protect your Dynamics AX ERP solution, by:
Orchestrating replication of your entire Dynamics AX environment (Web and AOS tiers, database tiers,
SharePoint) to Azure, or to a secondary site.
Simplifying migration of Dynamics AX deployments to the cloud (Azure).
Simplifying Dynamics AX application development and testing by creating a production-like copy on-demand,
for testing and debugging.
Learn more about protecting Dynamic AX.
Protect RDS
Remote Desktop Services (RDS) enables virtual desktop infrastructure (VDI), session-based desktops, and
applications, allowing users to work anywhere. With Azure Site Recovery you can:
Replicate managed or unmanaged pooled virtual desktops to a secondary site, and remote applications and
sessions to a secondary site or Azure.
Here's what you can replicate:
REPLICATE
HYPER-V VMS
TO A
SECONDARY
SITE
REPLICATE
HYPER-V VMS
TO AZURE
REPLICATE
VMWARE VMS
TO A
SECONDARY
SITE
Pooled
Virtual
Desktop
(unmanaged
)
Yes
No
Pooled
Virtual
Desktop
(managed
and without
UPD)
Yes
Remote
applications
and Desktop
sessions
(without
UPD)
Yes
RDS
REPLICATE
VMWARE VMS
TO AZURE
REPLICATE
PHYSICAL
SERVERS TO A
SECONDARY
SITE
REPLICATE
PHYSICAL
SERVERS TO
AZURE
Yes
No
Yes
No
No
Yes
No
Yes
No
Yes
Yes
Yes
Yes
Yes
Learn more about protecting RDS.
Protect Exchange
Site Recovery helps protect Exchange, as follows:
For small Exchange deployments, such as a single or standalone servers, Site Recovery can replicate and fail
over to Azure or to a secondary site.
For larger deployments, Site Recovery integrates with Exchange DAGS.
Exchange DAGs are the recommended solution for Exchange disaster recovery in an enterprise. Site Recovery
recovery plans can include DAGs, to orchestrate DAG failover across sites.
Learn more about protecting Exchange.
Protect SAP
Use Site Recovery to protect your SAP deployment, as follows:
Enable protection of the entire SAP deployment, by replicating different deployment layers to Azure, or to a
secondary site.
Simplify cloud migration, by using Site Recovery to migrate your SAP deployment to Azure.
Simplify SAP development and testing, by creating a production-like copy on-demand for testing and
debugging applications.
Learn more about protecting SAP.
Protect IIS
Use Site Recovery to protect your IIS deployment, as follows:
Azure Site Recovery provides disaster recovery by replicating the critical components in your environment to a
cold remote site or a public cloud like Microsoft Azure. Since the virtual machine with the web server and the
database are being replicated to the recovery site, there is no requirement to backup configuration files or
certificates separately. The application mappings and bindings dependent on environment variables that are
changed post failover can be updated through scripts integrated into the disaster recovery plans. Virtual Machines
are brought up on the recovery site only in the event of a failover. Not only this, Azure Site Recovery also helps
you orchestrate the end to end failover by providing you the following capabilities:
Sequencing the shutdown and startup of virtual machines in the various tiers.
Adding scripts to allow update of application dependencies and bindings on the virtual machines after they
have been started up. The scripts can also be used to update the DNS server to point to the recovery site.
Allocate IP addresses to virtual machines pre-failover by mapping the primary and recovery networks and
hence use scripts that do not need to be updated post failover.
Ability for a one-click failover for multiple web applications on the web servers, thus eliminating the scope for
confusion in the event of a disaster.
Ability to test the recovery plans in an isolated environment for DR drills.
Learn more about protecting IIS web farm.
Protect Citrix XenApp and XenDesktop
Use Site Recovery to protect your Citrix XenApp and XenDesktop deployments, as follows:
Enable protection of the Citrix XenApp and XenDesktop deployment, by replicating different deployment layers
including (AD DNS server, SQL database server, Citrix Delivery Controller, StoreFront server, XenApp Master
(VDA), Citrix XenApp License Server) to Azure.
Simplify cloud migration, by using Site Recovery to migrate your Citrix XenApp and XenDesktop deployment to
Azure.
Simplify Citrix XenApp/XenDesktop testing, by creating a production-like copy on-demand for testing and
debugging.
This solution is only applicable for Windows Server operating system virtual desktops and not client virtual
desktops as client virtual desktops are not yet supported for licensing in Azure. Learn More about licensing for
client/server desktops in Azure.
Learn more about protecting Citrix XenApp and XenDesktop deployments.
Next steps
Check prerequisites
Replicate between on-premises Hyper-V virtual
machines and Azure by using PowerShell and Azure
Resource Manager
2/21/2017 • 8 min to read • Edit Online
Overview
Azure Site Recovery contributes to your business continuity and disaster recovery strategy by orchestrating
replication, failover, and recovery of virtual machines in a number of deployment scenarios. For a full list of
deployment scenarios, see the Azure Site Recovery overview.
Azure PowerShell is a module that provides cmdlets to manage Azure through Windows PowerShell. It can work
with two types of modules: the Azure Profile module, or the Azure Resource Manager module.
Site Recovery PowerShell cmdlets, available with Azure PowerShell for Azure Resource Manager, help you protect
and recover your servers in Azure.
This article describes how to use Windows PowerShell, together with Azure Resource Manager, to deploy Site
Recovery to configure and orchestrate server protection to Azure. The example used in this article shows you how
to protect, fail over, and recover virtual machines on a Hyper-V host to Azure, by using Azure PowerShell with
Azure Resource Manager.
NOTE
The Site Recovery PowerShell cmdlets currently allow you to configure the following: one Virtual Machine Manager site to
another, a Virtual Machine Manager site to Azure, and a Hyper-V site to Azure.
You don't need to be a PowerShell expert to use this article, but you do need to understand the basic concepts,
such as modules, cmdlets, and sessions. For more information about Windows PowerShell, see Getting Started
with Windows PowerShell.
You can also read more about Using Azure PowerShell with Azure Resource Manager.
NOTE
Microsoft partners that are part of the Cloud Solution Provider (CSP) program can configure and manage protection of their
customers' servers to their customers' respective CSP subscriptions (tenant subscriptions).
Before you start
Make sure you have these prerequisites in place:
A Microsoft Azure account. You can start with a free trial. In addition, you can read about Azure Site Recovery
Manager pricing.
Azure PowerShell 1.0. For information about this release and how to install it, see Azure PowerShell 1.0.
The AzureRM.SiteRecovery and AzureRM.RecoveryServices modules. You can get the latest versions of these
modules from the PowerShell gallery
This article illustrates how to use Azure Powershell with Azure Resource Manager to configure and manage
protection of your servers. The example used in this article shows you how to protect a virtual machine, running on
a Hyper-V host, to Azure. The following prerequisites are specific to this example. For a more comprehensive set of
requirements for the various Site Recovery scenarios, refer to the documentation pertaining to that scenario.
A Hyper-V host running Windows Server 2012 R2 or Microsoft Hyper-V Server 2012 R2 containing one or
more virtual machines.
Hyper-V servers connected to the Internet, either directly or through a proxy.
The virtual machines you want to protect should conform with Virtual Machine prerequisites.
Step 1: Sign in to your Azure account
1. Open a PowerShell console and run this command to sign in to your Azure account. The cmdlet brings up a
web page that will prompt you for your account credentials.
Login-AzureRmAccount
Alternately, you could also include your account credentials as a parameter to the
cmdlet, by using the -Credential parameter.
Login-AzureRmAccount
If you are CSP partner working on behalf of a tenant, specify the customer as a tenant, by using their
tenantID or tenant primary domain name.
Login-AzureRmAccount -Tenant "fabrikam.com"
2. An account can have several subscriptions, so you should associate the subscription you want to use with
the account.
Select-AzureRmSubscription -SubscriptionName $SubscriptionName
3. Verify that your subscription is registered to use the Azure providers for Recovery Services and Site
Recovery, by using the following commands:
Get-AzureRmResourceProvider -ProviderNamespace Microsoft.RecoveryServices
Get-AzureRmResourceProvider -ProviderNamespace Microsoft.SiteRecovery
In the output of these commands, if the RegistrationState is set to Registered, you can proceed to Step 2.
If not, you should register the missing provider in your subscription.
To register the Azure provider for Site Recovery and Recovery Services, run the following commands:
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.SiteRecovery
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.RecoveryServices
Verify that the providers registered successfully by using the following commands:
Get-AzureRmResourceProvider -ProviderNamespace Microsoft.RecoveryServices and
Get-AzureRmResourceProvider -ProviderNamespace Microsoft.SiteRecovery .
Step 2: Set up the Recovery Services vault
1. Create an Azure Resource Manager resource group in which you'll create the vault, or use an existing
resource group. You can create a new resource group by using the following command:
New-AzureRmResourceGroup -Name $ResourceGroupName -Location $Geo
where the $ResourceGroupName variable contains the name of the resource group you want to create, and
the $Geo variable contains the Azure region in which to create the resource group (for example, "Brazil
South").
You can obtain a list of resource groups in your subscription by using the
Get-AzureRmResourceGroup
cmdlet.
2. Create a new Azure Recovery Services vault as follows:
$vault = New-AzureRmRecoveryServicesVault -Name <string> -ResourceGroupName <string> -Location
<string>
You can retrieve a list of existing vaults by using the
Get-AzureRmRecoveryServicesVault
cmdlet.
NOTE
If you wish to perform operations on Site Recovery vaults created using the classic portal or the Azure Service Management
PowerShell module, you can retrieve a list of such vaults by using the Get-AzureRmSiteRecoveryVault cmdlet. You should
create a new Recovery Services vault for all new operations. The Site Recovery vaults you've created earlier are supported,
but don't have the latest features.
Step 3: Set the Recovery Services vault context
1. Set the vault context by running the following command:
Set-AzureRmSiteRecoveryVaultSettings -ARSVault $vault
Step 4: Create a Hyper-V site and generate a new vault registration key
for the site.
1. Create a new Hyper-V site as follows:
$sitename = "MySite"
#Specify site friendly name
New-AzureRmSiteRecoverySite -Name $sitename
This cmdlet starts a Site Recovery job to create the site, and returns a Site Recovery job object. Wait for the
job to complete and verify that the job completed successfully.
You can retrieve the job object, and thereby check the current status of the job, by using the GetAzureRmSiteRecoveryJob cmdlet.
2. Generate and download a registration key for the site, as follows:
$SiteIdentifier = Get-AzureRmSiteRecoverySite -Name $sitename | Select -ExpandProperty SiteIdentifier
Get-AzureRmRecoveryServicesVaultSettingsFile -Vault $vault -SiteIdentifier $SiteIdentifier SiteFriendlyName $sitename -Path $Path
Copy the downloaded key to the Hyper-V host. You need the key to register the Hyper-V host to the site.
Step 5: Install the Azure Site Recovery provider and Azure Recovery
Services Agent on your Hyper-V host
1. Download the installer for the latest version of the provider from Microsoft.
2. Run the installer on your Hyper-V host, and at the end of the installation continue to the registration step.
3. When prompted, provide the downloaded site registration key, and complete registration of the Hyper-V host
to the site.
4. Verify that the Hyper-V host is registered to the site by using the following command:
$server = Get-AzureRmSiteRecoveryServer -FriendlyName $server-friendlyname
Step 6: Create a replication policy and associate it with the protection
container
1. Create a replication policy as follows:
$ReplicationFrequencyInSeconds = "300";
#options are 30,300,900
$PolicyName = “replicapolicy”
$Recoverypoints = 6
#specify the number of recovery points
$storageaccountID = Get-AzureRmStorageAccount -Name "mystorea" -ResourceGroupName "MyRG" | Select ExpandProperty Id
$PolicyResult = New-AzureRmSiteRecoveryPolicy -Name $PolicyName -ReplicationProvider
“HyperVReplicaAzure” -ReplicationFrequencyInSeconds $ReplicationFrequencyInSeconds -RecoveryPoints
$Recoverypoints -ApplicationConsistentSnapshotFrequencyInHours 1 -RecoveryAzureStorageAccountId
$storageaccountID
Check the returned job to ensure that the replication policy creation succeeds.
IMPORTANT
The storage account specified should be in the same Azure region as your Recovery Services vault, and should have
geo-replication enabled.
If the specified Recovery storage account is of type Azure Storage (Classic), failover of the protected machines
recover the machine to Azure IaaS (Classic).
If the specified Recovery storage account is of type Azure Storage (Azure Resource Manager), failover of the
protected machines recover the machine to Azure IaaS (Azure Resource Manager).
2. Get the protection container corresponding to the site, as follows:
$protectionContainer = Get-AzureRmSiteRecoveryProtectionContainer
3. Start the association of the protection container with the replication policy, as follows:
$Policy = Get-AzureRmSiteRecoveryPolicy -FriendlyName $PolicyName $associationJob = StartAzureRmSiteRecoveryPolicyAssociationJob -Policy $Policy -PrimaryProtectionContainer
$protectionContainer
Wait for the association job to complete, and ensure that it completed successfully.
Step 7: Enable protection for virtual machines
1. Get the protection entity corresponding to the VM you want to protect, as follows:
$VMFriendlyName = "Fabrikam-app"
#Name of the VM
$protectionEntity = Get-AzureRmSiteRecoveryProtectionEntity -ProtectionContainer $protectionContainer
-FriendlyName $VMFriendlyName
2. Start protecting the virtual machine, as follows:
$Ostype = "Windows"
# "Windows" or "Linux"
$DRjob = Set-AzureRmSiteRecoveryProtectionEntity -ProtectionEntity $protectionEntity -Policy $Policy Protection Enable -RecoveryAzureStorageAccountId $storageaccountID -OS $OStype -OSDiskName
$protectionEntity.Disks[0].Name
IMPORTANT
The storage account specified should be in the same Azure region as your Recovery Services vault, and should have
geo-replication enabled.
If the specified Recovery storage account is of type Azure Storage (Classic), failover of the protected machines
recover the machine to Azure IaaS (Classic).
If the specified Recovery storage account is of type Azure Storage (Azure Resource Manager), failover of the
protected machines recover the machine to Azure IaaS (Azure Resource Manager).
If the VM you are protecting has more than one disk attached to it, specify the operating system disk by using the
OSDiskName parameter.
3. Wait for the virtual machines to reach a protected state after the initial replication. This can take a while,
depending on factors such as the amount of data to be replicated and the available upstream bandwidth to
Azure. The job State and StateDescription are updated as follows, upon the VM reaching a protected state.
PS C:\> $DRjob = Get-AzureRmSiteRecoveryJob -Job $DRjob
PS C:\> $DRjob | Select-Object -ExpandProperty State
Succeeded
PS C:\> $DRjob | Select-Object -ExpandProperty StateDescription
Completed
4. Update recovery properties, such as the VM role size, and the Azure network to attach the virtual machine's
network interface cards to upon failover.
PS C:\> $nw1 = Get-AzureRmVirtualNetwork -Name "FailoverNw" -ResourceGroupName "MyRG"
PS C:\> $VMFriendlyName = "Fabrikam-App"
PS C:\> $VM = Get-AzureRmSiteRecoveryVM -ProtectionContainer $protectionContainer -FriendlyName
$VMFriendlyName
PS C:\> $UpdateJob = Set-AzureRmSiteRecoveryVM -VirtualMachine $VM -PrimaryNic
$VM.NicDetailsList[0].NicId -RecoveryNetworkId $nw1.Id -RecoveryNicSubnetName $nw1.Subnets[0].Name
PS C:\> $UpdateJob = Get-AzureRmSiteRecoveryJob -Job $UpdateJob
PS C:\> $UpdateJob
Name
: b8a647e0-2cb9-40d1-84c4-d0169919e2c5
ID
: /Subscriptions/a731825f-4bf2-4f81-a611c331b272206e/resourceGroups/MyRG/providers/Microsoft.RecoveryServices/vault
s/MyVault/replicationJobs/b8a647e0-2cb9-40d1-84c4-d0169919e2c5
Type
: Microsoft.RecoveryServices/vaults/replicationJobs
JobType
: UpdateVmProperties
DisplayName
: Update the virtual machine
ClientRequestId : 805a22a3-be86-441c-9da8-f32685673112-2015-12-10 17:55:51Z-P
State
: Succeeded
StateDescription : Completed
StartTime
: 10-12-2015 17:55:53 +00:00
EndTime
: 10-12-2015 17:55:54 +00:00
TargetObjectId : 289682c6-c5e6-42dc-a1d2-5f9621f78ae6
TargetObjectType : ProtectionEntity
TargetObjectName : Fabrikam-App
AllowedActions : {Restart}
Tasks
: {UpdateVmPropertiesTask}
Errors
: {}
Step 8: Run a test failover
1. Run a test failover job, as follows:
$nw = Get-AzureRmVirtualNetwork -Name "TestFailoverNw" -ResourceGroupName "MyRG" #Specify Azure vnet
name and resource group
$protectionEntity = Get-AzureRmSiteRecoveryProtectionEntity -FriendlyName $VMFriendlyName ProtectionContainer $protectionContainer
$TFjob = Start-AzureRmSiteRecoveryTestFailoverJob -ProtectionEntity $protectionEntity -Direction
PrimaryToRecovery -AzureVMNetworkId $nw.Id
2. Verify that the test VM is created in Azure. (The test failover job is suspended, after creating the test VM in
Azure. The job completes by cleaning up the created artefacts upon resuming the job, as illustrated in the next
step.)
3. Complete the test failover, as follows:
$TFjob = Resume-AzureRmSiteRecoveryJob -Job $TFjob
Next Steps
Read more about Azure Site Recovery with Azure Resource Manager PowerShell cmdlets.
Replicate Hyper-V virtual machines in VMM clouds
to Azure using PowerShell and Azure Resource
Manager
4/27/2017 • 11 min to read • Edit Online
Overview
Azure Site Recovery contributes to your business continuity and disaster recovery (BCDR) strategy by
orchestrating replication, failover and recovery of virtual machines in a number of deployment scenarios. For a full
list of deployment scenarios see the Azure Site Recovery overview.
This article shows you how to use PowerShell to automate common tasks you need to perform when you set up
Azure Site Recovery to replicate Hyper-V virtual machines in System Center VMM clouds to Azure storage.
The article includes prerequisites for the scenario, and shows you
How to set up a Recovery Services Vault
Install the Azure Site Recovery Provider on the source VMM server
Register the server in the vault, add an Azure storage account
Install the Azure Recovery Services agent on Hyper-V host servers
Configure protection settings for VMM clouds, that will be applied to all protected virtual machines
Enable protection for those virtual machines.
Test the fail-over to make sure everything's working as expected.
If you run into problems setting up this scenario, post your questions on the Azure Recovery Services Forum.
NOTE
Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. This
article covers using the Resource Manager deployment model.
Before you start
Make sure you have these prerequisites in place:
Azure prerequisites
You'll need a Microsoft Azure account. If you don't have one, start with a free account. In addition, you can read
about the Azure Site Recovery Manager pricing.
You'll need a CSP subscription if you are trying out the replication to a CSP subscription scenario. Learn more
about the CSP program in how to enroll in the CSP program.
You'll need an Azure v2 storage (Resource Manager) account to store data replicated to Azure. The account
needs geo-replication enabled. It should be in the same region as the Azure Site Recovery service, and be
associated with the same subscription or the CSP subscription. To learn more about setting up Azure storage,
see the Introduction to Microsoft Azure Storage for reference.
You'll need to make sure that virtual machines you want to protect comply with the Azure virtual machine
prerequisites.
NOTE
Currently, only VM level operations are possible through Powershell. Support for recovery plan level operations will be made
soon. For now, you are limited to performing fail-overs only at a ‘protected VM’ granularity and not at a Recovery Plan level.
VMM prerequisites
You'll need VMM server running on System Center 2012 R2.
Any VMM server containing virtual machines you want to protect must be running the Azure Site Recovery
Provider. This is installed during the Azure Site Recovery deployment.
You'll need at least one cloud on the VMM server you want to protect. The cloud should contain:
One or more VMM host groups.
One or more Hyper-V host servers or clusters in each host group.
One or more virtual machines on the source Hyper-V server.
Learn more about setting up VMM clouds:
Read more about private VMM clouds in What’s New in Private Cloud with System Center 2012 R2
VMM and in VMM 2012 and the clouds.
Learn about Configuring the VMM cloud fabric
After your cloud fabric elements are in place learn about creating private clouds in Creating a private
cloud in VMM and in Walkthrough: Creating private clouds with System Center 2012 SP1 VMM.
Hyper-V prerequisites
The host Hyper-V servers must be running at least Windows Server 2012 with Hyper-V role or Microsoft
Hyper-V Server 2012 and have the latest updates installed.
If you're running Hyper-V in a cluster note that cluster broker isn't created automatically if you have a static IP
address-based cluster. You'll need to configure the cluster broker manually. For
For instructions see How to Configure Hyper-V Replica Broker.
Any Hyper-V host server or cluster for which you want to manage protection must be included in a VMM cloud.
Network mapping prerequisites
When you protect virtual machines in Azure, the network mapping maps the virtual machine networks on the
source VMM server and target Azure networks to enable the following:
All machines which fail over on the same network can connect to each other, irrespective of which recovery
plan they are in.
If a network gateway is setup on the target Azure network, virtual machines can connect to other on-premises
virtual machines.
If you don’t configure network mapping, only the virtual machines that fail over in the same recovery plan will
be able to connect to each other after fail-over to Azure.
If you want to deploy network mapping you'll need the following:
The virtual machines you want to protect on the source VMM server should be connected to a VM network.
That network should be linked to a logical network that is associated with the cloud.
An Azure network to which replicated virtual machines can connect after fail-over. You'll select this network at
the time of fail-over. The network should be in the same region as your Azure Site Recovery subscription.
Learn more about network mapping in
How to configure logical networks in VMM
How to configure VM networks and gateways in VMM
How to configure and monitor virtual networks in Azure
PowerShell prerequisites
Make sure you have Azure PowerShell ready to go. If you are already using PowerShell, you'll need to upgrade to
version 0.8.10 or later. For information about setting up PowerShell, see the Guide to install and configure Azure
PowerShell. Once you have set up and configured PowerShell, you can view all of the available cmdlets for the
service here.
To learn about tips that can help you use the cmdlets, such as how parameter values, inputs, and outputs are
typically handled in Azure PowerShell, see the Guide to get Started with Azure Cmdlets.
Step 1: Set the subscription
1. From Azure powershell, login to your Azure account: using the following cmdlets
$UserName = "<[email protected]>"
$Password = "<password>"
$SecurePassword = ConvertTo-SecureString -AsPlainText $Password -Force
$Cred = New-Object System.Management.Automation.PSCredential -ArgumentList $UserName, $SecurePassword
Login-AzureRmAccount #-Credential $Cred
2. Get a list of your subscriptions. This will also list the subscriptionIDs for each of the subscriptions. Note
down the subscriptionID of the subscription in which you wish to create the recovery services vault
Get-AzureRmSubscription
3. Set the subscription in which the recovery services vault is to be created by mentioning the subscription ID
Set-AzureRmContext –SubscriptionID <subscriptionId>
Step 2: Create a Recovery Services vault
1. Create a resource group in Azure Resource Manager if you don't have one already
New-AzureRmResourceGroup -Name #ResourceGroupName -Location #location
2. Create a new Recovery Services vault and save the created ASR vault object in a variable (will be used later).
You can also retrieve the ASR vault object post creation using the Get-AzureRMRecoveryServicesVault
cmdlet:$vault = New-AzureRmRecoveryServicesVault -Name #vaultname -ResouceGroupName #ResourceGroupName Location #location
Step 3: Set the Recovery Services Vault context
Set the vault context by running the below command.
Set-AzureRmSiteRecoveryVaultSettings -ARSVault $vault
Step 4: Install the Azure Site Recovery Provider
1. On the VMM machine, create a directory by running the following command:
New-Item c:\ASR -type directory
2. Extract the files using the downloaded provider by running the following command
pushd C:\ASR\
.\AzureSiteRecoveryProvider.exe /x:. /q
3. Install the provider using the following commands:
.\SetupDr.exe /i
$installationRegPath = "hklm:\software\Microsoft\Microsoft System Center Virtual Machine Manager
Server\DRAdapter"
do
{
$isNotInstalled = $true;
if(Test-Path $installationRegPath)
{
$isNotInstalled = $false;
}
}While($isNotInstalled)
Wait for the installation to finish.
4. Register the server in the vault using the following command:
$BinPath = $env:SystemDrive+"\Program Files\Microsoft System Center 2012 R2\Virtual Machine
Manager\bin"
pushd $BinPath
$encryptionFilePath = "C:\temp\".\DRConfigurator.exe /r /Credentials $VaultSettingFilePath
/vmmfriendlyname $env:COMPUTERNAME /dataencryptionenabled $encryptionFilePath /startvmmservice
Step 5: Create an Azure storage account
If you don't have an Azure storage account, create a geo-replication enabled account in the same geo as the vault
by running the following command:
$StorageAccountName = "teststorageacc1"
#StorageAccountname
$StorageAccountGeo = "Southeast Asia"
$ResourceGroupName = “myRG”
#ResourceGroupName
$RecoveryStorageAccount = New-AzureRmStorageAccount -ResourceGroupName $ResourceGroupName -Name
$StorageAccountName -Type “StandardGRS” -Location $StorageAccountGeo
Note that the storage account must be in the same region as the Azure Site Recovery service, and be associated
with the same subscription.
Step 6: Install the Azure Recovery Services Agent
1. Download the Azure Recovery Services agent at http://aka.ms/latestmarsagent and install it on each Hyper-V
host server located in the VMM clouds you want to protect.
2. Run the following command on all VMM hosts:
marsagentinstaller.exe /q /nu
Step 7: Configure cloud protection settings
1. Create a replication policy to Azure by running the following command:
$ReplicationFrequencyInSeconds = "300";
#options are 30,300,900
$PolicyName = “replicapolicy”
$Recoverypoints = 6
#specify the number of recovery points
$policryresult = New-AzureRmSiteRecoveryPolicy -Name $policyname -ReplicationProvider
HyperVReplicaAzure -ReplicationFrequencyInSeconds $replicationfrequencyinseconds -RecoveryPoints
$recoverypoints -ApplicationConsistentSnapshotFrequencyInHours 1 -RecoveryAzureStorageAccountId
"/subscriptions/q1345667/resourceGroups/test/providers/Microsoft.Storage/storageAccounts/teststorageacc
1"
2. Get a protection container by running the following commands:
$PrimaryCloud = "testcloud"
$protectionContainer = Get-AzureRmSiteRecoveryProtectionContainer -friendlyName $PrimaryCloud;
3. Get the policy details to a variable using the job that was created and mentioning the friendly policy name:
$policy = Get-AzureRmSiteRecoveryPolicy -FriendlyName $policyname
4. Start the association of the protection container with the replication policy:
$associationJob = Start-AzureRmSiteRecoveryPolicyAssociationJob -Policy
PrimaryProtectionContainer $protectionContainer
$Policy -
5. After the job has finished, run the following command:
$job = Get-AzureRmSiteRecoveryJob -Job $associationJob
if($job -eq $null -or $job.StateDescription -ne "Completed")
{
$isJobLeftForProcessing = $true;
}
6. After the job has finished processing, run the following command:
if($isJobLeftForProcessing)
{
Start-Sleep -Seconds 60
}
}While($isJobLeftForProcessing)
To check the completion of the operation, follow the steps in Monitor Activity.
Step 8: Configure network mapping
Before you begin network mapping verify that virtual machines on the source VMM server are connected to a VM
network. In addition, create one or more Azure virtual networks.
Learn more about how to create a virtual network using Azure Resource Manager and PowerShell, in Create a
virtual network with a site-to-site VPN connection using Azure Resource Manager and PowerShell
Note that multiple Virtual Machine networks can be mapped to a single Azure network. If the target network has
multiple subnets and one of those subnets has the same name as subnet on which the source virtual machine is
located, then the replica virtual machine will be connected to that target subnet after fail-over. If there is no target
subnet with a matching name, the virtual machine will be connected to the first subnet in the network.
1. The first command gets servers for the current Azure Site Recovery vault. The command stores the
Microsoft Azure Site Recovery servers in the $Servers array variable.
$Servers = Get-AzureRmSiteRecoveryServer
2. The second command gets the site recovery network for the first server in the $Servers array. The
command stores the networks in the $Networks variable.
$Networks = Get-AzureRmSiteRecoveryNetwork -Server $Servers[0]
3. The third command gets Azure virtual networks, and then that value in the $AzureVmNetworks variable.
$AzureVmNetworks = Get-AzureRmVirtualNetwork
4. The final cmdlet creates a mapping between the primary network and the Azure virtual machine network.
The cmdlet specifies the primary network as the first element of $Networks. The cmdlet specifies a virtual
machine network as the first element of $AzureVmNetworks.
New-AzureRmSiteRecoveryNetworkMapping -PrimaryNetwork $Networks[0] -AzureVMNetworkId
$AzureVmNetworks[0]
Step 9: Enable protection for virtual machines
After the servers, clouds and networks are configured correctly, you can enable protection for virtual machines in
the cloud.
Note the following:
Virtual machines must meet Azure requirements. Check these in Prerequisites and Support in the planning
guide.
To enable protection, the operating system and operating system disk properties must be set for the virtual
machine. When you create a virtual machine in VMM using a virtual machine template you can set the property.
You can also set these properties for existing virtual machines on the General and Hardware Configuration
tabs of the virtual machine properties. If you don't set these properties in VMM you'll be able to configure them
in the Azure Site Recovery portal.
1. To enable protection, run the following command to get the protection container:
$ProtectionContainer = Get-AzureRmSiteRecoveryProtectionContainer -friendlyName $CloudName
2. Get the protection entity (VM) by running the following command:
$protectionEntity = Get-AzureRmSiteRecoveryProtectionEntity -friendlyName $VMName ProtectionContainer $protectionContainer
3. Enable the DR for the VM by running the following command:
$jobResult = Set-AzureRmSiteRecoveryProtectionEntity -ProtectionEntity $protectionentity -Protection
Enable –Force -Policy $policy -RecoveryAzureStorageAccountId $storageID
"/subscriptions/217653172865hcvkchgvd/resourceGroups/rajanirgps/providers/Microsoft.Storage/storageAcco
unts/teststorageacc1
Test your deployment
To test your deployment you can run a test fail-over for a single virtual machine, or create a recovery plan
consisting of multiple virtual machines and run a test fail-over for the plan. Test fail-over simulates your fail-over
and recovery mechanism in an isolated network. Note that:
If you want to connect to the virtual machine in Azure using Remote Desktop after the fail-over, enable Remote
Desktop Connection on the virtual machine before you run the test failover.
After fail-over, you'll use a public IP address to connect to the virtual machine in Azure using Remote Desktop.
If you want to do this, ensure you don't have any domain policies that prevent you from connecting to a virtual
machine using a public address.
To check the completion of the operation, follow the steps in Monitor Activity.
Run a test failover
Start the test failover by running the following command:
$protectionEntity = Get-AzureRmSiteRecoveryProtectionEntity -Name $VMName -ProtectionContainer
$protectionContainer
$jobIDResult = Start-AzureRmSiteRecoveryTestFailoverJob -Direction PrimaryToRecovery ProtectionEntity $protectionEntity -AzureVMNetworkId <string>
Run a planned failover
Start the planned failover by running the following command:
$protectionEntity = Get-AzureRmSiteRecoveryProtectionEntity -Name $VMName -ProtectionContainer
$protectionContainer
$jobIDResult = Start-AzureRmSiteRecoveryPlannedFailoverJob -Direction PrimaryToRecovery ProtectionEntity $protectionEntity -AzureVMNetworkId <string>
Run an unplanned failover
Start the unplanned failover by running the following command:
$protectionEntity = Get-AzureRmSiteRecoveryProtectionEntity -Name $VMName -ProtectionContainer
$protectionContainer
$jobIDResult = Start-AzureRmSiteRecoveryUnPlannedFailoverJob -Direction PrimaryToRecovery ProtectionEntity $protectionEntity -AzureVMNetworkId <string>
Monitor Activity
Use the following commands to monitor the activity. Note that you have to wait in between jobs for the processing
to finish.
Do
{
$job = Get-AzureSiteRecoveryJob -Id $associationJob.JobId;
Write-Host "Job State:{0}, StateDescription:{1}" -f Job.State, $job.StateDescription;
if($job -eq $null -or $job.StateDescription -ne "Completed")
{
$isJobLeftForProcessing = $true;
}
if($isJobLeftForProcessing)
{
Start-Sleep -Seconds 60
}
}While($isJobLeftForProcessing)
Next steps
Read more about Azure Site Recovery with Azure Resource Manager PowerShell cmdlets.
Replicate Hyper-V virtual machines in VMM clouds to
a secondary VMM site using PowerShell (Resource
Manager)
4/27/2017 • 10 min to read • Edit Online
Welcome to Azure Site Recovery! Use this article if you want to replicate on-premises Hyper-V virtual machines
managed in System Center Virtual Machine Manager (VMM) clouds to a secondary site.
This article shows you how to use PowerShell to automate common tasks you need to perform when you set up
Azure Site Recovery to replicate Hyper-V virtual machines in System Center VMM clouds to System Center VMM
clouds in secondary site.
The article includes prerequisites for the scenario, and shows you
How to set up a Recovery Services Vault
Install the Azure Site Recovery Provider on the source VMM server and the target VMM server
Register the VMM server(s) in the vault
Configure replication policy for the VMM Cloud. The replication settings in the policy will be applied to all
protected virtual machines
Enable protection for the virtual machines.
Test the failover of VMs individually or as part of a recovery plan to make sure everything is working as
expected.
Perform a planned or an unplanned failover of VMs individually or as part of a recovery plan to make sure
everything is working as expected.
If you run into problems setting up this scenario, post your questions on the Azure Recovery Services Forum.
NOTE
Azure has two different deployment models for creating and working with resources: Azure Resource Manager and classic.
Azure also has two portals – the Azure classic portal that supports the classic deployment model, and the Azure portal with
support for both deployment models. This article covers the Resource Manager deployment model.
On-premises prerequisites
Here's what you'll need in the primary and secondary on-premises sites to deploy this scenario:
PREREQUISITES
DETAILS
PREREQUISITES
DETAILS
VMM
We recommend you deploy a VMM server in the primary site
and a VMM server in the secondary site.
You can also replicate between clouds on a single VMM
server. To do this you'll need at least two clouds configured on
the VMM server.
VMM servers should be running at least System Center 2012
SP1 with the latest updates.
Each VMM server must have at one or more clouds
configured and all clouds must have the Hyper-V Capacity
profile set.
Clouds must contain one or more VMM host groups.
Learn more about setting up VMM clouds in Configuring the
VMM cloud fabric, and Walkthrough: Creating private clouds
with System Center 2012 SP1 VMM.
VMM servers should have internet access.
Hyper-V
Hyper-V servers must be running at least Windows Server
2012 with the Hyper-V role and have the latest updates
installed.
A Hyper-V server should contain one or more VMs.
Hyper-V host servers should be located in host groups in the
primary and secondary VMM clouds.
If you're running Hyper-V in a cluster on Windows Server
2012 R2 you should install update 2961977
If you're running Hyper-V in a cluster on Windows Server
2012 note that cluster broker isn't created automatically if you
have a static IP address-based cluster. You'll need to configure
the cluster broker manually. Read more.
Provider
During Site Recovery deployment you install the Azure Site
Recovery Provider on VMM servers. The Provider
communicates with Site Recovery over HTTPS 443 to
orchestrate replication. Data replication occurs between the
primary and secondary Hyper-V servers over the LAN or a
VPN connection.
The Provider running on the VMM server needs access to
these URLs: *.hypervrecoverymanager.windowsazure.com;
*.accesscontrol.windows.net; *.backup.windowsazure.com;
*.blob.core.windows.net; *.store.core.windows.net.
In addition allow firewall communication from the VMM
servers to the Azure datacenter IP ranges and allow the HTTPS
(443) protocol.
Network mapping prerequisites
Network mapping maps between VMM VM networks on the primary and secondary VMM servers to:
Optimally place replica VMs on secondary Hyper-V hosts after failover.
Connect replica VMs to appropriate VM networks.
If you don't configure network mapping replica VMs won't be connected to any network after failover.
If you want to set up network mapping during Site Recovery deployment here's what you'll need:
Make sure that VMs on the source Hyper-V host server are connected to a VMM VM network. That
network should be linked to a logical network that is associated with the cloud.
Verify that the secondary cloud that you'll use for recovery has a corresponding VM network configured.
That VM network should be linked to a logical network that's associated with the secondary cloud.
Learn more about configuring VMM networks in the below articles
How to configure logical networks in VMM
How to configure VM networks and gateways in VMM
Learn more about how network mapping works.
PowerShell prerequisites
Make sure you have Azure PowerShell ready to go. If you are already using PowerShell, you'll need to upgrade to
version 0.8.10 or later. For information about setting up PowerShell, see the Guide to install and configure Azure
PowerShell. Once you have set up and configured PowerShell, you can view all of the available cmdlets for the
service here.
To learn about tips that can help you use the cmdlets, such as how parameter values, inputs, and outputs are
typically handled in Azure PowerShell, see the Guide to get Started with Azure Cmdlets.
Step 1: Set the subscription
1. From Azure powershell, login to your Azure account: using the following cmdlets
$UserName = "<[email protected]>"
$Password = "<password>"
$SecurePassword = ConvertTo-SecureString -AsPlainText $Password -Force
$Cred = New-Object System.Management.Automation.PSCredential -ArgumentList $UserName, $SecurePassword
Login-AzureRmAccount #-Credential $Cred
2. Get a list of your subscriptions. This will also list the subscriptionIDs for each of the subscriptions. Note
down the subscriptionID of the subscription in which you wish to create the recovery services vault
Get-AzureRmSubscription
3. Set the subscription in which the recovery services vault is to be created by mentioning the subscription ID
Set-AzureRmContext –SubscriptionID <subscriptionId>
Step 2: Create a Recovery Services vault
1. Create an Azure Resource Manager resource group if you don't have one already
New-AzureRmResourceGroup -Name #ResourceGroupName -Location #location
2. Create a new Recovery Services vault and save the created ASR vault object in a variable (will be used later).
You can also retrieve the ASR vault object post creation using the Get-AzureRMRecoveryServicesVault
cmdlet:-
$vault = New-AzureRmRecoveryServicesVault -Name #vaultname -ResouceGroupName #ResourceGroupName Location #location
Step 3: Set the Recovery Services Vault context
1. If you have a vault already created, run the below command to get the vault.
$vault = Get-AzureRmRecoveryServicesVault -Name #vaultname
2. Set the vault context by running the below command.
Set-AzureRmSiteRecoveryVaultSettings -ARSVault $vault
Step 4: Install the Azure Site Recovery Provider
1. On the VMM machine, create a directory by running the following command:
New-Item c:\ASR -type directory
2. Extract the files using the downloaded provider by running the following command
pushd C:\ASR\
.\AzureSiteRecoveryProvider.exe /x:. /q
3. Install the provider using the following commands:
.\SetupDr.exe /i
$installationRegPath = "hklm:\software\Microsoft\Microsoft System Center Virtual Machine Manager
Server\DRAdapter"
do
{
$isNotInstalled = $true;
if(Test-Path $installationRegPath)
{
$isNotInstalled = $false;
}
}While($isNotInstalled)
Wait for the installation to finish.
4. Register the server in the vault using the following command:
$BinPath = $env:SystemDrive+"\Program Files\Microsoft System Center 2012 R2\Virtual Machine Manager\bin"
pushd $BinPath
$encryptionFilePath = "C:\temp\".\DRConfigurator.exe /r /Credentials $VaultSettingFilePath
/vmmfriendlyname $env:COMPUTERNAME /dataencryptionenabled $encryptionFilePath /startvmmservice
Step 5: Create and associate a replication policy
1. Create a Hyper-V 2012 R2 replication policy by running the following command:
$ReplicationFrequencyInSeconds = "300";
#options are 30,300,900
$PolicyName = “replicapolicy”
$RepProvider = HyperVReplica2012R2
$Recoverypoints = 24
#specify the number of hours to retain recovery pints
$AppConsistentSnapshotFrequency = 4 #specify the frequency (in hours) at which app consistent snapshots
are taken
$AuthMode = "Kerberos" #options are "Kerberos" or "Certificate"
$AuthPort = "8083" #specify the port number that will be used for replication traffic on Hyper-V hosts
$InitialRepMethod = "Online" #options are "Online" or "Offline"
$policyresult = New-AzureRmSiteRecoveryPolicy -Name $policyname -ReplicationProvider $RepProvider ReplicationFrequencyInSeconds $Replicationfrequencyinseconds -RecoveryPoints $recoverypoints ApplicationConsistentSnapshotFrequencyInHours $AppConsistentSnapshotFrequency -Authentication $AuthMode
-ReplicationPort $AuthPort -ReplicationMethod $InitialRepMethod
NOTE
The VMM cloud can contain Hyper-V hosts running different versions of Windows Server (as mentioned in the
Hyper-V prerequisites), but the replication policy is OS version specific. If you have different hosts running on
different operating system versions, then create separate replication policies for each type of OS version. For eg: If
you have five hosts running on Windows Servers 2012 and three on Windows Server 2012 R2, create two replication
polices – one for each type of operating system versions.
2. Get the primary protection container (primary VMM Cloud) and recovery protection container (recovery
VMM Cloud) by running the following commands:
$PrimaryCloud = "testprimarycloud"
$primaryprotectionContainer = Get-AzureRmSiteRecoveryProtectionContainer -friendlyName $PrimaryCloud;
$RecoveryCloud = "testrecoverycloud"
$recoveryprotectionContainer = Get-AzureRmSiteRecoveryProtectionContainer -friendlyName $RecoveryCloud;
3. Retrieve the policy you created in step 1 using the friendly name of the policy
$policy = Get-AzureRmSiteRecoveryPolicy -FriendlyName $policyname
4. Start the association of the protection container (VMM Cloud) with the replication policy:
$associationJob = Start-AzureRmSiteRecoveryPolicyAssociationJob -Policy
$Policy PrimaryProtectionContainer $primaryprotectionContainer -RecoveryProtectionContainer
$recoveryprotectionContainer
5. Wait for the policy association job to complete. You can check if the job has completed using the following
PowerShell snippet.
$job = Get-AzureRmSiteRecoveryJob -Job $associationJob
if($job -eq $null -or $job.StateDescription -ne "Completed")
{
$isJobLeftForProcessing = $true;
}
After the job has finished processing, run the following command:
if($isJobLeftForProcessing)
{
Start-Sleep -Seconds 60
}
}While($isJobLeftForProcessing)
To check the completion of the operation, follow the steps in Monitor Activity.
Step 6: Configure network mapping
1. The first command gets servers for the current Azure Site Recovery vault. The command stores the
Microsoft Azure Site Recovery servers in the $Servers array variable.
$Servers = Get-AzureRmSiteRecoveryServer
2. The below commands get the site recovery network for the source VMM server and the target VMM server.
$PrimaryNetworks = Get-AzureRmSiteRecoveryNetwork -Server $Servers[0]
$RecoveryNetworks = Get-AzureRmSiteRecoveryNetwork -Server $Servers[1]
NOTE
The source VMM server can be the first one or the second one in the servers array. Check the names of the VMM
servers and get the networks appropriately
3. The final cmdlet creates a mapping between the primary network and the recovery network. The cmdlet
specifies the primary network as the first element of $PrimaryNetworks and the recovery network as the
first element of $RecoveryNetworks.
New-AzureRmSiteRecoveryNetworkMapping -PrimaryNetwork $PrimaryNetworks[0] -RecoveryNetwork
$RecoveryNetworks[0]
Step 7: Configure storage mapping
1. The below command gets the list of storage classifications into $storageclassifications variable.
$storageclassifications = Get-AzureRmSiteRecoveryStorageClassification
2. The below commands get the source classification into $SourceClassificaion variable and target
classification into $TargetClassification variable.
$SourceClassificaion = $storageclassifications[0]
$TargetClassification = $storageclassifications[1]
NOTE
The source and target classifications can be any element in the array. Refer to the output of the below command to
figure the index of source and target classifications in $storageclassifications array.
Get-AzureRmSiteRecoveryStorageClassification | Select-Object -Property FriendlyName, Id | Format-Table
3. The below cmdlet creates a mapping between the source classification and the target classification.
New-AzureRmSiteRecoveryStorageClassificationMapping -PrimaryStorageClassification $SourceClassificaion
-RecoveryStorageClassification $TargetClassification
Step 8: Enable protection for virtual machines
After the servers, clouds and networks are configured correctly, you can enable protection for virtual machines in
the cloud.
1. To enable protection, run the following command to get the protection container:
$PrimaryProtectionContainer = Get-AzureRmSiteRecoveryProtectionContainer -friendlyName
$PrimaryCloudName
2. Get the protection entity (VM) by running the following command:
$protectionEntity = Get-AzureRmSiteRecoveryProtectionEntity -friendlyName $VMName ProtectionContainer $PrimaryProtectionContainer
3. Enable replication for the VM by running the following command:
$jobResult = Set-AzureRmSiteRecoveryProtectionEntity -ProtectionEntity $protectionentity -Protection
Enable -Policy $policy
Test your deployment
To test your deployment you can run a test failover for a single virtual machine, or create a recovery plan
consisting of multiple virtual machines and run a test failover for the plan. Test failover simulates your failover and
recovery mechanism in an isolated network.
NOTE
You can create a recovery plan for your application in Azure portal.
To check the completion of the operation, follow the steps in Monitor Activity.
Run a test failover
1. Run the below cmdlets to get the VM network to which you want to test failover your VMs to.
$Servers = Get-AzureRmSiteRecoveryServer
$RecoveryNetworks = Get-AzureRmSiteRecoveryNetwork -Server $Servers[1]
2. Perform a test failover of a VM by doing the following:
$protectionEntity = Get-AzureRmSiteRecoveryProtectionEntity -FriendlyName $VMName -ProtectionContainer
$PrimaryprotectionContainer
$jobIDResult = Start-AzureRmSiteRecoveryTestFailoverJob -Direction PrimaryToRecovery -ProtectionEntity
$protectionEntity -VMNetwork $RecoveryNetworks[1]
3. Perform a test failover of a recovery plan by doing the following:
$recoveryplanname = "test-recovery-plan"
$recoveryplan = Get-AzureRmSiteRecoveryRecoveryPlan -FriendlyName $recoveryplanname
$jobIDResult = Start-AzureRmSiteRecoveryTestFailoverJob -Direction PrimaryToRecovery -Recoveryplan
$recoveryplan -VMNetwork $RecoveryNetworks[1]
Run a planned failover
1. Perform a planned failover of a VM by doing the following:
$protectionEntity = Get-AzureRmSiteRecoveryProtectionEntity -Name $VMName -ProtectionContainer
$PrimaryprotectionContainer
$jobIDResult = Start-AzureRmSiteRecoveryPlannedFailoverJob -Direction PrimaryToRecovery ProtectionEntity $protectionEntity
2. Perform a planned failover of a recovery plan by doing the following:
$recoveryplanname = "test-recovery-plan"
$recoveryplan = Get-AzureRmSiteRecoveryRecoveryPlan -FriendlyName $recoveryplanname
$jobIDResult = Start-AzureRmSiteRecoveryPlannedFailoverJob -Direction PrimaryToRecovery -Recoveryplan
$recoveryplan
Run an unplanned failover
1. Perform an unplanned failover of a VM by doing the following:
$protectionEntity = Get-AzureRmSiteRecoveryProtectionEntity -Name $VMName -ProtectionContainer
$PrimaryprotectionContainer
$jobIDResult = Start-AzureRmSiteRecoveryUnPlannedFailoverJob -Direction PrimaryToRecovery ProtectionEntity $protectionEntity
2.Perform an unplanned failover of a recovery plan by doing the following:
$recoveryplanname = "test-recovery-plan"
$recoveryplan = Get-AzureRmSiteRecoveryRecoveryPlan -FriendlyName $recoveryplanname
$jobIDResult = Start-AzureRmSiteRecoveryUnPlannedFailoverJob -Direction PrimaryToRecovery ProtectionEntity $protectionEntity
Monitor Activity
Use the following commands to monitor the activity. Note that you have to wait in between jobs for the processing
to finish.
Do
{
$job = Get-AzureSiteRecoveryJob -Id $associationJob.JobId;
Write-Host "Job State:{0}, StateDescription:{1}" -f Job.State, $job.StateDescription;
if($job -eq $null -or $job.StateDescription -ne "Completed")
{
$isJobLeftForProcessing = $true;
}
if($isJobLeftForProcessing)
{
Start-Sleep -Seconds 60
}
}While($isJobLeftForProcessing)
Next steps
Read more about Azure Site Recovery with Azure Resource Manager PowerShell cmdlets.
Manage replication policy for VMware to Azure
2/21/2017 • 1 min to read • Edit Online
Create a replication policy
1. Select Manage > Site Recovery Infrastructure.
2. Select Replication policies under For VMware and Physical machines.
3. Select +Replication policy.
4. Enter the policy name.
5. In RPO threshold, specify the RPO limit. Alerts will be generated when continuous replication exceeds this
limit.
6. In Recovery point retention, specify (in hours) the duration of the retention window for each recovery
point. Protected machines can be recovered to any point within a retention window.
NOTE
Up to 24 hours of retention is supported for machines replicated to premium storage. Up to 72 hours of retention is
supported for machines replicated to standard storage.
NOTE
A replication policy for failback is automatically created.
7. In App-consistent snapshot frequency, specify how often (in minutes) recovery points that contain
application-consistent snapshots will be created.
8. Click OK. The policy should be created in 30 to 60 seconds.
Associate a configuration server with a replication policy
1. Choose the replication policy to which you want to associate the configuration server.
2. Click Associate.
3. Select the configuration server from the list of servers.
4. Click OK. The configuration server should be associated in one to two minutes.
Edit a replication policy
1. Choose the replication policy for which you want to edit replication settings.
2. Click Edit Settings.
3. Change the settings based on your need.
4. Click Save. The policy should be saved in two to five minutes, depending on how many VMs are using that
replication policy.
Dissociate a configuration server from a replication policy
1.
2.
3.
4.
Choose the replication policy to which you want to associate the configuration server.
Click Dissociate.
Select the configuration server from the list of servers.
Click OK. The configuration server should be dissociated in one to two minutes.
NOTE
You cannot dissociate a configuration server if there is at least one replicated item using the policy. Make sure there
are no replicated items using the policy before you dissociate the configuration server.
Delete a replication policy
1. Choose the replication policy that you want to delete.
2. Click Delete. The policy should be deleted in 30 to 60 seconds.
NOTE
You cannot delete a replication policy if it has at least one configuration server associated to it. Make sure there are
no replicated items using the policy and delete all the associated configuration servers before you delete the policy.
Manage a process server running in Azure (Resource
Manager)
2/21/2017 • 4 min to read • Edit Online
During failback, it is recommended to deploy process server in Azure if there is high latency between the Azure
Virtual Network and your on-premises network. This article describes how you can set up, configure, and manage
the process servers running in Azure.
NOTE
This article is to be used if you used Resource Manager as the deployment model for the virtual machines during failover. If
you used Classic as the deployment model, follow the steps in How to set up & configure a Failback process server (Classic)
Prerequisites
This article assumes that
1. A Site to Site VPN or an Express Route connection between your on-premises network and the Azure Virtual
Network has already been established.
2. Your user account has permissions to create a new virtual machine in the Azure Subscription that the virtual
machines have been failed over into.
3. Your subscription has a minimum of 4 Cores available to spin up a new Process Server virtual machine.
4. You have the Configuration Server Passphrase available.
TIP
Ensure that you are able to connect port 443 of the Configuration Server (running on-premises) from the Azure Virtual
Network that the virtual machines have been failed over into.
Deploy a process server on Azure
1. In the Vault > Site Recovery Infrastructure (under the "Manage" heading) > Configuration Servers (under
"For VMware and Physical Machines" heading), select the configuration server.
2. In the Configuration Server details page that opens click "+ Process server"
3. On the Add process server page, select the following values
FIELD NAME
VALUE
Choose where you want to deploy your process server
Select the value Deploy a failback process server in
Azure
Subscription
Select the Azure Subscription where you failed over the
virtual machines
Resource Group
You can create a Resource Group to deploy this process
server or choose to deploy the process server in an
existing Resource Group
Location
Select the Azure Data Center into which the virtual
machines where failed over into
FIELD NAME
VALUE
Azure Network
Select the Azure Virtual Network(VNet) that the virtual
machines where failed over into. If you failed over virtual
machines into multiple Azure VNets, then you need a
process server deployed per VNet
4. Fill in the rest of the properties for the process server
FIELD NAME
VALUE
Server Name
Display name & Host name for your process server virtual
machine
User Name
A user name that becomes an Administrator on that
virtual machine
Storage Account
Name of the Storage Account where the virtual machine's
virtual disk's are placed
FIELD NAME
VALUE
Subnet
The subnet of the Azure VNet to which the virtual
machine is connected
IP Address
IP Address that you would like the process server to
assume once it boots up
5. Click the OK button to start deploying the process server virtual machine.
NOTE
To be able to use this process server for failback, you need to register it with the on-premises configuration server.
Registering the process server (running in Azure) to a Configuration
Server (running on-premises)
Connect to the Process Server virtual machine using Remote Desktop Connection.
You can launch the cspsconfigtool.exe by clicking on the shortcut available on the desktop. (The tool will be
automatically launched if this the first time you are logging into the process sever).
Configuration Server's fully qualified name (FQDN) or IP Address
Port on which the Configuration server is listening on. The value should be 443
Connection Passphrase to connect to the configuration server.
Data Transfer port to be configured for this Process Server. Leave the default value as is unless you
have changed it to a different port number in your environment.
Click the save button to save the configuration and register the Process Server.
Upgrading the process server to latest version.
Typically when you create a process server using the Azure Gallery Image, it is provisioned with the latest version
of the process server software available at that time. The Azure Site Recovery team releases bugs fixes & new
enhancements to the product on a periodic basis. It is strongly recommended that you keep your process server
updated to the latest version to take advantage of the bug fixes, new features & enhancements that have been
released. Follow the below steps to update your Process Server running in Azure.
1.
2.
3.
4.
Login to the process server as an Administrator.
Download the latest version of the Unified Setup.
Double-click the installer to launch the update process.
The installer will detect the various components that are installed and upgrade them to the latest version.
Unregistering the process server (running in Azure) from a
Configuration Server (running on-premises)
The steps to unregister a process server differs depending on its connection status with the Configuration Server.
Unregister a process server that is in a connected state
1. Remote into the process server as an Administrator.
2. Launch the Control Panel and open Programs > Uninstall a program
3. Uninstall a program by the name Microsoft Azure Site Recovery Configuration/Process Server
4. Once step 3 is completed, you can uninstall Microsoft Azure Site Recovery Configuration/Process Server
Dependencies
Unregister a process server that is in a disconnected state
WARNING
Use the below steps should be used if there is no way to revive the virtual machine on which the Process Server was
installed.
1. Log on to your configuration server as an Administrator.
2. Open an Administrative command prompt and browse to the directory
3. Now run the command.
%ProgramData%\ASR\home\svsystems\bin
perl Unregister-ASRComponent.pl -IPAddress <IP_of_Process_Server> -Component PS
4. This will purge the details of the process server from the system.
.
Manage a Configuration Server
4/12/2017 • 11 min to read • Edit Online
Configuration Server acts as a coordinator between the Site Recovery services and your on-premises infrastructure.
This article describes how you can set up, configure, and manage the Configuration Server.
Prerequisites
The following are the minimum hardware, software, and network configuration required to set up a Configuration
Server.
NOTE
Capacity planning is an important step to ensure that you deploy the Configuration Server with a configuration that suites
your load requirements. Read more about Sizing requirements for a Configuration Server.
HARDWARE
Number of CPU cores
8
RAM
12 GB
Number of disks
3
- OS disk
- Process server cache disk
- Retention drive (for failback)
Disk free space (process server cache)
600 GB
Disk free space (retention disk)
600 GB
Software
Operating system version
Windows Server 2012 R2
Operating system locale
English (en-us)
VMware vSphere PowerCLI version
PowerCLI 6.0
Windows Server roles
Do not enable the following roles:
- Active Directory Domain Services
- Internet Information Services
- Hyper-V
Network
Network interface card type
VMXNET3
IP address type
Static
HARDWARE
Internet access
The server should be able to access the following URLs either
directly or through a proxy server:
- *.accesscontrol.windows.net
- *.backup.windowsazure.com
- *.store.core.windows.net
- *.blob.core.windows.net
- *.hypervrecoverymanager.windowsazure.com
- https://cdn.mysql.com/archives/mysql-5.5/mysql-5.5.37win32.msi (not required for Scale-out Process Servers)
- time.nist.gov
- time.windows.com
Ports
443 (Control channel orchestration)
9443 (Data transport)
Downloading the Configuration Server software
1. Log on to the Azure portal and browse to your Recovery Services Vault.
2. Browse to Site Recovery Infrastructure > Configuration Servers (under For VMware & Physical
Machines).
3. Click the +Servers button.
4. On the Add Server page, click the Download button to download the Registration key. You need this key during
the Configuration Server installation to register it with Azure Site Recovery service.
5. Click the Download the Microsoft Azure Site Recovery Unified Setup link to download the latest
version of the Configuration Server.
TIP
Latest version of the Configuration Server can be downloaded directly from Microsoft Download Center download
page
Installing and Registering a Configuration Server from GUI
1. Run the Unified Setup installation file.
2. In Before you begin, select Install the configuration server and process server.
3. In Third Party Software License, click I Accept to download and install MySQL.
4. In Registration, select the registration key you downloaded from the vault.
5. In Internet Settings, specify how the Provider running on the configuration server connects to Azure Site
Recovery over the Internet.
If you want to connect with the proxy that's currently set up on the machine, select Connect with
existing proxy settings.
If you want the Provider to connect directly, select Connect directly without a proxy.
If the existing proxy requires authentication, or if you want to use a custom proxy for the Provider
connection, select Connect with custom proxy settings.
If you use a custom proxy, you need to specify the address, port, and credentials.
If you're using a proxy, you should have already allowed the URLs described in prerequisites.
6. In Prerequisites Check, Setup runs a check to make sure that installation can run. If a warning appears
about the Global time sync check, verify that the time on the system clock (Date and Time settings) is the
same as the time zone.
7. In MySQL Configuration, create credentials for logging on to the MySQL server instance that is installed.
8. In Environment Details, select whether you're going to replicate VMware VMs. If you are, then setup
checks that PowerCLI 6.0 is installed.
9. In Install Location, select where you want to install the binaries and store the cache. The drive you select
must have at least 5 GB of disk space available, but we recommend a cache drive with at least 600 GB of free
space.
10. In Network Selection, specify the listener (network adapter and SSL port) on which the configuration
server sends and receives replication data. Port 9443 is the default port used for sending and receiving
replication traffic, but you can modify this port number to suit your environment's requirements. In addition
to the port 9443, we also open port 443, which is used by a web server to orchestrate replication operations.
Do not use Port 443 for sending or receiving replication traffic.
11. In Summary, review the information and click Install. When installation finishes, a passphrase is generated.
You will need this when you enable replication, so copy it and keep it in a secure location.
After registration finishes, the server is displayed on the Settings > Servers blade in the vault.
Installing and registering a Configuration Server using Command line
UnifiedSetup.exe [/ServerMode <CS/PS>] [/InstallDrive <DriveLetter>] [/MySQLCredsFilePath <MySQL credentials
file path>] [/VaultCredsFilePath <Vault credentials file path>] [/EnvType <VMWare/NonVMWare>] [/PSIP <IP
address to be used for data transfer] [/CSIP <IP address of CS to be registered with>] [/PassphraseFilePath
<Passphrase file path>]
Sample usage
MicrosoftAzureSiteRecoveryUnifiedSetup.exe /q /xC:\Temp\Extracted
cd C:\Temp\Extracted
UNIFIEDSETUP.EXE /AcceptThirdpartyEULA /servermode "CS" /InstallLocation "D:\" /MySQLCredsFilePath
"C:\Temp\MySQLCredentialsfile.txt" /VaultCredsFilePath "C:\Temp\MyVault.vaultcredentials" /EnvType "VMWare"
Configuration Server installer command-line arguments.
PARAMETER NAME
TYPE
DESCRIPTION
POSSIBLE VALUES
/ServerMode
Mandatory
Specifies whether both the
configuration and process
servers should be installed,
or the process server only
CS
PS
/InstallLocation
Mandatory
The folder in which the
components are installed
Any folder on the computer
/MySQLCredsFilePath
Mandatory
The file path in which the
MySQL server credentials are
stored
The file should be the format
specified below
/VaultCredsFilePath
Mandatory
The path of the vault
credentials file
Valid file path
PARAMETER NAME
TYPE
DESCRIPTION
POSSIBLE VALUES
/EnvType
Mandatory
Type of envrionment that
you want to protect
VMware
NonVMware
/PSIP
Mandatory
IP address of the NIC to be
used for replication data
transfer
Any valid IP Address
/CSIP
Mandatory
The IP address of the NIC on
which the configuration
server is listening on
Any valid IP Address
/PassphraseFilePath
Mandatory
The full path to location of
the passphrase file
Valid file path
/BypassProxy
Optional
Specifies that the
configuration server
connects to Azure without a
proxy
To do get this value from
Venu
/ProxySettingsFilePath
Optional
Proxy settings (The default
proxy requires
authentication, or a custom
proxy)
The file should be in the
format specified below
DataTransferSecurePort
Optional
Port number on the PSIP to
be used for replication data
Valid Port Number (default
value is 9433)
/SkipSpaceCheck
Optional
Skip space check for cache
disk
/AcceptThirdpartyEULA
Mandatory
Flag implies acceptance of
third-party EULA
/ShowThirdpartyEULA
Optional
Displays third-party EULA. If
provided as input all other
parameters are ignored
Create a MySql credentials file
MySQLCredsFilePath parameter takes a file as input. Create the file using the following format and pass it as input
MySQLCredsFilePath parameter.
[MySQLCredentials]
MySQLRootPassword = "Password>"
MySQLUserPassword = "Password"
Create a proxy settings configuration file
ProxySettingsFilePath parameter takes a file as input. Create the file using the following format and pass it as input
ProxySettingsFilePath parameter.
[ProxySettings]
ProxyAuthentication = "Yes/No"
Proxy IP = "IP Address"
ProxyPort = "Port"
ProxyUserName="UserName"
ProxyPassword="Password"
Modifying proxy settings for Configuration Server
1.
2.
3.
4.
Login to your Configuration Server.
Launch the cspsconfigtool.exe using the shortcut on your.
Click the Vault Registration tab.
Download a new Vault Registration file from the portal and provide it as input to the tool.
5. Provide the new Proxy Server details and click the Register button.
6. Open an Admin PowerShell command window.
7. Run the following command
$pwd = ConvertTo-SecureString -String MyProxyUserPassword
Set-OBMachineSetting -ProxyServer http://myproxyserver.domain.com -ProxyPort PortNumber – ProxyUserName
domain\username -ProxyPassword $pwd
net stop obengine
net start obengine
WARNING
If you have Scale-out Process servers attached to this Configuration Server, you need to fix the proxy settings on all
the scale-out process servers in your deployment.
Re-register a Configuration Server with the same Recovery Services
Vault
1.
2.
3.
4.
Login to your Configuration Server.
Launch the cspsconfigtool.exe using the shortcut on your desktop.
Click the Vault Registration tab.
Download a new Registration file from the portal and provide it as input to the tool.
5. Provide the Proxy Server details and click the Register button.
6. Open an Admin PowerShell command window.
7. Run the following command
$pwd = ConvertTo-SecureString -String MyProxyUserPassword
Set-OBMachineSetting -ProxyServer http://myproxyserver.domain.com -ProxyPort PortNumber – ProxyUserName
domain\username -ProxyPassword $pwd
net stop obengine
net start obengine
WARNING
If you have Scale-out Process servers attached to this Configuration Server, you need to re-register all the scale-out
process servers in your deployment.
Registering a Configuration Server with a different Recovery Services
Vault.
1. Login to your Configuration Server.
2. from an admin command prompt, run the command
reg delete HKLM\Software\Microsoft\Azure Site Recovery\Registration
net stop dra
1. Launch the cspsconfigtool.exe using the shortcut on your.
2. Click the Vault Registration tab.
3. Download a new Registration file from the portal and provide it as input to the tool.
4. Provide the Proxy Server details and click the Register button.
5. Open an Admin PowerShell command window.
6. Run the following command
$pwd = ConvertTo-SecureString -String MyProxyUserPassword Set-OBMachineSetting -ProxyServer
http://myproxyserver.domain.com -ProxyPort PortNumber – ProxyUserName domain\username -ProxyPassword $pwd net
stop obengine net start obengine
Decommissioning a Configuration Server
Ensure the following before you start decommissioning your Configuration Server.
1. Disable protection for all virtual machines under this Configuration Server.
2. Disassociate all Replication policies from the Configuration Server.
3. Delete all vCenters servers/vSphere hosts that are associated to the Configuration Server.
Delete the Configuration Server from Azure portal
1. In Azure portal, browse to Site Recovery Infrastructure > Configuration Servers from the Vault menu.
2. Click the Configuration Server that you want to decommission.
3. On the Configuration Server's details page, click the Delete button.
4. Click Yes to confirm the deletion of the server.
WARNING
If you have any virtual machines, Replication policies or vCenter servers/vSphere hosts associated with this
Configuration Server, you cannot delete the server. Delete these entities before you try to delete the vault.
Uninstall the Configuration Server software and its dependencies
TIP
If you plan to reuse the Configuration Server with Azure Site Recovery again, then you can skip to step 4 directly
1. Log on to the Configuration Server as an Administrator.
2. Open up Control Panel > Program > Uninstall Programs
3. Uninstall the programs in the following sequence:
Microsoft Azure Recovery Services Agent
Microsoft Azure Site Recovery Mobility Service/Master Target server
Microsoft Azure Site Recovery Provider
Microsoft Azure Site Recovery Configuration Server/Process Server
Microsoft Azure Site Recovery Configuration Server Dependencies
MySQL Server 5.5
4. Run the following command from and admin command prompt.
reg delete HKLM\Software\Microsoft\Azure Site Recovery\Registration
Renew Configuration Server Secure Socket Layer(SSL) Certificates
The Configuration Server has an inbuilt webserver, which orchestrates the activities of the Mobility Service, Process
Servers, and Master Target servers connected to the Configuration Server. The Configuration Server's webserver
uses an SSL certificate to authenticate its clients. This certificate has an expiry of three years and can be renewed at
any time using the following method:
WARNING
Certificate expiry can be performed only on version 9.4.XXXX.X or higher. Upgrade all the Azure Site Recovery components
(Configuration Server, Process Server, Master Target Server, Mobility Service) before you start the Renew Certificates
workflow.
1.
2.
3.
4.
On the Azure portal, browse to your Vault > Site Recovery Infrastructure > Configuration Server.
Click the Configuration Server for which you need to renew the SSL Certificate for.
Under the Configuration Server health, you can see the expiry date for the SSL Certificate.
Renew the certificate by clicking the Renew Certificates action as shown in the following image:
Secure Socket Layer certificate expiry warning
NOTE
The SSL Certificate's validity for all installations that happened before May 2016 was set to one year. you have started seeing
certificate expiry notifications showing up in the Azure portal.
1. If the Configuration Server's SSL certificate is going to expire in the next two months, the service starts
notifying users via the Azure portal & email (you need to be subscribed to Azure Site Recovery notifications).
You start seeing a notification banner on the Vault's resource page.
2. Click the banner to get additional details on the Certificate expiry.
TIP
If instead of a Renew Now button you see an Upgrade Now button. This means that there are some components
in your environment that have not yet been upgraded to 9.4.xxxx.x or higher versions.
Sizing requirements for a Configuration Server
CPU
MEMORY
CACHE DISK SIZE
DATA CHANGE RATE
PROTECTED MACHINES
8 vCPUs (2 sockets *
4 cores @ 2.5 GHz)
16 GB
300 GB
500 GB or less
Replicate fewer than
100 machines.
12 vCPUs (2 sockets *
6 cores @ 2.5 GHz)
18 GB
600 GB
500 GB to 1 TB
Replicate between
100-150 machines.
16 vCPUs (2 sockets *
8 cores @ 2.5 GHz)
32 GB
1 TB
1 TB to 2 TB
Replicate between
150-200 machines.
TIP
If your daily data churn exceeds 2 TB, or you plan to replicate more than 200 virtual machines, it is recommended to deploy
additional process servers to load balance the replication traffic. Learn more about How to deploy Scale-out Process severs.
Common issues
Installation failures
SAMPLE ERROR MESSAGE
RECOMMENDED ACTION
ERROR Failed to load Accounts. Error: System.IO.IOException:
Unable to read data from the transport connection when
installing and registering the CS server.
Ensure that TLS 1.0 is enabled on the computer.
Registration failures
Registration failures can be debugged by reviewing the logs in the %ProgramData%\ASRLogs folder.
SAMPLE ERROR MESSAGE
RECOMMENDED ACTION
09:20:06:InnerException.Type:
SrsRestApiClientLib.AcsException,InnerException.
Message: ACS50008: SAML token is invalid.
Trace ID: 1921ea5b-4723-4be7-8087-a75d3f9e1072
Correlation ID: 62fea7e6-2197-4be4-a2c0-71ceb7aa2d97>
Timestamp: 2016-12-12 14:50:08Z
Ensure that the time on your system clock is not more than
15 minutes off the local time. Rerun the installer to complete
the registration.
09:35:27 :DRRegistrationException while trying to get all
disaster recovery vault for the selected certificate: : Threw
Exception.Type:Microsoft.DisasterRecovery.Registration.DRRegi
strationException, Exception.Message: ACS50008: SAML token
is invalid.
Trace ID: e5ad1af1-2d39-4970-8eef-096e325c9950
Correlation ID: abe9deb8-3e64-464d-8375-36db9816427a
Timestamp: 2016-05-19 01:35:39Z
Ensure that the time on your system clock is not more than
15 minutes off the local time. Rerun the installer to complete
the registration.
06:28:45:Failed to create certificate
06:28:45:Setup cannot proceed. A certificate required to
authenticate to Site Recovery cannot be created. Rerun Setup
Ensure you are running setup as a local administrator.
Manage a Scale-out Process Server
3/3/2017 • 8 min to read • Edit Online
Scale-out Process Server acts as a coordinator for data transfer between the Site Recovery services and your onpremises infrastructure. This article describes how you can set up, configure, and manage a Scale-out Process
Server.
Prerequisites
The following are the recommended hardware, software, and network configuration required to set up a Scale-out
Process Server.
NOTE
Capacity planning is an important step to ensure that you deploy the Scale-out Process Server with a configuration that
suites your load requirements. Read more about Scaling characteristics for a Scale-out Process Server.
HARDWARE
Number of CPU cores
8
RAM
12 GB
Number of disks
3
- OS disk
- Process server cache disk
- Retention drive (for failback)
Disk free space (process server cache)
600 GB
Disk free space (retention disk)
600 GB
Software
Operating system version
Windows Server 2012 R2
Operating system locale
English (en-us)
VMware vSphere PowerCLI version
PowerCLI 6.0
Windows Server roles
Do not enable the following roles:
- Active Directory Domain Services
- Internet Information Services
- Hyper-V
Network
Network interface card type
VMXNET3
HARDWARE
IP address type
Static
Internet access
The server should be able to access the following URLs either
directly or through a proxy server:
- *.accesscontrol.windows.net
- *.backup.windowsazure.com
- *.store.core.windows.net
- *.blob.core.windows.net
- *.hypervrecoverymanager.windowsazure.com
- https://cdn.mysql.com/archives/mysql-5.5/mysql-5.5.37win32.msi (not required for Scale-out Process Servers)
- time.nist.gov
- time.windows.com
Ports
443 (Control channel orchestration)
9443 (Data transport)
Downloading the Scale-out Process Server software
1.
2.
3.
4.
5.
Log on to the Azure portal and browse to your Recovery Services Vault.
Browse to Site Recovery Infrastructure > Configuration Servers (under For VMware & Physical Machines).
Select your configuration server to drill down into the configuration server's details page.
Click the + Process Server button.
In the Add Process server page, select Deploy a Scale-out Process Server on-premises option from the
Choose where you want to deploy your process server drop-down.
6. Click the Download the Microsoft Azure Site Recovery Unified Setup link to download the latest
version of the Scale-out Process Server installation.
WARNING
The version of your Scale-out Process Server should be equal to or lesser than the Configuration Server version
running in your environment. A simple way to ensure version compatibility is to use the same installer bits that you
recently used to install/update your Configuration Server.
Installing and registering a Scale-out Process Server from GUI
If you have to scale out your deployment beyond 200 source machines, or a total daily churn rate of more than 2
TB, you need additional process servers to handle the traffic volume.
Check the size recommendations for process servers, and then follow these instructions to set up the process
server. After setting up the server, you migrate source machines to use it.
1. Launch the Azure Site Recovery UnifiedSetup.exe
2. In Before you begin, select Add additional process servers to scale out deployment.
3. In Configuration Server Details, specify the IP address of the Configuration Server, and the passphrase.
4. In Internet Settings, specify how the Provider running on the Configuration Server connects to Azure Site
Recovery over the Internet.
If you want to connect with the proxy that's currently set up on the machine, select Connect with
existing proxy settings.
If you want the Provider to connect directly, select Connect directly without a proxy.
If the existing proxy requires authentication, or if you want to use a custom proxy for the Provider
connection, select Connect with custom proxy settings.
If you use a custom proxy, you need to specify the address, port, and credentials.
If you're using a proxy, you should have already allowed access to the service urls.
5. In Prerequisites Check, Setup runs a check to make sure that installation can run. If a warning appears
about the Global time sync check, verify that the time on the system clock (Date and Time settings) is the
same as the time zone.
6. In Environment Details, select whether you're going to replicate VMware VMs. If you are, then setup
checks that PowerCLI 6.0 is installed.
7. In Install Location, select where you want to install the binaries and store the cache. The drive you select
must have at least 5 GB of disk space available, but we recommend a cache drive with at least 600 GB of free
space.
8. In Network Selection, specify the listener (network adapter and SSL port) on which the Configuration
Server sends and receives replication data. Port 9443 is the default port used for sending and receiving
replication traffic, but you can modify this port number to suit your environment's requirements. In addition
to the port 9443, we also open port 443, which is used by a web server to orchestrate replication operations.
Do not use Port 443 for sending or receiving replication traffic.
9. In Summary, review the information and click Install. When installation finishes, a passphrase is generated.
You will need this when you enable replication, so copy it and keep it in a secure location.
Installing and registering a Scale-out Process Server using commandline
UnifiedSetup.exe [/ServerMode <CS/PS>] [/InstallDrive <DriveLetter>] [/MySQLCredsFilePath <MySQL credentials
file path>] [/VaultCredsFilePath <Vault credentials file path>] [/EnvType <VMWare/NonVMWare>] [/PSIP <IP
address to be used for data transfer] [/CSIP <IP address of CS to be registered with>] [/PassphraseFilePath
<Passphrase file path>]
Sample usage
MicrosoftAzureSiteRecoveryUnifiedSetup.exe /q /xC:\Temp\Extracted
cd C:\Temp\Extracted
UNIFIEDSETUP.EXE /AcceptThirdpartyEULA /servermode "PS" /InstallLocation "D:\" /EnvType "VMWare" /CSIP
"10.150.24.119" /PassphraseFilePath "C:\Users\Administrator\Desktop\Passphrase.txt" /DataTransferSecurePort 443
Scale -out Process Server installer command-line arguments.
PARAMETER NAME
TYPE
DESCRIPTION
POSSIBLE VALUES
/ServerMode
Mandatory
Specifies whether both the
configuration and process
servers should be installed,
or the process server only
CS
PS
/InstallLocation
Mandatory
The folder in which the
components are installed
Any folder on the computer
/MySQLCredsFilePath
Mandatory
The file path in which the
MySQL server credentials are
stored
The file should be the format
specified below
/VaultCredsFilePath
Mandatory
The path of the vault
credentials file
Valid file path
PARAMETER NAME
TYPE
DESCRIPTION
POSSIBLE VALUES
/EnvType
Mandatory
Type of envrionment that
you want to protect
VMware
NonVMware
/PSIP
Mandatory
IP address of the NIC to be
used for replication data
transfer
Any valid IP Address
/CSIP
Mandatory
The IP address of the NIC on
which the configuration
server is listening on
Any valid IP Address
/PassphraseFilePath
Mandatory
The full path to location of
the passphrase file
Valid file path
/BypassProxy
Optional
Specifies that the
configuration server
connects to Azure without a
proxy
To do get this value from
Venu
/ProxySettingsFilePath
Optional
Proxy settings (The default
proxy requires
authentication, or a custom
proxy)
The file should be in the
format specified below
DataTransferSecurePort
Optional
Port number on the PSIP to
be used for replication data
Valid Port Number (default
value is 9433)
/SkipSpaceCheck
Optional
Skip space check for cache
disk
/AcceptThirdpartyEULA
Mandatory
Flag implies acceptance of
third-party EULA
/ShowThirdpartyEULA
Optional
Displays third-party EULA. If
provided as input all other
parameters are ignored
Create a proxy settings configuration file
ProxySettingsFilePath parameter takes a file as input. Create file using the following format and pass it as input
ProxySettingsFilePath parameter.
*
*
*
*
*
*
[ProxySettings]
ProxyAuthentication = "Yes/No"
Proxy IP = "IP Address"
ProxyPort = "Port"
ProxyUserName="UserName"
ProxyPassword="Password"
Modifying proxy settings for Scale-out Process Server
1. Login into your Scale-out Process Server.
2. Open an Admin PowerShell command window.
3. Run the following command
$pwd = ConvertTo-SecureString -String MyProxyUserPassword Set-OBMachineSetting -ProxyServer
http://myproxyserver.domain.com -ProxyPort PortNumber –ProxyUserName domain\username -ProxyPassword $pwd net
stop obengine net start obengine
4. Next browse to the directory %PROGRAMDATA%\ASR\Agent and run the following command
cmd
cdpcli.exe --registermt
net stop obengine
net start obengine
exit
Re-registering a Scale-out Process Server
Connect to the Process Server virtual machine using Remote Desktop Connection.
You can launch the cspsconfigtool.exe by clicking on the shortcut available on the desktop. (The tool will be
automatically launched if this the first time you are logging into the process sever).
Configuration Server's fully qualified name (FQDN) or IP Address
Port on which the Configuration server is listening on. The value should be 443
Connection Passphrase to connect to the configuration server.
Data Transfer port to be configured for this Process Server. Leave the default value as is unless you
have changed it to a different port number in your environment.
Click the save button to save the configuration and register the Process Server.
Next open an Admin command prompt.
Browse to the directory %PROGRAMDATA%\ASR\Agent and run the command
cdpcli.exe --registermt
net stop obengine
net start obengine
Upgrading a Scale-out Process Server
1.
2.
3.
4.
Login to the process server as an Administrator.
Download the latest version of the Unified Setup.
Double-click the installer to launch the update process.
The installer will detect the various components that are installed and upgrade them to the latest version.
Decommissioning a Scale-out Process Server
1. Ensure that:
Configuration Server's connection state shows as Connected in the Azure portal
Process Server's is still able to communicate with the Configuration server.
2. Log in to the process server as an administrator
3. Open up Control Panel > Program > Uninstall Programs
4. Uninstall the programs in the sequence given following:
Microsoft Azure Site Recovery Configuration Server/Process Server
Microsoft Azure Site Recovery Configuration Server Dependencies
Microsoft Azure Recovery Services Agent
It can take up-to 15 minutes for the Process Server deletion to reflect in the Azure portal.
NOTE
If the Process server is unable to communicate with the Configuration Server (Connection State in portal is Disconnected),
then you need to follow the following steps to purge it from the Configuration Server.
Unregistering a disconnected Scale-out Process server from a
Configuration Server
The steps to unregister a process server differs depending on its connection status with the Configuration Server.
Unregister a process server that is in a connected state
1. Remote into the process server as an Administrator.
2. Launch the Control Panel and open Programs > Uninstall a program
3. Uninstall a program by the name Microsoft Azure Site Recovery Configuration/Process Server
4. Once step 3 is completed, you can uninstall Microsoft Azure Site Recovery Configuration/Process Server
Dependencies
Unregister a process server that is in a disconnected state
WARNING
Use the below steps should be used if there is no way to revive the virtual machine on which the Process Server was installed.
1. Log on to your configuration server as an Administrator.
2. Open an Administrative command prompt and browse to the directory
3. Now run the command.
%ProgramData%\ASR\home\svsystems\bin
perl Unregister-ASRComponent.pl -IPAddress <IP_of_Process_Server> -Component PS
4. This will purge the details of the process server from the system.
.
Sizing requirements for a Scale-out Process Server
ADDITIONAL PROCESS SERVER
CACHE DISK SIZE
DATA CHANGE RATE
PROTECTED MACHINES
4 vCPUs (2 sockets * 2 cores
@ 2.5 GHz), 8-GB memory
300 GB
250 GB or less
Replicate 85 or less
machines.
8 vCPUs (2 sockets * 4 cores
@ 2.5 GHz), 12-GB memory
600 GB
250 GB to 1 TB
Replicate between 85-150
machines.
12 vCPUs (2 sockets * 6
cores @ 2.5 GHz) 24-GB
memory
1 TB
1 TB to 2 TB
Replicate between 150-225
machines.
Manage VMware vCenter Server in Azure Site
Recovery
2/21/2017 • 4 min to read • Edit Online
This article discusses the various Site Recovery operations that can be performed on a VMware vCenter.
Prerequisites
SUPPORT VMWARE VCENTER AND VMWARE VSPHERE ESX HOST
DETAILS
On-premises VMware servers
One or more VMware vSphere servers, running 6.0, 5.5, 5.1
with latest updates. Servers should be located in the same
network as the configuration server (or separate process
server).
We recommend a vCenter server to manage hosts, running
6.0 or 5.5 with the latest updates. Only features that are
available in 5.5 are supported when you deploy version 6.0.
Prepare an account for automatic discovery
Site Recovery needs access to VMware for the process server to automatically discover virtual machines, and for
failover and failback of virtual machines.
Migrate: If you only want to migrate VMware virtual machines to Azure, without ever failing them back, you can
use a VMware account with a read-only role. Such a role can run failover, but can't shut down protected source
machines. This is not necessary for migration.
Replicate/Recover: If you want to deploy full replication (replicate, failover, failback) the account must be able
to run operations such as creating and removing disks, powering on virtual machine.
Automatic discovery: At least a read-only account is required.
TASKS
REQUIRED ACCOUNT/ROLE
PERMISSIONS
DETAILS
Process server
automatically discovers
VMware virtual machines
You need at least a readonly user
Data Center object –>
Propagate to Child Object,
role=Read-only
User assigned at datacenter
level, and has access to all
the objects in the datacenter.
To restrict access, assign the
No access role with the
Propagate to child object,
to the child objects (vSphere
hosts, datastores, virtual
machines, and networks).
TASKS
REQUIRED ACCOUNT/ROLE
PERMISSIONS
DETAILS
Failover
You need at least a readonly user
Data Center object –>
Propagate to Child Object,
role=Read-only
User assigned at datacenter
level, and has access to all
the objects in the datacenter.
To restrict access, assign the
No access role with the
Propagate to child object
to the child objects (vSphere
hosts, datastores, virtual
machines, and networks).
Useful for migration
purposes, but not full
replication, failover, failback.
Failover and failback
We suggest you create a
role (AzureSiteRecoveryRole)
with the required
permissions, and then assign
the role to a VMware user or
group
Data Center object –>
Propagate to Child Object,
role=AzureSiteRecoveryRole
User assigned at datacenter
level, and has access to all
the objects in the datacenter.
Datastore -> Allocate space,
browse datastore, low-level
file operations, remove file,
update virtual machine files
To restrict access, assign the
No access role with the
Propagate to child object,
to the child objects (vSphere
hosts, datastores, virtual
machines, and networks).
Network -> Network assign
Resource -> Assign VM to
resource pool, migrate
powered off VM, migrate
powered on VM
Tasks -> Create task, update
task
Virtual machine ->
Configuration
Virtual machine -> Interact > answer question, device
connection, configure CD
media, configure floppy
media, power off, power on,
VMware tools install
Virtual machine -> Inventory
-> Create, register,
unregister
Virtual machine ->
Provisioning -> Allow virtual
machine download, allow
virtual machine files upload
Virtual machine ->
Snapshots -> Remove
snapshots
Create an account to connect to VMware vCenter Server/ VMware
vSphere EXSi host
1. Login into the Configuration server and launch the cspsconfigtool.exe using the shortcut placed on the Desktop.
2. Click Add Account on the Manage Account tab.
3. Provide the account details and click OK to add the account. The account should have the privileges listed in
the Prepare an account for automatic discovery section.
NOTE
It takes about 15 minutes for the account information to be synced up with the Site Recovery service.
Associate a VMware vCenter/ VMware vSphere ESX host (Add vCenter)
On the Azure portal, browse to YourRecoveryServicesVault > Site Recovery Infrastructure > Configuration
Severs > ConfigurationServer
In the Configuration server's details page click the +vCenter button.
In Add vCenter, specify a friendly name for the vSphere host or vCenter server, and then specify the IP
address or FQDN of the server. Leave the port as 443 unless your VMware servers are configured to listen
for requests on a different port. Select the account that is to connect to the VMware vCenter or vSphere ESXi
server. Click OK.
NOTE
If you're adding the VMware vCenter server or VMware vSphere host with an account that doesn't have
administrator privileges on the vCenter or host server, make sure that the account has these privileges enabled:
Datacenter, Datastore, Folder, Host, Network, Resource, Virtual machine, and vSphere Distributed Switch. In addition,
the VMware vCenter server needs the Storage views privilege enabled.
Modify credentials used to connect to the vCenter server/ vSphere
ESXi host
1. Login into the Configuration server and launch the cspsconfigtool.exe
2. Click Add Account on the Manage Account tab.
3. Provide the new account details and click OK to add the account. The account should have the privileges listed in
the Prepare an account for automatic discovery section.
4. On the Azure portal, browse to YourRecoveryServicesVault > Site Recovery Infrastructure > Configuration
Severs > ConfigurationServer
5. In the Configuration server's details page click the Refresh Server button.
6. Once the refresh server job completes, select the vCenter Server to open the vCenter Summary page.
7. Select the newly added account in the vCenter server/vSphere host account field and click the Save
button.
Delete a vCenter in Azure Site Recovery
1. On the Azure portal, browse to YourRecoveryServicesVault > Site Recovery Infrastructure > Configuration
Severs > ConfigurationServer
2. In the Configuration server's details page select the vCenter Server to open the vCenter Summary page.
3. Click on the Delete button to delete the vCenter
NOTE
If you need to modify the vCenters IP Address/FQDN, Port details then you need to delete the vCenter Server and add it
back again.
Remove servers and disable protection
3/27/2017 • 10 min to read • Edit Online
The Azure Site Recovery service contributes to your business continuity and disaster recovery (BCDR) strategy. The
service orchestrates replication, failover and recovery of virtual machines and physical servers. Machines can be
replicated to Azure, or to a secondary on-premises data center. For a quick overview read What is Azure Site
Recovery?
This article describes how to unregister servers from a Recovery Services vault in the Azure portal, and how to
disable protection for machines protected by Site Recovery.
Post any comments or questions at the bottom of this article, or on the Azure Recovery Services Forum.
Unregister a connected configuration server
If you replicate VMware VMs or Windows/Linux physical servers to Azure, you can unregister a connected
configuration server from a vault as follows:
1. Disable machine protection. In Protected Items > Replicated Items, right-click the machine > Delete.
2. Disassociate any policies. In Site Recovery Infrastructure > For VMWare & Physical Machines >
Replication Policies, double-click the associated policy. Right-click the configuration server > Disassociate.
3. Remove any additional on-premises process or master target servers. In Site Recovery Infrastructure > For
VMWare & Physical Machines > Configuration Servers, right-click the server > Delete.
4. Delete the configuration server.
5. Manually uninstall the Mobility service running on the master target server (this will be either a separate server,
or running on the configuration server).
6. Uninstall any additional process servers.
7. Uninstall the configuration server.
8. On the configuration server, uninstall the instance of MySQL that was installed by Site Recovery.
9. In the registry of the configuration server delete the key
HKEY_LOCAL_MACHINE\Software\Microsoft\Azure Site Recovery .
Unregister a unconnected configuration server
If you replicate VMware VMs or Windows/Linux physical servers to Azure, you can unregister an unconnected
configuration server from a vault as follows:
1. Disable machine protection. In Protected Items > Replicated Items, right-click the machine > Delete. Select
Stop managing the machine.
2. Remove any additional on-premises process or master target servers. In Site Recovery Infrastructure > For
VMWare & Physical Machines > Configuration Servers, right-click the server > Delete.
3. Delete the configuration server.
4. Manually uninstall the Mobility service running on the master target server (this will be either a separate server,
or running on the configuration server).
5. Uninstall any additional process servers.
6. Uninstall the configuration server.
7. On the configuration server, uninstall the instance of MySQL that was installed by Site Recovery.
8. In the registry of the configuration server delete the key
HKEY_LOCAL_MACHINE\Software\Microsoft\Azure Site Recovery .
Unregister a connected VMM server
As a best practice, we recommend that you unregister the VMM server when it's connected to Azure. This ensures
that settings on the VMM servers (and on other VMM servers with paired clouds) are cleaned up properly. You
should only remove an unconnected server if there's a permanent issue with connectivity. If the VMM server isn’t
connected, you will need to manually run a script to clean up settings.
1. Stop replicating VMs in clouds on the VMM server you want to remove.
2. Delete any network mappings used by clouds on the VMM server you want to delete. In Site Recovery
Infrastructure > For System Center VMM > Network Mapping, right-click the network mapping > Delete.
3. Disassociate replication policies from clouds on the VMM server you want to remove. In Site Recovery
Infrastructure > For System Center VMM > Replication Policies, double-click the associated policy. Rightclick the cloud > Disassociate.
4. Delete the VMM server or active VMM node. In Site Recovery Infrastructure > For System Center VMM >
VMM Servers, right-click the server > Delete.
5. Uninstall the Provider manually on the VMM server. If you have a cluster, remove from all nodes.
6. If you're replicating to Azure, manually remove the Microsoft Recovery Services agent from Hyper-V hosts in
the deleted clouds.
Unregister an unconnected VMM server
1. Stop replicating VMs in clouds on the VMM server you want to remove.
2. Delete any network mappings used by clouds on the VMM server that you want to delete. In Site Recovery
Infrastructure > For System Center VMM > Network Mapping, right-click the network mapping > Delete.
3. Note the ID of the VMM server.
4. Disassociate replication policies from clouds on the VMM server you want to remove. In Site Recovery
Infrastructure > For System Center VMM > Replication Policies, double-click the associated policy. Rightclick the cloud > Disassociate.
5. Delete the VMM server or active node. In Site Recovery Infrastructure > For System Center VMM > VMM
Servers, right-click the server > Delete.
6. Download and run the cleanup script on the VMM server. Open PowerShell with the Run as Administrator
option, to change the execution policy for the default (LocalMachine) scope. In the script, specify the ID of the
VMM server you want to remove. The script removes registration and cloud pairing information from the
server.
7. Run the cleanup script on any other VMM servers that contain clouds that are paired with clouds on the VMM
server you want to remove.
8. Run the cleanup script on any other passive VMM cluster nodes that have the Provider installed.
9. Uninstall the Provider manually on the VMM server. If you have a cluster, remove from all nodes.
10. If you replicating to Azure, you can remove the Microsoft Recovery Services agent from Hyper-V hosts in the
deleted clouds.
Unregister a Hyper-V host in a Hyper-V Site
Hyper-V hosts that aren't managed by VMM are gathered into a Hyper-V site. Remove a host in a Hyper-V site as
follows:
1. Disable replication for Hyper-V VMs located on the host.
2. Disassociate policies for the Hyper-V site. In Site Recovery Infrastructure > For Hyper-V Sites > Replication
Policies, double-click the associated policy. Right-click the site > Disassociate.
3. Delete Hyper-V hosts. In Site Recovery Infrastructure > For System Center VMM > Hyper-V Hosts, rightclick the server > Delete.
4. Delete the Hyper-V site after all hosts have been removed from it. In Site Recovery Infrastructure > For
System Center VMM > Hyper-V Sites, right-click the site > Delete.
5. Run the following script on each Hyper-V host that you removed. The script cleans up settings on the server,
and unregisters it from the vault.
`` pushd .
try
{
$windowsIdentity=[System.Security.Principal.WindowsIdentity]::GetCurrent()
$principal=new-object System.Security.Principal.WindowsPrincipal($windowsIdentity)
$administrators=[System.Security.Principal.WindowsBuiltInRole]::Administrator
$isAdmin=$principal.IsInRole($administrators)
if (!$isAdmin)
{
"Please run the script as an administrator in elevated mode."
$choice = Read-Host
return;
}
$error.Clear()
"This script will remove the old Azure Site Recovery Provider related properties. Do you want to
continue (Y/N) ?"
$choice = Read-Host
if (!($choice -eq 'Y' -or $choice -eq 'y'))
{
"Stopping cleanup."
return;
}
$serviceName = "dra"
$service = Get-Service -Name $serviceName
if ($service.Status -eq "Running")
{
"Stopping the Azure Site Recovery service..."
net stop $serviceName
}
$asrHivePath = "HKLM:\SOFTWARE\Microsoft\Azure Site Recovery"
$registrationPath = $asrHivePath + '\Registration'
$proxySettingsPath = $asrHivePath + '\ProxySettings'
$draIdvalue = 'DraID'
if (Test-Path $asrHivePath)
{
if (Test-Path $registrationPath)
{
"Removing registration related registry keys."
Remove-Item -Recurse -Path $registrationPath
}
if (Test-Path $proxySettingsPath)
{
"Removing proxy settings"
Remove-Item -Recurse -Path $proxySettingsPath
}
$regNode = Get-ItemProperty -Path $asrHivePath
if($regNode.DraID -ne $null)
{
"Removing DraId"
Remove-ItemProperty -Path $asrHivePath -Name $draIdValue
}
"Registry keys removed."
}
# First retrive all the certificates to be deleted
$ASRcerts = Get-ChildItem -Path cert:\localmachine\my | where-object
{$_.friendlyname.startswith('ASR_SRSAUTH_CERT_KEY_CONTAINER') -or
$_.friendlyname.startswith('ASR_HYPER_V_HOST_CERT_KEY_CONTAINER')}
# Open a cert store object
$store = New-Object System.Security.Cryptography.X509Certificates.X509Store("My","LocalMachine")
$store.Open('ReadWrite')
# Delete the certs
"Removing all related certificates"
foreach ($cert in $ASRcerts)
{
$store.Remove($cert)
}
}catch
{
[system.exception]
Write-Host "Error occured" -ForegroundColor "Red"
$error[0]
Write-Host "FAILED" -ForegroundColor "Red"
}
popd``
Disable protection for a VMware VM or physical server
1. In Protected Items > Replicated Items, right-click the machine > Delete.
2. In Remove Machine, select one of these options:
Disable protection for the machine (recommended). Use this option to stop replicating the machine.
Site Recovery settings will be cleaned up automatically. You will only see this option in the following
circumstances:
You've resized the VM volume—When you resize a volume the virtual machine goes into a
critical state. Select this option to disables protection while retaining recovery points in Azure.
When you enable protection for the machine again, the data for the resized volume will be
transferred to Azure.
You've recently run a failover—After you've run a failover to test your environment, select this
option to start protecting on-premises machines again. It disables each virtual machine, and then
you need to enable protection for them again. Disabling the machine with this setting doesn't
affect the replica virtual machine in Azure. Don't uninstall the Mobility service from the machine.
Stop managing the machine. If you select this option, the machine will only be removed from the
vault. On-premises protection settings for the machine won’t be affected. To remove settings on the
machine, and to remove the machine from the Azure subscription, you need to clean the settings by
uninstalling the Mobility service.
Disable protection for a Hyper-V VM in a VMM cloud
1. In Protected Items > Replicated Items, right-click the machine > Delete.
2. In Remove Machine, select one of these options:
Disable protection for the machine (recommended). Use this option to stop replicating the machine.
Site Recovery settings will be cleaned up automatically.
Stop managing the machine. If you select this option, the machine will only be removed from the
vault. On-premises protection settings for the machine won’t be affected. To remove settings on the
machine, and to remove the machine from the Azure subscription, you need to clean the settings up
manually, using the instructions below. Note that if you select to delete the virtual machine and its hard
disks, they'll be removed from the target location.
Clean up protection settings - replication to a secondary VMM site
If you selected Stop managing the machine and you replicating to a secondary site, run this script on the
primary server to clean up the settings for the primary virtual machine. In the VMM console click the PowerShell
button to open the VMM PowerShell console. Replace SQLVM1 with the name of your virtual machine.
``$vm = get-scvirtualmachine -Name "SQLVM1"
Set-SCVirtualMachine -VM $vm -ClearDRProtection``
1. On the secondary VMM server run this script to clean up the settings for the secondary virtual machine:
``$vm = get-scvirtualmachine -Name "SQLVM1"
Remove-SCVirtualMachine -VM $vm -Force``
2. On the secondary VMM server, refresh the virtual machines on the Hyper-V host server, so that the secondary
VM gets detected again in the VMM console.
3. The above steps clear up the replication settings on the VMM server. If you want to stop replication for the
virtual machine, run the following script oh the primary and secondary VMs. Replace SQLVM1 with the
name of your virtual machine.
``Remove-VMReplication –VMName “SQLVM1”``
Clean up protection settings - replication to Azure
1. If you selected Stop managing the machine and you replicate to Azure, run this script on the source VMM
server, using PowerShell from the VMM console.
$vm = get-scvirtualmachine -Name "SQLVM1" Set-SCVirtualMachine -VM $vm -ClearDRProtection
2. The above steps clear the replication settings on the VMM server. To stop replication for the virtual machine
running on the Hyper-V host server, run this script. Replace SQLVM1 with the name of your virtual machine,
and host01.contoso.com with the name of the Hyper-V host server.
``$vmName = "SQLVM1"
$hostName = "host01.contoso.com"
$vm = Get-WmiObject -Namespace "root\virtualization\v2" -Query "Select * From Msvm_ComputerSystem Where
ElementName = '$vmName'" -computername $hostName
$replicationService = Get-WmiObject -Namespace "root\virtualization\v2" -Query "Select * From
Msvm_ReplicationService" -computername $hostName
$replicationService.RemoveReplicationRelationship($vm.__PATH)``
Disable protection for a Hyper-V VM in a Hyper-V Site
Use this procedure if you're replicating Hyper-V VMs to Azure without a VMM server.
1. In Protected Items > Replicated Items, right-click the machine > Delete.
2. In Remove Machine, you can select the following options:
Disable protection for the machine (recommended). Use this option to stop replicating the machine.
Site Recovery settings will be cleaned up automatically.
Stop managing the machine. If you select this option the machine will only be removed from the vault.
On-premises protection settings for the machine won’t be affected. To remove settings on the machine,
and to remove the virtual machine from the Azure subscription, you need to clean the settings up
manually. If you select to delete the virtual machine and its hard disks they will be removed from the
target location.
3. If you selected Stop managing the machine, run this script on the source Hyper-V host server, to remove
replication for the virtual machine. Replace SQLVM1 with the name of your virtual machine.
$vmName = "SQLVM1"
$vm = Get-WmiObject -Namespace "root\virtualization\v2" -Query "Select * From Msvm_ComputerSystem Where
ElementName = '$vmName'"
$replicationService = Get-WmiObject -Namespace "root\virtualization\v2" -Query "Select * From
Msvm_ReplicationService"
$replicationService.RemoveReplicationRelationship($vm.__PATH)
Monitor and troubleshoot protection for virtual
machines and physical servers
3/6/2017 • 8 min to read • Edit Online
This monitoring and troubleshooting guide helps you learn how to track replication health and troubleshoot
techniques for Azure Site Recovery.
Understand the components
VMware virtual machine or physical server site deployment for replication between on-premises and Azure
To set up database recovery between an on-premises VMware virtual machine or physical server and Azure, you
need to set up the configuration server, master target server, and process server components on your virtual
machine or server. When you enable protection for the source server, Azure Site Recovery installs the Mobile Apps
feature of Microsoft Azure App Service. After an on-premises outage and after the source server fails over to Azure,
customers need to set up a process server in Azure and a master target server on premises to rebuild the source
server on premises.
Virtual Machine Manager site deployment for replication between on-premises sites
To set up database recovery between two on-premises locations, you need to download the Azure Site Recovery
provider and install it on the Virtual Machine Manager server. The provider needs Internet connectivity to ensure
that all the operations that are triggered from the Azure portal get translated to on-premises operations.
Virtual Machine Manager site deployment for replication between on-premises locations and Azure
When you set up database recovery between on-premises locations and Azure, you need to download the Azure
Site Recovery provider and install it on the Virtual Machine Manager server. You also need to install the Azure
Recovery Services Agent, which needs to be installed on each Hyper-V host. Learn more for more information.
Hyper-V site deployment for replication between on-premises locations and Azure
This process is similar to Virtual Machine Manager deployment. The only difference is that the Azure Site Recovery
provider and Azure Recovery Services Agent get installed on the Hyper-V host itself. Learn more. .
Monitor configuration, protection, and recovery operations
Every operation in Azure Site Recovery is audited and tracked under the JOBS tab. For any configuration,
protection, or recovery error, go to the JOBS tab and look for failures.
If you find failures under the JOBS tab, click the job, and click ERROR DETAILS for that job.
The error details will help you identify a possible cause and recommendation for the issue.
In the previous example, another operation that is in progress seems to be causing the protection configuration to
fail. Resolve the issue based on the recommendation, and then click RESART to initiate the operation again.
The RESTART option is not available for all operations. If an operation doesn’t have the RESTART option, go back
to the object and redo the operation again. You can cancel any job that's in-progress by using the CANCEL button.
Monitor replication health for virtual machines
You can use the Azure portal to remotely monitor Azure Site Recovery providers for each of the protected entities.
Click PROTECTED ITEMS, and then click VMM CLOUDS or PROTECTION GROUPS. The VMM CLOUDS tab is
only available for deployments that are based on Virtual Machine Manager. For other scenarios, the protected
entities are under the PROTECTION GROUPS tab.
Click a protected entity under the respective cloud or protection group to see all available operations are shown in
the bottom pane.
As shown in the previous screenshot, the virtual machine health is Critical. You can click the ERROR DETAILS
button on the bottom to see the error. Based on the Possible causes and Recommendation, resolve the issue.
NOTE
If any active operations are in progress or failed, go to the JOBS view as mentioned earlier to view the error for a specific job.
Troubleshoot on-premises Hyper-V issues
Connect to the on-premises Hyper-V manager console, select the virtual machine, and see the replication health.
In this case, Replication Health is Critical. Right-click the virtual machine, and then click Replication > View
Replication Health to see the details.
If replication is paused for the virtual machine, right-click the virtual machine, and then click Replication >
Resume replication.
If a virtual machine migrates a new Hyper-V host that's within the cluster or a standalone machine and the Hyper-V
host has been configured through Azure Site Recovery, replication for the virtual machine wouldn't be impacted.
Ensure that the new Hyper-V host meets all the prerequisites and is configured by using Azure Site Recovery.
Event Log
EVENT SOURCES
DETAILS
Applications and Service
Logs/Microsoft/VirtualMachineManager/Server/Admin
(Virtual Machine Manager server)
Provides useful logging to troubleshoot many different Virtual
Machine Manager issues.
Applications and Service
Logs/MicrosoftAzureRecoveryServices/Replication
(Hyper-V host)
Provides useful logging to troubleshoot many Microsoft Azure
Recovery Services Agent issues.
Applications and Service Logs/Microsoft/Azure Site
Recovery/Provider/Operational (Hyper-V host)
Provides useful logging to troubleshoot many Microsoft Azure
Site Recovery Service issues.
EVENT SOURCES
DETAILS
Applications and Service
Logs/Microsoft/Windows/Hyper-V-VMMS/Admin (HyperV host)
Provides useful logging to troubleshoot many Hyper-V virtual
machine management issues.
Hyper-V replication logging options
All events that pertain to Hyper-V replication are logged in the Hyper-V-VMMS\Admin log located under
Applications and Services Logs\Microsoft\Windows. In addition, you can enable an Analytic log for the Hyper-V
Virtual Machine Management Service. To enable this log, first make the Analytic and Debug logs viewable in the
Event Viewer. Open Event Viewer, and then click View > Show Analytic and Debug Logs.
An Analytic log is visible under Hyper-V-VMMS.
In the Actions pane, click Enable Log. After it's enabled, it appears in Performance Monitor as an Event Trace
Session located under Data Collector Sets.
To view the collected information, first stop the tracing session by disabling the log. Save the log, and open it again
in Event Viewer or use other tools to convert it as desired.
Reach out for Microsoft Support
Log collection
For Virtual Machine Manager site protection, refer to Azure Site Recovery log collection using Support Diagnostics
Platform (SDP) Tool to collect the required logs.
For Hyper-V site protection, download the tool and execute it on the Hyper-V host to collect the logs.
For VMware/physical server scenarios, refer to Azure Site Recovery log collection for VMware and physical site
protection to collect the required logs.
The tool collects the logs locally in a randomly named subfolder under %LocalAppData%\ElevatedDiagnostics.
Open a support ticket
To raise a support ticket for Azure Site Recovery, reach out to Azure Support by using the URL at
http://aka.ms/getazuresupport.
KB articles
How to preserve the drive letter for protected virtual machines that are failed over or migrated to Azure
How to manage on-premises to Azure protection network bandwidth usage
Azure Site Recovery: "The cluster resource could not be found" error when you try to enable protection for a
virtual machine
Understand and Troubleshoot Hyper-V replication guide
Common Azure Site Recovery errors and their resolutions
Following are common errors and their resolutions. Each error is documented in a separate wiki page.
General
NEW Jobs failing with error "An operation is in progress." Error 505, 514, 532.
NEW Jobs failing with error "Server isn't connected to the Internet". Error 25018.
Setup
The Virtual Machine Manager server cannot be registered due to an internal error. Please refer to the jobs view
in the Site Recovery portal for more details on the error. Run setup again to register the server.
A connection can’t be established to the Hyper-V Recovery Manager vault. Verify the proxy settings or try again
later.
Configuration
Unable to create Protection Group: An error occurred while retrieving the list of servers.
Hyper-V host cluster contains at least one static network adapter, or no connected adapters are configured to
use DHCP.
Virtual Machine Manager does not have permissions to complete an action.
Can't select the storage account within the subscription while configuring protection.
Protection
NEW Enable Protection failing with error "Protection couldn't be configured for the virtual machine". Error
60007, 40003.
NEW Enable Protection failing with error "Protection couldn't be enabled for the virtual machine." Error 70094.
NEW Live migration error 23848 - The virtual machine is going to be moved using type Live. This could break
the recovery protection status of the virtual machine.
Enable protection failed since Agent not installed on host machine.
A suitable host for the replica virtual machine can't be found - Due to low compute resources.
A suitable host for the replica virtual machine can't be found - Due to no logical network attached.
Cannot connect to the replica host machine - connection could not be established.
Recovery
Virtual Machine Manager cannot complete the host operation:
Fail over to the selected recovery point for virtual machine: General access denied error.
Hyper-V failed to fail over to the selected recovery point for virtual machine: Operation aborted. Try a
more recent recovery point. (0x80004004).
A connection with the server could not be established (0x00002EFD).
Hyper-V failed to enable reverse replication for virtual machine.
Hyper-V failed to enable replication for virtual machine virtual machine.
Could not commit failover for virtual machine.
The recovery plan contains virtual machines which are not ready for planned failover.
The virtual machine isn't ready for planned failover.
Virtual machine is not running and is not powered off.
Out of band operation happened on a virtual machine and commit failover failed.
Test failover
Failover could not be initiated since test failover is in progress.
NEW Failover times out with 'PreFailoverWorkflow task WaitForScriptExecutionTaskTimeout' due to the
configuration settings on the Network Security Group associated with the Virtual Machine or the subnet to
which the machine belongs to. Refer to 'PreFailoverWorkflow task WaitForScriptExecutionTaskTimeout' for
details.
Configuration server, process server, master target
The ESXi host on which the PS/CS is hosted as a VM fails with a purple screen of death.
Remote desktop troubleshooting after failover
Many customers have faced issues to connect to the failed over virtual machine in Azure. Use the
troubleshooting document to RDP into the virtual machine.
Adding a public IP on a resource manager virtual machine
If the Connect button in the portal is dimmed, and you are not connected to Azure via an Express Route or Site-toSite VPN connection, you need to create and assign your virtual machine a public IP address before you can use
Remote Desktop/Shared Shell. You can then add a Public IP on the network interface of the virtual machine.