Knowledge · Windows Update · ConfigMgr · Intune

KB36495448 : remettre à niveau la scan source policy Windows Update après ConfigMgr 2503/2509

Un seul script, auto-correctif, pour Intune Remédiations et pour ConfigMgr.

Le hotfix KB36495448 empêche le client Configuration Manager 2503 et 2509 de laisser des clés de scan source incomplètes sur les postes cogérés, et nettoie celles qui existent. Il ne pose aucune configuration à leur place. Cet article donne la configuration cible, le comportement observé sur Windows 11 — qui n'est pas celui que décrit la documentation — et un script qui audite le poste, le corrige s'il s'écarte, et le dit.

Windows UpdateConfigMgrIntunePowerShell

Publié le 5 octobre 2026 · sources relues le 5 octobre 2026

La configuration cible Lire le script

5 valeursposées ensemble, jamais une à une

2 types de posteavec ou sans Windows Update for Business

PowerShell 5.1+Windows 10 2004 et ultérieur, Windows 11

1 scriptil analyse, il corrige, il rapporte

Le constat

Des mises à jour Windows qui arrivent d'ailleurs que prévu.

Sur un parc cogéré (Intune et Configuration Manager) où Windows Update for Business (WUfB) pilote les mises à jour de Windows et où ConfigMgr ne pilote que les mises à jour tierces, certains postes reçoivent leurs mises à jour de fonctionnalités et de qualité par WSUS, sans que personne l'ait décidé.

C'est le signe d'une configuration de « scan source » incomplète. La source d'où chaque catégorie de mises à jour est cherchée — WSUS ou Windows Update — se décrit par cinq valeurs de registre qui doivent exister ensemble. Le client Configuration Manager 2503 et 2509 en laissait deux sur cinq.

L'origine

Deux clés sur cinq.

Dans Configuration Manager 2503 (avec le rollup 32851084) et 2509, quand les mises à jour tierces sont activées sur un poste cogéré, le client ne positionne que deux valeurs de scan source. Les trois autres sont absentes, et supprimées si elles existaient.

Valeur	Posée par le client	État laissé sur le poste
`AU\UseUpdateClassPolicySource`	Oui, à 1	Interrupteur maître actif
`SetPolicyDrivenUpdateSourceForOtherUpdates`	Oui, à 1	Active
`SetPolicyDrivenUpdateSourceForFeatureUpdates`	Non — supprimée si elle existait	Absente
`SetPolicyDrivenUpdateSourceForQualityUpdates`	Non — supprimée si elle existait	Absente
`SetPolicyDrivenUpdateSourceForDriverUpdates`	Non — supprimée si elle existait	Absente

Sous HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate, sauf l'interrupteur maître, qui est dans le sous-dossier AU.

Quand seules certaines classes sont présentes, l'agent Windows Update peut supposer que toutes les catégories suivent la même source. Les mises à jour de fonctionnalités et de qualité destinées à Intune ou à WUfB partent alors vers WSUS et ConfigMgr, alors que l'environnement était configuré pour les en tenir à l'écart.

Ce que le hotfix fait, et ce qu'il laisse

Le client ne pose plus ni ne modifie UseUpdateClassPolicySource ni les quatre SetPolicyDrivenUpdateSourceFor* sur un poste cogéré.
Les états partiels laissés par les versions précédentes sont nettoyés une fois.
Il ne pose rien à la place. Microsoft indique que la source de scan est désormais l'affaire de l'administrateur, par stratégie de groupe ou par la stratégie CSP de Windows Update for Business.

Pourquoi cela ne suffit pas

Après ce nettoyage, plus aucune clé de scan source ne subsiste. Le poste est alors dans le cas où la documentation et le comportement réel divergent le plus : la section suivante le mesure.

Ce que la documentation ne dit pas

Le double scan n'est pas mort sur Windows 11.

Une fois les clés nettoyées, un poste avec WSUS configuré et sans scan source policy se retrouve dans le cas que la documentation Microsoft décrit le moins bien. Elle indique que le double scan (« dual scan », la stratégie Do not allow update deferral policies to cause scans against Windows Update) n'est plus pris en charge sur Windows 11.

