Updaterollup 42 für Azure Site Recovery

Gilt für
Azure Site Recovery

Einführung

In diesem Artikel werden die Probleme beschrieben, die in Updaterollup 42 in den folgenden Versionen von Microsoft Azure Site Recovery behoben wurden:

Erfahren Sie mehr über die Details der behobenen Probleme und die Voraussetzungen, die vor der Installation dieses Updates überprüft werden sollten.

Voraussetzungen

Um Microsoft Azure Site Recovery Provider Update Rollup 42 (Version 5.1.5200.0) installieren zu können, muss eine der folgenden Komponenten installiert sein:

  • Microsoft Azure Site Recovery Provider (Version 5.1.4800 oder höher)
  • Microsoft Azure Site Recovery Unified Setup (VMware zu Azure) (Version 9.26.xxxx.x oder höher)
  • Microsoft Azure Recovery Services-Agent (Version 2.0.8700.0 oder höher)

Hinweis Sie können die installierte Anbieterversion im Element Programme und Features in Systemsteuerung überprüfen.

In diesem Update vorgenommene Verbesserungen und behobene Probleme

Nach der Installation dieses Updates sind die folgenden Probleme behoben, und die folgenden Verbesserungen sind enthalten.

Mobility Service

Verbesserungen

  • Azure Site Recovery unterstützt jetzt Testfailover, Failover & Failback von VMware- und Azure Computern mit UEFI-Layout.

    • VMware-Computer mit den folgenden Betriebssystemen werden unterstützt: Windows Server 2012, Windows Server 2012R2, Windows Server 2016, Windows Server 2019, SLES12Sp4, RHEL8

    • Alle Azure Computer der Generation 2 werden unterstützt.

  • Verbesserungen bei Linux BS-Unterstützung

    • RHEL 8

    • Oracle Linux 7.7

  • Azure zur Azure Notfallwiederherstellung

    • Azure Linux Computer mit Azure Disk Encryption (ADE) können jetzt über Azure Site Recovery

    • Python 3 für Linux-Erweiterung wird jetzt unterstützt

  • VMware zur Azure Notfallwiederherstellung

    • Datenänderungsrate (Änderungsrate) von Datenträgern und Datenuploadrate-Protokollen sind jetzt in der Log Analytics-Integration mit Recovery Services-Tresor verfügbar.

Behobene Probleme

  • Voraussetzungsprüfungen sind aktiviert, um die Unterstützung von SHA2-Codesignatur zu überprüfen. Unter Windows 2008 R2 mit SP1, Windows 2008 SP2 und Windows 7 SP1 müssen bestimmte KBs installiert werden, um sha2-Codesignatur zu ermöglichen. Upgrades und Neuinstallationen des ASR-Mobilitäts-Agents sind nicht erfolgreich, wenn die SHA2-Codesignatur nicht aktiviert ist. Weitere Informationen

Microsoft Azure Site Recovery (Dienst)

Verbesserungen

  • Azure virtuellen Computer im geografischen Norwegen können jetzt durch Azure Site Recovery geschützt werden.
  • Azure Prozessserver-SKU, die für Failbackvorgänge in VMware verwendet wird, um die Notfallwiederherstellung zu Azure, ist standardmäßig auf Standard_A8_v2

Behobene Probleme
      

  • Leistungsverbesserungen werden vorgenommen, um den Zeitaufwand für das Laden replizierter Elemente aus dem Recovery Services-Tresor & auf dem Blatt "Prozessserver" zu minimieren.

  • Neusynchronisierungsbenachrichtigungen werden aktualisiert, um Details zu Computern bereitzustellen, die eine erneute Synchronisierung erfordern.

  • In Azure Azure Notfallwiederherstellungsszenarios befindet sich das automation-Konto, das beim Aktivieren der Replikation ausgewählt wurde, nicht immer in der Zielregion (da nicht alle Regionen über Automatisierungskonten verfügen). Es gibt eine Geozuordnung, die informiert, in welcher Region das Automation-Konto bereitgestellt werden muss. Diese Geozuordnung wird aktualisiert, damit Kunden Automatisierungskonten aus einer anderen Region verwenden können.

Aktualisieren Ihrer Azure Site Recovery lokalen Komponenten

Zwischen zwei lokalen VMM-Standorten

  1. Herunterladen des neuesten Updaterollups für Microsoft Azure Site Recovery Provider
  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 dem 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 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. Laden Sie das Updaterollup für Microsoft Azure Site Recovery Provider herunter.
  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 Server 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 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.

Agent-Version beim letzten Neustart Upgrade auf Ist ein Neustart obligatorisch?
9.25 9.27 Nicht zwingend erforderlich
9.25 9.28 Nicht zwingend erforderlich
9.25 9.29 Nicht zwingend erforderlich
9.25 9.30 Mandatory

Führen Sie zunächst ein Upgrade auf Version 9.29 durch, und starten Sie dann neu, bevor Sie auf Version 9.30 aktualisieren (da der Unterschied zwischen der letzten Neustartversion und der Zielversion größer als 4 ist).