A WSUS device installed something WSUS never approved: diagnosing dual scan before you touch a policy

A device that has pointed at your WSUS server for four years installs a cumulative update that is not in your WSUS console. Or worse: a user opens Settings, clicks one link, and comes back on a Windows build you never approved.

The WSUS console still shows the machine as green. From WSUS's point of view nothing happened, and nothing did happen — on WSUS. The device went somewhere else.

The instinct at this point is to start editing Group Policy. Do not. Change one policy value now and you destroy the only evidence that tells you which of your two control planes actually served that update, which means your fix is a guess and you will be back here next month.

The problem: WSUS says compliant, the device says otherwise

The symptom set is always some combination of the following, and none of them look like the same fault at first glance.

• A feature update, or the optional Windows 11 upgrade offer, appears on a machine that WSUS manages.
• Quality updates install that are not approved on your WSUS server — sometimes not even synchronised to it.
• WSUS reports the device as needing updates it already has, because WSUS never saw the install.
• The Check online for updates from Microsoft Update link is present when you were sure you had removed it. Or it has vanished, and nobody touched anything.
• A support engineer re-points WUServer, the device behaves for a week, and then does it again.

What links them is that the device has two plausible sources of truth for Windows content and you do not currently know which one it used. Until you know that, every change you make is a coin flip.

So three questions, strictly in this order, before you touch a single policy.

1. Which update services are registered on this device right now, and which one is Automatic Updates actually treating as its default?
2. Which policy values actually exist in the registry — not which GPOs you believe are linked, and not what the Intune blade says it pushed?
3. What did the last scan talk to, according to the client's own log?

All three are read-only. Together they take about four minutes on one machine, and they turn a fleet-wide argument into a single sentence you can put in a change record.

Why it happens: two control planes, one device

The behaviour has a name and it was designed on purpose. Microsoft's WSUS team introduced dual scan in Windows 10 1607 for a specific customer shape: an enterprise that wanted Windows Update to be the primary source for Windows content while WSUS carried everything else — third-party packages, line-of-business applications, other Microsoft products.

Under dual scan the client scans against both WSUS and Windows Update, but it only accepts scan results for Windows content from Windows Update. Anything sitting in the Windows product family on your WSUS server is simply ignored. Microsoft's own framing for why it works that way was the "two masters" problem: if two services can both claim authority over the same update, the client has no way to pick.

That design is defensible. The trouble is how easily you fall into it by accident.

The ingredient list

Dual scan turns itself on when a particular combination of policies is present. Microsoft was explicit that it does not matter whether you set them through Group Policy, through their MDM equivalents, or by writing the underlying registry values directly — all three count.

Read the third column again, because it is the part that catches experienced people. A GPO you decommissioned two years ago that left values behind in the registry still counts. A task sequence step, an LGPO import baked into your image, a ConfigMgr client setting — all of them write the same values, and the client cannot tell where they came from.

The original trap was almost poetic. Admins who did not want unapproved feature updates arriving from ad hoc scans enabled the feature-update deferral policy to stop them. That worked. It also completed the dual scan ingredient list, which handed Windows content to Windows Update wholesale and took the device out of WSUS's control for exactly the updates the admin cared most about.

Two historical traps that still show up in inherited policy

• On 1607, the Do not include drivers with Windows Updates policy — registry value ExcludeWUDriversInQualityUpdate — was on its own enough to flip a client into dual scan. Microsoft acknowledged it as a bug and fixed it in 1703. Devices are long past 1607, but the GPO that was written to work around it usually is not.
• A legacy deferral policy set explicitly to Disabled also triggered dual scan, because Disabled writes a value rather than removing one. Microsoft later changed the client so that Disabled no longer triggers it. The general lesson outlives the specific bug: in Windows Update policy, Disabled and Not Configured are different states and the client can behave differently under each.

What the client actually does in 2026

Microsoft's current guidance collapses the whole question down to two inputs: whether a WSUS server is configured, and whether the scan source policy is configured. Everything else is noise. Here is the documented default behaviour.

Row four is the dual scan row, and it is why a device you believe is WSUS-managed can be taking its Windows content from Microsoft with no error anywhere.

One more documented behaviour explains most surprise-upgrade tickets. If devices are configured for WSUS and you have configured neither a scan source for feature updates nor any offering policy, a user who clicks Check online for updates in Settings may be offered the optional upgrade to Windows 11. Microsoft's recommendation is to configure a scan source or an offering policy to prevent exactly that.

How to verify: name the service before you name the culprit

Everything in this section is read-only. Nothing here changes the device, so you can run it on the affected machine while the incident is still open.

Step 1: ask the agent which services are registered

This is Microsoft's own documented procedure for determining the source of Windows updates on a device, and it is the single most useful thing in this article. The Windows Update Agent keeps a list of registered update services, and it will tell you what they are and which one Automatic Updates has adopted.

Take the fields one at a time, because each one answers a different question.

