Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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.