Windows - Configuration - Disable Check for Updates

What the Check for Updates button disabler does

This Automox Worklet™ hides the Check for Updates button on the Windows Update page of the Settings app. The Worklet writes the SetDisableUXWUAccess policy value at HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate as a DWORD of 1, which matches Microsoft's documented Update/SetDisableUXWUAccess CSP setting.

The control applies only to the user-facing Settings UI. It does not edit NoAutoUpdate under the WindowsUpdate\AU subkey, does not change the WUServer or WUStatusServer values that point an endpoint at WSUS, and does not disable the Windows Update service, UsoClient.exe, or the scheduled update scan tasks. Automatic scans, downloads, and installs continue running against whatever update source your patch policy assigns.

The Worklet evaluates and remediates a single registry value, so it is fast, idempotent, and safe to run on a recurring schedule. The remediation script calls RegistryKey.CreateSubKey against HKLM, which both creates the WindowsUpdate policy key when it is missing and sets the DWORD when it is present but holds the wrong value. Endpoints already at the desired state exit zero without making any registry write.

Why enforce the managed patching cadence

When the Check for Updates button is reachable, every end user is one click away from pulling whatever Microsoft Update or WSUS has staged at that moment. That click bypasses maintenance windows, defeats deferral rings, and can pull a feature update into a workstation that the patch team had explicitly held back. The Settings app also surfaces the Get the latest as soon as they're available toggle on Windows 11, which has the same effect: it pulls forward the install schedule a managed environment is trying to pace.

Setting SetDisableUXWUAccess to 1 removes the manual entry point so the rest of your WSUS, Automox, or Intune configuration actually governs when updates land. The value drifts in three predictable ways: a Windows feature update rewrites HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate, a competing Group Policy on the same OU pushes a conflicting value, or an admin runs Reset-WindowsUpdate during a break-fix and clears the key. This Worklet asserts the value on every evaluation, so the next policy pass catches a re-enabled Check for Updates button before it pulls an unscheduled feature update into a production workstation.

How the Settings app update check is blocked

1. Evaluation phase: The Worklet opens the LocalMachine hive with [Microsoft.Win32.RegistryKey]::OpenBaseKey, reads SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\SetDisableUXWUAccess, and compares the current value against the desired DWORD of 1. Endpoints that return 1 exit zero as compliant. Endpoints that return a missing key, a different value, or a different type are flagged for remediation and the policy proceeds to the remediation script.

2. Remediation phase: The Worklet calls CreateSubKey on the WindowsUpdate policy path, which creates the subkey when it does not exist, then writes SetDisableUXWUAccess as a DWORD of 1. The change takes effect for new Settings sessions immediately and survives reboots and feature updates. The remediation script writes Registry key created successfully. on success and exits 0, or exits 1 with the underlying exception on a registry access failure.

SetDisableUXWUAccess policy requirements

• Windows 10 version 1809 or later, Windows 11, or Windows Server 2016 and newer (the Update/SetDisableUXWUAccess CSP was introduced in 1809)

• PowerShell 3.0 or later, which is pre-installed on every supported Windows release

• The Automox agent running in its default SYSTEM context, which already has the rights needed to write under HKLM\SOFTWARE\Policies

• No conflicting Group Policy at Computer Configuration > Administrative Templates > Windows Components > Windows Update > Remove access to use all Windows Update features that holds the value to 0; GPO refresh will overwrite the registry between policy runs if it does

• Endpoints managed by WSUS, Automox Patch, Intune, or another central patching source – the Worklet hides the manual surface but does not replace the patch policy itself

Expected Settings app behavior after remediation

On the next Settings session, the Windows Update page loads without the Check for Updates button. On Windows 11 the page header shows the current update status, the pause options, and the schedule, but the manual trigger is gone. The endpoint continues to scan, download, and install updates on the cadence your patch policy already defines, and UsoClient.exe StartScan still runs from the scheduled task surface and from the Automox patch policy itself. Only the user-driven check is suppressed.

Validate compliance with a one-line PowerShell read against the same registry value the Worklet wrote: Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' -Name SetDisableUXWUAccess. A return of SetDisableUXWUAccess : 1 confirms the policy is in place. For a visual check, open Settings > Windows Update on a remediated endpoint and confirm the button no longer renders. Capture both outputs against the policy run identifier as audit evidence for change management or for CIS-aligned baseline reviews of Windows Update configuration controls.