Plutôt que de trancher sur la seule lecture de la documentation, le comportement a été vérifié par un test contrôlé, en isolant une seule variable.

Le protocole

Un poste Windows 11 de laboratoire, non cogéré : le mécanisme de l'OS est testé seul, sans ConfigMgr.
UseWUServer = 1 et WUServer vers un point de mise à jour de test ; différés WUfB actifs (17 jours pour la qualité, 5 pour les fonctionnalités) ; aucune clé de scan source.
Une recherche complète par l'API COM, UpdateSearcher.Search("IsInstalled=0"), puis lecture du journal produit par Get-WindowsUpdateLog : les lignes Total possible federated services et Candidate federated service disent quelles sources l'agent interroge réellement.
Le même test après suppression des quatre clés de différé — seule variable modifiée entre les deux mesures.

Mesure	Différé WUfB actif	Sans différé WUfB
Services candidats	3 : Windows Update, un service tiers, WSUS	1 : WSUS seul
Windows Update interrogé ?	Oui — réponse réelle, 3 mises à jour trouvées	Non — absent de la liste des candidats
WSUS injoignable	Échec silencieux de la branche WSUS ; la recherche aboutit par Windows Update	Échec bloquant (`0x80072EE6`), plus aucun repli

Seule la présence des policies de différé change, et elle fait apparaître ou disparaître Windows Update de la liste des services interrogés. Un mécanisme fonctionnellement équivalent au double scan reste donc actif sur cette build de Windows 11, déclenché par le différé WUfB, malgré UseWUServer = 1 et sans aucune scan source policy.

Ce que ce test ne prouve pas

Les mises à jour renvoyées par Windows Update au premier scan — l'outil de suppression de logiciels malveillants, la plateforme et les renseignements de sécurité Defender — relèvent de la catégorie « Other », pas des mises à jour de fonctionnalités ou de qualité au sens strict : aucune n'était disponible sur le poste de test. La conclusion sur ces deux catégories repose sur un faisceau d'indices concordant (le poste transmet ses valeurs de différé Quality et Feature au service dans le même échange), pas sur une preuve directe d'installation. Un seul poste, une seule build : à revalider le jour où une mise à jour de qualité ou de fonctionnalités est disponible sur un poste de test, et après toute montée de version majeure de Windows 11.

Conséquence pratique : on ne compte pas sur un comportement que la documentation contredit. C'est ce qui justifie de poser les cinq valeurs explicitement, plutôt que de s'en remettre à la seule présence des différés.

La configuration cible

Cinq valeurs, posées ensemble, selon le type de poste.

Deux types de poste, deux cibles. Dans les deux cas, les cinq valeurs sont écrites dans la même opération : c'est leur écriture en plusieurs temps, par des mécanismes distincts, qui a produit l'état partiel.

Postes cogérés

Windows Update for Business pilote Windows ; ConfigMgr ne pilote que le tiers. Les quatre classes vont à Windows Update (0).

Postes non cogérés

Tout passe par WSUS ou ConfigMgr, y compris Windows. Les quatre classes vont à WSUS (1), pour verrouiller la décision.

Valeur	Où	Cogéré	Non cogéré
`UseWUServer`	sous `AU`	1 — posé par le client ConfigMgr	1
`WUServer` / `WUStatusServer`	racine	l'adresse du point de mise à jour — inchangée	idem
`UseUpdateClassPolicySource`	sous `AU`	1	1
`SetPolicyDrivenUpdateSourceFor` `Feature / Quality / Driver / OtherUpdates`	racine	0 — Windows Update	1 — WSUS / ConfigMgr

« Racine » désigne HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. UseUpdateClassPolicySource est l'interrupteur maître : sans lui à 1, les quatre classes sont ignorées — et UseWUServer = 1 envoie alors tout vers WSUS, l'OS compris. Microsoft le dit dans le même sens : si l'on écrit les clés à la main, il faut aussi poser UseUpdateClassPolicySource, faute de quoi la scan source n'est pas modifiée.

Les postes non cogérés ne sont pas à l'abri