Name is the human-readable service name, and it is what Microsoft's documentation tells you to read. OffersWindowsUpdates is a boolean saying whether that service offers Windows operating system content as opposed to something else. IsManaged tells you whether the service is a managed service. And IsDefaultAUService — which comes from the second-generation interface, IUpdateService2 — is documented as indicating whether the service is registered with Automatic Updates and is currently the one Automatic Updates uses as its default. That last one is the field people skip and then argue about for an hour.

Microsoft publishes the interpretation table. Here it is, with the meaning of each row.

One honest observation from the lab device: the fourth service reports as Windows Store (Prod), not the Windows Store (DCat Prod) that the documentation lists. Service names drift between releases. That is one more reason to read the whole row rather than pattern-matching on one string.

Step 2: read the policy values that actually exist

Now compare intent against reality. The point of this step is not to confirm your GPO design; it is to find the values nobody remembers writing.

Here is the reference table for the values that decide where updates come from. All of these live directly under one key.

Three more values live one level down, in the legacy Automatic Updates subkey. This is the key that separates a legacy-AU-managed device from a cloud-managed one.

Step 3: decode the log and read the ServiceID

The client keeps its diagnostics as Event Tracing for Windows trace files, not as a text log. Microsoft documents windowsupdate.log as living in C:\Windows\Logs\WindowsUpdate, and Get-WindowsUpdateLog as the way to merge and convert those .etl files into one readable file. Note the documented caveat: the cmdlet produces a static snapshot, so it does not keep updating the way the old text log did. Run it again for fresh data.

Two things to pull out of that. The ServiceID on the Agent line is the identifier of the service that search ran against — match it back to the Name you resolved in Step 1, do not translate it from memory. The redir Client/Server URL on the Misc line is the endpoint the agent actually resolved, and it is the least ambiguous line in the entire file. If a device you believe is WSUS-managed shows a delivery.mp.microsoft.com endpoint for a Windows content search, you have your answer and you did not have to change anything to get it.

It is worth knowing which component names to filter on, because the file is enormous. Microsoft documents ProtocolTalker as client-server sync, DownloadManager as the component that creates and monitors payload downloads, DataStore as the local update cache, Handler and Setup as the installer handlers, and EEHandler as applicability rule evaluation. For a source question you want Agent, Misc and PT. Everything else is noise on this particular hunt.

Step 4: corroborate with the event log

The log tells you what the client intended. The event log gives you timestamps you can put in a ticket and correlate against your WSUS approval history. One channel carries the useful entries.

One channel across: the Setup log carries Event 2, which reports that a package was successfully changed to the Staged state and names the KB. That is your bridge from "a scan happened" to "this specific KB was staged on this device", which is how you answer the question your change board will actually ask.

Step 5: the decision path

Follow this in order and you will land on a named root cause rather than a hunch.

1. Is there a Windows Server Update Service row in Step 1? If no, no WSUS registration exists on this device. Stop looking for dual scan — your problem is an offering, deferral or target-version policy, or a genuinely unmanaged device. If yes, continue.
2. Is WUServer present, and is UseWUServer set to 1 in the AU subkey? A WUServer value with no UseWUServer is a half-applied policy, and it is a common outcome when a GPO was scoped wrongly or a task sequence step half-ran.
3. Are either DeferFeatureUpdatesPeriodInDays or DeferQualityUpdatesPeriodInDays present alongside it? If yes, the dual scan ingredient list is complete. On Windows 10 with no scan source policy, expect Windows content to come from Windows Update. That is the documented behaviour, not a fault.
4. Is any SetPolicyDrivenUpdateSourceFor* value present? If some are and some are not, you have a per-class split and you should expect exactly the inconsistency you are seeing. If they were written straight into the registry and UseUpdateClassPolicySource is missing, the scan source was never altered at all.
5. Is DisableDualScan present? On Windows 11 it does nothing. On Windows 10 alongside the scan source policy it stops Windows Update content entirely, which presents as "no updates found" rather than "wrong source".
6. Which ServiceID did the last scan actually use? This is the answer. Steps 1 to 5 are the explanation for it. Write both down before you change anything.

The fix: decide who owns Windows updates, then say it out loud

The fix is not a registry tweak. It is a decision, followed by expressing that decision unambiguously so the client never has to guess.

1. Decide per update class, not per device. There are four classes: feature updates, Windows quality updates, driver and firmware updates, and updates for other Microsoft products. Microsoft's guidance is explicit that only two things determine where updates come from — the scan source policy, and whether a WSUS server is configured. Decide each class once, write it down, and stop configuring anything else that touches the question.

2. Express it with the scan source policy. In Group Policy it is Specify source service for specific classes of Windows Updates, under Computer Configuration \ Administrative Templates \ Windows Components \ Windows Update \ Manage updates offered from Windows Server Update Service. By CSP it is the Update/SetPolicyDrivenUpdateSourceFor<Update Type> family, and Microsoft says to configure all of them if you go the CSP route. 0 means take that class from Windows Update, 1 means take it from WSUS.

3. If you insist on the registry, set the companion value. Microsoft says editing the registry to change update policy behaviour is not recommended and you should use Group Policy or the CSP. If you do it anyway, you must also configure UseUpdateClassPolicySource, or the scan source will not be altered.

