Which Update Service Is This Device Actually Registered Against? Enumerate the Service IDs Before You Debug Anything Else

Every Windows Update investigation I have ever been handed started in the wrong place. Somebody says a device is not getting the August cumulative update, and within thirty seconds someone else is stopping wuauserv and renaming SoftwareDistribution. Nobody has yet established the one fact that determines whether the device could ever have received that update: which update service it is actually talking to.

That fact takes two seconds to obtain, and it comes from the agent itself rather than by inference from group policy. The Windows Update Agent (WUA) COM API names every registered service, says which one Automatic Updates treats as default, and says which are even willing to offer Windows updates. On the 25H2 machine I ran it on, the answer was not the one the documentation predicts.

The problem: debugging the wrong update service

The symptom is almost never "no updates". It is "the wrong updates", and it is maddening precisely because everything looks healthy. The services are running, the component store is clean, the device reports to Intune, and the update history has entries in it. Something is arriving. It is just not the thing you deployed.

Three variants of this show up constantly. A device that should be on WSUS quietly pulls straight from Windows Update. A device that should be WUfB-managed sits waiting for approvals on a WSUS server nobody remembers building. Or a device receives .NET Framework and Office updates that were never in scope, because at some point it was opted in to Microsoft Update.

All three are the same failure: the device is registered against a different update service than the one your policy targets. And none of the three is visible from the places engineers habitually look. The Windows Update settings page does not name the service. The update history does not name it. Most importantly, and I measured this, the event log does not name it either.

Here is the census from the live 25H2 device. Four hundred events from the Windows Update client channel, and not one of them carries a service identifier.

Three hundred and forty-four "found 0 updates" events, and no way to tell which service was asked. The operational channel records that the agent ran and what it found, never who it talked to.

So before you form a hypothesis about approvals, deferrals, deadlines or rings, establish the registration. It is the cheapest fact to obtain and it invalidates the largest number of wrong theories.

Why it happens: registration, default AU service and scan source are three different things

Practitioners collapse these into one idea called "the update source". They are three independent layers, and a device can be misconfigured at any one while the other two look correct.

Layer one is registration. A service is registered with WUA. Microsoft's reference describes IUpdateServiceManager as the interface that "adds or removes the registration of the update service with Windows Update Agent or Automatic Updates", and its Services property as returning "an IUpdateServiceCollection of the services that are registered with WUA". Registration means available, not active. On my device four services were registered and only one was being used for background scans.

Layer two is the default Automatic Updates service. Exactly one registered service holds this role. It is exposed as IsDefaultAUService, which Microsoft documents on IUpdateService2 - not on IUpdateService - as indicating "whether the service is registered with Automatic Updates and whether the service is currently used by Automatic Updates as the default service". This is the field that actually answers "where do my background updates come from".

Layer three is the scan source policy. Since the September 1, 2021 update KB5005101, Windows 10 version 2004 and later and Windows 11 decide per update class whether to scan WSUS or Windows Update, through the SetPolicyDrivenUpdateSourceFor family. This layer can override the intuition you formed from layers one and two.

How a device ends up somewhere unexpected

Registration is not something only your management platform does. Microsoft's own opt-in guidance shows a two-line script that any admin-context caller can run, setting a ClientApplicationID of its choosing and calling AddService2 with the Microsoft Update GUID. The documentation is explicit that the alternative route is simply a user visiting Microsoft Update.

That is how you get a fleet where some devices offer .NET Framework and Office updates and others do not, with nothing in your policy set to explain the split. An installer did it. A remediation script did it. A technician clicked the box in 2019.

A legacy seeding mechanism explains stale state on long-lived images. Microsoft documents that writing ClientApplicationID and RegisterWithAU under a PendingServiceRegistration key causes the opt-in to occur on the next WUA search, and notes the key "is respected once only when WUA is updated from a version that is earlier than version 7.0.6000". On my device it was absent.

Offline scanning creates a service too. AddScanPackageService registers a wsusscn2.cab scan package as a service, and the resulting object reports IsScanPackageService as true. If a vulnerability scanner has ever run an offline scan here, that is where a fifth entry in your enumeration comes from.

The scan source policy family

This is the layer most likely to make an otherwise correct configuration behave wrongly, because its defaults are counter-intuitive and its preconditions are easy to miss. All four policies live under one key.

That last row is the trap. My test device had exactly two policy values, both about version pinning, and nothing at all about scan source. Anyone reasoning from group policy alone would have concluded "WUfB-managed, pinned to 24H2" and been wrong on the second half.

One more interaction to retire. The old dual-scan policy, "Do not allow update deferral policies to cause scans against Windows Update", is documented as no longer supported on Windows 11, and on Windows 10 as replaced by the scan source policy. Microsoft's warning is blunt: configure both on Windows 10 and "you won't get updates from Windows Update." If you find that policy in a GPO, it is a finding.

