Migration mithilfe von automatisierten Runbookskripts

  • Artikel

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

In diesem Artikel wird beschrieben, wie Sie mithilfe von Migrationsrunbooks alle Workloads (Computer und Zeitpläne) automatisch aus der Automation-Updateverwaltung zu Azure Update Manager migrieren können.

In den folgenden Abschnitten werden die Ausführung, die Funktionsweise im Back-End, das erwartete Verhalten und gegebenenfalls die Einschränkungen des Skripts erläutert. Das Skript kann alle Computer und Zeitpläne in einem Automation-Konto gleichzeitig migrieren. Wenn Sie über mehrere Automation-Konten verfügen, müssen Sie das Runbook für alle Automation-Konten ausführen.

Im Allgemeinen müssen Sie die folgenden Schritte ausführen, um Ihre Computer und Zeitpläne aus der Automation-Updateverwaltung zu Azure Update Manager zu migrieren.

Nicht unterstützte Szenarien

  • Gespeicherte Abfragen, die nicht aus Azure Cognitive Search stammen, werden nicht migriert. Diese müssen manuell migriert werden.

Die vollständige Liste der Einschränkungen und wichtigen Aspekte finden Sie unter Wichtige Punkte bei der Migration.

Leitfaden mit Schrittanleitungen

Die in den obigen Schritten aufgeführten Informationen werden in den folgenden Abschnitten ausführlich erläutert.

Voraussetzung 1: Onboarding für Nicht-Azure-Computern in Arc

Vorgehensweise

Das Runbook für die Migrationsautomatisierung ignoriert Ressourcen, für die kein Onboarding in Arc durchgeführt wurde. Deshalb besteht eine Voraussetzung darin, vor dem Ausführen des Migrationsrunbooks ein Onboarding für alle Nicht-Azure-Computer in Azure Arc durchzuführen. Führen Sie die Schritte zum Durchführen eines Onboardings von Computern in Azure Arc aus.

Voraussetzung 2: Erstellen von Benutzeridentitäts- und Rollenzuweisungen durch das Ausführen des PowerShell-Skripts

.A Voraussetzungen für die Ausführung des Skripts

  • Führen Sie den Befehl Install-Module -Name Az -Repository PSGallery -Force in PowerShell aus. Das erforderliche Skript hängt von Az.Modules ab. Dieser Schritt ist erforderlich, wenn Az.Modules nicht vorhanden oder nicht aktualisiert ist.
  • Um dieses erforderliche 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.
  • Sie müssen über die Berechtigungen für die Updateverwaltung verfügen.

Screenshot, der zeigt, wie der Befehl zum Installieren des Moduls ausgeführt wird.

B. Ausführen des Skripts

Laden Sie das PowerShell-Skript MigrationPrerequisiteScript herunter, und führen Sie es lokal aus. Dieses Skript verwendet AutomationAccountResourceId des zu migrierenden Automation-Kontos und AutomationAccountAzureEnvironment als die Eingaben. Die akzeptierten Werte für AutomationAccountAzureEnvironment sind AzureCloud, AzureUSGovernment und AzureChina, welche die Cloud angeben, zu der das Automatisierungskonto gehört.

Screenshot, der zeigt, wie Das Skript heruntergeladen und ausgeführt wird.

Sie können den Parameter AutomationAccountResourceId abrufen, indem Sie zu Automation-Konto>Eigenschaften navigieren.

Screenshot, der zeigt, wie die Ressourcen-ID abgerufen wird.

C. Überprüfen

Überprüfen Sie nach dem Ausführen des Skripts, ob eine benutzerseitig verwaltete Identität im Automation-Konto erstellt wurde. Automation-Konto>Identität>Benutzerseitig zugewiesen.

Screenshot, der zeigt, wie Sie überprüfen können, ob eine vom Benutzer verwaltete Identität erstellt wird.

