Update Rollup 36 for Azure Site Recovery

Microsoft Azure Site Recovery Provider

Improvements

A2A:

• Improved certificate expiration and renewal support from service (with PowerShell support).

• Virtual machine (VM) intraregional move support from service.

• Improved monitoring experience.

• Support for adding a new disk to a protected VM.

• For enabling automatic update of agents that are used in replication of Azure VMs, an automation account is used. Previously, this was the default account as created by Site Recovery. Now, you can choose a different existing automation account. This option can be found when you enable replication for a VM. Changing the setting for a VM that is protected as part of a specific Recovery Services vault applies to all Azure VMs that are protected in the same vault.
  

Issues fixed

 A2A:

• New validator to check whether the availability set and VM resource  groups are different to warn users before failover.

• Failback enhancement to handle the scenario if the VM gets deleted from the source region.

• Fixed creation of Cache Storage Accounts in random resource groups instead of customer-specified resource groups.

• Fixed an issue in which protection of a VM fails while checking an availability zone in a region.

• Fixed an issue in which reprotection fails if the source VM system disks is deleted.

• Fixed an issue during failback in which the UI gets stuck in process if the availability zone property is not retrieved.

• Adds logic to delete stale resource links that are created by ASR in a cross subscription.

Microsoft Azure Site Recovery Unified Setup and Configuration Server Template

Improvements   

Configuration server monitoring improvements:

Error message enhancements are made for the following scenarios to provide a clear root cause and recommended actions:

• vCenter disconnected

• Process server disconnected

• CS disconnected

• Process server has no heartbeat

• MT disconnected

• VM shutdown

• VM deleted

Process Server Monitoring

The following alerts are added for process servers to improve monitoring:

• CPU, memory, and free space alerts to monitor resource usage

• Alerts when essential ASR services are not running

Process Server selection in-product guidance

During the selection of a process server for new replications, the health of the process server (Critical, Warning, and Healthy) is displayed based on resource availability and connectivity health.

Notes

• A critical process server cannot be used to enable replication of new VMs.

• Although you can choose a process server that shows a warning state, we do not recommended that you to this. Any additional workload could affect the existing workload.

• A process server that is marked as healthy can be used to  protect new servers.

For more information about process server guidance, see https://aka.ms/asr_ps_selection_guidance.
 

Issues Fixed

(Not applicable)

Mobility Service

Issues fixed: Applicable to DR of VMware VMs

• Reduced size of mobility agent installers (affects Ubuntu*, Debian*, SLES 12 - Push Install and Upgrade)

• Restart warning appears only when there are associated driver changes

• Installer error message enhancements that provide a clear root cause of failure issues

• Enhancements in service startup logging mechanism

• Fixed failover issue for Windows Server 2019-based computers in a physical or VMware environment that qualify for no-hydration

• Fixed failures in Mobility agent upgrade that returned error code 95507

• For a VMware-to-Azure and Azure-to-Azure DR scenario, the following operating systems can be protected:

  • Windows 10 (x64)

  • Windows 8.1 (x64)

  • Windows 8 (x64)

  • Windows 7 (x64) SP1 and later (Windows 7 RTM is not supported)
    

Issues fixed

• Fixed an occasional issue in which data disks are visible offline in Windows Server 2019.

Microsoft Azure Site Recovery (Service)

Improvements

Data replication from VMware or physical servers to Azure is now supported for Azure storage accounts that are configured to have a virtual network firewall.
 

Issues fixed

(Not applicable)

Microsoft Azure Site Recovery (Portal)

Improvements

For VMware to Azure, Process Server health status is added to VM overview blade. Events that are raised on the process server are added to an events table on the Process Server blade.
 

Issues fixed

(Not applicable)

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 is managing the recovery site.

3. After the recovery site is updated, install the update rollup on the VMM server that is managing the primary site.

Note 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.
 

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.

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

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.

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

1. Update your on-premises management server. This is the server that has the Configuration Server and Process Server roles. To do this, download and run Microsoft Azure Site Recovery Unified Setup.

2. If you have scale-out process servers, update them next by running 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.

A restart is recommended after every upgrade of Mobility agent to ensure that all the latest changes are loaded on the source VM. However, a restart is not mandatory. If the difference between agent version during last reboot and current version is greater than four (4), a reboot is mandatory. Refer to the following table for a detailed explanation.