Hotpatch et mise à jour des clusters sous Windows Server

Les serveurs prennent du retard sur les correctifs pour une raison principale : les redémarrer a un coût. Un redémarrage mensuel d'une base de données, d'un serveur de fichiers ou d'une application métier nécessite une fenêtre, un responsable et un plan de retour arrière, et chaque mois quelqu'un a une bonne raison de s'en dispenser. Le guide pilier sur les correctifs fixe des objectifs pour les serveurs ; ce guide couvre les deux fonctionnalités de Windows Server qui rendent ces objectifs réalistes en réduisant ou en masquant les interruptions : le hotpatch et la mise à jour adaptée aux clusters (CAU, Cluster-Aware Updating).

Comment fonctionne le hotpatch

Un hotpatch met à jour le code en mémoire des processus en cours d'exécution, et sur disque pour le prochain démarrage, sans redémarrage. Microsoft publie les hotpatchs selon un cycle trimestriel :

Un serveur corrigé par hotpatch est entièrement à jour sur le plan de la sécurité ; il n'est pas mis à jour « partiellement ». La contrepartie est que les correctifs non liés à la sécurité attendent la baseline suivante, et que tout ce qui sort de la mise à jour cumulative de l'OS (pilotes, micrologiciel, .NET, logiciels tiers) suit toujours son processus habituel et peut redémarrer le serveur.

Étape 1 : vérifier l'éligibilité

Le hotpatch dépend de l'édition, de l'emplacement et des fonctionnalités de sécurité :

• Windows Server 2022 ou 2025 Datacenter: Azure Edition sur des VM Azure ou sur Azure Local. Le hotpatch est inclus et géré via Azure Update Manager.
• Windows Server 2025 Standard ou Datacenter (build 26100.1742 ou ultérieur, Expérience utilisateur ou Server Core) sur des machines physiques ou virtuelles hors d'Azure, connectées à Azure Arc, avec le hotpatch activé sur la ressource Arc. Depuis mai 2026, cela n'entraîne aucun surcoût ; auparavant, il s'agissait d'un abonnement payant par cœur.
• La sécurité basée sur la virtualisation (VBS) doit être active : la machine doit donc disposer d'UEFI avec Secure Boot (sous Hyper-V, une VM de génération 2). Le hotpatch s'appuie sur VBS pour protéger le processus de correction, ce qui en fait aussi un bon complément de VBS et intégrité de la mémoire.
• Le serveur doit être sur la baseline courante ; une machine qui manque une baseline ne peut pas recevoir les hotpatchs suivants et revient aux mises à jour cumulatives complètes jusqu'à ce qu'elle rattrape son retard.

Windows 11 Entreprise 24H2 et versions ultérieures peuvent aussi recevoir des hotpatchs via Windows Autopatch dans Intune. Ce programme client a ses propres prérequis de licence et d'appareil, distincts du modèle serveur décrit ici.

Vérifiez VBS sur un serveur candidat :

Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning
# VirtualizationBasedSecurityStatus = 2 signifie que VBS est actif

Si VBS est désactivé, activez-le via Computer Configuration > Policies > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security, testez la charge de travail (certains pilotes anciens et outils dépendant de l'hyperviseur s'y opposent), puis redémarrez.

Étape 2 : inscrire les serveurs

VM Azure avec Azure Edition : choisissez une image compatible hotpatch et, dans les paramètres de correctifs de la VM, utilisez l'application de correctifs orchestrée par Azure avec le hotpatch activé. Azure Update Manager planifie alors pour vous les baselines et les hotpatchs.

Windows Server 2025 connecté à Arc : intégrez la machine à Azure Arc avec l'agent Connected Machine, puis, dans le portail Azure, allez dans Azure Arc > Machines, ouvrez la machine, sélectionnez Hotpatch puis Confirm. La modification s'applique en une dizaine de minutes (le portail vérifie que VBS est actif et échoue dans le cas contraire). Le serveur reçoit ensuite les hotpatchs à partir du prochain mois de hotpatch, à condition d'être sur la baseline courante. Utilisez Azure Update Manager ou votre outil existant pour planifier les redémarrages de baseline.