How to verify: enumerate the service IDs before anything else

Two lines. Microsoft's own troubleshooting article gives them, under the heading about updates not downloading from the intranet endpoint. Create the service manager, read the collection.

Read that output from the bottom up. The service named "Windows Update" is registered, is willing to offer Windows updates, and is not the default AU service. Microsoft Update is. That single line explains why this device received KB5120708, a .NET Framework 3.5 and 4.8.1 cumulative update, alongside its August Windows patches. Nothing in the policy set said "give me other Microsoft products". The registration said it.

Where the device and the docs disagree

Now the part that breaks compliance scripts. Microsoft's troubleshooting article publishes a table of expected Name values. Compare it to what the device returned.

There is a second, subtler discrepancy, and it is worth stating carefully: it involves two Microsoft pages disagreeing with each other rather than with me.

The Intune support article on feature updates never being offered attributes GUID 855E8A7C-ECB4-4CA3-B045-1DFA50104289 to "the DCAT Flighting service", and shows it redirecting to fe3.delivery.mp.microsoft.com. On my device that GUID belongs to the service named "Windows Store (Prod)", pointing at tas01.cwsapp.update.microsoft.com, with OffersWindowsUpdates false. The service actually pointing at the fe3cr.delivery.mp.microsoft.com family is the separately-registered "DCat Flighting Prod", under a different GUID entirely.

I am not going to declare Microsoft wrong. That article is scoped to Windows 10 version 1709 and later and may well describe accurate behaviour for its era. But the mapping does not hold on 25H2, and meanwhile the equivalent Windows client troubleshooting page has replaced the real GUID in the same log excerpt with the placeholder aaaabbbb-0000-cccc-1111-dddd2222eeee. There is currently no first-party table of these GUIDs to trust.

The registry side of the same truth

The API reads from a registry store, and cross-checking the two is how you catch a device whose COM layer is broken. Every registered service has a subkey named for its GUID under one parent.

The decision path

Follow these in order. Each step either produces a root cause or narrows the next one.

1. Enumerate and record. Run the two lines above and save the output before you change anything. Capture Name, ServiceID, IsDefaultAUService, IsRegisteredWithAU, OffersWindowsUpdates, IsManaged, IsScanPackageService and ServiceUrl for every entry.
2. Find the default. Exactly one service should report IsDefaultAUService as true. If that service is not the one your management model assumes, stop - you have found the root cause and the rest of the investigation is moot.
3. Check for a scan-package service. Any entry with IsScanPackageService true came from an offline wsusscn2.cab scan. Note it and exclude it from your reasoning about live scans.
4. Check for a managed service. IsManaged true, or a service named "Windows Server Update Service", means WSUS is in play regardless of what anyone told you.
5. Cross-check the registry. Confirm DefaultService matches the API's default and that the per-GUID subkeys match the enumerated list. Mismatch means a broken or partial registration.
6. Read the scan source policy. Only now. Check all four SetPolicyDrivenUpdateSourceFor values, UseUpdateClassPolicySource, and whether WUServer actually resolves. A policy naming WSUS while no WSUS registration exists is your answer.
7. Decode the log last. Generate the readable log and confirm the GUID the agent used at scan time is the one you expect.

The fix: correct the policy, not the registration

The instinct after finding an unexpected registration is to remove it. Resist that, in most cases. There is a supported control surface for "where do my updates come from", and it is not service surgery.

For the WSUS-versus-Windows-Update question, the fix is the scan source policy plus a correct service URL. Microsoft's guidance reduces the whole thing to two knobs: "The only two relevant policies for where your updates come from are the specify scan source policy and whether or not you have configured a WSUS server." Configure the group policy "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, or set all four CSP policies. The documentation is explicit that you should configure all of them if you go the CSP route.

For the Microsoft Update question - the one that explains stray .NET and Office updates - the API is the right tool, because that is what created the state in the first place. Microsoft's documented opt-in is a single call.

That is worth staring at. My test machine has Microsoft Update as its default AU service because somebody, at some point, passed a flags value with 0x4 set. The documentation for AddService2 spells out the consequence: with asfRegisterServiceWithAU, "the change to the default Automatic Updates service doesn't occur (and isn't reflected in the Windows Update user interface) until the service registration succeeds."

To reverse it, the narrowly-scoped operation is UnregisterServiceWithAU, documented as unregistering a service with Automatic Updates. That drops the AU role without tearing out the registration. RemoveService removes the registration from WUA entirely and is the heavier hammer. Both are on IUpdateServiceManager; there is also a SetOption method documented as controlling "whether a warning is displayed when you change the registration of Automatic Updates".

