Partager via

Points clés à noter pour une migration automatisée

  • Article

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

Cet article liste les détails significatifs que vous devez noter lorsque vous effectuez une migration avec l’outil de migration du portail ou des scripts de migration.

Rappels importants

  • Les requêtes de recherche enregistrées non-Azure ne sont pas migrées.

  • Az.Modules doit être mis à jour pour que les runbooks de migration et de retrait fonctionnent.

  • Le script prérequis met à jour Az.Modules vers la dernière version 8.0.0.

  • La valeur StartTime de la planification MRP est égale à la valeur nextRunTime de la configuration de mise à jour de logiciel.

  • Les données de Log Analytics ne sont pas migrées.

  • Les identités managées par l’utilisateur ne prennent pas en charge les scénarios inter-locataires.

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

  • À des fins de périodicité, les planifications Automation prennent en charge des valeurs comprises entre 1 et 100 pour les planifications horaires/quotidiennes/hebdomadaires/mensuelles, tandis que la configuration de maintenance du Gestionnaire de mise à jour Azure prend en charge des valeurs comprises entre 6 et 35 pour les planifications horaires et entre 1 et 35 pour les planifications quotidiennes/hebdomadaires/mensuelles. Regardez les exemples suivants :

    Périodicité de la planification d’automatisation Calcul de la périodicité de la planification de la configuration de maintenance
    100 heures 100/24 = 4,16 (Arrondi à la valeur la plus proche) -> tous les quatre jours
    1 heure Toutes les 6 heures, car il s’agit de la valeur minimale
    100 jours 100/7 = 14,28 (Arrondi à la valeur la plus proche) -> toutes les 14 semaines
    100 semaines 100/4,34 = 23,04 (Arrondi à la valeur la plus proche) -> tous les 23 mois
    Toutes les 100 semaines et doit être exécuté le vendredi 23 mois (100/4,34). Mais il n’existe aucun moyen dans le Gestionnaire de mise à jour Azure de spécifier que la planification doit s’exécuter tous les 23 mois chaque vendredi de ce mois, donc elle n’est pas migrée.
    Plus de 35 mois Périodicité de 35 mois

  • La SUC (Software Update Configuration, Configuration de la mise à jour de logiciel) prend en charge une fenêtre de maintenance comprise entre 30 minutes et 6 heures. Le MRP (Maintenance Resource Provider, fournisseur de ressources de maintenance) prend en charge entre 1 heure 30 et 4 heures.

    Fenêtre de maintenance dans Automation Update Management Fenêtre de maintenance dans le Gestionnaire de mise à jour Azure
    30 minutes une heure 30 minutes
    6 heures Quatre heures

  • Lorsque le runbook de migration est exécuté plusieurs fois (par exemple, après avoir migré toutes les planifications Automation, vous réessayez de migrer toutes les planifications), le runbook de migration exécute la même logique. Le fait de répéter cette opération met à jour la planification MRP si de nouvelles modifications sont présentes dans la SUC. Aucune affectation de configuration en double n’est effectuée. Par ailleurs, les opérations sont réalisées uniquement pour les planifications Automation avec des planifications activées. Si une SUC a été migrée précédemment, elle est ignorée au tour suivant puisque sa planification sous-jacente est désactivée.

  • Au final, vous pouvez résoudre davantage de machines d’Azure Resource Graph que dans le Gestionnaire de mise à jour Azure. Vous ne pouvez pas vérifier si Runbook Worker hybride génère un rapport ou non, contrairement à Automation Update Management où il s’agissait d’un croisement de requêtes dynamiques et de Runbook Worker hybride.

  • Les machines non prises en charge dans le Gestionnaire de mise à jour Azure ne sont pas migrées. Les planifications qui ont ces machines sont partiellement migrées et seules les machines prises en charge de la configuration des mises à jour logicielles sont déplacées vers le Gestionnaire de mise à jour Azure. Pour empêcher la mise à jour corrective d’Automation Update Management et du Gestionnaire de mise à jour Azure, supprimez les machines migrées des planifications de déploiement dans Automation Update Management.

  • Post Deboarding :

    • Veillez à exécuter le script qui effectue les opérations suivantes :
      • Supprimer la variable du compte Automation AzureAutomationAccountEnvironment créée pour la migration.
      • Supprimer l’identité managée par l’utilisateur créée pour la migration à partir du compte Automation.
      • Supprimer les rôles attribués pour l’identité managée par l’utilisateur créée pour la migration.
      • Supprimer l’identité managée par l’utilisateur créée pour la migration.
    • Pour exécuter le script ci-dessus, 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. Pour plus d’informations, consultez Comment attribuer un rôle Azure.
    • Le script doit être exécuté de la même manière que le script prérequis.

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 suivant 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)
Échec de création de la configuration de maintenance pour la configuration des mises à jour logicielles Nombre non nul de machines sur lesquelles l’application de Patch-Settings a échoué.
Par exemple, si une machine n’est pas prise en charge dans le Gestionnaire de mise à jour Azure, l’état de la configuration des mises à jour logicielles est partiellement migré.		 Nous n’avons pas pu obtenir la configuration des mises à jour logicielles à partir de l’API en raison d’une erreur client/serveur comme Erreur de service interne. Aucune machine où l’application des paramètres de correctif a échoué
et
Aucune machine avec des affectations de configuration ayant échoué.
et
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.
et
Aucun échec d’affectation de configuration d’étendue dynamique
et
La configuration des mises à jour logicielles n’a aucune requête de recherche enregistrée.
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. La configuration des mises à jour logicielles n’a pas un état d’approvisionnement réussi dans la base de données.
Nombre non nul d’échecs d’affectation de configuration d’étendue dynamique. La configuration de mise à jour de logiciel est dans un état d’erreur dans la base de données.
La configuration de mise à jour de logiciel comporte des requêtes de recherche enregistrées. La planification associée à la configuration de mise à jour de logiciel a déjà expiré au moment de la migration.
La configuration des mises à jour logicielles présente des pré-/post-tâches qui n’ont pas été migrées correctement. 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.

Étapes suivantes