Azure Update Manager : diagnostiquer une fenêtre de maintenance avant de forcer le patching

La fenêtre de maintenance est terminée, mais une partie des machines reste non conforme. Certaines VM affichent des correctifs installés, d’autres n’ont aucun historique récent, et quelques serveurs attendent un redémarrage. L’urgence pousse souvent à lancer une installation ponctuelle sur toute la flotte. Cette relance peut pourtant patcher des machines qui n’étaient pas dans le scope, dépasser la fenêtre métier ou masquer un problème de ciblage.

Le cas d’usage couvre des VM Azure et des serveurs Azure Arc associés à une Maintenance Configuration Azure Update Manager, directement ou par scope dynamique. L’objectif est de décider si la campagne doit reprendre sur un lot borné, attendre la prochaine fenêtre, être corrigée dans sa configuration ou être arrêtée au profit d’un rollback applicatif.

Figer le contrat de la fenêtre

Conservez la configuration qui devait s’appliquer, pas seulement l’état visible après l’incident. Une fenêtre de patching relie un horaire, un fuseau, une durée, des classifications, une politique de reboot et une population de machines.

maintenance_configuration: mc-prod-linux-weekly
window:
start_utc: 2026-09-01T01:00:00Z
duration: PT2H
expected_end_utc: 2026-09-01T03:00:00Z

selection:
assignment: dynamic_scope
filters:
  resource_groups: [rg-app-prod]
  os_types: [Linux]
  tags:
    patch_ring: ring-2
    environment: production

updates:
classifications: [Critical, Security]
reboot_setting: IfRequired

evidence:
- maintenance configuration version
- assignment and dynamic-scope filters
- machine inventory at window start
- update assessment before the window
- installation and maintenance run IDs
- application health before and after

Cette capture évite de comparer les résultats avec une configuration modifiée après coup. Elle rend aussi explicite le temps réellement disponible : Update Manager réserve une partie de la fenêtre aux opérations de fin et au reboot. Une campagne peut donc s’arrêter proprement avant d’avoir installé tous les correctifs sélectionnés.

Reconstruire la population réellement ciblée

Le preview d’un scope dynamique n’est pas une preuve de la population exécutée. L’appartenance est réévaluée : une machine créée, déplacée ou retaguée entre la préparation et la fenêtre peut entrer ou sortir du scope.

Construisez trois ensembles :

• les machines attendues selon l’inventaire de changement ;
• les machines qui correspondent aux filtres au moment du diagnostic ;
• les machines qui possèdent un run de maintenance ou d’installation pour la fenêtre.

Toute différence doit être expliquée avant la relance. Vérifiez les tags avec leur casse réelle, le resource group, l’OS, l’association à la Maintenance Configuration et le niveau auquel le scope dynamique a été créé. Une affectation au niveau d’un resource group ne sélectionne pas des machines situées ailleurs, même dans la même subscription.

Confirmez aussi que les VM Azure utilisent une orchestration compatible avec les Customer Managed Schedules. Une machine visible dans l’inventaire mais non consentie pour ce mode n’est pas équivalente à une machine patchée puis en échec.

Séparer absence de run, arrêt de fenêtre et échec

Ne regroupez pas toutes les machines non conformes sous le statut « patching failed ». Chaque famille appelle une action différente.

Aucun run de maintenance
Vérifier assignment, scope dynamique, horaire, fuseau et orchestration

Run créé, aucune installation
Vérifier assessment, classifications, exclusions et correctifs applicables

Installation partielle sans erreur de package
Vérifier le temps restant dans la fenêtre et la réserve de reboot

Un ou plusieurs correctifs en échec
Lire le résultat par patch et les journaux du gestionnaire de paquets

Installation réussie, machine encore non conforme
Relancer une assessment et vérifier remplacement ou supersedence

Reboot requis ou santé applicative dégradée
Ne pas forcer un nouveau lot ; qualifier le retour en service

Un statut global Succeeded ne signifie pas que toutes les machines attendues ont été ciblées. Inversement, un run incomplet peut refléter une protection de fenêtre plutôt qu’un défaut du moteur de patch.

Lire les résultats dans Azure Resource Graph

Azure Update Manager publie les résultats d’assessment et d’installation dans Azure Resource Graph. Utilisez les identifiants de run et de machine pour reconstruire la campagne, plutôt qu’un simple compteur de conformité.