Sans co-gestion ni différé, UseWUServer et WUServer suffisent et restent déterministes. Mais il suffit qu'un différé apparaisse — résidu d'un test, erreur de ciblage d'une collection ou d'un groupe, bascule accidentelle de co-gestion — pour que Windows Update redevienne un service candidat, sans qu'aucune autre clé ait changé (voir le test plus haut). Forcer les quatre classes à 1 l'interdit explicitement. C'est particulièrement indiqué sur un parc isolé d'Internet.

Cela n'en supprime pas la cause : la présence d'un différé WUfB sur un poste de ce type reste un signal à investiguer, dans tous les cas.

Où poser ces valeurs

Cogérés : Intune, Settings Catalog, catégorie Update — « Specify source service for specific classes of Windows Updates », les quatre listes sur Windows Update. Jamais en écriture directe du registre.
Non cogérés : stratégie de groupe, Computer Configuration › Administrative Templates › Windows Components › Windows Update › Manage updates offered from Windows Server Update Service, la même stratégie, les quatre listes sur WSUS.

Le piège : Settings Catalog ne pose pas l'interrupteur maître

Cette stratégie relève du CSP Update, et l'énumération complète de ce CSP ne comporte aucun nœud UseUpdateClassPolicySource : aucun CSP, natif ou ADMX, ne l'expose. Un profil Settings Catalog configure donc les quatre classes mais pas l'interrupteur qui les rend effectives, quelle que soit la façon dont on le remplit. Il faut le compléter par une stratégie de groupe résiduelle qui active ce seul interrupteur — si les postes reçoivent encore des GPO — ou par le script de cet article. Vérifiez sur un poste pilote que AU\UseUpdateClassPolicySource vaut bien 1.

L'option minimale, à ne pas retenir

Sur un poste cogéré, ne poser aucune clé de scan source marche tant que les différés WUfB sont actifs : Windows Update reste interrogé en parallèle de WSUS (voir le test). C'est un comportement non documenté, que la documentation contredit, sans garantie de stabilité après une mise à jour de build. À réserver au cas où la configuration explicite ne peut vraiment pas être déployée, et à revalider après chaque montée de version majeure.

Le script

Il analyse, il corrige s'il le faut, il le dit.

Un seul fichier, avec une seule logique de décision. Voici ce qu'il décide, dans l'ordre, et pourquoi.

Il déduit le type de poste

La paire de différés WUfB (fonctionnalités et qualité) doit être complète au même emplacement : la ruche des stratégies, ou PolicyManager où écrit un anneau de mise à jour Intune. Une clé à chaque endroit ne fait pas une paire : le poste est alors traité comme non cogéré.

Il vérifie l'éligibilité

La scan source policy existe sur Windows 11 et, sur Windows 10, depuis la version 2004 avec KB5005101 (build 19041.1202 ou plus). Sur un poste non éligible, il bascule sur le mécanisme historique : DisableDualScan à 0 (WUfB) ou à 1 (WSUS).

Il écrit les cinq valeurs d'un bloc

Dès qu'une seule s'écarte, les cinq sont réécrites ensemble : les quatre classes d'abord, l'interrupteur maître en dernier — une interruption laisse ainsi une configuration inactive, pas une configuration partielle. Un poste conforme n'est pas retouché : le lancer chaque jour ne change rien.

Il retire DisableDualScan

Sur un poste éligible, Microsoft ne recommande pas cette stratégie, et la configurer en même temps que la scan source policy sur Windows 10 empêche toute mise à jour de venir de Windows Update. Le script la supprime plutôt que de la mettre à 0. C'est une inférence à partir de ces recommandations, pas une instruction littérale : à confirmer en pilote.

Il pose un filet de sécurité

Si aucun WUServer réel n'est configuré, il force UseWUServer = 1 et pointe WUServer et WUStatusServer vers une adresse en .invalid — un nom que la norme réserve et qui ne se résout jamais. Le poste est verrouillé sur un WSUS qui n'existe pas, et se retrouve facilement dans un rapport de registre.

Il refuse le PowerShell 32 bits

