Partager via

Migration en utilisant des scripts runbook automatisés

  • Article

S’applique à : ✔️ Machines virtuelles Windows ✔️ Machines virtuelles Linux ✔️ Environnement local ✔️ Serveurs avec Azure Arc

Cet article décrit en détail l’utilisation de runbooks de migration pour migrer automatiquement toutes vos charges de travail (machines et planifications) d’Automation Update Management vers le Gestionnaire de mise à jour Azure.

Les sections suivantes expliquent comment exécuter le script, ce que fait le script au niveau du back-end, le comportement attendu et les éventuelles limitations. Le script peut migrer l’ensemble des machines et des planifications d’un compte Automation en une seule fois. Si vous avez plusieurs comptes Automation, vous devez exécuter le runbook pour tous les comptes Automation.

De façon sommaire, vous devez effectuer les étapes ci-dessous pour migrer vos machines et planifications d’Automation Update Management vers le Gestionnaire de mise à jour Azure.

Scénarios non pris en charge

  • Les requêtes de recherche enregistrées non-Azure ne sont pas migrées ; vous devez les migrer manuellement.

Pour obtenir la liste complète des limitations et des éléments à noter, consultez les points clés pendant la migration.

Guide pas à pas

Les informations mentionnées dans chacune des étapes ci-dessus sont expliquées en détail ci-dessous.

Prérequis 1 : intégrer des machines non-Azure à Arc

Procédure à suivre

Le runbook Automation de migration ignore les ressources qui ne sont pas intégrées à Arc. Vous devez donc intégrer toutes les machines non-Azure à Azure Arc avant d’exécuter le runbook de migration. Suivez les étapes pour intégrer des machines à Azure Arc.

Prérequis 2 : créer une identité d’utilisateur et des attributions de rôles en exécutant un script PowerShell

A. Prérequis liés à l’exécution du script

  • Exécutez la commande Install-Module -Name Az -Repository PSGallery -Force dans PowerShell. Le script prérequis dépend d’Az.Modules. Cette étape est obligatoire si Az.Modules n’est ni présent ni mis à jour.
  • Pour exécuter ce script prérequis, vous devez disposer d’autorisations Microsoft.Authorization/roleAssignments/write sur tous les abonnements qui contiennent des ressources Automation Update Management, notamment des machines, des planifications, un espace de travail Log Analytics et un compte Automation. Consultez la procédure d’attribution d’un rôle Azure.
  • Vous devez disposer des autorisations Update Management.

Capture d’écran montrant la commande pour installer le module.

B. Exécuter le script

Téléchargez et exécutez le script PowerShell MigrationPrerequisiteScript localement. Ce script prend AutomationAccountResourceId du compte Automation et AutomationAccountAzureEnvironment à migrer comme entrées. Les valeurs acceptées pour AutomationAccountAzureEnvironment sont AzureCloud, AzureUSGovernment et AzureChina signifiant le cloud auquel appartient le compte Automation.

Capture d’écran montrant comment télécharger et exécuter le script.

Vous pouvez extraire AutomationAccountResourceId en accédant à Compte Automation>Propriétés.

Capture d’écran montrant comment extraire l’ID de la ressource.

C. Vérification

Après avoir exécuté le script, vérifiez qu’une identité managée par l’utilisateur est créée dans le compte Automation. Compte Automation>Identité>Affectée par l’utilisateur.

Capture d’écran montrant comment vérifier qu’une identité managée par l’utilisateur est créée.

D. Opérations effectuées par le script au niveau du back-end

  • Mise à jour d’Az.Modules pour le compte Automation, ce qui est nécessaire pour exécuter les scripts de migration et de retrait.

  • Crée une variable Automation avec le nom AutomationAccountAzureEnvironment qui stocke l’environnement cloud Azure auquel appartient le compte Automation.

  • Création d’une identité d’utilisateur dans le même abonnement et le même groupe de ressources que le compte Automation. Le nom de l’identité d’utilisateur ressemble à ceci : AutomationAccount_aummig_umsi.

  • Attachement de l’identité d’utilisateur au compte Automation.

  • Le script attribue les autorisations suivantes à l’identité managée par l’utilisateur : autorisations Update Management requises.

    1. Pour cela, le script extrait toutes les machines intégrées à la Gestion des mises à jour Automation sous ce compte Automation et analyse leurs ID d’abonnement pour fournir le RBAC requis à l’identité utilisateur.
    2. Le script fournit un RBAC approprié à l’identité d’utilisateur dans l’abonnement auquel appartient le compte Automation afin que les configurations MRP puissent être créées ici.
    3. Le script affecte les rôles requis pour l’espace de travail et la solution Log Analytics.

  • Inscription des abonnements nécessaires aux fournisseurs de ressources Microsoft.Maintenance et Microsoft.EventGrid.

Étape 1 : migration des machines et des planifications

Cette étape implique l’utilisation d’un runbook Automation pour migrer toutes les machines et les planifications d’un compte Automation vers le Gestionnaire de mise à jour Azure.

