How to Disable WSUS via the Registry on Windows Clients?

TL;DR

• WSUS can be disabled on Windows clients by modifying specific registry settings, allowing devices to stop using an internal WSUS server and instead receive updates directly from Microsoft Update when appropriate.
• The guide explains the complete process, including identifying the relevant Windows Update registry keys, backing up the registry, modifying or removing WSUS-related values, restarting Windows Update services, and verifying that clients successfully connect to Microsoft Update.
• Group Policy should be reviewed before editing the registry, as domain-based policies can automatically recreate WSUS registry settings and override manual changes after the next policy refresh.
• The article covers common troubleshooting scenarios, including Windows Update errors, failed policy refreshes, service restarts, registry permission issues, and verifying update source changes using Windows Update logs and administrative tools.
• Organizations should understand when disabling WSUS is appropriate, such as device migrations, troubleshooting update issues, transitioning to cloud-based management, or moving away from on-premises WSUS infrastructure.
• Modern endpoint management alternatives include Action1, Microsoft Intune, Windows Autopatch, Microsoft Configuration Manager (MECM/SCCM), NinjaOne, ManageEngine Endpoint Central, Automox, Atera, and Ivanti Neurons, which offer centralized patch management, automation, compliance reporting, and support for remote and hybrid devices.
• Before making registry changes, administrators should test the procedure on a small group of devices, document configuration changes, verify update behavior after migration, and ensure security policies continue to meet organizational compliance requirements.

Windows client machines in mostly medium to large environments are configured to fetch updates from an internal Windows Server Update Services (WSUS) for security reason, instead of directly fetching from Windows Updates. Pointing to an internal WSUS server is commonly enforced using a Group Policy Object (GPO) to 100s of clients by modifying their registry settings under Windows Update Settings. If that WSUS server is down or decommissioned, clients will not be able to fetch the updates and pointing them to fetch directly from Windows Updates does not work due to next GPO refresh keep pointing to WSUS server again. This article covers two registry based methods to disable WSUS Registry on a client machine and preventing GPO from undoing the change.

When and Why to Disable WSUS

Windows Server Update Services are excellent for controlling the patch deployment along with bandwidth across the network but there are several scenarios where an admin must separate a client computer from the local update infrastructure. Below are some common scenarios.

• When a WSUS server is not reachable, decommissioned or faces a critical hardware failure, client machines pointed to that server will face errors when they try to fetch new updates, specially security patches and will be vulnerable to security threats. Administrators must intervene to disable the WSUS link, enabling those client machines to directly connect to the Microsoft Update server. An example would be a WSUS server facing critical hardware problem and shuts down, leaving 50 plus computers failing with update errors until their WSUS registry paths are removed or pointed to a working WSUS server.
• Administrators working in isolated lab environments for troubleshooting update-related issues or creating reference operating system images may need immediate access to new security patches from Microsoft Update servers directly. Waiting for a WSUS server to synchronize, approve, and download these updates will take time and may disrupt the development cycle. Disabling WSUS in the registry ensures that test environments can fetch critical updates on demand. An example would be a deployment engineer temporarily unlinking a Windows 11 reference VM from WSUS to be able to download directly from Microsoft.
• A standalone desktop or laptop accidentally moved into a WSUS GPO scope OU, this can be a misconfiguration case, the machine was using its own direct connection to Microsoft Updates but due to the scope, now inheriting the GPO settings and uses WSUS. A concise example would be a vendor’s laptop needed to join an Active Directory domain for a critical software or agent installation, but then gets its registry updated by the WSUS server path and is no longer able to connect to it when it leaves the building, missing the next critical updates.
• Critical production servers need urgent zero day security patching and cannot wait for the next monthly maintenance due to being locked down by WSUS schedule. Disabling WSUS for that particular server provides the administrators immediate control over the Windows Updates to ensure its security. A concise example would be an admin bypassing a corporate SQL server from WSUS to install a vulnerability patch at any time outside of the WSUS maintenance cycle.

To achieve this control, whatever the reason, you will learn in the next section how to force your Windows clients to communicate directly with the Microsoft Update server by modifying specific keys in the Windows Registry.

Understanding the Registry Key to Modify

Windows Registry needs careful understanding, Windows Update behavior on client machines is controlled by two paths under policy branch of Windows settings, which contains settings applied by either Local Group Policy or Active Directory Group Policy; misconfiguration of these paths can lead the clients to completely ignore the changes. Below are the two paths for WSUS registry entries; we will explain them in detail in the following sections.

Parent WSUS Registry Key

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

Specific Subkey for automatic updates

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

The UseWUServer DWORD value (0 = disabled, 1 = enabled)