D: Back-End-Vorgänge durch das Skript

  • Aktualisierung von Az.Modules für das Automation-Konto, was für die Ausführung von Migrations- und Entladeskripts erforderlich ist.

  • Erstellt eine Automatisierungsvariable mit dem Namen AutomationAccountAzureEnvironment, welche die Azure Cloud-Umgebung speichert, zu der das Automation-Konto gehört.

  • Erstellen von Benutzeridentitäten im selben Abonnement und in derselben Ressourcengruppe wie das Automation-Konto. Der Name der Benutzeridentität lautet AutomationAccount_aummig_umsi.

  • Anfügen der Benutzeridentität an das Automation-Konto

  • Das Skript weist der benutzerseitig verwalteten Identität die folgenden Berechtigungen zu: Erforderliche Berechtigungen für die Updateverwaltung.

    1. Dazu ruft das Skript alle Computer ab, für die unter diesem Automation-Konto ein Onboarding in die Automation-Updateverwaltung durchgeführt wurde. Zudem parst es die Abonnement-IDs der Computer, um die erforderliche rollenbasierte Zugriffssteuerung (RBAC) für die Benutzeridentität zu erhalten.
    2. Das Skript weist der Benutzeridentität im Abonnement, zu dem das Automation-Konto gehört, die korrekte RBAC zu, damit die MRP-Konfigurationen dort erstellt werden können.
    3. Das Skript weist die erforderlichen Rollen für den Log Analytics-Arbeitsbereich und die Log Analytics-Lösung zu.

  • Registrierung erforderlicher Abonnements für Microsoft.Maintenance- und Microsoft.EventGrid-Ressourcenanbieter.

Schritt 1: Migration von Computern und Zeitplänen

Dieser Schritt umfasst die Verwendung eines Automatisierungsrunbooks zum Migrieren aller Computer und Zeitpläne aus einem Automation-Konto zu Azure Update Manager.

Führen Sie die folgenden Schritte aus:

  1. Importieren Sie das Migrationsrunbook aus dem Runbookkatalog, und veröffentlichen Sie es. Suchen Sie auf der Seite „Katalog durchsuchen“ nach azure automation update, importieren Sie das Migrationsrunbook namens Migrieren von der Azure Automation-Updateverwaltung zu Azure Update Manager, und veröffentlichen Sie das Runbook.

    Screenshot, der zeigt, wie Sie aus der Automation-Updateverwaltung migrieren.

    Das Runbook unterstützt PowerShell 5.1.

    Screenshot mit Runbook unterstützt PowerShell 5.1 beim Importieren.

  2. Legen Sie die ausführliche Protokollierung für das Runbook auf TRUE fest.

    Screenshot, der zeigt, wie ausführliche Protokolldatensätze festgelegt werden.

  3. Führen Sie das Runbook aus, und übergeben Sie die erforderlichen Parameter wie AutomationAccountResourceId und UserManagedServiceIdentityClientId.

    Screenshot, der zeigt, wie sie das Runbook ausführen und die erforderlichen Parameter übergeben.

    1. Sie können den Parameter AutomationAccountResourceId über Automation-Konto>Eigenschaften abrufen.

      Screenshot, der zeigt, wie Die Ressourcen-ID des Automatisierungskontos abgerufen wird.

    2. Sie können den Parameter UserManagedServiceIdentityClientId über Automation-Konto>Identität>Benutzerseitig zugewiesen>Identität>Eigenschaften>Client-ID abrufen.

      Screenshot, der zeigt, wie Client-ID abgerufen wird.

    3. Das Festlegen des Parameters EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement auf TRUE würde die Eigenschaft der regelmäßigen Bewertung auf allen Computern aktivieren, für die ein Onboarding in die Automation-Updateverwaltung durchgeführt wurde.

    4. Das Festlegen des Parameters MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines auf TRUE würde alle Updatezeitpläne in der Automation-Updateverwaltung zu Azure Update Manager migrieren. Außerdem würde dadurch die Eigenschaft der regelmäßigen Bewertung auf allen Computern, die mit diesen Zeitplänen verknüpft sind, auf TRUE festgelegt werden.

    5. Sie müssen über den Parameter ResourceGroupForMaintenanceConfigurations angeben, wo alle Wartungskonfigurationen in Azure Update Manager erstellt werden. Wenn Sie einen neuen Namen angeben, wird eine Ressourcengruppe erstellt, in der alle Wartungskonfigurationen erstellt werden. Wenn Sie jedoch einen Namen angeben, für den eine Ressourcengruppe bereits vorhanden ist, werden alle Wartungskonfigurationen in der vorhandenen Ressourcengruppe erstellt.

  4. Überprüfen Sie die Azure-Runbookprotokolle auf den Status der Ausführung und der Migration von SUCs.

    Screenshot der Runbook-Protokolle.

