WSUS: Troubleshooting and Best Practices

Issue

A Windows device managed by WSUS is not receiving the updates expected through Automox, or an administrator needs to confirm which WSUS settings apply to a device and which Group Policy sets them.

Environment

• Automox (current agent release)
• Windows (domain-joined or otherwise GPO- or MDM-managed)
• WSUS

How WSUS interacts with Automox

On Windows, Automox patches through the Windows Update Agent (WUA), so a device pointed at a WSUS server receives only the updates that server carries and has approved. When a group's OS Patch Management Windows Update Source is set to WSUS (with a WSUS Server Address), the device scans and determines applicability against that WSUS server. Third-party application updates are not served from WSUS, as Automox downloads those directly from Automox's own CDN.

Group Policy can also set the update source, so GPO and Automox group settings can conflict — a device may toggle between sources across scan intervals. Group Policy takes precedence on Windows, so where a GPO manages Windows Update, set the group's Windows Update Source to Keep Device's Setting. For the console-side options, see OS Patch Management Settings for Groups and Configuring WSUS for Automox Integration.

The decisive setting: UseWUServer

Whether a device uses WSUS at all is controlled by a single value:

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer (REG_DWORD)

• 1 — the device uses the WSUS server named in WUServer.
• 0 or absent — the device contacts Windows Update / Microsoft Update directly.

The WUServer and WUStatusServer values are ignored unless UseWUServer is 1.

Where WSUS settings live in the registry

All paths are under HKEY_LOCAL_MACHINE (HKLM). GPO-driven settings are written under the Policies hive.

...\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate — service location and scan behavior:

...\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU — Automatic Updates behavior:

Non-policy state lives under ...\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update; the Policies hive overrides it. MDM/Intune settings land under ...\SOFTWARE\Microsoft\PolicyManager\current\device\Update, a different tree — a device may have GPO settings, MDM settings, or a conflicting mix.

The Group Policies that set them

Group Policy path for all of the following: Computer Configuration → Administrative Templates → Windows Components → Windows Update → …

UseWUServer is not a standalone policy — Windows sets it to 1 automatically when the intranet update service location is specified.

How to find these settings on a device

Step 1 — Identify which GPO is winning.
In an elevated Command Prompt, generate an HTML Resultant Set of Policy report, then open it and check the Winning GPO column for each Windows Update setting:

gpresult /h C:\rsop.html

For a quick text summary of the applied computer-scope policies:

gpresult /r /scope computer

Step 2 — Dump the WSUS registry keys.
Read the full WindowsUpdate key and its \AU subkey:

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

To check only the decisive WSUS switch:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer

Step 3 — Or read the keys with PowerShell.

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"

On an MDM/Intune-managed device, also check the MDM policy tree:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update"

Step 4 — Confirm the server the client actually contacted.
On Windows 10/11 the update log is written as ETL traces. Decode them into a readable WindowsUpdate.log (written to the Desktop), then review the ProtocolTalker (PT) entries to see which server the client reached:

Get-WindowsUpdateLog

Step 5 — Check the console signal.
In Settings → Windows Update, the message "Some settings are managed by your organization" confirms that policy (GPO or MDM) is present. (Visual check — no command.)

What to look for, and when

• WSUS or Windows Update? Read UseWUServer first — 1 = WSUS (read WUServer), 0/absent = Windows Update / Microsoft Update directly. This is the most decisive value when a device is not receiving expected updates through Automox.
• Client-side targeting. TargetGroupEnabled=1 with a TargetGroup means the client declares its own WSUS group; the name must match a WSUS console group or the device lands in "Unassigned Computers" and receives nothing.
• Unreachable or mis-set WSUS server. A wrong host/port (WSUS defaults 8530 HTTP / 8531 HTTPS) or an offline server surfaces as scan failures and stale devices. Confirm the reachable endpoint from the decoded log's ProtocolTalker entries.
• Deferrals that withhold updates. Windows Update for Business deferral policies intentionally hold updates until their window elapses, so a device can scan correctly and still report no updates available — expected behavior, not a failure.
• Dual scan (Microsoft mechanism). When a WSUS server is set and a deferral policy is present, older Windows builds could scan both WSUS and public Windows Update. Microsoft controls this with DisableDualScan and has deprecated it on Windows 10/11. This is a Microsoft-side setting — to change a device's source in Automox, use the group's Windows Update Source.

Best practices and resolving conflicts

• Pick one authority. Where WSUS is not required, manage the source through the Automox group's Windows Update Source and remove WSUS settings from Group Policy to avoid the source-toggling conflict. Where a GPO manages Windows Update, use Keep Device's Setting.
• Ensure WSUS carries and approves what you expect. WUA (and therefore Automox) only sees updates present and approved in the WSUS database — confirm the required Classifications and Products are enabled and the updates approved, or they will not appear in Automox.
• Ensure reachability. Devices must reach the WSUS server during scans and policy runs; remote devices typically require VPN access to an intranet WSUS server.

Other options

• Microsoft Intune / Windows Update for Business (Update Rings) — the cloud alternative to WSUS + GPO; settings land in the MDM (PolicyManager) registry tree, not the GPO Policies hive.
• Local Group Policy (gpedit.msc) on non-domain devices writes the same Policies-hive values.

Notes

• UseWUServer is the definitive indicator of WSUS management; WUServer/WUStatusServer are ignored without it.
• MDM/Intune Windows Update policy lands in a different registry tree than GPO — check both on a co-managed device.
• Third-party application updates are not served by WSUS and are unaffected by the WSUS source setting.