Suivez ces étapes :

  1. Importez le runbook de migration à partir de la galerie de runbooks et publiez-le. Recherchez azure automation update dans Parcourir la galerie, importez le runbook de migration nommé Migrate from Azure Automation Update Management to Azure Update Manager (Migrer d’Azure Automation Update Management vers le Gestionnaire de mise à jour Azure), puis publiez le runbook.

    Capture d’écran montrant comment effectuer la migration à partir de la Gestion des mises à jour Automation.

    Le runbook prend en charge PowerShell 5.1.

    Capture d’écran montrant le runbook qui prend en charge PowerShell 5.1 lors de l’importation.

  2. Définissez la journalisation détaillée sur True pour le runbook.

    Capture d’écran montrant comment définir les enregistrements de la journalisation détaillée.

  3. Exécutez le runbook et passez les paramètres requis comme AutomationAccountResourceId, UserManagedServiceIdentityClientId, etc.

    Capture d’écran montrant comment exécuter le runbook et passer les paramètres requis.

    1. Vous pouvez extraire AutomationAccountResourceId à partir de Compte Automation>Propriétés.

      Capture d’écran montrant comment extraire l’ID de la ressource du compte Automation.

    2. Vous pouvez extraire UserManagedServiceIdentityClientId à partir de Compte Automation>Identité>Affectée par l’utilisateur>Identité>Propriétés>ID client.

      Capture d’écran montrant comment extraire l’ID client.

    3. La définition d’EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement sur True entraîne l’activation de la propriété d’évaluation périodique sur toutes les machines intégrées à Automation Update Management.

    4. La définition de MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines à True entraîne la migration de toutes les planifications de mise à jour d’Automation Update Management vers le Gestionnaire de mise à jour Azure ainsi que l’activation (True) de la propriété d’évaluation périodique sur toutes les machines liées à ces planifications.

    5. Vous devez spécifier le groupe de ressources ResourceGroupForMaintenanceConfigurations où toutes les configurations de maintenance dans le Gestionnaire de mise à jour Azure sont créées. Le fait de fournir un nouveau nom entraîne la création d’un groupe de ressources où toutes les configurations de maintenance sont créées. Toutefois, si ce nom est déjà utilisé par un groupe de ressources, toutes les configurations de maintenance sont créées dans le groupe de ressources existant.

  4. Consultez les journaux Azure Runbook pour connaître l’état de l’exécution et de la migration des SUC.

    Capture d’écran montrant les journaux du runbook.

Opérations du runbook dans le back-end

La migration du runbook effectue les tâches suivantes :

  • Active l’évaluation périodique sur toutes les machines.
  • Toutes les planifications du compte Automation sont migrées vers le Gestionnaire de mise à jour Azure, et une configuration de maintenance correspondante est créée pour chaque planification avec les mêmes propriétés.

À propos du script

Voici le comportement du script de migration :

  • Vérifie si un groupe de ressources portant le nom indiqué en entrée est déjà présent dans l’abonnement du compte Automation ou non. Si ce n’est pas le cas, un groupe de ressources portant le nom spécifié par le client est créé. Ce groupe de ressources est utilisé pour créer les configurations MRP pour V2.

  • Le paramètre RebootOnly n’est pas disponible dans le Gestionnaire de mise à jour Azure. Les planifications comportant le paramètre RebootOnly ne sont pas migrées.

  • Exclut par filtrage les SUC se trouvant dans l’un des états suivants : errored (erroné), expired (expiré), provisioningFailed (échec de l’approvisionnement) ou disabled (désactivé). Marquez-les comme Non migrées, puis imprimez les journaux appropriés indiquant que ces SUC ne sont pas migrées.

  • Le nom de l’affectation de configuration est une chaîne au format AUMMig_AAName_SUCName

  • Déterminez si cette étendue dynamique est déjà affectée à la configuration de maintenance ou non en vous reportant à Azure Resource Graph. Si elle ne l’est pas, affectez-la uniquement avec un nom d’affectation au format AUMMig_AAName_SUCName_SomeGUID.

  • Pour les planifications qui ont des pré-/post-tâches configurées, le script crée un webhook d’automatisation pour les runbooks de ces tâches et des abonnements Event Grid pour les événements de pré-/post-maintenance. Pour plus d’informations, consultez la description du fonctionnement des pré-événements/post-événements dans le Gestionnaire de mise à jour Azure

  • Un ensemble résumé de journaux est affiché dans le flux de sortie pour donner un état global des machines et des SUC.

  • Les journaux détaillés sont affichés dans le flux de commentaires.

  • Après la migration, une configuration de mise à jour de logiciel (SUC, Software Update Configuration) peut se trouver dans l’un des quatre états de migration suivants :

    • MigrationFailed (Échec de la migration)
    • PartiallyMigrated (Partiellement migrée)
    • NotMigrated (Non migrée)
    • Migrated (Migrée)

Le tableau ci-dessous présente les scénarios associés à chaque état de migration.