Runbookvorgänge im Back-End

Bei der Migration des Runbooks werden die folgenden Aufgaben ausgeführt:

  • Die regelmäßige Bewertung wird auf allen Computern aktiviert.
  • Alle Zeitpläne im Automation-Konto werden zu Azure Update Manager migriert, und für jeden Zeitplan wird eine entsprechende Wartungskonfiguration mit denselben Eigenschaften erstellt.

Informationen zum Skript

Das Migrationsskript weist das folgende Verhalten auf:

  • Es überprüft, ob eine Ressourcengruppe mit dem Namen, der als Eingabe verwendet wurde, bereits im Abonnement des Automation-Kontos vorhanden ist. Sollte keine vorhanden sein, erstellt es eine Ressourcengruppe mit dem durch den Kunden oder die Kundin angegebenen Namen. Diese Ressourcengruppe wird zum Erstellen der MRP-Konfigurationen für Version 2 verwendet.

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

  • Es filtert SUCs mit dem Status errored/expired/provisioningFailed/disabled heraus und markiert diese als NotMigrated. Anschließend gibt es die entsprechenden Protokolle aus, die angeben, dass solche SUCs nicht migriert werden.

  • Der Name der Konfigurationszuweisung ist eine Zeichenfolge im Format AUMMig_AAName_SUCName.

  • Es ermittelt, ob dieser dynamische Bereich bereits der Wartungskonfiguration zugewiesen ist, indem es den Bereich mit Azure Resource Graph abgleicht. Sollte keiner zugewiesen sein, weist es lediglich den Zuordnungsnamen im Format AUMMig_ AAName_SUCName_SomeGUID zu.

  • Für Zeitpläne mit konfigurierten Pre-/Postaufgaben erstellt das Skript einen Automatisierungswebhook für die Runbooks in Pre-/Postaufgaben und Event Grid-Abonnements für Wartungsereignisse von Pre-/Postaufgaben. Weitere Informationen finden Sie unter So funktionieren Pre-/Postaufgaben in Azure Update Manager

  • Es gibt eine Protokollzusammenfassung im Ausgabestream aus, um den Gesamtstatus von Computern und SUCs anzugeben.

  • Detaillierte Protokolle werden im ausführlichen Stream ausgegeben.

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

    • MigrationFailed
    • PartiallyMigrated
    • NotMigrated
    • Migrated

In der folgenden Tabelle werden die Szenarios 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. Das Abrufen der Konfiguration des Softwareupdates aus der API ist aufgrund eines Client- bzw. Serverfehlers wie ein interner Dienstfehler fehlgeschlagen.
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 Konfigurationszuweisung von mindestens einem dynamischen Bereich ist fehlgeschlagen. Die Konfiguration des Softwareupdates in der Datenbank weist nicht den Bereitstellungsstatus „erfolgreich“ auf.
Die Konfiguration des Softwareupdates hat gespeicherte Abfragen von Azure Cognitive Search. Die Konfiguration des Softwareupdates in der Datenbank befindet sich im Fehlerstatus.
Die Softwareupdatekonfiguration verfügt über Pre-/Postaufgaben, die nicht erfolgreich migriert wurden. Der mit der Konfiguration des Softwareupdates verknüpfte Zeitplan ist zum Zeitpunkt der Migration bereits abgelaufen.
Der der Konfiguration des Softwareupdates zugeordnete Zeitplan ist deaktiviert.
Ausnahmefehler beim Migrieren der Konfiguration des Softwareupdates Das Anwenden der Patcheinstellung ist bei keinem Computer fehlgeschlagen.

