Windows Autopatch, anneaux et Hotpatch : construire une stratégie de mise à jour moderne

Résumé

Windows Autopatch s’intègre à Intune pour gérer les politiques de mises à jour qualité, accélérées, fonctionnalités et pilotes. Les groupes Autopatch organisent plusieurs anneaux et leurs affectations ; les politiques directes offrent le même socle fonctionnel avec davantage de gestion manuelle.

Hotpatch distribue certains correctifs de sécurité sans redémarrage immédiat entre des mises à jour cumulatives de baseline. Le poste doit rester éligible : licence, version Windows, build minimale, VBS et baseline courante font partie des contrôles à maintenir.

Je distingue toujours l’autorité de politique, la source de scan, l’approbation du contenu et l’état d’installation. En co-management, une source WSUS persistante peut contredire la stratégie cloud même si les profils Intune existent.

Windows Autopatch s’intègre à Intune pour gérer les politiques de mises à jour qualité, accélérées, fonctionnalités et pilotes. Les groupes Autopatch organisent plusieurs anneaux et leurs affectations ; les politiques directes offrent le même socle fonctionnel avec davantage de gestion manuelle.

Contexte, objectif et périmètre

Windows Update for Business a évolué d’un ensemble d’anneaux vers un plan de gestion comprenant policies par type de contenu, rapports, safeguards, Autopatch, pilotes et Hotpatch.

L’objectif n’est pas de supprimer les tests, mais d’organiser une progression mesurable. Les deadlines, pauses et rollbacks sont des contrôles opérationnels, pas des solutions à une architecture de ciblage incohérente.

Je traite « Autopatch, anneaux et Hotpatch » comme une chaîne de preuves et non comme une succession de boutons à cliquer. Une action n’est considérée comme réussie que lorsque le résultat est visible au niveau attendu : configuration du service, état reçu par le poste, traitement local, puis remontée cohérente dans les outils d’administration. Cette séparation évite de confondre une affectation valide avec une exécution terminée.

Je conserve systématiquement les heures en UTC et en heure locale, l’identité de l’appareil, le contexte utilisateur ou système, la version de Windows et la version des composants concernés. Sans ces repères, deux événements semblables peuvent appartenir à des cycles différents. Les exemples de journaux sont anonymisés et les identifiants techniques doivent l’être avant tout partage.

Pour expliquer la technologie, je sépare le plan de contrôle, le transport, les composants locaux et les données de résultat. Cette lecture évite d’attribuer au portail une décision prise par Windows, ou à un agent local une limitation qui appartient en réalité au service cloud, à la licence ou au modèle d’affectation.

Les détails internes observés dans les journaux ou le registre servent à établir une hypothèse de diagnostic. Ils ne deviennent pas pour autant une interface publique stable. Toute automatisation durable doit s’appuyer sur une API ou une configuration officiellement supportée, puis être revalidée quand la version du service ou du client change.

• Objectif : expliquer le rôle d’Autopatch et des politiques
• Objectif : concevoir des anneaux représentatifs
• Objectif : qualifier et surveiller Hotpatch
• Périmètre : Windows 11 géré par Intune/Autopatch
• Périmètre : qualité, fonctionnalités, pilotes et Hotpatch
• Périmètre : co-management et source de scan

Architecture et fonctionnement général

Lorsqu’un device est ciblé par une policy, il est inscrit auprès du service de déploiement Autopatch pour le type de contenu concerné. Il ne s’agit plus d’un enregistrement global unique : la relation dépend du contenu et de l’affectation.

Les groupes Autopatch créent et associent les groupes Entra et politiques nécessaires aux anneaux. Une modification doit être faite via le flux du groupe pour conserver la cohérence, plutôt qu’en éditant isolément un profil généré.

Hotpatch reste intégré aux mises à jour qualité. Les mois de baseline utilisent une mise à jour cumulative avec redémarrage ; les autres publications Hotpatch réduisent le nombre de redémarrages lorsque l’appareil demeure éligible.

Prérequis techniques et préparation

Avant toute mise en œuvre, je fige le périmètre de test et je capture l’état initial. Cette photographie comprend les versions, les affectations, les autorités de gestion, les dépendances et les exceptions connues. Elle sert autant à interpréter le résultat qu’à construire le retour arrière.

Je vérifie les prérequis sur un appareil réellement représentatif. Une console qui autorise la création d’un profil ne prouve ni l’éligibilité du poste, ni la disponibilité effective de la fonctionnalité dans le tenant. Les prérequis réseau, licence, identité et système doivent tous être confirmés.

• licences Autopatch/Windows éligibles
• Entra join ou hybrid join supporté
• Intune et télémétrie Windows Update opérationnels
• groupes d’audience stables
• VBS et baseline courante pour Hotpatch
• source de scan cloud confirmée

Procédure de mise en œuvre

La procédure suivante est volontairement découpée en points de contrôle. Je ne poursuis pas lorsqu’un résultat attendu manque : continuer masquerait la première divergence et produirait des symptômes secondaires plus difficiles à interpréter.

Les noms de groupes, profils, applications et fichiers sont des exemples. Je les remplace par les conventions de l’organisation, je documente la population ciblée et je conserve une preuve avant/après pour chaque changement.

Anneaux, deadlines et qualité de l’échantillon

Un anneau pilote composé uniquement de techniciens récents ne représente pas les appareils métier, les modèles anciens ou les réseaux lents. Je construis un échantillon couvrant matériels, applications critiques, sites et profils d’usage.

