Update Rollup 35 for Azure Site Recovery

Applies to: Site Recovery

Introduction


This article describesthe issues that are fixed in Update Rollup 35 in the following versions ofMicrosoft Azure Site Recovery components:

Notes

  • This is a hotfix for the issues mentioned in the “Issues that are fixed in this update” section.
  • See the “Issues that are fixed in this update” section and the “Prerequisites” section for what should be validated before you install this update.

For more information about how to download Microsoft supportfiles, see the following Microsoft KnowledgeBase article:  

119591How to obtain Microsoft support files from online services

Microsoftscanned these files for viruses. Microsoft used the most currentvirus-detection software that was available on the date that the file wasposted. The file is stored on security-enhanced servers that help prevent anyunauthorized changes to the file.

Prerequisites


To install Microsoft Azure Site Recovery Provider Update Rollup 35 (version5.1.4000.0), you must have one of the following prerequisites installed:
  • Microsoft Azure Hyper-V Recovery Manager (version 3.4.486 or a later version)
  • Microsoft Azure Site Recovery Hyper-V Provider (version 4.6.660 or a later version)
  • Microsoft Azure Site Recovery Provider (version 5.1.3600 or a later version) 
  • Microsoft Azure Site Recovery Unified Setup (VMware to Azure) (version 9.19.xxxx.x or a later version) 
Note You can check theinstalled provider version in the Programs and Features item in ControlPanel.

Issues that are fixed in this update


After you install this update, the following issues are fixed, and thefollowing improvements are included.

Microsoft AzureSite Recovery Provider

Improvements

Azureto Azure DR

  • Updates that are made to Network Mappings no longer affect the target configurations for existing replications.

    If the network mapping between source VNet and target VNet is modified, the target VNet for existing replications aren't updated. The previously chosen target VNet configuration will stay intact.

VMware to Azure DR

  • Directly write to managed disks.

    All new protections are now replicated directly to Managed Disks. Data from on-premise is sent to a cache storage account in Azure. Recovery points are created in Managed Disks on the target side. This means that you don't have to manage multiple target storage accounts on the target.

Issues Fixed

Azure to Azure DR

  • Error message improvement when a failover that generates errors is completed after a primary VM is deleted.
  • Error message during a purge or disable operation if cleanup of resource links fails is improved by including actionable details.
  • Warning messages are added during Azure Encrypted VM protection if there are access issues.
  • Fixes an issue during reprotection in which the error message “The virtual machine couldn't be protected as the disk is already configured with a different seed blob URI for protection” occurred.
  • Improved the encrypted VM protection workflow to reduce exception messages.
  • Improved failover readiness validations.
  • DR Cross Subscription: Allow For network mapping to a different subscription even if it's already mapped.
  • Fixes an issue in reprotection workflows in which an option for managed disk did not show.
  • Added support for retaining the ApplicationGateway BackendAddressPools property in IpConfigurations when you update existing NICs.
  • Generation of failover health issues if there's a change in disk type post protection.

Microsoft AzureSite Recovery Unified Setup & Configuration Server Template

Improvements   

  • Support for configuration server that uses multiple NICs.
    • If you design an on-premises network as a separate network that does not have access to the Internet or Azure storage (by having multiple NICs on Configuration Server), you have to register both networks during configuration server registration or post an upgrade to this version.
    • After both networks are registered by using Azure Site Recovery, the networks cannot be modified.
    • Failback isn't supported if both networks aren't registered.

Issues Fixed

  • Error message improvement for vCenter discovery failures.
  • An error message is added when you try to protect Azure Site Recovery components such as Configuration Server, Process Server, and Master Target.

Mobility Service

Issues fixed

  • Physical servers now qualify for no-hydration at the time of failover. This brings down recovery time objective (RTO). Learn more about no-hydration.
  • Support for SUSE Linux Enterprise Server 12 Service Pack 4 (SP4)
  • Mobility Agent installation improvements:
    • Before version 9.23, errors in the installation of the Azure Site Recovery VSS provider led to Mobility Agent installation failures. In version 9.23 and later versions, if the VSS provider installation fails during Mobility Agent installation, then the following improvements occur:
    • Mobility Agent installation continues and the VSS provider installation is skipped.
    • The job status would be updated as "Warning" and a clear error message will be shown stating the exact reason why Azure Site Recovery VSS provider installation failed. Follow the recommended action provided in the error message for a successful generation of application consistent points.
    • You should be aware that VSS provider installation failures don't affect crash-consistent points generation. Your servers will continue to generate crash-consistent points.

Updating your Azure Site Recovery On-Premises components


Between two on-premisesVMM sites

  1. Download the latest Update Rollup for Microsoft Azure Site Recovery Provider.
  2. Install the Update Rollup first on the on-premises VMM server that's managing the recovery site.

After the recovery site is updated, install the Update Rollup on the VMM server that's managing the primary site.

Notes

  • If the VMM is a Highly Available VMM (Clustered VMM), make sure that you install the upgrade on all nodes of the cluster where the VMM service is installed.
  • A restart of the host isn't required unless specified otherwise.

Between an on-premisesVMM site and Azure

  1. Download the Update Rollup for Microsoft Azure Site Recovery Provider.
  2. Install the Update Rollup on the on-premises VMM server.
  3. Install the latest MARS agent on all Hyper-V hosts.

Notes

  • If your VMM is a Highly Available VMM (Clustered VMM), make sure that you install the upgrade on all nodes of the cluster where the VMM service is installed.
  • A restart of the host isn't required unless specified otherwise.


Between an on-premisesHyper-V site and Azure

  1. Download the Update Rollup for Microsoft Azure Site Recovery Provider.
  2. Install the provider on each node of the Hyper-V servers that you have registered in Azure Site Recovery.

Notes

  • If your Hyper-V is a Host Clustered Hyper-V server, make sure that you install the upgrade on all nodes of the cluster.
  • A restart of the host isn't required unless specified otherwise.


Between an on-premisesVMware or physical site to Azure

  1. Install the Microsoft Azure Site Recovery Provider first on your on-premises management server. This is the server that has the Configuration server and Process server roles.
  2. If you have scale-out process servers, update them next.
  3. Go to the Azure portal, and then go to the Protected Items > Replicated Items page. Select a VM on this page. Select the Update Agent button that appears at the bottom of the page for each VM. This updates the Mobility Service Agent on all protected VMs.

Note A restart isrecommended after every upgrade of the Mobility agent to make sure that alllatest changes are loaded on the source computer. However, this is notmandatory. If the difference between agent versions from the last restart and thecurrent version is greater than 4, then a restart is mandatory. See thefollowing table for a detailed explanation.

Agent version during last restart

Upgrading to

Is a restart mandatory?

9.16

9.18

Not mandatory

9.16

9.19

Not mandatory

9.16

9.20

Not mandatory

9.16

9.21

Yes, first upgrade to version 9.20, then restart before upgrading to version 9.21 as the difference between the versions (version 9.16 where the last restart was performed and the target version 9.21) is >4,

Known issues


Thereare no known issues in this update.

References


Learn about the terminology thatMicrosoft uses to describe software updates. 

Third-party information disclaimer

The third-party products that this article discusses are manufactured bycompanies that are independent of Microsoft. We make no warranty, implied orotherwise, about the performance or reliability of these products.

We provide third-party contact and website information to help you findtechnical support. This information may change without notice. We do notguarantee the accuracy of this third-party information.