Partager via


Fonctionnement du Gestionnaire de mise à jour

Le Gestionnaire de mise à jour évalue et applique les mises à jour à toutes les machines Azure et tous les serveurs avec Azure Arc pour Windows et Linux.

Capture d’écran montrant le workflow du gestionnaire de mise à jour.

Extensions de machine virtuelle du Gestionnaire de mise à jour

Quand une opération AUM (Gestionnaire de mise à jour Azure) est activée ou déclenchée sur votre serveur Azure ou serveur avec Arc, AUM installe une extension Azure ou des extensions serveurs avec Arc, respectivement, sur votre machine pour gérer les mises à jour.

L’extension est automatiquement installée sur votre machine quand vous lancez une opération AUM (Gestionnaire de mise à jour Azure) sur votre machine pour la première fois, par exemple rechercher les mises à jour, installer une mise à jour ponctuelle, effectuer une évaluation périodique, ou quand le déploiement de mises à jour planifiées s’exécute sur votre machine pour la première fois.

Le client n’a pas à installer explicitement l’extension et son cycle de vie, car cette opération est gérée par le Gestionnaire de mise à jour Azure, notamment l’installation et la configuration. L’extension du Gestionnaire de mise à jour est installée et gérée à l’aide des agents ci-dessous, qui sont nécessaires au bon fonctionnement du Gestionnaire de mise à jour sur vos machines :

Remarque

La connectivité Arc est un prérequis pour le Gestionnaire de mise à jour, les machines non Azure, notamment VMWare avec Arc, SCVMM, etc.

Pour les machines Azure, une seule extension est installée, alors que pour les machines avec Azure Arc, deux extensions sont installées. Vous trouverez ci-dessous les détails des extensions qui sont installées :

Système d’exploitation Extension
Windows Microsoft.CPlat.Core.WindowsPatchExtension
Linux Microsoft.CPlat.Core.LinuxPatchExtension

Source des mises à jour

Le Gestionnaire de mise à jour Azure respecte les paramètres relatifs à la source des mises à jour sur la machine, et récupère les mises à jour de manière appropriée. AUM ne publie pas ou ne fournit pas de mises à jour.

Si l’agent Windows Update (WUA) est configuré pour récupérer les mises à jour à partir du référentiel Windows Update, du référentiel Microsoft Update ou de WSUS (Windows Server Update Services), AUM respecte ces paramètres. Pour plus d’informations, consultez les détails relatifs à la configuration du client Windows Update. Par défaut, il est configuré pour récupérer les mises à jour à partir du référentiel de mises à jour Windows mise à jour.

AUM effectue les étapes suivantes :

  • Il récupère les informations d’évaluation relatives à l’état des mises à jour système pour le système spécifié par le client Windows Update ou le gestionnaire de package Linux.
  • Il lance le téléchargement et l’installation des mises à jour avec le client Windows Update ou le gestionnaire de package Linux.

Remarque

  1. Les machines signalent leur état de mise à jour en fonction de la source avec laquelle elles sont configurées pour se synchroniser. Si le service Windows Update est configuré pour envoyer un rapport à WSUS, les résultats présents dans le Gestionnaire de mise à jour peuvent différer de ceux affichés par Microsoft Update, en fonction de la date de la dernière synchronisation de WSUS avec Microsoft Update. Ce comportement est le même pour les machines Linux configurées pour rendre compte à un référentiel local et non pas à un référentiel de package public.
  2. Le Gestionnaire de mise à jour recherche uniquement les mises à jour que le service Windows Update trouve quand vous sélectionnez le bouton local Rechercher les mises à jour sur le système Windows local. Sur les systèmes Linux, seules les mises à jour du référentiel local sont découvertes.

Met à jour les données stockées dans Azure Resource Graph

L’extension Gestionnaire de mise à jour envoie toutes les informations sur les mises à jour en attente ainsi que les résultats de l’installation des mises à jour vers Azure Resource Graph, où les données sont conservées pendant les périodes ci-dessous :

Données Période de rétention dans Azure Resource Graph
Mises à jour en attente (nom de table ARG : patchassessmentresources) Sept jours
Résultats de l’installation des mises à jour (nom de table ARG : patchinstallationresources) 30 jours

Pour plus d’informations, consultez Structure des journaux d’Azure Resource Graph et Exemples de requêtes.

Mode d’installation des correctifs dans le Gestionnaire de mise à jour Azure

Dans le Gestionnaire de mise à jour Azure, les correctifs sont installés de la manière suivante :

  1. Le processus commence par une nouvelle évaluation des mises à jour disponibles sur la machine virtuelle.

  2. L’installation des mises à jour suit l’évaluation.

    • Dans Windows, les mises à jour sélectionnées qui répondent aux critères du client sont installées une par une,
    • Dans Linux, elles sont installées par lots.
  3. Durant l’installation des mises à jour, l’utilisation de la fenêtre de maintenance est vérifiée à plusieurs étapes. Pour Windows et Linux, 10 et 15 minutes de la fenêtre de maintenance sont respectivement réservées au redémarrage à tout moment. Avant de procéder à l’installation des mises à jour restantes, le processus vérifie si le temps de redémarrage prévu plus le temps d’installation moyen des mises à jour (pour la prochaine mise à jour ou le prochain ensemble de mises à jour) ne dépassent pas la fenêtre de maintenance. Dans le cas de Windows, le temps d’installation moyen des mises à jour est de 10 minutes pour tous les types de mises à jour, à l’exception des mises à jour de Service Pack. Pour les mises à jour de Service Pack, le délai est de 15 minutes.

  4. Notez qu’une installation de mise à jour en cours d’exécution (une fois lancée sur la base du calcul ci-dessus) n’est pas arrêtée de force, même si elle dépasse la fenêtre de maintenance, et ce pour éviter que la machine ne se retrouve dans un état éventuellement indéterminé. Toutefois, l’installation des mises à jour restantes ne se poursuit pas une fois la fenêtre de maintenance dépassée. Dans ce cas de figure, une erreur de dépassement de fenêtre de maintenance est levée.

  5. L’installation de la mise à jour corrective/de la mise à jour est uniquement considérée comme réussie si toutes les mises à jour sélectionnées sont installées, et si toutes les opérations impliquées (notamment le redémarrage et l’évaluation) réussissent. Sinon, elle est marquée avec l’état Échec ou Terminé avec avertissements. Par exemple,

    Scénario État de l’installation des mises à jour
    Échec de l’installation de l’une des mises à jour sélectionnées. Échec
    Le redémarrage n’a pas lieu pour une raison quelconque, et le délai d’attente pour le redémarrage a expiré. Échec
    La machine ne parvient pas à démarrer durant un redémarrage. Échec
    Échec de l’évaluation initiale ou finale Échec
    Le redémarrage est imposé par les mises à jour, mais l’option Ne jamais redémarrer est sélectionnée. Terminé avec des avertissements
    Les packages ESM ont ignoré la mise à jour corrective dans Ubuntu 18 ou version antérieure si la licence Ubuntu pro n’était pas présente. Terminé avec des avertissements
  6. Une évaluation est effectuée à la fin. Notez que le redémarrage et l’évaluation effectués à la fin de l’installation d’une mise à jour risquent de ne pas avoir lieu dans certains cas, par exemple si la fenêtre de maintenance a déjà été dépassée, si l’installation de la mise à jour échoue pour une raison quelconque, etc.

Étapes suivantes