La deadline définit le moment où l’installation devient obligatoire ; elle ne remplace pas le délai entre anneaux. Je calcule la durée complète afin que les derniers appareils restent dans la fenêtre de sécurité acceptée.

Une pause bloque la progression pendant l’analyse. Un rollback de feature ou qualité dépend des capacités Windows et de la fenêtre disponible ; il doit être testé avant l’incident.

Éligibilité et cadence Hotpatch

L’éligibilité Hotpatch dépend du canal supporté, de la licence, de Windows 11, de la baseline courante et des prérequis matériels/sécurité documentés. Microsoft fait évoluer cette liste ; je la recalcule à chaque baseline.

Un poste temporairement inéligible peut recevoir la mise à jour de sécurité standard. Le rapport doit distinguer protection atteinte et méthode utilisée afin de ne pas classer automatiquement le fallback comme échec de sécurité.

Les événements contenant Hotpatch et les versions de build permettent la preuve locale. Les mois de baseline restent essentiels : manquer la baseline peut empêcher les hotpatchs suivants.

Co-management et source de scan

Le workload Windows Update doit être cohérent avec les paramètres clients Configuration Manager et les GPO. Dual Scan est un modèle historique ; la source de scan actuelle doit être vérifiée explicitement.

Je contrôle qui configure qualité, fonctionnalités, pilotes et Office séparément. Une seule phrase comme ‘géré par Autopatch’ masque ces autorités distinctes.

Le rollback d’une migration rétablit les politiques et la source de scan précédente. Reculer uniquement le curseur de workload laisse parfois le client dans un état hybride.

Scripts, commandes et exemples de lecture

Les commandes présentées servent à observer ou illustrer le fonctionnement. Les scripts de diagnostic restent de niveau 1, avec arrêt sur erreur et gestion globale de l’exception. Ils ne modifient pas le poste. Une remédiation serait au minimum de niveau 2, avec mode de simulation, journalisation adaptée au test et comportement de rollback explicitement validé.

Je lis toujours la sortie avec le contexte d’exécution. Une commande lancée dans la session de l’utilisateur ne voit pas nécessairement les mêmes certificats, chemins, variables, applications ou ruches de registre qu’un processus exécuté par l’Intune Management Extension sous SYSTEM.

# Exemple pédagogique de lecture
Get-Service usosvc,wuauserv,bits | Select-Object Name,Status,StartType
Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 40 | Select-Object TimeCreated,Id,LevelDisplayName,Message

Validation et critères de contrôle

Je valide d’abord le résultat technique sur le poste, puis sa remontée dans le service. Le portail peut conserver un état ancien pendant un certain temps ; inversement, un état vert dans la console ne dispense pas de contrôler l’artefact local réellement attendu.

Le critère GO exige un résultat reproductible, une absence de régression sur les fonctions voisines, une documentation à jour et un retour arrière démontré. Le critère NO-GO s’applique dès qu’une dépendance n’est pas maîtrisée, qu’une partie du parc réagit différemment ou que l’état final ne peut pas être prouvé.

• autorité et source cohérentes
• anneaux représentatifs
• policy par contenu connue
• Hotpatch éligibilité prouvée
• rapports opérationnels
• pause et rollback testés

Journaux, diagnostic et constitution des preuves

Je combine les rapports Windows Update dans Intune, le statut de policy, les événements WindowsUpdateClient et les données de build. Pour Hotpatch, je recherche aussi les événements et le KB correspondant à la publication.

Une absence de mise à jour peut signifier non-éligibilité, safeguard hold, pause, contenu non approuvé, scan vers WSUS, deadline future ou erreur client. Le diagnostic doit identifier la branche exacte.

• affectation et inscription par type de contenu
• source de scan réelle
• build et KB installés
• éligibilité Hotpatch
• WindowsUpdateClient/Operational
• rapports Autopatch et safeguards

Dépannage : symptômes, preuves et corrections

Je pars de la colonne Symptôme, mais je ne choisis jamais une correction sur ce seul indice. La colonne Preuve indique l’élément qui doit confirmer la cause. Si cette preuve manque, l’hypothèse reste ouverte et l’action proposée ne doit pas être appliquée comme une recette automatique.

Après correction, je reproduis le scénario initial et je compare les mêmes points de mesure. Un changement de symptôme n’est pas toujours une résolution : il peut simplement indiquer que le traitement progresse jusqu’à une nouvelle phase. La chronologie complète reste donc la référence.

Retour arrière et points de vigilance

Le retour arrière ne consiste pas seulement à retirer une affectation. Je restaure l’autorité précédente, la configuration ou la version attendue, puis je vérifie que le poste a effectivement reçu et appliqué ce nouvel état. Les caches et délais de remontée sont documentés au lieu d’être interprétés comme une absence de rollback.

Je conserve les preuves du pilote, le motif de la décision et les écarts rencontrés. Si le service cloud ou une interface évolue, je réévalue les étapes avant une nouvelle vague. Aucun succès obtenu uniquement sur le poste de développement ne constitue une validation de production.

• Rollback : retirer policy Hotpatch pilote
• Rollback : restaurer groupes et policies précédents
• Rollback : réaligner source de scan en co-management
• Vigilance : ne pas confondre moins de redémarrages et absence de baseline
• Vigilance : ne pas modifier directement les policies d’un groupe Autopatch sans vérifier le flux
• Vigilance : revalider les prérequis Microsoft