Windows Update scan sources: verify each update class before closing a WSUS gap

What a Missing WSUS Marker Says About Windows Update Scan Sources

Windows Update scan sources determine where a client looks for updates. A collected WUServer value answers a narrower question: did the audit find a nonempty WSUS server string in a GPO? That string cannot establish which update classes use the server, whether the policy reaches a particular computer, or whether its latest scan succeeded.

Start a WSUS finding review with the intended update strategy. An organization can manage clients centrally while choosing Windows Update as their source. Conversely, a WSUS URL can exist in a policy while an affected population uses another source or cannot complete its scans. Treat policy configuration, successful scanning, and installed patch compliance as three separate evidence sets.

This walkthrough covers the Windows 10/11 client behavior documented by Microsoft. Its scan source policy applies to Windows 10 version 2004 and later with the documented servicing prerequisites, and Windows 11. Record edition, version, build, and management method before applying it. Do not extend the client behavior table below to every Windows Server release; assess servers against their own supported policies and deployment design. Microsoft's scan source guidance defines this client scope.

How It Works: Four Update Classes and Different Defaults

Microsoft allows separate selection between WSUS and Windows Update for feature updates, quality updates, driver and firmware updates, and updates for other Microsoft products. A migration can therefore move one class before the others. An audit record needs a source for each class, rather than a single label such as “cloud managed” or “uses WSUS.”

The following summarizes the documented default scan behavior for the supported Windows clients. Read it alongside the actual policy result on each population:

Microsoft also identifies a migration trap: Do not allow update deferral policies to cause scans against Windows Update, the older dual scan policy, is unsupported on Windows 11 and replaced by the scan source policy on Windows 10. Configuring both on Windows 10 prevents updates from Windows Update. Inventory that legacy policy before changing the newer source settings. These distinctions come from the Windows Update and WSUS scan behavior reference.

Source selection is also distinct from reporting and content delivery. Specify intranet Microsoft update service location has a detection/download server field and a statistics server field. They can point to the same server, but serve different purposes. An optional alternate download server changes where files are downloaded. It does not replace the need to establish the intended scan source. Microsoft's additional Windows Update settings describes those fields and download options.

An HTTPS endpoint needs its own transport validation. Use our WSUS TLS and client URL checks for that review. Here, the question is which source each update class should use and whether the client actually scanned it successfully.

Detection: Reconcile Applied Policies with Client Evidence

Step 1: Identify Populations and Policy Owners

Split the estate by OS build, management method, and meaningful policy scope. Include remote clients and any population required to retain an on-premises update source. For each population, ask who owns feature, quality, driver/firmware, and other-product updates; which classes should use WSUS or Windows Update; and what network constraints apply.

Collect the applied GPO result on a representative target in each scope, then expand verification to the affected computers. Microsoft's gpresult command reference documents computer scope and verbose output:

gpresult /scope computer /v

Review the actual settings and contributing GPOs. A policy visible in the domain inventory may be irrelevant to this computer. For MDM-managed or co-managed clients, also collect the assigned and effective management policies from the existing management system. GPO output alone does not establish the CSP result. Resolve disagreements with the responsible management owners; do not assume that a policy's existence tells you which authority wins.

Step 2: Inspect WSUS and Class-Specific Source Settings

The source policy 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.

For CSP-managed clients, Microsoft lists four policies:

The scan source configuration guide says to configure all four when using CSPs. The Update CSP reference documents 0 for Windows Update and 1 for WSUS for these source settings. It also warns that the policies have no effect if Update/UpdateServiceUrl has not been configured correctly to point to WSUS. Check applicability and prerequisites before interpreting a configured value.

On a target, the following uses Microsoft's documented reg query syntax to read the Windows Update policy branch recursively:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s

The Windows Update settings reference documents WUServer and WUStatusServer under that branch, and UseWUServer under its AU subkey. Review the configured update endpoint, statistics endpoint, and WSUS-use setting together. These are local configuration observations, not successful-connection results. Missing output must be reconciled with policy scope and the management method.

