Freigeben über

Wichtige Punkte für die automatisierte Migration

  • Artikel

Gilt für: ✔️ Windows-VMs ✔️ Linux-VMs ✔️ Lokale Umgebung ✔️ Azure Arc-fähige Server

In diesem Artikel werden die wichtigen Details aufgeführt, die Sie beachten müssen, wenn Sie das Migrationstool im Portal oder Migrationsskripts zur Migration verwenden.

Wichtige Hinweise

  • Abfragen für die gespeicherte Suche, die nicht aus Azure stammen, werden nicht migriert.

  • Für die Migrations- und Offboardingrunbooks muss Az.Modules aktualisiert werden, damit diese funktionieren.

  • Das erforderliche Skript aktualisiert Az.Modules auf die neueste Version 8.0.0.

  • StartTime des MRP-Zeitplans entspricht nextRunTime der Konfiguration des Softwareupdates.

  • Daten aus Log Analytics werden nicht migriert.

  • Benutzerseitig verwaltete Identitäten verfügen über keine Unterstützung für mandantenübergreifende Szenarios.

  • Die RebootOnly-Einstellung ist in Azure Update Manager nicht verfügbar. Zeitpläne mit der RebootOnly-Einstellung werden nicht migriert.

  • Für eine Serie werden in Automation-Zeitplänen Werte zwischen (1 und 100) für stündliche, tägliche, wöchentliche bzw. monatliche Zeitpläne unterstützt, wohingegen die Wartungskonfiguration von Azure Update Manager Werte zwischen (6 und 35) für stündliche und Werte zwischen (1 und 35) für tägliche, wöchentliche bzw. monatliche Zeitpläne unterstützt. Hierzu folgende Beispiele:

    Wiederholung des Automationszeitplans Berechnung der Wiederholung für den Zeitplan zur Wartungskonfiguration
    100 Stunden 100/24 = 4,16 (auf den nächsten Wert runden) –> alle vier Tage
    1 Stunde Alle 6 Stunden, da dies der Mindestwert ist
    100 Tage 100/7 = 14,28 (auf den nächsten Wert runden) –> alle 14 Wochen
    100 Wochen 100/4,34 = 23,04 (auf den nächsten Wert runden) –> alle 23 Monate
    Alle 100 Wochen und muss an Freitagen ausgeführt werden 23 Monate (100/4,34). Es besteht jedoch keine Möglichkeit, Azure Update Manager anzuweisen, den Vorgang alle 23 Monate an allen Freitagen des Monats auszuführen. Deshalb wird der Zeitplan nicht migriert.
    Mehr als 35 Monate Wiederholung von 35 Monaten

  • SUC (Software Update Configuration) unterstützt ein Wartungsfenster von 30 Minuten bis sechs Stunden. MRP (Maintenance Resource Provider) unterstützt zwischen 1 Stunde 30 Minuten und 4 Stunden.

    Wartungsfenster in der Automation-Updateverwaltung Wartungsfenster in Azure Update Manager
    30 Minuten eine Stunde 30 Minuten
    6 Stunden Vier Stunden

  • Wenn das Migrationsrunbook mehrmals ausgeführt wird, beispielsweise beim Versuch, nach der Migration aller Automatisierungszeitpläne alle Zeitpläne erneut zu migrieren, führt das Migrationsrunbook dieselbe Logik aus. Durch ein Wiederholen dieser Aktion wird der MRP-Zeitplan aktualisiert, wenn neue Änderungen in SUC vorhanden sind. Dabei werden keine doppelten Konfigurationszuweisungen erstellt. Außerdem werden Vorgänge lediglich für Automatisierungszeitpläne mit aktivierten Zeitplänen ausgeführt. Wenn eine SUC-Instanz zuvor als Migrated markiert wurde, wird sie im nächsten Schritt übersprungen, da der zugrunde liegende Zeitplan deaktiviert wird.

  • Schließlich können Sie mehr Computer aus Azure Resource Graph als in Azure Update Manager auflösen. Im Gegensatz zur Automation-Updateverwaltung, bei der eine Überschneidung von dynamischen Abfragen und Hybrid Runbook Worker verwendet wird, können Sie nicht überprüfen, ob der Hybrid Runbook Worker Meldungen ausgibt.

  • Computer, die in Azure Update Manager nicht unterstützt werden, werden nicht migriert. Die Zeitpläne, die solche Computer enthalten, werden teilweise migriert, und nur unterstützte Computer der Softwareupdatekonfiguration werden in Azure Update Manager verschoben. Um das Patchen durch sowohl die Automation-Updateverwaltung als auch durch Azure Update Manager zu verhindern, entfernen Sie migrierte Computer aus Bereitstellungszeitplänen in der Automation-Updateverwaltung.

  • Nach dem Deboarding:

    • Stellen Sie sicher, dass Sie das Skript ausführen, das die folgenden Aktionen ausführt:
      • Löschen der Automatisierungskontovariable AzureAutomationAccountEnvironment, die für die Migration erstellt wurde.
      • Entfernen der für die Migration erstellten vom Benutzer verwalteten Identität, die im Automatisierungskonto erstellt wurde.
      • Löschen der zugewiesenen Rollen für die vom Benutzer verwaltete Identität, die für die Migration erstellt wurde.
      • Löschen der vom Benutzer verwalteten Identität, die für die Migration erstellt wurde.
    • Um dieses Skript auszuführen, müssen Sie über „Microsoft.Authorization/roleAssignments/write“-Berechtigungen für alle Abonnements verfügen, die Ressource der Automation-Updateverwaltung wie Computer, Zeitpläne, ein Log Analytics-Arbeitsbereich und ein Automation-Konto enthalten. Weitere Informationen finden Sie unter Zuweisen einer Azure-Rolle.
    • Das Skript sollte auf die gleiche Weise wie das Prerequisite-Skript ausgeführt werden.