The UseWUServer DWORD is the actual binary switch that dictates whether Windows looks for an internal WSUS server on the local network or an external network, such as the Microsoft Update server, for patches and updates. Setting this value to 1 tells the operating system to use HTTP or HTTPS path of WSUS server to connect and fetch updates, while setting this value to 0 bypass the internal WSUS server paths and query the Microsoft Update servers. Windows Update Service (wuauserv) reads this value only during startup rather than continuous registry monitoring; a service restart is required if the DWORD value is changed. Below is how this registry key will look with a value.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]

“UseWUServer”=dword:00000001

Key path: HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

This is the specific subkey that controls the behavior of Automatic Updates and contains the WSUS targeting flag, along with other automatic update-related settings. If this subkey and its underlying value does not exist, it means that Group Policy have never been configured on the machine for managed updates, as Windows does not automatically populate this subkey. This also confirms that the machine is configured for communicating directly with Microsoft Update servers. To confirm these values, open registry editor by typing “regedit” on “Run” dialog box on the client machine and navigate to below path and check if the UseWUServer value is present.

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

The WindowsUpdate parent key — full removal option

The HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate is the parent registry key which contains all the Windows Update policy values such as WSUS server paths, WSUS reporting server path or target group. It contains the AU subkey and values such as UseWUServer, ScheduledInstallDay, ScheduledInstalledTime or RebootWarningTimeOut DWORDs. Deleting this parent key is the full removal or nuclear option; it removes all WSUS and Windows Update policy bindings applied to the client machine. Administrators should prefer this method when they want to restore immediate cloud-based patching functionality instead of troubleshooting dozens of WSUS configurations on a client machine.

Method 1 — Set UseWUServer to 0 (Quick Toggle)

Bypassing the local update policy by toggling the UseWUServer registry value is the most efficient way for temporarily disabling WSUS, leaves your existing WSUS server configurations intact within the registry for later use by a quick reversal, and leverages the direct connectivity to Microsoft Updates.

Note: The core registry path and its structural behavior are completely identical across Windows 10, Windows 11, Windows Server 2019, and Windows Server 2022.

Restart the wuauserv service after the change

Windows Update service (wuauserv) reads those registry parameters exclusively during its initialization sequence, not as dynamic hot reloading of paths. If the service is running and modifications are made to the registry, the service will only recognize them upon the next initialization, which requires a service restart. Restarting the service flushes its runtime memory with existing configurations and loads new configurations. Admins can use the following two commands in command line or PowerShell cmdlet respectively to restart the Windows Update service.

Administrative Command Line

net stop wuauserv

net start wuauserv

PowerShell

Restart-Service wuauserv

Verification Tip: To verify that this registry toggle has worked, admins should navigate to SettingsèWindows Update and make sure that warning message “Some settings are managed by your organization” is not there.

CMD / Batch Script approach (reg add)

The easiest way to modify the registry is still to use the Registry Editor, but what if you have to modify the registry for WSUS settings on multiple client machines? Admins can use the reg native command-line utility with the one-liner below; it can be executed as a batch file on multiple clients. This command must be executed using an elevated command prompt.

reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU” /v UseWUServer /t REG_DWORD /d 0 /f

Each parameter serves a unique purpose as follows:

• /v parameter is used to define specific value name under the specific registry location.
• /t defines the registry data type e.g. REG_DWORD.
• /d specifies the data being injected to registry value, in this case it will be 0.
• /f is the force switch, overwriting the existing value without any warning prompt.

Same command can be run to revert the re-enable WSUS settings with just changing the /d parameter with value 1.

reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU” /v UseWUServer /t REG_DWORD /d 1 /f

PowerShell approach (Set-ItemProperty)

PowerShell can also be used for registry modification; it provides efficient error handling in automated scripted deployments. Set-ItemProperty cmdlet is highly efficient for existing registry value modifications. Use the full cmdlet below to modify the UseWUServer value.

Set-ItemProperty -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU” -Name “UseWUServer” -Value 0

Automation script must include error handling in case if the registry value does not exist, adding -ErrorAction and SilentlyContinue parameters allow scripts to run silently and smoothly. Use the below cmdlet to create registry key, value and update data if the key does not exist.

New-ItemProperty -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU” -Name “UseWUServer” -PropertyType DWord -Value 0 -ErrorAction SilentlyContinue

Note that both PowerShell cmdlets require administrative privileges; run them as Administrator.

Below is a complete PowerShell script that checks UseWUServer current state, toggles it to 0, restarts Windows Update service, and confirms Windows Update is now pulling from Microsoft by again verifying the registry change just made. Save the below script in a text file, rename the file extension to .ps1 and run it on a client machine using WSUS for pulling updates.

# Disable WSUS configurations on a client machine to force it to use Microsoft Update

$Path = “HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU”

