Updaterollup 59 für Azure Site Recovery -KB5008707

Mobility Service 

Verbesserungen

• Unterstützung für Windows Server 2022 als Replikationsbetriebssystem des Computers, für Replikationen von Azure in Azure und für VMWare in Azure-Replikationen hinzugefügt.

Behobene Probleme

• Es wurde ein Problem behoben, bei dem die Erstellung einer anwendungskonsistenten Momentaufnahme fehlschlägt, während eine andere Momentaufnahme ausgeführt wurde.

• Es wurde ein Fehler behoben, bei dem die Zertifikaterneuerung für den Konfigurationsserver sowohl im Portal als auch im Tool fehlschlägt, weil einer der Dienste nicht beendet wurde. 

• Es wurde ein Problem behoben, bei dem die Installation des Mobilitätsdiensts fehlgeschlagen ist, weil die Manifestdatei nicht installiert werden konnte. 

• Es wurde ein Block für die Installation des Mobilitätsdiensts auf Computern hinzugefügt, auf denen die älteren InMage Scout-Bits bereits installiert sind.

• Die Protokollmeldungen wurden für ein einfacheres und schnelleres Debuggen verbessert. 

• [VMware-Vorschauarchitektur]Es wurde ein Problem behoben, bei dem eine unvollständige Fehlermeldung für einen Fehler bei der Registrierung der ASR-Replikationsappliance angezeigt wurde. 

• Es wurde ein Problem behoben, bei dem die Replikation aufgrund der Rotation von Speicherschlüsseln in "Kritisch" umgewandelt wurde. 

• Bei fehlender Stammzertifizierungsstelle wurden genaue Zertifikatnamen hinzugefügt, um das Debuggen besser zu unterstützen. 

• Verbesserte Fehlerbenachrichtigung für mehrere Szenarien.

• [VMware preview architecture] Es wurde ein Problem behoben, bei dem die während der umgekehrten Replikation durchgeführte Neusynchronisierung unterbrochen wurde. 

• [VMware preview architecture] Es wurde ein Problem behoben, bei dem die umgekehrte Replikation nicht fortgesetzt und nicht fehlgeschlagen ist, wenn auf das Cachespeicherkonto nicht zugegriffen werden konnte. 

• [VMware preview architecture] Es wurde ein bekanntes Problem behoben, bei dem eine ASR-Replikationsappliance, die nicht erfolgreich registriert wurde, auch im Portal angezeigt wurde. 

• [VMware preview architecture] Es wurde ein bekanntes Problem behoben, dass beim erneuten Schutz von PowerShell ein Fehler aufgrund einer ungültigen Failoverrichtung aufgetreten ist.

• Unterstützung für Oracle Linux 8.4 mit UEK-Kernel hinzugefügt.

Microsoft Azure Site Recovery (Dienst)

Es wurden keine Änderungen hinzugefügt.

Microsoft Azure Site Recovery (Portal)

No changes added.

Zwischen zwei lokalen VMM-Standorten

1. Laden Sie das neueste Updaterollup für Microsoft Azure Site Recovery Provider herunter.

2. Installieren Sie zuerst das Updaterollup auf dem lokalen VMM-Server, der den Wiederherstellungsstandort verwaltet.

3. Nachdem der Wiederherstellungsstandort aktualisiert wurde, installieren Sie das Updaterollup auf dem VMM-Server, der den primären Standort verwaltet.

Hinweis Wenn es sich bei der VMM um eine hochverfügbare VMM (clustered VMM) handelt, stellen Sie sicher, dass Sie das Upgrade auf allen Knoten des Clusters installieren, auf denen der VMM-Dienst installiert ist.

Zwischen einem lokalen VMM-Standort und Azure

1. Laden Sie das Updaterollup für Microsoft Azure Site Recovery Provider herunter.

2. Installieren Sie das Updaterollup auf dem lokalen VMM-Server.

3. Installieren Sie den neuesten Microsoft Azure Recovery Services-Agent auf allen Hyper-V-Hosts.

Hinweis Wenn es sich bei Ihrem VMM um ein hochverfügbares VMM (clustered VMM) handelt, stellen Sie sicher, dass Sie das Upgrade auf allen Knoten des Clusters installieren, auf denen der VMM-Dienst installiert ist.

Zwischen einem lokalen Hyper-V-Standort und Azure

1. Download the Update Rollup for Microsoft Azure Site Recovery Provider.

2. Installieren Sie den Anbieter auf jedem Knoten der Hyper-V-Server, die Sie in Azure Site Recovery registriert haben.

Hinweis Wenn Es sich bei Ihrem Hyper-V-Server um einen Hostclusterserver handelt, stellen Sie sicher, dass Sie das Upgrade auf allen Knoten des Clusters installieren.

Zwischen einem lokalen VMware-Standort oder einem physischen Standort zu Azure

1. Aktualisieren Sie Ihren lokalen Verwaltungsserver, indem SieMicrosoft Azure Site Recovery Unified Setup herunterladen . Dies ist der Server, der über die Serverrollen Konfigurationsserver und Prozessserver verfügt.

2. Wenn Sie über Prozessserver mit horizontaler Skalierung verfügen, aktualisieren Sie diese als Nächstes, indem Sie Microsoft Azure Site Recovery Unified Setup ausführen.

3. Wechseln Sie zum Azure-Portal und dann zur Seite Geschützte Elemente > Replizierte Elemente. Wählen Sie auf dieser Seite einen virtuellen Computer aus. Wählen Sie die Schaltfläche Agent aktualisieren aus, die unten auf der Seite für jede VM angezeigt wird. Dadurch wird der Mobility Service-Agent auf allen geschützten VMs aktualisiert.

Hinweis: Wenn Sie SUSE Linux Enterprise Server 11 SP3-, SUSE Linux Enterprise Server 11 SP4-, RHEL5-, CentOS 5-, Oracle Linux 6-, DEBIAN7-, DEBIAN8- und UBUNTU-14.04-Computer aktualisieren oder schützen, müssen Sie die folgenden Schritte ausführen:

1. Laden Sie das entsprechende Installationsprogramm für Ihre Computer herunter:

   • SUSE Linux Enterprise Server 11 SP3

   • SUSE Linux Enterprise Server 11 SP4

   • RHEL5

   • CentOS 5

   • Oracle Linux 6

   • DEBIAN 7

   • DEBIAN 8

   • UBUNTU-14.04

2. Kopieren Sie das Installationsprogramm in die Ordner INSTALL_DIR\home\svsystems\pushinstallsvc\repository auf Konfigurationsserver und Scale Out Prozessserver, bevor Sie Ihr Virtual Machines aktualisieren oder schützen. Im Folgenden finden Sie beispielsweise den Ordnernamen, wenn der Installationspfad für Konfigurationsserver/Prozessserver C:\Programme (x86)\Microsoft Azure Site Recovery lautet:

   • C:\Programme (x86)\Microsoft Azure Site Recovery\home\svsystems\pushinstallsvc\repository

3. Wechseln Sie nach dem Kopieren des Installers zu services.msc , und starten Sie den InMage PushInstall-Dienst neu.

Hinweis: Nach jedem Upgrade des Mobilitäts-Agents wird ein Neustart empfohlen, um sicherzustellen, dass alle aktuellen Änderungen auf dem Quellcomputer geladen werden. Dies ist nicht unbedingt obligatorisch. Ein Neustart ist jedoch obligatorisch, wenn der Unterschied zwischen agent-Versionen vom letzten Neustart und der Zielversion größer als vier (4) in der letzten Dezimalstelle ist. Eine ausführliche Erläuterung finden Sie in der folgenden Tabelle.