Knowledge · Windows Update · ConfigMgr · Intune

KB36495448: restoring the Windows Update scan source policy after ConfigMgr 2503/2509

One self-correcting script, for Intune Remediations and for ConfigMgr.

Hotfix KB36495448 stops the Configuration Manager 2503 and 2509 client from leaving incomplete scan source keys on co-managed devices, and cleans up the ones that exist. It puts no configuration in their place. This article gives the target configuration, the behaviour observed on Windows 11 — which is not the one the documentation describes — and a script that audits the device, corrects it if it deviates, and says so.

Windows UpdateConfigMgrIntunePowerShell

Published 5 October 2026 · sources checked 5 October 2026

The target configuration Read the script

5 valueswritten together, never one by one

2 device typeswith or without Windows Update for Business

PowerShell 5.1+Windows 10 2004 and later, Windows 11

1 scriptit analyses, corrects and reports

What you see

Windows updates coming from somewhere other than planned.

On a co-managed estate (Intune and Configuration Manager) where Windows Update for Business (WUfB) drives Windows updates and ConfigMgr drives only the third-party ones, some devices get their feature and quality updates from WSUS, with nobody having decided it.

It is the sign of an incomplete « scan source » configuration. Where each category of updates is searched for — WSUS or Windows Update — is described by five registry values that must exist together. The Configuration Manager 2503 and 2509 client left two out of five.

The cause

Two keys out of five.

In Configuration Manager 2503 (with update rollup 32851084) and 2509, when third-party updates are enabled on a co-managed device, the client sets only two scan source values. The other three are not set, and are removed if they existed.

Value	Set by the client	State left on the device
`AU\UseUpdateClassPolicySource`	Yes, to 1	Master switch on
`SetPolicyDrivenUpdateSourceForOtherUpdates`	Yes, to 1	On
`SetPolicyDrivenUpdateSourceForFeatureUpdates`	No — removed if it existed	Missing
`SetPolicyDrivenUpdateSourceForQualityUpdates`	No — removed if it existed	Missing
`SetPolicyDrivenUpdateSourceForDriverUpdates`	No — removed if it existed	Missing

Under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate, except the master switch, which sits in the AU sub-key.

When only some classes are present, the Windows Update agent can assume every category follows the same source. Feature and quality updates meant for Intune or WUfB are then redirected to WSUS and ConfigMgr, although the environment was configured to keep them away from there.

What the hotfix does, and what it leaves

The client no longer sets or modifies UseUpdateClassPolicySource or the four SetPolicyDrivenUpdateSourceFor* values on a co-managed device.
The partial states left by earlier builds are cleaned up once.
It puts nothing in their place. Microsoft states that the scan source is now the administrator's to control, through Group Policy or the Windows Update for Business CSP policy.

Why that is not enough

After that cleanup no scan source key is left. The device is then in the case where the documentation and the real behaviour diverge the most: the next section measures it.

What the documentation does not say

Dual scan is not dead on Windows 11.

Once the keys are cleaned, a device with WSUS configured and no scan source policy is in the case Microsoft's documentation describes least well. It states that dual scan (the Do not allow update deferral policies to cause scans against Windows Update policy) is no longer supported on Windows 11.

Rather than settle it on the documentation alone, the behaviour was checked with a controlled test, isolating a single variable.

The protocol

A Windows 11 lab device, not co-managed: the OS mechanism is tested alone, with no ConfigMgr.
UseWUServer = 1 and WUServer pointing at a test software update point; WUfB deferrals active (17 days for quality, 5 for features); no scan source key.
A full search through the COM API, UpdateSearcher.Search("IsInstalled=0"), then reading the log produced by Get-WindowsUpdateLog: the Total possible federated services and Candidate federated service lines say which sources the agent really queries.
The same test after removing the four deferral keys — the only variable changed between the two measurements.

Measurement	WUfB deferral active	No WUfB deferral
Candidate services	3: Windows Update, a third-party service, WSUS	1: WSUS only
Windows Update queried?	Yes — a real answer, 3 updates found	No — absent from the candidates
WSUS unreachable	The WSUS branch fails silently; the search succeeds through Windows Update	Blocking failure (`0x80072EE6`), no fallback left

Only the presence of the deferral policies changes, and it makes Windows Update appear in or vanish from the list of queried services. A mechanism functionally equivalent to dual scan therefore stays active on this Windows 11 build, triggered by the WUfB deferral, despite UseWUServer = 1 and with no scan source policy at all.

What this test does not prove

The updates Windows Update returned on the first scan — the Malicious Software Removal Tool, the Defender platform and security intelligence — belong to the « Other » category, not to feature or quality updates in the strict sense: none was available on the test device. The conclusion for those two categories rests on a body of consistent evidence (the device sends its Quality and Feature deferral values to the service in the same exchange), not on direct proof of installation. One device, one build: to be re-checked the day a quality or feature update is available on a test device, and after any major Windows 11 version upgrade.

Practical consequence: one does not rely on behaviour the documentation contradicts. That is why the five values are set explicitly, rather than left to the mere presence of the deferrals.

The target configuration