PolicyManager n'est pas exclu de la redirection WOW64, contrairement à la ruche des stratégies : un processus 32 bits y lirait une vue vide et prendrait un poste cogéré pour un poste non cogéré, sans erreur. Le script s'arrête et le dit, plutôt que de se tromper en silence.

Une précision sur la classe « Other ». SetPolicyDrivenUpdateSourceForOtherUpdates ne pilote pas les applications ni les mises à jour tierces gérées par ConfigMgr. « Other updates » est la catégorie des mises à jour de Windows qui ne sont ni des fonctionnalités, ni de la qualité, ni des pilotes (renseignements de sécurité Defender, outil de suppression de logiciels malveillants, autres produits Microsoft). Le tiers passe par le circuit habituel du point de mise à jour (UseWUServer, WUServer), indépendant de cette classe.

Avant de le lancer

Ce qu'il modifie.

Le script écrit dans la base de registre de chaque poste, en SYSTEM. Voici tout ce qu'il touche, et à quelle condition.

Ce que vous en faites vous appartient

Ce script est publié pour être lu, adapté et essayé. Lancez-le d'abord en lecture seule (-ReportOnly), puis sur un poste pilote, avant tout déploiement à l'échelle. Ce qu'il fait sur vos postes est votre décision et votre responsabilité : il est mis à disposition tel quel, sans garantie, et son auteur ne peut pas connaître votre parc.

Ce qui change	Quand	À savoir
Les quatre classes `SetPolicyDrivenUpdateSourceFor…` et `AU\UseUpdateClassPolicySource`	Poste éligible, dès qu'une des cinq valeurs s'écarte de la cible	Cible 0 (Windows Update) ou 1 (WSUS) selon le type de poste détecté. Une cible fausse envoie les mises à jour au mauvais endroit : contrôlez le type détecté avec `-ReportOnly` avant tout.
`DisableDualScan`	Supprimée sur un poste éligible ; posée à 0 ou 1 sur un poste non éligible	Choix déduit de la documentation Microsoft, pas d'une instruction littérale : à confirmer en pilote.
`UseWUServer`, `WUServer`, `WUStatusServer`	Seulement si aucun WUServer réel n'est configuré	L'effet le plus lourd. Le poste est verrouillé sur une adresse qui ne se résout jamais : plus aucune mise à jour tant qu'un vrai serveur n'est pas configuré. C'est voulu — mieux vaut un poste visiblement bloqué qu'un poste qui se met à jour sur Internet sans autorisation — mais il faut le savoir avant, pas après. L'adresse se change avec `-GhostWsusUrl`.
Rien d'autre	—	Ni service, ni tâche planifiée, ni fichier, ni connexion réseau. Il lit aussi la version de Windows pour décider de l'éligibilité.

Ce qu'il faut pour l'exécuter

SYSTEM ou administrateur : il écrit sous HKLM. En lecture seule, un compte standard suffit à lire.
PowerShell 64 bits : en 32 bits il s'arrête avec le code 1 et le dit. Sous Intune, l'option Run script in 64-bit PowerShell à Oui n'est pas un confort mais une condition.
Windows PowerShell 5.1 ou PowerShell 7. Le fichier est en ASCII : l'encodage choisi à l'enregistrement n'y change rien.

Déployer

Intune Remédiations, ou ConfigMgr.

Le même fichier, sans modification, sur les deux plateformes. Il s'auto-corrige puis sort en 0 une fois conforme : il n'y a pas de second script à écrire.

Intune Remediations

Devices › Scripts and remediations › Remediations, puis créer un package.
Detection script : ce fichier. Remediation script : aucun. Microsoft documente qu'un package peut ne contenir qu'un script de détection.
Run this script using the logged-on credentials : Non. Run script in 64-bit PowerShell : Oui.
Assigner d'abord à un groupe pilote, avec la planification de votre choix.

ConfigMgr

Créer un élément de configuration : Setting type = Script, Data type = String.
Script de découverte : le contenu de ce fichier. Pas de script de correction.
Règle de conformité : « la valeur retournée par le script » Égale Compliant.
Ajouter à une ligne de base, déployer sur une collection pilote, et vérifier dans CIAgent.log que le garde-fou 64 bits ne se déclenche pas dans le contexte réel du client : aucune confirmation Microsoft n'a été trouvée sur son comportement par défaut.

