Problèmes de mise à jour : Windows 11 24H2 et Windows Server 2025 ne reçoivent pas les correctifs via WSUS

Blocage massif des correctifs depuis avril 2025 : les éditions Windows 11 24H2 et Windows Server 2025 ignorent tout simplement les paquets envoyés par WSUS. Ce silence perturbe les cycles de maintenance, fait monter le risque d’attaque et pousse déjà plusieurs entreprises à geler leurs déploiements. Les premiers retours terrain pointent un conflit de registre apparu avec la nouvelle stratégie de «Dual Scan». L’enjeu est clair : rétablir au plus vite un canal de mise à jour fiable sans attendre un patch officiel de Microsoft.

Windows 11 24H2 et Windows Server 2025 coupés de WSUS : impact immédiat

Le problème se déclare aussitôt qu’un poste ou un serveur passe en version 24H2. Les machines remontent bien dans la console Windows Server Update Services, mais aucune mise à jour n’est téléchargée. Résultat : le tableau de bord sécurité clignote au rouge, tandis que les administrateurs voient s’accumuler les alertes CVE non corrigées.

Dans un groupe industriel français de cinq mille postes, le service IT a dû revenir en urgence sur un ancien snapshot Azure pour protéger les contrôleurs Active Directory. Même scénario chez un cabinet médical, où les correctifs antivirus dépendaient de Windows Update hors ligne via System Center. À chaque fois, la chaîne de conformité tombe et la direction exige une solution avant la revue d’audit mensuelle.

Ce blocage se révèle d’autant plus critique que Microsoft concentre ses bulletins de sécurité sur l’écosystème Windows. Sans WSUS, impossible de tester un patch en labo ni de contrôler la phase pilote. Les patchs cumulés deviennent un «Tout ou rien» où chaque redémarrage se fait à l’aveugle. Les DSI redoutent déjà le classique combo : perte de productivité, exposition accrue et surcoût de maintenance.

Origine du bug : nouvelles clés de registre et «Dual Scan» mal aiguillé

Le diagnostic est désormais clair : la version 24H2 introduit plusieurs valeurs, dont DeferFeatureUpdate, qui pilotent la cohabitation entre WSUS et Windows Update for Business. Quand ces clés restent à zéro, le client tente un double pointage. Cette logique fonctionne avec Intune ou ConfigMgr en mode co-management, mais provoque un court-circuit si la machine n’a qu’un serveur WSUS local.

L’analyse d’un administrateur allemand montre une requête HTTP vers la plate-forme cloud de Microsoft suivie d’un refus 0x8024500c, puis une tentative vers WSUS qui tourne en boucle. Chaque échec reporte la prochaine détection de vingt-quatre heures. Pendant ce laps de temps, la console marque simplement «Dernier contact : OK», masquant la panne réelle.

La décompilation des journaux PowerShell Get-WindowsUpdateLog révèle aussi que l’agent 24H2 cherche un catalogue nommé «Microsoft Server Operating System Version 24H2». Or, sur un serveur 2022, le catalogue porte encore l’ID d’ancienne génération. La correspondance échoue et le téléchargement s’interrompt.

Correctif express : script PowerShell et stratégie de groupe

Deux lignes suffisent pour débloquer la distribution. D’abord, supprimer les clés fautives :

Remove-ItemProperty -Path ‘HKLM:SOFTWAREMicrosoftWindowsUpdateUXSettings’ -Name DeferFeatureUpdate

Puis forcer la source WSUS :

Reg Add HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdate /v SetPolicyDrivenUpdateSourceForDriverUpdates /t REG_DWORD /d 1 /f

Une fois le script déployé via Intune ou une GPO classique, le client relance la détection, télécharge les paquets et applique le dernier cumulative update. Le service IT d’une PME brestoise a ramené ainsi quatre-vingts postes dans le green en moins d’une heure. La même méthode fonctionne côté serveur : un redémarrage et le correctif de mai 2025 se déploie sans heurt.

Pour éviter la récidive, plusieurs experts recommandent d’activer le mode TargetReleaseVersion. L’administrateur définit alors explicitement «24H2» comme seule version cible. Ce verrou bloque toute tentative de bascule vers le cloud et maintient la cohérence avec l’infrastructure WSUS existante.

Voies alternatives : Azure Update Management, Intune ou System Center

Face à l’incertitude, certaines organisations basculent déjà sur des plates-formes hybrides. Avec Azure Update Management, la VM déployée sur site ou dans le cloud reçoit les correctifs via un agent Log Analytics. L’outil offre un tableau bord élargi et un reporting en temps quasi réel. L’inconvénient reste la latence de catalogue : les correctifs sortent souvent vingt-quatre heures après WSUS.

ConfigMgr reste la référence pour les environnements qui veulent coupler inventaire matériel, déploiement applicatif et patch management. En mode «Cloud attach», il pousse les correctifs tout en donnant la main au service sécurité pour approuver ou refuser un KB. L’intégration avec Intune simplifie la gestion des postes distants et évite l’ouverture de ports VPN.

Enfin, certains DSI choisissent simplement de libérer le trafic direct vers Windows Update. Cette solution diminue la charge serveur, mais retire le contrôle granulaire. Dans un contexte réglementaire serré, elle n’est acceptable qu’avec un environnement Active Directory isolé et une stratégie de déploiement progressive via anneaux.

Perspectives : après l’abandon de WSUS, quelle feuille de route ?

Microsoft a confirmé la fin du développement actif de WSUS, tout en garantissant son support jusqu’en 2034. Cette posture laisse neuf ans pour migrer. Les retours d’expérience de la crise 24H2 rappellent qu’un basculement ne se limite pas à changer d’outil. Il faut revoir la gouvernance des correctifs, réécrire les procédures d’escalade et bâtir un laboratoire de test automatisé.

La tendance va vers une architecture mixte : Windows Update for Business pour les postes itinérants, System Center ou Azure pour les workloads serveurs, et un canal d’urgence géré par PowerShell pour les patchs hors bande. Le succès dépendra de la capacité des équipes à orchestrer ces flux multiples sans multiplier les exceptions.

Autre piste : le catalogue unifié prometteur annoncé lors d’Ignite 2025. Il combinera drivers, firmware et paquets de sécurité en un unique end-point API. Les premiers retours privés évoquent une intégration fluide avec Intune et un modèle de facturation au nombre de nœuds plutôt qu’au processeur. De quoi inciter même les plus prudents à planifier un pilote dès le prochain trimestre.

Au-delà de la technique, l’épisode 24H2 rappelle une évidence : sans mécanisme de repli robuste, chaque changement de version devient un pari. La priorité immédiate consiste à documenter le correctif de registre, mettre à jour les scripts et conserver un canal de surveillance hors bande. Un investissement modeste pour éviter une paralysie totale lors du prochain Patch Tuesday.

Source: borncity.com