Sign in with Microsoft
Sign in or create an account.
Hello,
Select a different account.
You have multiple accounts
Choose the account you want to sign in with.

Introduction

This article describes the issues that are fixed in Update Rollup 35 in the following versions of Microsoft 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 support files, see the following Microsoft Knowledge Base article:  

119591 How to obtain Microsoft support files from online services

Microsoft scanned these files for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file.

Prerequisites

To install Microsoft Azure Site Recovery Provider Update Rollup 35 (version 5.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 the installed provider version in the Programs and Features item in Control Panel.

Issues that are fixed in this update

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

Microsoft Azure Site Recovery Provider

Improvements

Azure to 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 Azure Site 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-premises VMM 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-premises VMM 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-premises Hyper-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-premises VMware or physical site to Azure

  1. Update your on-premises management server by downloading Microsoft Azure Site Recovery Unified Setup. This is the server that has the Configuration server and Process server roles.

  2. If you have scale-out process servers, update them next by using Microsoft Azure Site Recovery Unified Setup.

  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 is recommended after every upgrade of the Mobility agent to make sure that all latest changes are loaded on the source computer. However, this is not mandatory. If the difference between agent versions from the last restart and the current version is greater than 4, then a restart is mandatory. See the following 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

There are no known issues in this update.

References

Learn about the terminology that Microsoft uses to describe software updates. 

Third-party information disclaimer

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

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

Facebook LinkedIn Email
SUBSCRIBE RSS FEEDS

Need more help?

Want more options?

Discover Community

Explore subscription benefits, browse training courses, learn how to secure your device, and more.

Microsoft 365 subscription benefits

Microsoft 365 training

Microsoft security

Accessibility center

Communities help you ask and answer questions, give feedback, and hear from experts with rich knowledge.

Ask the Microsoft Community

Microsoft Tech Community

Windows Insiders

Microsoft 365 Insiders

Was this information helpful?

What affected your experience?
By pressing submit, your feedback will be used to improve Microsoft products and services. Your IT admin will be able to collect this data. Privacy Statement.

Thank you for your feedback!

×