Un premier passage, sans rien modifier

powershell -ExecutionPolicy Bypass -File .\Repair-WUScanSource.ps1 -ReportOnly

Il affiche l'emplacement de chaque clé de différé, le type de poste déduit, l'éligibilité, puis ce qui s'écarte de la cible, et sort en 1 si le poste n'est pas conforme. Rien n'est écrit.

Les paramètres et la sortie

Paramètre	Effet
`-ReportOnly`	Analyse et rapporte, n'écrit rien. Sortie 0 si le poste est conforme, 1 s'il s'écarte.
`-ForceTarget`	`Auto` (défaut) lit les clés de différé ; `WindowsUpdate` ou `WSUS` impose le type de poste, pour un test manuel. L'éligibilité reste évaluée sur le poste réel.
`-GhostWsusUrl`	L'adresse du filet de sécurité. Défaut : `http://wsus-non-configure.invalid:8530`.
Sortie	Le rapport passe par `Write-Host` ; la dernière ligne, par `Write-Output`, est un jeton unique `Compliant` ou `NonCompliant` — la seule valeur que retient ConfigMgr. Code de sortie 0 : conforme ; 1 : non conforme, correction échouée, ou PowerShell 32 bits.

Vérifier

Contrôler le résultat, poste par poste.

Le nettoyage du hotfix a-t-il eu lieu ? HKLM\SOFTWARE\Microsoft\CCM\SoftwareUpdates\IsScanSourcePolicyRemoved vaut 0 quand le nettoyage automatique a été exécuté sur le poste.
Les cinq valeurs sont-elles là ensemble ? L'interrupteur maître et les quatre classes, simultanément : aucune configuration partielle ne doit subsister. -ReportOnly le dit en une ligne.
Quelles sources Windows interroge-t-il vraiment ? C'est la méthode du test plus haut, et la seule preuve directe :

Get-WindowsUpdateLog
Select-String -Path "$env:USERPROFILE\Desktop\WindowsUpdate.log" -Pattern 'Total possible federated services|Candidate federated service'

Sur les postes non cogérés, confirmer l'absence de tout différé WUfB : sa présence est un signal à investiguer, même quand la cible à 1 en neutralise l'effet.
Après une montée de version majeure de Windows, relancer le script et refaire le contrôle ci-dessus : le comportement observé ici est celui d'une build, pas une garantie.

Le code

Le script, en entier.

Découpé en sections, chacune expliquée en une phrase. Tout est en clair : pas de bloc encodé, pas de téléchargement, aucune connexion réseau. Copiez-le, enregistrez-le sous Repair-WUScanSource.ps1, et lisez-le avant de le lancer. Vous pouvez l'adapter à votre parc ou à celui d'un client, pas le republier : voir les conditions d'utilisation.

Lisez avant de lancer

Ce script modifie la base de registre de chaque poste où vous le lancez. Essayez-le d'abord avec -ReportOnly, puis sur un poste pilote : ce qu'il fait ensuite sur votre parc est votre décision.

Repair-WUScanSource.ps1

281 lignes · 15 Ko

Cet article vous a-t-il aidé ?

Votre avis est compté sans vous identifier : ni compte, ni cookie, ni commentaire — seul le sens du vote.

Sources

Software update management client fix for Configuration Manager versions 2503, 2509 (KB36495448)
Use Windows Update client policies and WSUS together — la page qui indique le double scan comme non pris en charge sur Windows 11, que la section « Ce que la documentation ne dit pas » nuance par l'observation.
KB5005101 — l'aperçu du 1^er septembre 2021 qui introduit la scan source policy (builds 19041.1202, 19042.1202, 19043.1202).
Troubleshoot Update ring policies for Windows devices — Intune écrit les valeurs d'un anneau de mise à jour sous PolicyManager\current\device\Update.
Use Remediations to detect and fix support issues — le script de remédiation y est facultatif.