And

Die Konfigurationszuweisungen sind bei keinem Computer fehlgeschlagen.

And

Die Auflösung keiner dynamischen Abfragen ist fehlgeschlagen. Dabei konnte die Abfrage für Azure Resource Graph nicht ausführen werden.

And

Keine Konfigurationszuweisung eines dynamischen Bereichs ist fehlgeschlagen.

And

Die Konfiguration des Softwareupdates hat keine gespeicherten Abfragen von Azure Cognitive Search.

Um anhand der Tabelle zu ermitteln, aufgrund welcher Szenarios die Konfiguration des Softwareupdates einen bestimmten Status aufweist, überprüfen Sie die ausführlichen Protokolle, die fehlgeschlagenen Protokolle oder die Warnungsprotokolle, um den Fehlercode und die Fehlermeldung zu erhalten.

Sie können ebenfalls mit dem Namen des Updatezeitplans nach spezifischen Protokollen für das Debuggen suchen.

Screenshot, der zeigt, wie Protokolle für das Debuggen angezeigt werden.

Schritt 2: Lösung zum Offboarding aus der Automation-Updateverwaltung

Führen Sie die folgenden Schritte aus:

  1. Importieren Sie das Migrationsrunbook aus dem Runbookkatalog. Suchen Sie auf der Seite „Katalog durchsuchen“ nach azure automation update, importieren Sie das Migrationsrunbook namens Offboarding aus der Azure Automation-Updateverwaltung, und veröffentlichen Sie das Runbook.

    Screenshot, der zeigt, wie das Runbook für die Deaboardmigration importiert wird.

    Das Runbook unterstützt PowerShell 5.1.

    Screenshot, der zeigt, dass das Runbook PowerShell 5.1 während des Deboardings unterstützt.

  2. Legen Sie die ausführliche Protokollierung für das Runbook auf TRUE fest.

    Screenshot, der die Einstellung für ausführliche Protokolldatensätze während der Deboardierung zeigt.

  3. Starten Sie das Runbook, und übergeben Sie Parameter wie AutomationAccountResourceId und UserManagedServiceIdentityClientId.

    Screenshot, der zeigt, wie Sie Runbook starten und Parameter beim Deboarding übergeben.

    Sie können den Parameter AutomationAccountResourceId über Automation-Konto>Eigenschaften abrufen.

    Screenshot, der zeigt, wie Ressourcen-ID beim Deboarding abgerufen wird.

    Sie können den Parameter UserManagedServiceIdentityClientId über Automation-Konto>Identität>Benutzerseitig zugewiesen>Identität>Eigenschaften>Client-ID abrufen.

    Screenshot, der zeigt, wie Client-ID beim Deboarding abgerufen wird.

  4. Überprüfen Sie die Azure-Runbookprotokolle auf den Offboardingstatus von Computern und Zeitplänen.

    Screenshot, der zeigt, wie Runbook während des Deboardings protokolliert.

Vorgänge des Offboardingskrips im Back-End

  • Alle zugrunde liegenden Zeitpläne für alle Konfigurationen des Softwareupdates, die in diesem Automation-Konto vorhanden sind, werden deaktiviert. Dadurch wird gewährleistet, dass das Runbook Patch-MicrosoftOMSComputers nicht für SUCs ausgelöst wird, die teilweise zur Version 2 migriert wurden.
  • Die Updatelösung wird aus dem verknüpften Log Analytics-Arbeitsbereich für das Automation-Konto gelöscht, für das ein Offboarding aus der Automation-Updateverwaltung in Version 1 durchgeführt wird.
  • Ein zusammengefasstes Protokoll aller deaktivierten SUCs und des Status für das Entfernen der Updatelösung aus dem verknüpften Log Analytics-Arbeitsbereich wird ebenfalls im Ausgabestream ausgegeben.
  • Detaillierte Protokolle werden im ausführlichen Stream ausgegeben.

Nächste Schritte