Five values, written together, depending on the device type.

Two device types, two targets. In both cases the five values are written in the same operation: it was writing them in several steps, through separate mechanisms, that produced the partial state.

Co-managed devices

Windows Update for Business drives Windows; ConfigMgr drives only the third-party updates. The four classes go to Windows Update (0).

Devices not co-managed

Everything goes through WSUS or ConfigMgr, Windows included. The four classes go to WSUS (1), to lock the decision.

Value	Where	Co-managed	Not co-managed
`UseWUServer`	under `AU`	1 — set by the ConfigMgr client	1
`WUServer` / `WUStatusServer`	root	the software update point address — unchanged	same
`UseUpdateClassPolicySource`	under `AU`	1	1
`SetPolicyDrivenUpdateSourceFor` `Feature / Quality / Driver / OtherUpdates`	root	0 — Windows Update	1 — WSUS / ConfigMgr

« Root » means HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. UseUpdateClassPolicySource is the master switch: without it at 1 the four classes are ignored — and UseWUServer = 1 then sends everything to WSUS, the OS included. Microsoft says the same: when writing the keys by hand you must also set UseUpdateClassPolicySource, otherwise the scan source is not altered.

Devices that are not co-managed are not immune

With no co-management and no deferral, UseWUServer and WUServer are enough and stay deterministic. But all it takes is a deferral appearing — a leftover from a test, a collection or group targeting mistake, an accidental co-management switch — for Windows Update to become a candidate service again, with no other key having changed (see the test above). Forcing the four classes to 1 forbids it explicitly. This is especially fitting on an estate cut off from the Internet.

It does not remove the cause: a WUfB deferral on a device of this type remains a signal to investigate, in every case.

Where to set these values

Co-managed: Intune, Settings Catalog, Update category — « Specify source service for specific classes of Windows Updates », the four lists on Windows Update. Never by writing the registry directly.
Not co-managed: Group Policy, Computer Configuration › Administrative Templates › Windows Components › Windows Update › Manage updates offered from Windows Server Update Service, the same policy, the four lists on WSUS.

The trap: Settings Catalog does not set the master switch

This policy belongs to the Update CSP, and the complete enumeration of that CSP contains no UseUpdateClassPolicySource node: no CSP, native or ADMX, exposes it. A Settings Catalog profile therefore configures the four classes but not the switch that makes them effective, however it is filled in. It has to be completed by a residual Group Policy that enables that one switch — if the devices still receive GPOs — or by this article's script. Check on a pilot device that AU\UseUpdateClassPolicySource is really 1.

The minimal option, not to be relied on

On a co-managed device, setting no scan source key works as long as the WUfB deferrals are active: Windows Update stays queried alongside WSUS (see the test). It is undocumented behaviour that the documentation contradicts, with no guarantee of stability after a build update. Keep it for the case where the explicit configuration really cannot be deployed, and re-check it after every major version upgrade.

The script

It analyses, corrects if it must, and says so.

One file, with a single decision logic. Here is what it decides, in order, and why.

It works out the device type

The WUfB deferral pair (feature and quality) must be complete at the same location: the policies hive, or PolicyManager, where an Intune update ring writes. One key in each place is not a pair: the device is then treated as not co-managed.

It checks eligibility

The scan source policy exists on Windows 11 and, on Windows 10, from version 2004 with KB5005101 (build 19041.1202 or later). On an ineligible device it falls back to the legacy mechanism: DisableDualScan at 0 (WUfB) or 1 (WSUS).

It writes the five values as one block

As soon as one deviates, all five are rewritten together: the four classes first, the master switch last — an interruption thus leaves an inactive configuration, not a partial one. A conformant device is not touched: running it every day changes nothing.

It removes DisableDualScan

On an eligible device Microsoft does not recommend this policy, and configuring it together with the scan source policy on Windows 10 stops any update coming from Windows Update. The script removes it rather than setting it to 0. That is an inference from those recommendations, not a literal instruction: confirm it on a pilot.

It sets a safety net

If no real WUServer is configured, it forces UseWUServer = 1 and points WUServer and WUStatusServer at a .invalid address — a name the standard reserves and that never resolves. The device is locked on a WSUS that does not exist, and is easy to find in a registry report.

It refuses 32-bit PowerShell

PolicyManager is not excluded from WOW64 redirection, unlike the policies hive: a 32-bit process would read an empty view there and take a co-managed device for a non-co-managed one, with no error. The script stops and says so, rather than being wrong silently.

A precision about the « Other » class. SetPolicyDrivenUpdateSourceForOtherUpdates does not drive the applications or third-party updates managed by ConfigMgr. « Other updates » is the category of Windows updates that are neither features, quality nor drivers (Defender security intelligence, the Malicious Software Removal Tool, other Microsoft products). Third-party updates go through the usual software update point path (UseWUServer, WUServer), independent of that class.

Before you run it

What it changes.

The script writes to the registry of every device, as SYSTEM. Here is everything it touches, and under which condition.

What you do with it is up to you