let WindowStart = datetime(2026-09-01T00:30:00Z);
let WindowEnd = datetime(2026-09-01T03:30:00Z);
patchinstallationresources
| where type !has "softwarepatches"
| extend p = parse_json(properties)
| extend LastModified = todatetime(p.lastModifiedDateTime),
       Machine = tostring(split(id, "/", 8)),
       ResourceGroup = tostring(split(id, "/", 4)),
       Status = tostring(p.status),
       Installed = toint(p.installedPatchCount),
       Failed = toint(p.failedPatchCount),
       Pending = toint(p.pendingPatchCount),
       Excluded = toint(p.excludedPatchCount),
       RebootStatus = tostring(p.rebootStatus)
| where LastModified between (WindowStart .. WindowEnd)
| project LastModified, name, Machine, ResourceGroup,
        Status, Installed, Failed, Pending, Excluded, RebootStatus
| order by LastModified asc

Cette requête montre uniquement les machines qui ont produit un résultat d’installation. Comparez-la à l’inventaire attendu. Pour une machine absente, recherchez aussi les enregistrements microsoft.maintenance/applyupdates dans maintenanceresources afin de savoir si la Maintenance Configuration a lancé une opération sans résultat d’installation exploitable.

Conservez le détail par correctif pour les machines en échec. Le nom du package, sa classification et son installationState permettent de séparer dépôt indisponible, dépendance, conflit, exclusion et reboot en attente.

Valider la machine et le service avant toute reprise

Le contrôle Azure n’est qu’une partie de la preuve. Sur un canari de chaque famille, vérifiez l’heure, l’espace disque, le gestionnaire de paquets, les services en échec et le besoin de reboot. Pour Azure Arc, ajoutez l’état de connexion et de l’agent.

La validation applicative doit rester indépendante du statut de patching :

• health probe et taux d’erreur ;
• capacité disponible et répartition des instances ;
• connexion aux dépendances ;
• version du noyau ou du composant réellement chargée après reboot ;
• possibilité de retirer une instance du trafic avant intervention.

Une machine « conforme » mais sortie du load balancer n’est pas un succès de campagne. Une machine avec un correctif en attente peut rester saine jusqu’à une fenêtre mieux préparée.

Choisir une reprise bornée

Ne relancez pas la Maintenance Configuration complète pour corriger trois machines. Formez un lot explicite à partir des résultats, puis appliquez une décision par famille.

decisions:
resume_bounded:
  when:
    - affected machines are explicitly listed
    - application redundancy is proven
    - a new approved window exists
    - reboot and stop conditions are defined

wait_next_window:
  when:
    - patches remain pending without emergency exposure
    - current service health is stable
    - dynamic scope and orchestration are corrected

stop_and_repair:
  when:
    - target membership is unexplained
    - package or Arc connectivity failures repeat
    - maintenance evidence is incomplete

rollback_service:
  when:
    - post-patch health degrades
    - safe OS patch removal is not proven
    - traffic can return to a known-good instance or image

stop_conditions:
- error rate exceeds the approved threshold
- healthy capacity drops below quorum
- an unexpected machine enters the batch
- reboot exceeds the machine budget
- run IDs cannot be correlated

Un rollback de patch OS n’est pas une primitive universelle. Certains packages peuvent être désinstallés, d’autres non ; un kernel précédent peut rester disponible, mais ce n’est pas une stratégie à improviser. Le chemin le plus fiable est souvent applicatif : drainer l’instance, restaurer une image connue, rétablir la capacité ou basculer le trafic pendant que la machine est réparée.

Corriger le prochain passage sans effacer les preuves

Après stabilisation, corrigez la cause au bon niveau : filtre du scope dynamique, association, orchestration, classifications, durée de fenêtre, politique de reboot ou prérequis du système. Rejouez d’abord une assessment, puis un lot canari capable de terminer installation, reboot et validation dans le budget.

Gardez les run IDs, résultats Resource Graph, versions de configuration et contrôles applicatifs avec le changement. La conformité finale doit converger avec la population attendue et la santé du service, pas seulement avec un pourcentage dans le portail.

Conclusion

Une campagne Azure Update Manager incomplète ne justifie pas une relance globale. Il faut reconstruire le scope réellement exécuté, distinguer absence de run, fenêtre épuisée, échec de patch et reboot en attente, puis valider la capacité applicative.

La décision devient défendable : reprendre un lot explicitement borné, attendre la prochaine fenêtre, réparer la configuration ou revenir à une capacité connue. Tant que la population ciblée ou le chemin de retour restent ambigus, ne forcez pas le patching hors fenêtre.