L'intégration à Arc donne une identité Azure à un serveur sur site. Traitez le principal de service d'intégration et les autorisations sur les ressources Arc comme des accès privilégiés : un rôle capable d'exécuter des commandes ou d'installer des extensions sur des machines Arc est de fait administrateur de ces serveurs. Délimitez le RBAC Azure avec le même soin que votre tiering d'administration, et n'intégrez jamais de contrôleurs de domaine dans un abonnement géré par des administrateurs de tier inférieur.

Étape 3 : organiser le calendrier des correctifs autour des baselines

Avec le hotpatch, le plan mensuel change de forme :

• Mois de baseline : le même processus qu'aujourd'hui. Groupes de correctifs, fenêtres de maintenance, responsables applicatifs d'astreinte. Planifiez ces fenêtres un an à l'avance, puisque les mois sont fixes.
• Mois de hotpatch : installez dans les jours qui suivent le Patch Tuesday, sur tous les serveurs éligibles à la fois si vos tests le permettent, puisqu'il n'y a aucun redémarrage à coordonner. Gardez un petit groupe pilote avec un ou deux jours d'avance.
• Baselines non planifiées : maintenez une procédure permanente de fenêtre d'urgence, pour qu'une baseline hors cycle n'attende pas le trimestre suivant.

Distinguez dans vos rapports les serveurs inscrits au hotpatch des autres. Un serveur sorti silencieusement du circuit hotpatch, qui a désormais besoin d'un redémarrage chaque mois, passe facilement inaperçu.

Étape 4 : mise à jour adaptée aux clusters pour les rôles en cluster

Pour les clusters de basculement (hôtes Hyper-V, serveurs de fichiers, instances de cluster de basculement SQL Server), CAU automatise le schéma par roulement : vider un nœud, déplacer ses rôles, installer les mises à jour, redémarrer, reprendre, passer au nœud suivant. CAU fonctionne avec ou sans hotpatch et fait partie de la fonctionnalité Clustering de basculement (module ClusterAwareUpdating).

Vérifiez d'abord que tout est prêt, puis ajoutez le rôle en cluster CAU en mode de mise à jour automatique :

Test-CauSetup -ClusterName FS-CLU01

Add-CauClusterRole -ClusterName FS-CLU01 `
  -DaysOfWeek Tuesday -WeeksOfMonth 3 `
  -MaxFailedNodes 0 -MaxRetriesPerNode 2 -RequireAllNodesOnline `
  -EnableFirewallRules -Force

Paramètres clés :

• -RequireAllNodesOnline refuse de démarrer si un nœud est déjà arrêté, de sorte qu'une exécution de mise à jour ne dégrade jamais davantage un cluster déjà dégradé.
• -MaxFailedNodes 0 arrête l'exécution au premier nœud en échec au lieu de continuer.
• -PreUpdateScript et -PostUpdateScript exécutent vos propres contrôles, par exemple pour confirmer qu'un groupe de disponibilité SQL est sain avant de passer au nœud suivant.
• Le plug-in par défaut, Microsoft.WindowsUpdatePlugin, utilise l'agent Windows Update et la source configurée sur les nœuds (Windows Update, WSUS). Microsoft.HotfixPlugin installe des paquets depuis un partage de fichiers que vous contrôlez.

Pour une exécution ponctuelle à la demande, depuis une machine d'administration plutôt que depuis un nœud du cluster :

Invoke-CauScan -ClusterName FS-CLU01 -CauPluginName Microsoft.WindowsUpdatePlugin
Invoke-CauRun  -ClusterName FS-CLU01 -CauPluginName Microsoft.WindowsUpdatePlugin `
  -MaxFailedNodes 0 -RequireAllNodesOnline -Force

L'objet ordinateur CAU et le compte qui exécute le mode de mise à jour à distance disposent d'un accès administrateur à chaque nœud. Placez le cluster et sa machine d'administration dans le bon tier, et limitez les règles de pare-feu de CAU au réseau d'administration (voir durcissement du pare-feu Windows).

Les clusters Azure Local utilisent leur propre gestionnaire de cycle de vie pour les mises à jour de l'OS, des pilotes et du micrologiciel ; suivez ce processus sur ces clusters plutôt que de configurer CAU directement.

Étape 5 : maintenir à jour le reste du serveur