Microsoft recommends configuring scan sources through GPO or CSP instead of direct registry writes. Its scan source guidance specifically warns that a registry-based change also needs UseUpdateClassPolicySource or the source will not change. Use the supported policy workflow for corrections; do not add a string simply to satisfy a detector.

Step 3: Collect a Successful Scan and a Separate Patch Inventory

On the Windows client, Microsoft's Get-WindowsUpdateLog reference documents conversion of Windows Update ETL traces into a readable log:

Get-WindowsUpdateLog

This converts diagnostic traces; it does not initiate a scan or certify update installation. Use retained client diagnostics and the existing management platform's scan records to investigate the actual service contacted, scan completion, timestamps, and failures. Attach the device identity and evidence window. If the available records cannot establish a class or source, mark that part of the matrix unknown instead of inferring it from a URL.

Then compare the installed update inventory with the organization's applicable patch baseline. Record inventory freshness, applicability, installation results, and pending work separately. A successful scan can discover updates that remain uninstalled. A populated statistics endpoint or a recent management check-in cannot substitute for this installation evidence.

Remediation: Correct Proven Source Divergences

Step 1: Build the Source, Class, and Population Matrix

Create one copy of this worksheet for each population. The cells are evidence to collect, not example results from an environment:

Keep intended source and effective source separate. If a managed population intentionally uses Windows Update, document that decision, the governing policies, responsible owner, and scan/installation evidence. Installing WSUS to make an audit marker disappear would not answer those operational questions.

Step 2: Change the Responsible Policy in a Pilot Scope

Correct only the mismatch supported by the worksheet. For clients intended to use WSUS, validate the intranet service configuration and the class selections through the owning GPO or CSP workflow. For a planned mixed-source transition, set each class to its approved source and configure all four CSP settings when that is the deployment method.

Reconcile old dual scan controls before the pilot. Also examine Do not connect to any Windows Update Internet locations where it applies: Microsoft warns that this setting can stop public services, including Windows Update client policies and Delivery Optimization, from working. A cloud-source decision needs compatible network and policy constraints. Follow the documented Windows Update settings behavior, rather than broadly removing restrictions without checking their purpose.

Keep the detection server, reporting destination, and optional download server aligned with the approved design. Preserve the prior configuration for rollback and agree on a pilot evidence window with the update owner. Configuration Manager or other existing management requires its own client configuration review; this procedure does not replace that management workflow.

Step 3: Repeat the Same Measurements Before Expanding

After the policy applies, rerun the GPO and registry reads, collect fresh MDM evidence where relevant, and observe successful scans against the intended service. Investigate failed scans, unintended sources, or missing evidence before expanding the change. Check installation compliance independently after the deployment window.

Attach this evidence to the recurring AD audit workflow and post-change verification cadence. Recheck the matrix after changes to policy scope, management ownership, or network access. A later reviewer should be able to distinguish intentional Windows Update use from a lost policy or an incomplete collection.

How EtcSec Detects This

The reviewed etc-collector implementation of PA038_WSUS_NOT_CONFIGURED examines collected GPOPolicies. A nonempty WUServer string in any GPO sets its count to 0. If there are no policies, or every available value is absent or empty, it returns a Low finding with count 1. This count does not describe the number of unmanaged or unpatched clients.

The reviewed Registry.pol parser maps a nonempty string named WUServer when the registry key contains windowsupdate. The SMB collection routine ignores unsuccessful file reads at these call sites and still retains the GPO policy object. A missing or unreadable policy file can therefore leave the expected data absent without a separate read-error result here.

This check does not resolve per-target GPO application, links, filtering, or precedence. It does not validate the URL or protocol, inspect UseWUServer or WUStatusServer, collect the CSP source settings, distinguish update classes, test connectivity, confirm a successful scan, or inventory installed patches. A positive marker in an unrelated GPO can satisfy the check while leaving the population under review unresolved.

Use the finding to open the population-specific verification described above. Retain intentional cloud-source decisions and collection unknowns in the audit record. Resolve the operational issue only when the intended source, effective client policies, successful scans, and separate installation inventory have been reconciled.