MigrationFailed (Échec de la migration) PartiallyMigrated (Partiellement migrée) NotMigrated (Non migrée) Migrated (Migrée)
La création de la configuration de maintenance pour la configuration de mise à jour de logiciel a échoué. Nombre non nul de machines sur lesquelles l’application de Patch-Settings a échoué. Nous n’avons pas pu obtenir la configuration de mise à jour de logiciel à partir de l’API en raison d’une erreur client/serveur (peut-être une erreur de service interne).
Nombre non nul de machines avec des affectations de configuration ayant échoué. Le paramètre de redémarrage de la configuration de mise à jour de logiciel est défini sur RebootOnly. Cela n’est pas pris en charge pour l’instant dans le Gestionnaire de mise à jour Azure.
Nombre non nul de requêtes dynamiques qui n’ont pas pu être résolues, c’est-à-dire qui n’ont pas pu être exécutées sur Azure Resource Graph.
Nombre non nul d’échecs d’affectation de configuration d’étendue dynamique. La configuration de mise à jour de logiciel n’a pas réussi à approvisionner l’état dans la base de données.
La configuration de mise à jour de logiciel comporte des requêtes de recherche enregistrées. La configuration de mise à jour de logiciel est dans un état d’erreur dans la base de données.
La configuration des mises à jour de logiciels comporte des tâches de pré/post-traitement qui n’ont pas été migrées correctement. La planification associée à la configuration de mise à jour de logiciel a déjà expiré au moment de la migration.
La planification associée à la configuration de mise à jour de logiciel est désactivée.
Exception non prise en charge lors de la migration de la configuration de mise à jour de logiciel. Aucune machine sur laquelle l’application de Patch-Settings a échoué.

And

Aucune machine avec des affectations de configuration ayant échoué.

And

Aucune requête dynamique qui n’a pas pu être résolue, c’est-à-dire qui n’a pas pu être exécutée sur Azure Resource Graph.

And

Aucun échec d’affectation de configuration d’étendue dynamique.

And

La configuration de mise à jour de logiciel ne comporte aucune requête de recherche enregistrée.

Pour trouver à partir du tableau ci-dessus le ou les scénarios correspondant à la raison pour laquelle la configuration de mise à jour de logiciel se trouve dans un état spécifique, consultez les journaux détaillés, les journaux des échecs et les journaux d’avertissements afin d’obtenir le code d’erreur et le message d’erreur.

Vous pouvez également lancer une recherche avec le nom de la planification de mise à jour pour obtenir des journaux propres à cette planification à des fins de débogage.

Capture d’écran montrant comment afficher les journaux spécifiques au débogage.

Étape 2 : retrait de la solution Automation Update Management

Suivez ces étapes :

  1. Importez le runbook de migration à partir de la galerie de runbooks. Recherchez azure automation update dans Parcourir la galerie, importez le runbook de migration nommé Deboard from Azure Automation Update Management (Retirer Azure Automation Update Management), puis publiez le runbook.

    Capture d’écran montrant comment importer le runbook de migration de suppression.

    Le runbook prend en charge PowerShell 5.1.

    Capture d’écran montrant le runbook qui prend en charge PowerShell 5.1 lors de la suppression.

  2. Définissez la journalisation détaillée sur True pour le runbook.

    Capture d’écran montrant le paramètre des enregistrements de la journalisation détaillée lors de la suppression.

  3. Démarrez le runbook et passez des paramètres comme AutomationAccountResourceId, UserManagedServiceIdentityClientId, etc.

    Capture d’écran montrant comment démarrer le runbook et transmettre les paramètres lors de la suppression.

    Vous pouvez extraire AutomationAccountResourceId à partir de Compte Automation>Propriétés.

    Capture d’écran montrant comment extraire l’ID de la ressource lors de la suppression.

    Vous pouvez extraire UserManagedServiceIdentityClientId à partir de Compte Automation>Identité>Affectée par l’utilisateur>Identité>Propriétés>ID client.

    Capture d’écran montrant comment extraire l’ID client lors de la suppression.

  4. Consultez les journaux du runbook Azure pour connaître l’état du retrait des machines et des planifications.

    Capture d’écran montrant les journaux du runbook lors de la suppression.

Opérations du script de retrait dans le back-end

  • Désactive toutes les planifications sous-jacentes pour toutes les configurations de mise à jour de logiciel présentes dans ce compte Automation. Cette opération permet de s’assurer que le runbook Patch-MicrosoftOMSComputers n’est pas déclenché pour les SUC qui ont été partiellement migrées vers V2.
  • Supprime la solution de mises à jour de l’espace de travail Log Analytics lié pour le compte Automation en cours de retrait d’Automation Update Management dans V1.
  • Un journal résumé de toutes les SUC désactivées et de l’état de la suppression de la solution de mise à jour de l’espace de travail Log Analytics lié est également affiché dans le flux de sortie.
  • Les journaux détaillés sont affichés dans les flux de commentaires.

Étapes suivantes