Le hotpatch et CAU gèrent la mise à jour cumulative de l'OS. Les autres couches ont toujours besoin de leur propre processus :

• Micrologiciel et pilotes : outils constructeur (par exemple la suite de mise à jour du fabricant du serveur) au rythme des mois de baseline, pour que leurs redémarrages coïncident avec celui que vous avez déjà. Sur les serveurs protégés par BitLocker, la protection peut devoir être suspendue le temps d'un redémarrage.
• .NET et autres produits Microsoft : autorisez Microsoft Update dans votre source de mises à jour ; les mises à jour .NET nécessitent généralement un redémarrage des applications qui l'utilisent, parfois du serveur.
• Rôles serveur et applications : les mises à jour cumulatives de SQL Server, Exchange, les modules IIS et les agents tiers suivent le calendrier de leurs éditeurs. Alignez-les autant que possible sur les mois de baseline.
• Hôtes Hyper-V : les invités ne profitent du hotpatch que si leur OS est éligible ; le redémarrage de l'hôte déplace ou suspend toujours les VM, et c'est là que CAU est utile.

L'objectif est un seul redémarrage planifié par trimestre qui absorbe tout, plutôt que plusieurs redémarrages imprévus.

Vérifier

Sur un serveur, vérifiez la révision du build et l'historique des mises à jour :

$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
'{0}.{1}' -f $cv.CurrentBuild, $cv.UBR
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, Description, InstalledOn
(Get-CimInstance Win32_OperatingSystem).LastBootUpTime

Un serveur corrigé par hotpatch affiche une nouvelle révision de build tandis que LastBootUpTime reste à la dernière baseline. Comparez la révision avec celle indiquée dans les notes de publication Microsoft pour le hotpatch du mois. Les résultats d'installation figurent dans le journal System, source Microsoft-Windows-WindowsUpdateClient (événement 19 succès, 20 échec). Dans Azure Update Manager, l'historique des mises à jour de la machine distingue les installations hotpatch et baseline.

Pour CAU, examinez la dernière exécution et les journaux d'événements :

Get-CauReport -ClusterName FS-CLU01 -Last -Detailed
Get-WinEvent -LogName 'Microsoft-Windows-ClusterAwareUpdating/Admin' -MaxEvents 20

Ce qui casse

• VBS désactivé par un pilote ou une modification du BIOS. Le serveur cesse discrètement d'être éligible au hotpatch. Surveillez VirtualizationBasedSecurityStatus.
• Baseline manquée. Un serveur qui saute le redémarrage trimestriel revient aux mises à jour cumulatives complètes. Considérez les fenêtres de baseline comme obligatoires.
• Installations manuelles de mises à jour cumulatives. Installer un paquet autonome hors séquence peut faire sortir une machine du circuit hotpatch ; laissez l'outil d'orchestration installer les mises à jour.
• Des exécutions CAU qui se bloquent sur un nœud qui refuse de se vider, souvent à cause d'un rôle avec des propriétaires préférés ou d'une VM incapable de migrer à chaud. Corrigez le problème de santé du cluster ; n'augmentez pas MaxFailedNodes.
• Des clusters corrigés à la fois par CAU et par un autre outil. Deux orchestrateurs redémarrent les nœuds indépendamment et peuvent faire perdre le quorum. Excluez les nœuds de cluster des stratégies d'anneaux de type client, comme les stratégies Windows Update.

Liste de contrôle

• Parc de serveurs classé : Azure Edition, 2025 connecté à Arc, non éligible
• VBS actif et surveillé sur les candidats au hotpatch
• Identité d'intégration Arc et RBAC délimités comme des accès privilégiés
• Fenêtres de baseline planifiées en janvier, avril, juillet et octobre
• Mois de hotpatch installés en quelques jours, groupe pilote en premier
• Clusters mis à jour par CAU avec RequireAllNodesOnline et MaxFailedNodes 0
• Scripts de contrôle de santé avant et après mise à jour pour les rôles en cluster critiques
• Rapports distinguant les serveurs en hotpatch, en baseline uniquement et non conformes

Le hotpatch et CAU lèvent l'objection du redémarrage pour la plupart des serveurs. Le reste du processus, des anneaux aux logiciels tiers, se trouve dans le domaine correctifs et mises à jour.