Important: This release only has updates for Azure-to-Azure and Modernized VMware-to-Azure protection scenarios.
Introduction
This article describes the issues that are fixed in Update Rollup 69 in the following versions of Microsoft Azure Site Recovery:
-
Azure to Azure
-
Modernized VMware/Physical to Azure
Learn about the details of the issues that are fixed and the prerequisites that should be verified before you install this update.
Prerequisites
To install Microsoft Azure Site Recovery Provider Update Rollup 69, you must have one of the following installed:
-
Microsoft Azure Site Recovery Provider (version 5.1.7700 or a later version)
-
Microsoft Azure Site Recovery Unified Setup (VMware to Azure) (version 9.52.xxxx.x or a later version)
-
Microsoft Azure Recovery Services Agent (version 2.0.9202.0 or a later version)
Note: You can check the installed provider version in the Programs and Features item in Control Panel.
Improvements made and issues fixed in this update
After you install this update, the following issues are fixed, and the following improvements are included.
Mobility Service
Linux OS Support
-
Azure to Azure
-
Rocky Linux 8.7
-
Rocky Linux 9.0
-
Rocky Linux 9.1
-
SUSE Linux Enterprise Server 15 SP5
-
-
Modernized VMware/Physical to Azure
-
Rocky Linux 8.7
-
Rocky Linux 9.0
-
Rocky Linux 9.1
-
SUSE Linux Enterprise Server 15 SP5
-
Windows OS Support
-
Azure to Azure
-
Windows 11
-
Issues fixed:
-
Added a check which makes sure that a resynchronization is not triggered if the protected machine was shutdown gracefully, avoiding additional data transfer operations.
-
Fixed an issue for Oracle Linux 7.9 VMware VMs, where the ASR driver was unable to identify a few files and was causing the kernel to crash.
-
Edited error messages where the churn metrics were showing up with incorrect units.
-
Resolved a bug where protected RHEL machines where Site Recovery driver may cause a crash due to memory spikes.
-
Fixed an issue where re-protect operation for a Debian 11 machine failed due to missing cleanup steps.
-
Fixed an issue where mobility service installation was failing on CentOS 7.8 machines, due to an operation not being compatible with kernels older than 3.1.x.
-
Fixed an issue where initial replication/resynchronization operation doesn’t progress during the re-protection of a Windows VMware VM because a Mobility Service process did not exit on stop.
Microsoft Azure Site Recovery replication appliance
Updates:
|
Component |
Version |
|---|---|
|
Physical discovery server |
|
|
Discovery server |
|
|
Site Recovery provider |
|
|
Appliance configuration manager |
|
|
Proxy server |
|
|
Replication service |
|
|
Re-protection server |
|
|
Push install agent |
|
|
Recovery Services agent |
|
|
Process server |
Updating your Azure Site Recovery On-Premises components
Between an on-premises VMM site and Azure
-
Download the Update Rollup for Microsoft Azure Site Recovery Provider.
-
Install the Update Rollup on the on-premises VMM server.
-
Install the latest Microsoft Azure Recovery Services Agent on all Hyper-V hosts.
Note 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.
Between an on-premises Hyper-V site and Azure
-
Download the Update Rollup for Microsoft Azure Site Recovery Provider.
-
Install the provider on each node of the Hyper-V servers that you have registered in Azure Site Recovery.
Note If your Hyper-V is a Host Clustered Hyper-V server, make sure that you install the upgrade on all nodes of the cluster.
Between an on-premises VMware or physical site to Azure (Modernized experience)
-
Ensure that your on-premises management appliance is up to date by navigating to the Appliance configuration manager. If not, download the latest version for the components that are behind the latest version.
-
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. This is not necessarily mandatory. However, a restart is mandatory if the difference between agent versions from the last restart and the target version is greater than four (4) in the last decimal place. See the following table for a detailed explanation.
|
Agent version during last restart |
Upgrading to |
Is a restart mandatory? |
|---|---|---|
|
9.25 |
9.27 |
Not mandatory |
|
9.25 |
9.28 |
Not mandatory |
|
9.25 |
9.29 |
Not mandatory |
|
9.25 |
9.30 |
Mandatory First upgrade to version 9.29, and then restart before you upgrade to version 9.30 (because the difference between the last restart version and the target version is greater than 4) |
