Cet article fait partie de la série Migrer un millier de postes vers Windows 11 et Intune.
Une bascule WSUS vers Intune qui ne démarre pas
Le parc était mis à jour par WSUS, via une GPO de domaine. L’objectif : basculer vers Windows Update for Business, piloté par Intune, avec des anneaux de déploiement et un profil de mise à niveau vers Windows 11.
Pour le premier poste pilote, la démarche paraissait simple : exclure le poste de la GPO WSUS, l’ajouter à un anneau de mise à jour Intune, lui attribuer le profil de mise à niveau, et attendre.
Rien ne s’est passé.
Le poste ne proposait aucune mise à jour Windows Update for Business. Pas de mise à niveau vers Windows 11. Pas d’erreur explicite non plus : Windows Update cherchait des mises à jour… et n’en trouvait aucune.
Trois pistes : attribution, tenant et registre
L’exclusion de la GPO. Premier réflexe : vérifier que la GPO WSUS ne s’appliquait plus. Le poste était dans une mauvaise unité d’organisation, où une autre GPO prenait le relais. Déplacé, rapport de stratégie de groupe vérifié : la GPO WSUS ne s’appliquait plus. Toujours rien.
Le tenant. Nous avons aussi vérifié l’autorisation d’utiliser les données de diagnostic Windows dans Intune : elle était désactivée. Son activation n’a pas résolu le blocage. Il faut distinguer la télémétrie requise côté appareil de l’autorisation tenant utilisée pour les rapports : la documentation des profils de mise à niveau présente cette dernière comme un prérequis de reporting.
Le registre. C’est là que le problème est apparu. Le poste pointait toujours vers un serveur WSUS :
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' |
Select-Object WUServer, WUStatusServer
Les valeurs étaient bien là, et le serveur indiqué n’était même pas celui de la GPO : c’était un ancien serveur, arrêté depuis longtemps. Le poste interrogeait donc un serveur mort, ne recevait rien, et considérait qu’il n’y avait rien à installer.
Une stratégie locale restée après SCCM
Ces valeurs ne venaient d’aucune GPO de domaine. Elles venaient de la stratégie de groupe locale du poste, stockée dans un fichier que l’on oublie souvent :
Get-Item "$env:windir\System32\GroupPolicy\Machine\Registry.pol" |
Select-Object LastWriteTime
Dans notre investigation, ces paramètres ont été rattachés à l’ancien client Configuration Manager du poste, à l’époque où le parc était géré par SCCM. La date de Registry.pol est un indice de chronologie : elle ne prouve pas, seule, l’auteur ni le contenu de la stratégie. L’infrastructure SCCM avait disparu, mais la stratégie locale était restée.
Tant que la GPO WSUS du domaine s’appliquait, elle écrivait les mêmes clés de registre avec ses propres valeurs : le reste de SCCM était invisible, recouvert. Dès que le poste a été exclu de la GPO, les valeurs de la stratégie locale ont repris le dessus, avec l’adresse du vieux serveur.
Autrement dit : retirer la GPO WSUS ne faisait pas sortir le poste de WSUS, elle le renvoyait vers un WSUS encore plus ancien.
Nettoyer la source des réglages
Supprimer les valeurs du registre ne suffit pas : la stratégie locale est réappliquée à chaque actualisation des stratégies de groupe, et les valeurs reviennent. Il faut nettoyer à la fois le registre et la stratégie locale qui les réécrit.
Nous avons retenu une paire de scripts de remédiation Intune, attribuée à tous les postes qui basculent vers Windows Update for Business :
-
La détection vérifie la présence de valeurs WSUS (WUServer, WUStatusServer, et UseWUServer sous la clé AU) sur un poste censé ne plus en avoir.
-
La remédiation retire ces valeurs, nettoie les entrées correspondantes de la stratégie locale, et relance une détection Windows Update.
La clé à surveiller est celle-ci :
(Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' -ErrorAction SilentlyContinue).UseWUServer
# 1 = utilisation de WSUS configurée ; vérifier aussi les sources par catégorie
La présence de UseWUServer = 1 ne suffit pas à déduire la source de toutes les mises à jour. Des stratégies de source d’analyse peuvent répartir les mises à jour de fonctionnalités, de qualité, de pilotes et d’autres produits entre WSUS et Windows Update. Il faut aussi vérifier les paramètres effectifs de source et les éventuelles règles MDM concurrentes, comme l’explique la documentation Microsoft sur la coexistence WSUS et Windows Update.
Les scripts complets ne sont pas reproduits ici. Le nettoyage doit cibler les entrées WSUS identifiées, sans supprimer globalement Registry.pol, qui peut porter d’autres réglages locaux.
Après remédiation dans ce cas, le poste a contacté Windows Update, reçu les mises à jour de son anneau, puis commencé le téléchargement de Windows 11.
Cibler uniquement les postes réellement sortis de WSUS
Ce nettoyage n’a de sens que pour les postes réellement sortis de la GPO WSUS. Attribuée à un poste encore soumis à la GPO, la remédiation retirerait des valeurs que la GPO rétablirait à la prochaine actualisation : un combat sans fin, et des journaux pollués. L’attribution doit donc suivre exactement le groupe des postes exclus de WSUS, et rien d’autre.
Ce que ce pilote a changé
Inventorier les stratégies locales avant toute migration. Un parc qui a connu SCCM, des masters successifs ou des réglages manuels garde souvent des stratégies locales que personne ne surveille. Elles ne posent aucun problème tant qu’une GPO de domaine les recouvre, et ressurgissent le jour où on retire la GPO.
Tester sur un poste ancien, pas sur un poste neuf. Un poste neuf n’a pas d’historique : il aurait basculé sans problème, et le piège serait apparu en production, sur des centaines de postes à la fois.
Les premiers contrôles à réaliser
Sur un poste que vous pensez sorti de WSUS, deux premières vérifications sont utiles : la présence de la valeur UseWUServer à 1, et la date de dernière écriture du fichier Registry.pol de la stratégie locale. Un Registry.pol ancien sur un poste qui n’a jamais reçu de stratégie locale volontaire mérite toujours un coup d’œil.
Côté console, le rapport de stratégie de groupe (gpresult /h) indique la GPO à l’origine de chaque paramètre. Le rapport aide à identifier une origine de stratégie de groupe. L’absence de GPO de domaine ne suffit pas à conclure à la stratégie locale : MDM, scripts ou outils de gestion peuvent aussi écrire des réglages. Il faut confronter le rapport aux entrées de la stratégie locale et aux sources d’administration présentes.
Le rapport standard des anneaux Intune n’est pas un inventaire de ces clés de registre. Une détection ou une collecte ciblée permet d’en remonter l’état à l’échelle du parc ; le diagnostic n’est donc pas nécessairement limité à une vérification manuelle poste par poste.
Vous préparez une bascule de WSUS vers Windows Update for Business ? AuditMS donne un état de l’inscription, de la conformité et du chiffrement du parc Intune, en lecture seule. Le diagnostic des stratégies locales WSUS décrit ici reste un contrôle complémentaire sur les postes. Lancer un audit sur auditms.fr