Sequence the change like a change, not like a fix. Record the enumeration. Make one modification. Re-enumerate. Only then trigger a scan. Change registration and policy in the same window and you will not know which moved the needle.

One special case deserves its own handling. If your enumeration turned up an entry with IsScanPackageService true, that is a leftover offline-scan service. Microsoft's offline scanning guidance shows how they are created - AddScanPackageService("Offline Sync Service", "c:\wsusscn2.cab"), then a searcher with ServerSelection set to 3 for ssOthers and ServiceID set to the returned service. It is a transient construct for a specific scan, not a source you should leave lying around.

Proof it worked: API, registry and decoded log agree

Three independent sources have to tell the same story. If they disagree, that disagreement is the next thing to investigate.

The first two are covered above: the API's IsDefaultAUService and the registry's DefaultService. The third is the decoded trace - the only place recording which GUID the agent actually used during a given scan.

Remember what you are working with. The file at C:\Windows\WindowsUpdate.log is a 276-byte stub on this device; it is not the log. Real traces are ETW .etl files - 99 of them, 42.5 MB, in C:\Windows\Logs\WindowsUpdate - and you convert them with Get-WindowsUpdateLog. Do that after your enumeration, never before, for the reason in the first callout.

Match every GUID you find there against your enumerated list. A GUID in the log that is not in your enumeration means a registration was removed after the scan. A scan against the null GUID, in Microsoft's own worked example, accompanies a criteria string of DeploymentAction=* - which the documentation explains means "there is nothing specified from the server", so the scan runs and returns results with no instruction to download or install.

Then confirm through the event channel. It will not name the service, but it does confirm the scan completed and what it found.

Finally, know which binaries you are exercising, because "the WUA API is broken" is a real diagnosis with a file-level shape. All of these were version 1509.2607.1012.0 - the agent is versioned separately from the 26200.9168 OS build.

The agent also reports its own version through Microsoft.Update.AgentInfo. On this device: ProductVersionString 1509.2607.1012.0, ApiMajorVersion 8, ApiMinorVersion 0. Record those alongside an enumeration.

The habit to take away is small and cheap. Put the two-line enumeration at the top of every Windows Update runbook you own, before the service checks, before the log collection, before anything. Most of the time it confirms what you expected in two seconds. The rest of the time it saves you an afternoon.

References

• Windows Update issues troubleshooting — the two-line Microsoft.Update.ServiceManager procedure, the interpretation table of expected service names (including "Windows Store (DCat Prod)"), the worked null-GUID example, and the placeholder GUID now standing in for the real DCat identifier.
• IUpdateServiceManager (wuapi.h) — the full method list, the Services property description, the Microsoft.Update.ServiceManager ProgID and the Wuapi.dll requirement.
• IUpdateService (wuapi.h) and IUpdateService2 — every property you can read off a registered service, and confirmation that IsDefaultAUService lives on the second interface, not the first.
• Opt-In to Microsoft Update — the Microsoft Update service GUID 7971f918-a847-4430-9279-4a52d1efe18d, the AddService2 sample with flags value 7, and the legacy PendingServiceRegistration seed key.
• AddServiceFlag enumeration and IUpdateServiceManager2::AddService2 — the 0x1/0x2/0x4 flag values that decompose that 7, the pending-versus-online registration behaviour, and the documented error returns.
• Use Windows Update client policies and WSUS together — KB5005101, the scan source policy, the default scan behaviour list, the UseUpdateClassPolicySource requirement, and the dual-scan deprecation.
• Update Policy CSP — the four SetPolicyDrivenUpdateSourceFor policies, their 0/1 semantics, the documented default of 1, and the registry key they map to.
• Windows 10 feature updates not offered on Intune-managed devices — the GUID 855E8A7C-ECB4-4CA3-B045-1DFA50104289 attributed to the DCAT Flighting service, and the 0x80070426 / MSA dependency.
• Troubleshoot Windows Update error 0x80244007 — a real log excerpt showing the WSUS service ID {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} alongside the resolved ClientWebService/client.asmx URL.
• Using WUA to scan for updates offline — AddScanPackageService, the wsusscn2.cab signing and scope caveats, and the ssOthers searcher pattern that a scan-package service requires.
• IUpdateSearcher::get_ServiceID and [MS-UAMG]: ServerSelection — the rule that a non-Windows-Update service is searched only when ServerSelection is ssOthers, and the 0/1/2/3 enumeration values.

Lab notes: every device measurement here was captured read-only on 2026-08-23 from a corporate Windows 11 Enterprise 25H2 machine, build 26200.9168, WUA 1509.2607.1012.0. No registration was added, removed or modified. The console blocks are CSS-simulated renderings of that captured output and of Microsoft's published log excerpts, labelled in each title bar.