Vue d’ensemble de Update Management
Attention
Cet article fait référence à CentOS, une distribution Linux qui a atteint l’état de fin de vie (EOL). Faites le point sur votre utilisation pour vous organiser de manière appropriée. Pour plus d’informations, consultez l’aide relative à la fin de vie de CentOS.
Important
Automation Update Management a été mis hors service le 31 août 2024. Nous vous recommandons d’utiliser le Gestionnaire de mise à jour Azure. Suivez les instructions de migration d’Automation Update Management vers le Gestionnaire de mise à jour Azure.
Important
L’agent Azure Log Analytics, également connu sous le nom de Microsoft Monitoring Agent (MMA), a été mis hors service en août 2024. La solution Azure Automation Update Management repose sur cet agent et peut rencontrer des problèmes une fois que l'agent est mis hors service, car il ne fonctionne pas avec Azure Monitoring Agent (AMA). Par conséquent, si vous utilisez la solution Azure Automation Update Management, nous vous recommandons de passer à Azure Update Manager pour vos besoins de mise à jour logicielle. Toutes les fonctionnalités de la solution de gestion des mises à jour Azure Automation seront disponibles sur Azure Update Manager avant la date de mise hors service.
Vous pouvez utiliser Update Management dans Azure Automation pour gérer les mises à jour des systèmes d’exploitation de vos machines virtuelles Windows et Linux dans Azure, des machines virtuelles ou physiques dans les environnements locaux et dans d’autres environnements cloud. Vous pouvez rapidement évaluer l’état des mises à jour disponibles et gérer le processus d’installation des mises à jour nécessaires pour vos machines qui communiquent leurs rapports à Update Management.
En tant que fournisseur de services, vous avez peut-être intégré plusieurs locataires clients à Azure Lighthouse. La gestion des mises à jour peut être utilisée pour évaluer et planifier des déploiements de mises à jour sur des machines dans plusieurs abonnements dans le même locataire Microsoft Entra, ou entre les locataires à l’aide d’Azure Lighthouse.
Microsoft propose d’autres fonctionnalités pour vous aider à gérer les mises à jour de vos machines virtuelles Azure ou groupes de machines virtuelles identiques Azure que vous devez prendre en compte dans le cadre de votre stratégie globale de gestion des mises à jour.
Si vous souhaitez évaluer et mettre à jour automatiquement vos machines virtuelles Azure, afin de garantir la conformité en matière de sécurité à l’aide des mises à jour Critiques et de Sécurité publiées chaque mois, consultez Mise à jour corrective automatique d’un invité de machine virtuelle. Il s’agit d’une autre solution de gestion des mises à jour qui permet à vos machines virtuelles Azure d’être mises à jour automatiquement pendant les heures creuses, notamment les machines virtuelles d’un groupe à haute disponibilité, en comparaison avec la gestion des déploiements de mises à jour sur ces machines virtuelles à partir d’Update Management dans Azure Automation.
Si vous gérez des groupes de machines virtuelles identiques Azure, regardez comment effectuer des Mises à niveau automatiques de l’image du système d’exploitation pour mettre à niveau le disque du système d’exploitation de toutes les instances du groupe identique de manière sécurisée et automatique.
Avant de déployer Update Management et d’activer vos machines pour la gestion, assurez-vous de bien comprendre les informations contenues dans les sections suivantes.
À propos d’Update Management
Le schéma suivant illustre la façon dont Update Management évalue les mises à jour de sécurité et les applique à tous les serveurs Windows Server et Linux connectés.
Update Management s’intègre aux journaux Azure Monitor pour stocker les évaluations de mise à jour et les résultats de déploiement des mises à jour sous la forme de données de journal, depuis des machines Azure et non Azure assignées. Pour collecter ces données, le compte Automation et l’espace de travail Log Analytics sont liés entre eux ; l’agent Log Analytics pour Windows et Linux est nécessaire sur la machine, et il est configuré pour produire des rapports vers cet espace de travail.
Update Management prend en charge la collecte d’informations concernant les mises à jour système auprès des agents dans un groupe d’administration SCOM (System Center Operations Manager) connecté à l’espace de travail. L’inscription d’une machine auprès du service Update Management dans plusieurs espaces de travail Log Analytics (également appelé multihébergement) n’est pas prise en charge.
Le tableau suivant récapitule les sources connectées prises en charge avec Update Management.
| Source connectée | Prise en charge | Description |
|---|---|---|
| Windows | Oui | Update Management collecte des informations concernant les mises à jour système auprès des machines Windows par l’intermédiaire de l’agent Log Analytics et de l’installation des mises à jour obligatoires. Les ordinateurs doivent envoyer un rapport à Microsoft Update ou Windows Server Update Services (WSUS). |
| Linux | Oui | Update Management collecte des informations concernant les mises à jour système auprès des machines Linux par l’intermédiaire de l’agent Log Analytics et de l’installation des mises à jour obligatoires sur les distributions prises en charge. Les ordinateurs doivent envoyer un rapport à un référentiel local ou distant. |
| Groupe d’administration d’Operations Manager | Oui | Update Management collecte des informations concernant les mises à jour logicielles auprès d’agents dans un groupe d’administration connecté. Une connexion directe entre l’agent Operations Manager et les journaux Azure Monitor n’est pas obligatoire. Les données de journal sont transférées du groupe d’administration à l’espace de travail Log Analytics. |
Les machines affectées à Update Management signalent l’état de mise à jour dans lequel elles se trouvent, en fonction de la source avec laquelle elles sont configurées pour se synchroniser. Les machines Windows doivent être configurées pour envoyer des rapports soit à Windows Server Update Services, soit à Microsoft Update tandis que les machines Linux doivent être configurées pour les envoyer à un référentiel local ou public. Vous pouvez également utiliser Update Management avec Microsoft Configuration Manager ; pour en savoir plus, consultez Intégrer Update Management à Windows Configuration Manager.
Si l’agent Windows Update sur la machine Windows est configuré pour transmettre les rapports à WSUS (Windows Server Update Services), en fonction de la date de la dernière synchronisation de WSUS à Microsoft Update, les résultats peuvent être différents de ce qu’indique Microsoft Update. Le 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 public. Sur une machine Windows, l’analyse de conformité est effectuée toutes les 12 heures par défaut. Sur une machine Linux, l’analyse de conformité est effectuée toutes les heures par défaut. Si l’agent Log Analytics est redémarré, une analyse de conformité est démarrée dans les 15 minutes. À l’issue de l’analyse de conformité de la mise à jour effectuée par la machine, l’agent transfère les informations en bloc aux journaux Azure Monitor.
Vous pouvez déployer et installer des mises à jour logicielles sur des machines qui nécessitent les mises à jour en créant un déploiement planifié. Les mises à jour considérées comme facultatives ne sont pas incluses dans le déploiement des machines Windows. Seules les mises à jour nécessaires sont incluses dans le déploiement.
Le déploiement planifié définit quelles machines cibles reçoivent les mises à jour applicables. Soit il désigne explicitement certaines machines, soit il sélectionne un groupe d’ordinateurs d’après des recherches dans les journaux d’un ensemble spécifique de machines (ou selon une requête Azure qui sélectionne des machines virtuelles Azure de manière dynamique en fonction de critères spécifiés). Ces groupes diffèrent de la configuration d’étendue, utilisée pour contrôler le ciblage des machines qui reçoivent la configuration permettant d’activer Update Management. Cela les empêche de procéder à la conformité des mises à jour et de créer des rapports, puis d’installer les mises à jour nécessaires approuvées.
Lorsque vous définissez un déploiement, vous spécifiez également une planification pour approuver et définir la période pendant laquelle les mises à jour peuvent être installées. Cette période est appelée fenêtre de maintenance. Dix minutes de la fenêtre de maintenance sont réservées aux redémarrages si un redémarrage est nécessaire et que vous avez sélectionné l’option de redémarrage appropriée. Si la mise à jour corrective prend plus longtemps que prévu et qu’il reste moins de dix minutes dans la fenêtre de maintenance, il n’y aura pas de redémarrage.
Après la planification du déploiement d’un package de mise à jour, il faut compter 2 à 3 heures pour que la mise à jour apparaisse sur les machines Linux à des fins d’évaluation. Pour les machines Windows, ce délai est de 12 à 15 heures après la publication. Avant et après l’installation de la mise à jour, une analyse de conformité de la mise à jour est effectuée, et les résultats des données de journal sont transférés à l’espace de travail.
Les mises à jour sont installées par des Runbooks dans Azure Automation. Vous ne pouvez pas visualiser ces runbooks, ils ne nécessitent par ailleurs aucune configuration. Lorsqu’un déploiement de mises à jour est créé, il génère une planification qui démarre un runbook de mise à jour principal au moment indiqué pour les machines incluses. Le runbook principal démarre un runbook enfant sur chaque agent qui lance l’installation des mises à jour obligatoires avec l’agent Windows Update sur Windows, ou la commande correspondante sur les distributions Linux prises en charge.
À la date et l’heure spécifiées dans le déploiement de mises à jour, les machines cibles exécutent le déploiement en parallèle. Avant l’installation, une analyse est lancée pour vérifier que les mises à jour sont encore requises. Pour les machines clientes WSUS, si les mises à jour ne sont pas approuvées dans WSUS, leur déploiement échoue.
Limites
Voici les limites qui s’appliquent à Update Management :
| Ressource | Limite | Remarques |
|---|---|---|
| Nombre de machines par déploiement de mises à jour | 1 000 | |
| Nombre de groupes dynamiques par déploiement de mise à jour | 500 |
autorisations
Pour créer et gérer des déploiements de mises à jour, vous devez disposer d’autorisations spécifiques. Pour en savoir plus sur ces autorisations, consultez Accès en fonction du rôle - Update Management.
Composants Update Management
Update Management utilise les ressources décrites dans cette section. Ces ressources sont automatiquement ajoutées à votre compte Automation quand vous activez Update Management.
Groupes de Runbooks Workers hybrides
Après avoir activé Update Management, toute machine Windows directement connectée à votre espace de travail Log Analytics est automatiquement configurée en tant que Runbook Worker hybride système, afin de gérer les runbooks qui prennent en charge Update Management.
Chaque machine Windows gérée par Update Management est répertoriée dans le volet Groupes de Workers hybrides en tant que Groupe de Workers hybrides système pour le compte Automation. Les groupes utilisent la convention d’affectation de noms Hostname FQDN_GUID. Vous ne pouvez pas cibler ces groupes avec des Runbooks dans votre compte. Si vous essayez, la tentative échoue. Ces groupes sont destinés à prendre uniquement en charge Update Management. Pour en savoir plus sur l’affichage de la liste des machines Windows configurées en tant que Runbook Worker hybride, consultez Afficher les Runbooks Workers hybrides.
Vous pouvez ajouter la machine Windows à un groupe Runbook Worker hybride utilisateur dans votre compte Automation, afin de prendre en charge des runbooks Automation, à condition d’utiliser le même compte pour Update Management et pour l’appartenance au groupe Runbook Worker hybride. Cette fonctionnalité a été ajoutée à la version 7.2.12024.0 du Runbook Worker hybride.
Dépendances externes
Azure Automation Update Management dépend des dépendances externes suivantes pour fournir des mises à jour de logiciel.
- Les services WSUS (Windows Server Update Services) ou Microsoft Update sont nécessaires pour les packages de mises à jour logicielles et les analyses de mise en application des mises à jour logicielles sur les ordinateurs Windows.
- Le client Agent Windows Update (WUA) est nécessaire sur les ordinateurs Windows pour qu’ils puissent se connecter au serveur WSUS ou à Microsoft Update.
- Un référentiel local ou distant pour récupérer et installer les mises à jour du système d’exploitation sur les ordinateurs Linux.
Packs d’administration
Les packs d’administration suivants sont installés sur les machines managées par Update Management. Si votre groupe d’administration Operations Manager est connecté à un espace de travail Log Analytics, les packs d’administration sont installés dans le groupe d’administration Operations Manager. Il n’est pas nécessaire de les configurer ou de les gérer.
- Microsoft System Center Advisor Update Assessment Intelligence Pack (Microsoft.IntelligencePacks.UpdateAssessment)
- Microsoft.IntelligencePack.UpdateAssessment.Configuration (Microsoft.IntelligencePack.UpdateAssessment.Configuration)
- Pack d’administration du déploiement des mises à jour
Remarque
Si vous avez un groupe d’administration Operations Manager 1807 ou 2019 connecté à un espace de travail Log Analytics, avec des agents configurés dans le groupe d’administration pour collecter les données de journal, vous devez remplacer le paramètre IsAutoRegistrationEnabled et le définir sur True dans la règle Microsoft.IntelligencePacks.AzureAutomation.HybridAgent.Init.
Pour plus d’informations sur les mises à jour des packs d’administration, consultez Connecter Operations Manager aux journaux Azure Monitor.
Remarque
Pour que Update Management gère entièrement les machines avec l’agent Log Analytics, vous devez mettre à jour l’agent Log Analytics pour Windows ou l’agent Log Analytics pour Linux. Pour savoir comment mettre à jour l’agent, consultez Guide pratique pour mettre à niveau un agent Operations Manager. Dans les environnements qui utilisent Operations Manager, vous devez exécuter System Center Operations Manager 2012 R2 UR 14 ou une version ultérieure.
Fréquence de collecte de données
Update Management analyse les données des machines gérées à l’aide des règles suivantes. L’affichage sur le tableau de bord des données mises à jour provenant des machines gérées peut prendre entre 30 minutes et 6 heures.
Chaque machine Windows : Update Management effectue une analyse deux fois par jour pour chaque machine.
Chaque machine Linux : Update Management effectue une analyse toutes les heures.
La consommation moyenne de données par les journaux Azure Monitor pour une machine utilisant Update Management est d’environ 25 Mo par mois. Cette valeur est approximative et sujette à modification en fonction de votre environnement. Nous vous recommandons de surveiller votre environnement pour assurer le suivi de votre consommation exacte. Pour plus d’informations sur l’analyse de l’utilisation des données des journaux Azure Monitor, consultez les détails de la tarification des journaux Azure Monitor.
Classifications des mises à jour
Le tableau suivant définit les classifications que Update Management prend en charge pour les mises à jour Windows.
| classification ; | Description |
|---|---|
| Mises à jour critiques | Mise à jour d’un problème spécifique qui concerne un bogue critique non lié à la sécurité. |
| Mises à jour de sécurité | Mise à jour pour un problème de sécurité propre à un produit. |
| Correctifs cumulatifs | Cumul de correctifs logiciels regroupés pour faciliter leur déploiement. |
| Packs de fonctionnalités | Nouvelles fonctionnalités de produit distribuées en dehors d’une version de produit. |
| Service Packs | Cumul de correctifs logiciels appliqués à une application. |
| Mises à jour de définitions | Mise à jour de fichiers de virus ou d’autres définitions. |
| Outils | Utilitaire ou fonctionnalité permettant d’effectuer une ou plusieurs tâches. |
| Mises à jour | Mise à jour d’une application ou d’un fichier actuellement installé. |
Le tableau suivant définit les classifications prises en charge pour les mises à jour Linux.
| Classification | Description |
|---|---|
| Mises à jour critiques et de sécurité | Mises à jour pour un problème spécifique ou un problème de sécurité propre à un produit. |
| Autres mises à jour | Toutes les autres mises à jour qui ne sont ni critiques par nature, ni des mises à jour de sécurité. |
Remarque
La classification des mises à jour pour les machines Linux n’est disponible que dans les régions de cloud public Azure prises en charge. Les mises à jour Linux ne font l’objet d’aucune classification quand Update Management est utilisé dans les régions de cloud national suivantes :
- Azure US Government
- 21Vianet en Chine
Au lieu d’être classées, les mises à jour sont signalées sous la catégorie Autres mises à jour.
Update Management utilise les données publiées par les distributions prises en charge, en particulier leurs fichiers publiés OVAL (Open Vulnerability and Assessment Language). Étant donné que l’accès à Internet est limité à partir de ces clouds nationaux, Update Management ne peut pas accéder aux fichiers.
Classification des mises à jour logiques pour Linux
Pour l’évaluation, Update Management classifie les mises à jour en trois catégories : Sécurité, Critique ou Autres. Cette classification des mises à jour est en fonction des données provenant de deux sources :
- Les fichiers OVAL (Vulnerability and Assessment Language) sont fournis par le fournisseur de distribution Linux, qui inclut des données sur les problèmes de sécurité ou les vulnérabilités que la mise à jour corrige.
- Gestionnaire de package sur votre ordinateur, par exemple YUM, APT ou ZYPPER.
Pour la mise à jour corrective, Update Management classifie les mises à jour en deux catégories : Critique et Sécurité ou Autres. Cette classification des mises à jour est basée uniquement sur les données des gestionnaires de package tels que YUM, APT ou ZYPPER.
CentOS : contrairement à d’autres distributions, CentOS n’a pas de données de classification disponibles à partir du gestionnaire de package. Si vous disposez de machines CentOS configurées pour retourner les données de sécurité de la commande suivante, Update Management peut appliquer la mise à jour corrective en fonction des classifications.
sudo yum -q --security check-update
Remarque
Il n’existe actuellement aucune méthode prise en charge permettant d’activer la disponibilité des données de classification natives sur CentOS. Pour le moment, une prise en charge limitée est proposée aux clients qui pourraient avoir activé cette fonctionnalité eux-mêmes.
Redhat – Pour classifier les mises à jour sur Red Hat Enterprise version 6, vous devez installer le plug-in de sécurité YUM. Sur Red Hat Enterprise Linux 7, le plug-in fait déjà partie de YUM lui-même et il est inutile d’installer quoi que ce soit. Pour plus d’informations, consultez l’article de base de connaissances Red Hat suivant.
Intégrer Update Management à Configuration Manager
Les clients qui ont investi dans Microsoft Configuration Manager pour gérer les PC, les serveurs et les appareils mobiles s’appuient également sur la force et la maturité de Configuration Manager pour aider à gérer les mises à jour logicielles. Pour savoir comment intégrer Update Management à Configuration Manager, consultez Intégrer Update Management à Windows Configuration Manager.
Mises à jour tierces sur Windows
Update Management s’appuie sur le référentiel de mise à jour configuré localement pour mettre à jour les systèmes Windows pris en charge : WSUS ou Windows Update. Des outils, tels que l’éditeur de mise à jour System Center , vous permettent d’importer et de publier des mises à jour personnalisées avec WSUS. Ce scénario permet à Update Management de mettre à jour des machines qui utilisent Configuration Manager comme référentiel de mise à jour avec des logiciels tiers. Pour savoir comment configurer l’éditeur de mise à jour, consultez Installer l’éditeur de mise à jour.
Mettre à jour l’agent Windows Log Analytics vers la dernière version
Update Management nécessite l’agent Log Analytics pour son fonctionnement. Nous vous recommandons de mettre à jour l’agent Windows Log Analytics (également appelé Windows Microsoft Monitoring Agent (MMA)) vers la dernière version pour réduire les vulnérabilités de sécurité et tirer parti des correctifs de bogues. Les versions de l’agent Log Analytics antérieures à 10.20.18053 (bundle) et 1.0.18053.0 (extension) utiliser une méthode antérieure de gestion des certificats et, par conséquent, il n’est pas recommandé. Les anciens agents Windows Log Analytics ne seraient pas en mesure de se connecter à Azure et Update Management cesseraient de travailler dessus.
Vous devez mettre à jour l’agent Log Analytics vers la dernière version, en suivant les étapes ci-dessous :
Vérifiez la version actuelle de l’agent Log Analytics pour votre ordinateur : accédez au chemin d’installation - C :\ProgramFiles\Microsoft Monitoring Agent et cliquez avec le bouton droit sur HealthService.exe pour vérifier Propriétés. Sous l’onglet Détails, le champ version du produit fournit le numéro de version de l’agent Log Analytics.
Si votre version de l’agent Log Analytics est antérieure à 10.20.18053 (bundle) et 1.0.18053.0 (extension), effectuez une mise à niveau vers la dernière version de l’agent Windows Log Analytics, en suivant ces instructions.
Remarque
Pendant le processus de mise à niveau, les planifications de gestion des mises à jour peuvent échouer. Veillez à ce faire lorsqu’il n’y a pas de planification planifiée.
Étapes suivantes
Avant d’activer et d’utiliser Update Management, consultez Planifier votre déploiement Update Management.
Consultez les questions fréquemment posées au sujet d’Update Management sur le forum aux questions Azure Automation.