# Show current value of UseWUServer

Get-ItemProperty -Path $Path -Name UseWUServer

# Change the value to disable WSUS

Set-ItemProperty -Path $Path -Name UseWUServer -Value 0

# Restart Windows Update service

Restart-Service wuauserv

# Verify the value has been changed.

Get-ItemProperty -Path $Path -Name UseWUServer

Method 2 — Delete the Entire WindowsUpdate Registry Key

Toggling UseWUServer value is only sufficient if the requirement to use Windows Update server is temporary no matter what the reason is, deleting the entire parent key with every WSUS configuration is the proper way, but this is the nuclear option and is not revertible. There are two possible scenarios as follows.

• When a full WSUS server is being decommissioned and requires a clean slate for all its serving clients, maybe later pointing to a new WSUS server. Or an organization is fully migrating its device fleet from domain-joined to Microsoft Intune and from Windows Update Services to a cloud-based patch management program. These WSUS registry keys can cause unexpected configurations and compliance issues with third-party patch management agents.
• Due to WSUS configurations being applied by domain Group Policy Objects, these settings are not sticking, and upon the next client restart or when the Group Policy refreshes, it will revert the value back to using WSUS server configurations. Enforcing complete removal of the parent WindowsUpdate key ensures the successful direct connection to the Microsoft Update Server.

Administrators can safely remove the WindowsUpdate key using Registry Editor GUI for standalone systems or individual troubleshooting sessions, by navigating to HKLM\SOFTWARE\Policies\Microsoft\WindowsèRight click on WindowsUpdate keyèSelect Delete.

Administrators who want to use automated helpdesk scripts for registry key removal on multiple remote computers using Group Policies or Endpoint Management tools can use the command below as a batch file.

reg delete “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate” /f

Note: Beware that removing the WindowsUpdate key will also remove any non-WSUS policies your organization may have set, so be careful.

Note: Do not forget to restart the Windows Update Service on target computers after deleting the whole registry key using both GUI and command line methods.

How to Re-enable WSUS When Done

Once admins are finished with typical scenarios such as troubleshooting, isolated testing, or creating golden images with specific updates after disabling WSUS, they must restore the clients to use the WSUS server again for downloading the updates. This ensures that endpoints start receiving approved and staged updates and report back compliance to the WSUS reporting server. If you have used method 1 by setting the UseWUServer value to 0, reverting back is straightforward process by just changing the value back to 1 using the below command and restart the (wuauserv) service.

reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU” /v UseWUServer /t REG_DWORD /d 1 /f

Re-enabling WSUS will work instantly as all your WSUS related configurations were still intact when you changed the value to 0, clients will be directed to use WSUS server instead of Microsoft Update cloud servers. But if you have removed the entire WindowsUpdate parent registry key, toggling just one value will not work, you will have to reapply all the WSUS related settings using GPO or manually recreate all values, this is why method 1 is preferred for temporary disablement.

Critical Caveat: Group Policy Will Re-Apply WSUS Settings

As discussed earlier, modifying the registry locally on domain joined machines is temporary as Active Directory uses continuous enforcement of local configurations and settings using Group Policy Objects for centralized security baseline. In this section, we will explain why it happens and how to troubleshoot it.

• Windows background processing engines periodically pull down the configurations from domain controllers automatically by default every 90 minutes, that is why modifications to UseWUServer value or complete WindowsUpdate key removal keeps getting reverted, because machines are still in the GPO scope for applying WSUS related settings.
• To determine which Group Policy is overriding the local WSUS registry modifications, run the following Group Policy diagnostic tool command in an elevated command prompt; it will generate a report containing all the Group Policy Objects applying computer configurations.

Gpresult /r

• When performing the registry edits for disabling WSUS server settings, run the gpupdate /force command to see if the changes are reverting, instead of waiting 2 hours for the next policy refresh to take effect. Force parameter instruct Group Policy engine to bypass optimization checks and apply the policies immediately.

In order to make the local registry change permanent, either edit the GPO and explicitly deny the applying permissions to that specific machine in security filtering settings or move the machine from the OU on which the WSUS setting GPO is being applied.

Perform the below two-step WSUS persistence audit workflow to verify if you client machine is in the policy enforcement loop.

1. Run the below command in an elevated command prompt to discover which Group Policy Object is applying the updates settings. Change the string value in -i parameter to any other such as “Update Management Policy” or “Update Policy WSUS”, as policy name could differ based on organization’s GPO naming conventions.

gpresult /r | findstr -i “wsus”

2. Query the registry path directly using the command line by running the following command to see if an intranet WSUS server is being used for direct communication with Microsoft Update servers.

reg query “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate” /v WUServer

Discover our complete WSUS Setup Guides