Detect Windows Update Group Policies on Windows Endpoints

What the Windows Update policy audit Worklet does

This Automox Worklet™ collects the Windows Update policy picture from a Windows endpoint and prints it to the Automox Activity Log. It runs gpresult.exe /r /scope:computer to list every applied computer-scoped Group Policy Object, then reads the two policy-backed registry keys where Group Policy writes Windows Update settings: HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate and HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU.

Every value it finds is reported with its data, its source key, and a description of what the setting controls. The Worklet recognizes more than 70 value names, including WUServer, UseWUServer, NoAutoUpdate, AUOptions, DisableDualScan, DeferQualityUpdatesPeriodInDays, DeferFeatureUpdatesPeriodInDays, PauseFeatureUpdates, BranchReadinessLevel, TargetReleaseVersionInfo, and ProductVersion. Anything it does not recognize is still reported as a policy-applied Windows Update setting, so nothing gets dropped.

Values that Automox manages directly through your device group patch settings, such as AUOptions, NoAutoUpdate, UseWUServer, WUServer, WUStatusServer, and DisableDualScan, carry a note saying so. That keeps you from hunting for a GPO that does not exist. The Worklet is read-only from end to end, so you can run it against production endpoints in the middle of the day.

Why audit Windows Update Group Policy

Stubborn patching problems usually trace back to policy rather than to the agent. A forgotten GPO can pin endpoints to a decommissioned WSUS server, defer quality updates by 30 days, pause feature updates indefinitely, or hold a machine on one feature update version long after the team that wrote the policy moved on. The endpoint reports healthy while patches quietly never arrive.

Finding that by hand means remoting into each endpoint, running gpresult, and translating raw registry value names into real behavior. This Worklet does the same work across a whole device group in one run and returns output an administrator can read, so you know which policy object to edit before you change anything.

The output also doubles as evidence. Change advisory boards, CIS Benchmark reviews, and SOC 2 control walkthroughs all ask how update behavior is enforced on endpoints. A timestamped Activity Log entry that names each applied GPO and each policy value answers that question per endpoint without a screenshot exercise.

How the Windows Update policy scan works

1. Evaluation phase: Runs gpresult.exe against the computer scope to confirm Group Policy is reachable and to capture the list of applied Group Policy Objects, then enumerates every value under the two WindowsUpdate policy keys. An endpoint with no policy-applied Windows Update or Update Channel values is reported compliant and the run stops there.

2. Remediation phase: Reports instead of repairing. It writes the full Resultant Set of Policy summary for the computer scope to the Activity Log, followed by each policy-applied Windows Update setting, its value, its source key, and a description of its effect. No registry value, Group Policy Object, service, or update setting is modified.

Windows Update policy audit requirements

• Windows 10, Windows 11, Windows Server 2016, or later, with the Automox agent running as SYSTEM

• An English Windows display language: applied GPO names are parsed from gpresult.exe output, and localized output may not be recognized on non-English installations

• gpresult.exe available in the System32 directory, which is standard on supported Windows builds

• Read access to HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate and its AU subkey

• No variables or parameters to configure before you run it

Run it on demand from the endpoint page with Run on This Device, or from the policy page with Run Policy, so the report lands in an Activity Log entry you can find right away.

Expected output after the policy scan

On an endpoint with no Windows Update policy in play, the Activity Log confirms how many computer-scoped GPOs are applied, names them, and states that no policy-applied Windows Update or Update Channel settings were detected. The endpoint is reported compliant and nothing else runs.

On an endpoint where policy is active, the log lists every applied Group Policy Object, then each detected setting with its value, source key, and description. Use the GPO list to identify which policy object owns the setting, edit or unlink it in Group Policy Management, run gpupdate, and re-run this Worklet to confirm the value is gone. Settings marked as Automox-managed are expected and need no GPO work.