4. Retire DisableDualScan. Not "set it to 0" — remove it, by setting the policy to Not Configured. It is unsupported on Windows 11 and counter-recommended on Windows 10.

5. Leave DoNotConnectToWindowsUpdateInternetLocations alone unless you actively want it. This one has a genuine trap in it, described below.

Finally, there is a published list of the values Microsoft itself treats as disqualifying. Windows Autopatch inspects three during readiness checks: DoNotConnectToWindowsUpdateInternetLocations and DisableWindowsUpdateAccess under the WindowsUpdate policy key, and NoAutoUpdate under the AU subkey. Any value at all in those three marks a device Not ready. Microsoft also names the four usual sources when a removed value keeps coming back: Active Directory Group Policy, Configuration Manager device client settings, manual registry edits, and local Group Policy applied during imaging. If your remediation keeps getting reverted, that list is where to look next.

Proof it worked: what a single-source device looks like

Here is the reference case, read from a real corporate Windows 11 device with nothing changed on it. Use it as the shape you are aiming for: one control plane, unambiguously.

The device is Windows 11 Enterprise, DisplayVersion 25H2, build 26200.9168, with servicing stack 10.0.26100.9156 — a 26100 stack on a 26200 build, which is normal. The Windows Update Agent binaries are all at 1509.2607.1012.0.

Its evidence set reads as follows. The ServiceManager enumeration returns four services and no Windows Server Update Service row, so there is no WSUS registration to argue about. Microsoft Update is the one with IsDefaultAUService True, so that is what Automatic Updates uses. The policy key holds exactly two values, TargetReleaseVersion and TargetReleaseVersionInfo. There is no WUServer, no UseWUServer, no deferral value and no scan source value. The AU subkey is present and empty.

That is a cleanly cloud-managed client. Dual scan cannot occur on it, because the WSUS half of the ingredient list does not exist.

The binaries worth knowing by name

When you are reading a decoded update log at two in the morning, these are the files behind the components you are filtering on. Paths and versions read from the lab device.

Notice the version split: the three agent binaries share 1509.2607.1012.0 while UsoClient.exe reports 10.0.26100.8328. The Windows Update Agent and the Update Session Orchestrator are versioned on different trains. If you are diffing "the update stack" across machines, you need both numbers, not one.

What to re-check after you change the policy, and in what order

1. Re-run Step 1. The registered service list is what should change first, and if it does not, your policy did not apply.
2. Re-read the policy key. Confirm the values you intended are there and the ones you retired are gone, not zeroed.
3. Force exactly one scan. One, so there is one record to read.
4. Decode the log once and check the ServiceID and the resolved endpoint on that single scan.
5. Check Event 26 for the scan and Event 41 for any download, and note the timestamps.
6. Only now open the WSUS console. It is the last place to look, because it can only ever tell you what WSUS thinks.

References

• Windows Update issues troubleshooting — the documented Microsoft.Update.ServiceManager procedure for determining the update source, the Name / OffersWindowsUpdates interpretation table, and real log excerpts showing the ServiceID and redir Client/Server URL lines.
• Use Windows Update client policies and WSUS together — the scan source policy, the four SetPolicyDrivenUpdateSourceFor<Update Type> CSP nodes, the UseUpdateClassPolicySource requirement, the default scan behaviour table, and the statement that DisableDualScan is unsupported on Windows 11.
• Demystifying "Dual Scan" — the original design intent, the exact policy combination that triggers it, and the confirmation that MDM equivalents and raw registry values count too.
• Improving Dual Scan on 1607 — the DisableDualScan policy, the five management scenarios it was and was not meant for, and the note that WSUS ignores deferral policies entirely.
• Manage additional Windows Update settings — WUServer, WUStatusServer, UseWUServer, NoAutoUpdate and AUOptions with their key paths and types, plus what "Do not connect to any Windows Update Internet locations" does and does not block.
• No option to check online for updates from Microsoft Update — the DoNotConnectToWindowsUpdateInternetLocations value with 1 = Enabled / 0 = Disabled, and why a leftover 0 hides the link on 24H2.
• Policy CSP — Update — allowed values for each scan source node, the 0–365 and 0–30 deferral ranges, and the Group Policy to registry mappings for TargetReleaseVersion.
• Windows Update log files — log locations, the Get-WindowsUpdateLog static-snapshot caveat, the component name list, and where the local update identifiers are stored in Datastore.edb.
• Windows Autopatch: conflicting configurations — the three registry values Microsoft treats as disqualifying, the detection and removal scripts, and the four common sources of values that keep coming back.
• IUpdateService2 interface and IUpdateService interface — the definitions of IsDefaultAUService, OffersWindowsUpdates, IsManaged and ServiceID, and confirmation that Wuapi.dll implements them.
• Opt-In to Microsoft Update — the only update service GUID published in Microsoft's own documentation, and the Microsoft.Update.ServiceManager usage pattern.
• Plan your WSUS deployment — the default client-facing ports 8530 (HTTP) and 8531 (HTTPS), and the 22-hours-minus-a-random-offset default detection interval.