Nach der Migration kann die Konfiguration des Softwareupdates einen der folgenden vier Migrationsstatus aufweisen:

  • MigrationFailed
  • PartiallyMigrated
  • NotMigrated
  • Migrated

In der folgenden Tabelle werden die Szenarien aufgeführt, die den einzelnen Migrationsstatus zugeordnet sind:

MigrationFailed PartiallyMigrated NotMigrated Migrated
Die Erstellung der Wartungskonfiguration für die Konfiguration des Softwareupdates ist fehlgeschlagen Die Anwendung der Patcheinstellungen ist auf mindestens einem Computer fehlgeschlagen.
Wenn beispielsweise ein Computer in Azure Update Manager nicht unterstützt wird, wird der Status der Softwareupdatekonfiguration teilweise migriert.		 Die Softwareupdatekonfiguration konnte wegen eines Client-/Serverfehlers nicht von der API abgerufen werden. Beispielsweise ist ein interner Dienstfehler aufgetreten. Keine Computer, auf denen Patcheinstellungen nicht angewendet werden konnten
Und
Keine Computer mit fehlgeschlagenen Konfigurationszuweisungen.
Und
Die Auflösung von keinen dynamischen Abfragen ist fehlgeschlagen, das heißt, es gab keine Abfragen, die nicht für Azure Resource Graph ausgeführt werden konnten.
Und
Keine Fehler bei der dynamischen Bereichskonfigurationszuweisung
Und
Softwareupdatekonfiguration hat keine Abfragen für eine gespeicherte Suche.
Die Konfigurationszuweisung ist auf mindestens einem Computer fehlgeschlagen. In der Konfiguration des Softwareupdates ist die Einstellung für den Neustart als RebootOnly angegeben. Das wird heutzutage in Azure Update Manager nicht unterstützt.
Die Auflösung mindestens einer dynamischen Abfrage ist fehlgeschlagen. Dabei konnte die Abfrage für Azure Resource Graph nicht ausführen werden. Die Softwareupdatekonfiguration weist in der Datenbank nicht den Bereitstellungsstatus „erfolgreich“ auf.
Die Konfigurationszuweisung von mindestens einem dynamischen Bereich ist fehlgeschlagen. Die Konfiguration des Softwareupdates in der Datenbank befindet sich im Fehlerstatus.
Die Konfiguration des Softwareupdates hat gespeicherte Abfragen von Azure Cognitive Search. Der mit der Konfiguration des Softwareupdates verknüpfte Zeitplan ist zum Zeitpunkt der Migration bereits abgelaufen.
Die Softwareupdatekonfiguration verfügt über Pre-/Postaufgaben, die nicht erfolgreich migriert wurden. Der der Konfiguration des Softwareupdates zugeordnete Zeitplan ist deaktiviert.
Ausnahmefehler beim Migrieren der Konfiguration des Softwareupdates

Nächste Schritte