Einführung
In diesem Artikel werden die Probleme beschrieben, die in Update Rollup 42 in den folgenden Versionen von Microsoft Azure Site Recovery behoben wurden:
-
Herunterladen von Microsoft Azure Site Recovery Provider (Version 5.1.5200.0)
-
Herunterladen von Microsoft Azure Recovery Services Agent (Version 2.0.9165.0)
-
Microsoft Azure Site Recovery Configuration Server OVF-Vorlage herunterladen (Version 5.1.5200.0)
-
Mobility Service für Windows herunterladen (Version 9.30.5407.1)
-
Mobility Service für CentOS herunterladen (Version 9.30.5407.1)
-
Mobility Service für Ubuntu herunterladen (Version 9.30.5407.1)
Erfahren Sie mehr über die Details der behobenen Probleme und Voraussetzungen die überprüft werden sollten, bevor Sie dieses Update installieren.
Voraussetzungen
Um microsoft Azure Site Recovery Provider Update Rollup 42 (Version 5.1.5200.0) zu installieren, müssen Sie eine der folgenden Installationen haben:
-
Microsoft Azure Site Recovery Provider (Version 5.1.4800 oder eine neuere Version)
-
Microsoft Azure Site Recovery Unified Setup (VMware to Azure) (Version 9.26.xxxx.x oder eine neuere Version)
-
Microsoft Azure Recovery Services Agent (Version 2.0.8700.0 oder eine neuere Version)
Hinweis Sie können die installierte Anbieterversion im Element Programme und Features in der Systemsteuerung überprüfen.
In diesem Update vorgenommene Verbesserungen und Probleme
Nach der Installation dieses Updates werden die folgenden Probleme behoben, und die folgenden Verbesserungen sind enthalten.
Mobilitätsservice
Verbesserungen
-
Azure Site Recovery unterstützt jetzt Testfailover, Failover & Failback von VMware und Azure-Computer mit UEFI-Layout
-
-
Vmware Maschinen mit 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 der Unterstützung von Linux-Betriebssystemen
-
-
Rhel 8
-
Oracle Linux 7.7
-
-
Azure zu Azure DR
-
-
Azure Linux-Computer mit Azure Disk Encryption (ADE) können jetzt über Azure Site Recovery geschützt werden
-
Python 3 für Linux Extension wird jetzt unterstützt
-
-
Vmware zu Azure DR
-
-
Daten Änderungsrate (Abwanderung) von Datenträgern und Datenuploadratenprotokolle sind jetzt im Log verfügbar Analytics-Integration mit Recovery Services Vault
-
Probleme behoben
-
Voraussetzung Prüfungen sind aktiviert, um die SHA2-Codesignaturunterstützung zu überprüfen. Betriebssystem, das unter Windows ausgeführt wird 2008 R2 mit SP1, Windows 2008 SP2 und Windows 7 SP1 erfordert, dass bestimmte installiert, um die SHA2-Codesignatur zu aktivieren. ASR Mobility Agent Upgrades und frische Installationen sind nicht erfolgreich, wenn die SHA2-Codesignatur nicht aktiviert ist. Erfahren Sie mehr
Microsoft Azure Site Recovery (Dienst)
Verbesserungen
-
Azure virtuelle Computer in Norwegen geo können jetzt über Azure Site Recovery geschützt werden.
-
Azure-Prozessserver-SKU, die für Failbackvorgänge verwendet wird in VMware zu Azure DR standardmäßig auf Standard_A8_v2
Probleme behoben
-
Leistung Verbesserungen werden vorgenommen, um den Zeitaufwand für das Laden replizierter Artikel zu minimieren vom Recovery Services-Tresor & vom Prozessserver-Blade
-
Neusynchronisierung Benachrichtigungen werden aktualisiert, um Details zu Maschinen bereitzustellen, die Resynchronisierung.
-
In Azure to Azure DR-Szenario Automatisierungskonto, das während der Aktivierung der Replikation ausgewählt wurde, Zielregion (da nicht alle Regionen über Automatisierungskonten verfügen). Es gibt eine Geo- Mapping, die informiert, welche Region das Automatisierungskonto vorgesehen sind. Diese Geo-Mapping wird aktualisiert, damit Kunden Automatisierungskonten aus einer anderen Region.
Aktualisieren Ihrer lokalen Azure Site Recovery-Komponenten
Zwischen zwei lokalen VMM-Standorten
-
Laden Sie das neueste Update Rollup fürMicrosoft Azure Site Recovery Provider herunter
-
Installieren Sie das Updaterollup zuerst auf dem lokalen VMM-Server, der die Wiederherstellungssite verwaltet.
-
Installieren Sie nach der Aktualisierung des Wiederherstellungsstandorts 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 dem der VMM-Dienst installiert ist.
Zwischen einer lokalen VMM-Site und Azure
-
Laden Sie das Update Rollup herunter, Microsoft Azure Site Recovery-Anbieter.
-
Installieren Sie das UpdateRollup auf dem lokalen VMM-Server.
-
Installieren Sie die 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 dem der VMM-Dienst installiert ist.
Zwischen einer lokalen Hyper-V-Site und Azure
-
Laden Sie das Update Rollup herunter,Microsoft Azure Site Recovery-Anbieter.
-
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 um einen Host Clustered Hyper-V-Server handelt, stellen Sie sicher, dass Sie das Upgrade auf allen Knoten des Clusters installieren.
Zwischen einer lokalen VMware- oder physischen Site zu Azure
-
Aktualisieren Sie Ihren lokalen Verwaltungsserver, indem Sie Microsoft Azure Site Recovery Unified Setup. Dies ist der Server mit den Konfigurationsserver- und Prozessserverrollen.
-
Wenn Sie über scale-out-Prozessserver verfügen, aktualisieren Sie diese als nächstes, indem Sie Microsoft Azure Site Recovery Unified Setup.
-
Wechseln Sie zum Azure-Portal, und wechseln Sie 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-Agenten wird ein Neustart empfohlen, um sicherzustellen, dass alle neuesten Änderungen auf dem Quellcomputer geladen werden. Dies ist nicht unbedingt obligatorisch. Ein Neustart ist jedoch obligatorisch, wenn der Unterschied zwischen Agentenversionen beim 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.
Agentenversion beim letzten Neustart |
Upgrade auf |
Ist ein Neustart obligatorisch? |
---|---|---|
9.25 |
9.27 |
Nicht obligatorisch |
9.25 |
9.28 |
Nicht obligatorisch |
9.25 |
9.29 |
Nicht obligatorisch |
9.25 |
9.30 |
MandatoryErstes Upgrade auf Version 9.29 und anschließendes Neustarten, bevor Sie auf Version 9.30 aktualisieren (da der Unterschied zwischen der letzten Neustartversion und der Zielversion größer als 4 ist). |