This script is published to be read, adapted and tried. Run it read-only first (-ReportOnly), then on a pilot device, before any large-scale deployment. What it does on your devices is your decision and your responsibility: it is provided as is, without warranty, and its author cannot know your estate.

What changes	When	Worth knowing
The four `SetPolicyDrivenUpdateSourceFor…` classes and `AU\UseUpdateClassPolicySource`	Eligible device, as soon as one of the five values deviates from the target	Target 0 (Windows Update) or 1 (WSUS) depending on the detected device type. A wrong target sends updates to the wrong place: check the detected type with `-ReportOnly` first.
`DisableDualScan`	Removed on an eligible device; set to 0 or 1 on an ineligible one	A choice inferred from Microsoft's documentation, not from a literal instruction: confirm it on a pilot.
`UseWUServer`, `WUServer`, `WUStatusServer`	Only if no real WUServer is configured	The heaviest effect. The device is locked on an address that never resolves: no update at all until a real server is configured. That is intended — better a visibly blocked device than one updating from the Internet unasked — but you need to know it beforehand, not afterwards. The address is changed with `-GhostWsusUrl`.
Nothing else	—	No service, no scheduled task, no file, no network connection. It also reads the Windows version to decide eligibility.

What it takes to run it

SYSTEM or administrator: it writes under HKLM. In report-only mode a standard account is enough to read.
64-bit PowerShell: in 32-bit it stops with exit code 1 and says so. In Intune, Run script in 64-bit PowerShell set to Yes is not a convenience but a condition.
Windows PowerShell 5.1 or PowerShell 7. The file is ASCII: whatever encoding you save it in makes no difference.

Deploying

Intune Remediations, or ConfigMgr.

The same file, unmodified, on both platforms. It corrects itself then exits 0 once conformant: there is no second script to write.

Intune Remediations

Devices › Scripts and remediations › Remediations, then create a package.
Detection script: this file. Remediation script: none. Microsoft documents that a package may hold a detection script alone.
Run this script using the logged-on credentials: No. Run script in 64-bit PowerShell: Yes.
Assign to a pilot group first, with the schedule of your choice.

ConfigMgr

Create a configuration item: Setting type = Script, Data type = String.
Discovery script: the content of this file. No remediation script.
Compliance rule: « the value returned by the script » Equals Compliant.
Add to a baseline, deploy to a pilot collection, and check in CIAgent.log that the 64-bit guard does not trigger in the client's real context: no Microsoft confirmation was found on its default behaviour.

A first pass, changing nothing

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

It shows where each deferral key was found, the device type it deduced, eligibility, then what deviates from the target, and exits 1 if the device is not conformant. Nothing is written.

Parameters and output

Parameter	Effect
`-ReportOnly`	Analyses and reports, writes nothing. Exit 0 if the device conforms, 1 if it deviates.
`-ForceTarget`	`Auto` (default) reads the deferral keys; `WindowsUpdate` or `WSUS` imposes the device type, for a manual test. Eligibility is still evaluated on the real device.
`-GhostWsusUrl`	The safety net's address. Default: `http://wsus-non-configure.invalid:8530`.
Output	The report goes through `Write-Host`; the last line, through `Write-Output`, is a single token, `Compliant` or `NonCompliant` — the only value ConfigMgr keeps. Exit code 0: conformant; 1: not conformant, correction failed, or 32-bit PowerShell.

Verifying

Checking the result, device by device.

Has the hotfix cleanup run? HKLM\SOFTWARE\Microsoft\CCM\SoftwareUpdates\IsScanSourcePolicyRemoved is 0 once the automatic cleanup has run on the device.
Are the five values there together? The master switch and the four classes, simultaneously: no partial configuration may remain. -ReportOnly says so in one line.
Which sources does Windows really query? It is the method of the test above, and the only direct proof:

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

On devices that are not co-managed, confirm there is no WUfB deferral at all: its presence is a signal to investigate, even when the target at 1 neutralises its effect.
After a major Windows version upgrade, run the script again and repeat the check above: the behaviour observed here is that of one build, not a guarantee.

The code

The whole script.

Split into sections, each explained in one sentence. Everything is in plain text: no encoded block, no download, no network connection. Copy it, save it as Repair-WUScanSource.ps1, and read it before you run it. You may adapt it to your estate or to a client's, not republish it: see the terms of use.

Read before you run

This script changes the registry of every device you run it on. Try it with -ReportOnly first, then on a pilot device: what it does on your estate after that is your decision.

Repair-WUScanSource.ps1

281 lines · 15 KB

Did this article help?

Your answer is counted without identifying you: no account, no cookie, no comment — only which way you voted.

Sources

Software update management client fix for Configuration Manager versions 2503, 2509 (KB36495448)
Use Windows Update client policies and WSUS together — the page that lists dual scan as unsupported on Windows 11, which the section « What the documentation does not say » qualifies by observation.
KB5005101 — the September 1, 2021 preview that introduced the scan source policy (builds 19041.1202, 19042.1202, 19043.1202).
Troubleshoot Update ring policies for Windows devices — Intune writes an update ring's values under PolicyManager\current\device\Update.
Use Remediations to detect and fix support issues — the remediation script is optional there.