Windows Update Registry Settings | WSUS, Intune, & Configuration Manager

TL;DR

• WSUS registry settings determine how Windows devices discover, download, and install updates, allowing administrators to redirect clients from Microsoft Update to an internal WSUS server and centrally manage patch deployments.
• The guide explains the most important registry keys, including WUServer, WUStatusServer, TargetGroup, TargetGroupEnabled, UseWUServer, AUOptions, DetectionFrequency, NoAutoRebootWithLoggedOnUsers, and ScheduledInstallDay, along with their purpose and configuration.
• WSUS registry values are typically managed through Group Policy, Microsoft Intune, Configuration Manager (ConfigMgr/MECM), or PowerShell scripts, ensuring consistent update policies across enterprise environments while minimizing manual configuration.
• Troubleshooting often begins with verifying registry settings, since outdated server URLs, missing policy values, conflicting management platforms, or incorrect Group Policy application are among the most common causes of Windows Update failures.
• The guide also explains registry ownership in co-managed environments, helping administrators distinguish between traditional WSUS policies, Intune Update CSP settings, Configuration Manager policies, and scenarios where overlapping policies create conflicts.
• Best practices include deploying registry settings through centralized management tools, avoiding manual registry edits on production devices, validating policy application after configuration changes, and routinely auditing client configurations to maintain update compliance and simplify troubleshooting.
• As organizations move toward cloud-native endpoint management, modern patch management platforms reduce reliance on manual registry configuration by automating Windows updates, third-party application patching, compliance reporting, and endpoint management across distributed and hybrid workforces.

WSUS registry settings are configuration keys stored in the Windows Registry that control how clients’ machines discover, download, and install Windows updates from an internal server. These settings allow administrators to direct client computers to internal Update server instead of going towards public Microsoft Update service, ensure consistent patching, compliance and administrative control across the organization. Administrators can deploy this configuration via Group Policy Objects (GPOs), Mobile device management (MDM) tools like Microsoft Intune or through Microsoft Configuration Manager. These tools automatically create, update and enforce the appropriate registry values, required for each platform, on managed endpoints, ensuring consistency across thousands of devices.

What are WSUS Registry Settings and Why Do They Matter?

WSUS registry settings are configuration values with which WSUS server controls how clients connect to WSUS server, scan for updates, download and install updates through Windows update agent. For system administrators, understanding these settings is critical because they provide granular control over update and reboot behavior, target groups, scan intervals, and compliance enforcement. The location of WSUS server-related settings resides under

“HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate” registry path. The values stored here determine critical updates behavior such as WSUS server URL, target group assignment, update detection frequency and client-side targeting. These settings are the troubleshooting starting point when windows update failure occurs, administrators first inspect registry settings to verify if the devices are receiving the intended policies. Missing, duplicate or outdated values explain why a device cannot contact WSUS or fails to receive updates. For example, if a client registry value is still pointing to an old WSUS server, either the GPO didn’t correctly update the new WSUS value or client is not in the target of GPO, and thus the client is not contacting correct WSUS server for receiving updates. These values can be updated through Group Policy, through Intune MDM policies, Configuration Manager client or through custom scripting. However, administrators should always verify which management platform owns Windows update settings, whether Group Policy and cloud platform policies are overlapping, or if Configuration Manager co-management settings are correctly configured, because conflicts between different management solutions settings are common cause of Update failures.

WSUS Core Registry Settings

The following registry values are the most important client-side WSUS settings. These settings determine where Windows clients obtain updates, how they report compliance, and which WSUS computer group a client belongs to.

https://learn.microsoft.com/en-us/windows/deployment/update/waas-wu-settings

WUServer: This registry value holds the full HTTP or HTTPS URL of the WSUS server, including the port number, which the Windows Update Agent uses to connect to the local WSUS server. It requires a URL as the value, a fully qualified domain name (FQDN) or IP address, and port 8530 (HTTP) or 8531 (HTTPS). Configuring this key is the first step to enforce localized, internal enterprise update management and direct client computers to connect to a local WSUS server instead of Microsoft Update servers over the internet.

Example: WUServer = https://wsus1.copr.contoso.com:8531

Both server FQDN and port number are important; if the URL is incorrect, unreachable, or points to a retired server, update scans and deployments will fail on clients.

WUStatusServer: This configuration explicitly tells the client machines where to send its post-scan compliance reports, installation success receipts, and error codes. It must be set exactly as the same value as WUServer registry. If the two values differ even by a trailing slash or upper/lower case, updates may get installed successfully on clients, but the WSUS console will show clients as “unknown” or “Not yest reported”. For example, a client downloads updates from https://wsus1.copr.contoso.com:8531 according to WUServer registry value, and it must report its status to the same server https://wsus1.copr.contoso.com:8531, not to any other WSUS server URL https://wsus2.copr.contoso.com:8531

UseWUServer: It is a DWORD value that acts as an activation value for all WSUS redirection, and its value set to 1 instructs clients to use the WUS server, and a value set to 0 or an absent value directs clients to use the Microsoft Update server over the internet. This settings misconfiguration is one of the most common reasons when clients with a correctly populated WUSServer value still pull updates from the internet. Changes to this setting require restarting the Windows Update server or performing a policy refresh before it takes effect. For example, setting UseWUServer to 1 activates local WSUS update management and forces clients to get updates from the local WSUS update catalog.

Targetgroup: it is a REG_SZ value containing the exact name of the WSUS computer group the client should join, that is created within the WSUS administrator console. This setting is used for client-side targeting, and administrators use this setting to automate update deployment rings such as deploying updates first to a test group, then to a pilot group, and afterward production and critical servers. For example, a client machine is in the testing group “Test”; i.e., updates are first tested on this client. Its TargetGroup should be “Test,” and the exact same name computer group should exist in the WSUS console.

TargetGroupEnabled: It enables or disables client-side targeting functionality. When set to 1, windows clients use the TargetGroup value to place themselves into the appropriate WSUS computer group. When set to “0”, administrators must manually assign devices to a computer group using the WSUS console.

DisableWindowsUpdateAccess: This is a DWORD value; when set to “1”, it removes the Windows Update option from the UI settings and prevents users from manually checking for or installing updates outside of scheduled update timing. It locks down the client-side GUID for updates and displays a message that update settings are managed by the organization. This setting is commonly used in regulated or strictly managed corporate environments and applies to all non-administrative accounts, ensuring that only sysadmins with direct access to the registry or Group Policy can override the policy.

ElevateNonAdmins: This setting determines whether non-admin users can receive and act upon Windows Update notifications that pop up in their taskbar. It’s a DWORD value; when set to “0”, only local administrators can authorize minor update alerts, and non-admin users cannot interfere with the managed update schedule. When this value is set to “1”, regular users can approve updates, i.e., can install pending updates, trigger unplanned reboots after updates, or install optional drivers.

Registry Keys for Update File Synchronization and Download

While the previous section registry settings control client-side Windows Update behavior, WSUS servers use a different set of registry values to manage update synchronization from Microsoft Update servers and update storage. These server-side registry settings are located under:
“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup”

The most important value in this location is ContentDir, which specifies where the WSUS server stores downloaded update files. Unlike client-side policies that determine where devices should obtain updates, these server-side settings govern how the WSUS server downloads, organizes, and maintains update content.

ContentDir (REG_SZ): This value defines the local file system path where WSUS downloads and stores all synchronized update binaries i.e. “.cab” and “.exe” files from Microsoft Update servers. This path must point to a storage volume with a minimum of 30 GB of space, and in large production environments it may regularly require hundreds of gigabytes, depending on the products and update classification type being synchronized.

Example: ContentDir= D:\WSUS\WsusContent
some of the other important server-side registry values are as follows:

General WSUS Configuration

Beyond Client update settings, WSUS maintains additional configuration values that influence synchronization behavior, update approvals, and server maintenance activities. These key values sit under “HKLM\SOFTWARE\Microsoft\Update Services\Server” and are typically managed from the WSUS administration console.

How to Identify Problematic WSUS Registry Entries?

WSUS registry misconfigurations are a common cause of update scan failures, reporting issues, missed patch deadlines, and devices unexpectedly connecting directly to Microsoft Update servers on the internet instead of to the organization’s internal WSUS server.

Indicators of broken WSUS registry configuration:

1. WUServer configuration value pointing to a decommissioned WSUS server that no longer exists. This issue commonly occurs after WSUS migrations, server replacements, or incomplete Group Policy cleanup. E.g., instead of using the new server URL, https://WSUS01:8531, clients are still pointing to https://WSUS-old:8531
2. UseWUServer configuration value is set to “0” instead of “1,” and clients ignore the WUServer value entirely, and route all update traffic directly to Microsoft Update servers.

• Mismatching WUServer and WUStatusServer values containing different URLs. Clients may successfully apply updates, but their status remains Unknown. For example, WUServer =https://WSUS01:8531, and WUStatusServer = https://WSUS04:8531.

1. Connectivity and communication errors between the client and the WSUS server, which can be traced from the client OS Event Viewer logs. For example, the presence of Event ID 16 indicates that the Windows Update agent initiated an update download, but it was canceled; Event ID 25 indicates that the update scan returned no results due to a server-side communication error, or Event ID 20 indicates that the update installation failed with errors after downloading from the WSUS server.

To manually inspect and investigate problematic WSUS registry entries, do the following steps:

1. Administrators have to open the registry editor, i.e., by running regedit.exe as administrator on the managed client. Go to path “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate” and review core WSUS registry values i.e. WUServer, WUStatusServer, UseWUServer,
2. After that Open Event Viewer, navigate to Applications and Services Logs > Microsoft > Windows > WindowsUpdate-Client > Operational, and filter for Event IDs 16, 20, and 25.

How to Modify or Remove WSUS Registry Entries?

Back Up the Registry Before Making Changes

Before modifying critical update configuration through registry editing, back up the existing registry to ensure a reliable recovery point if a system error occurs. A single deleted key or overwritten value can silently break the update process before the next Group Policy update occurs.

In the Registry Editor (regedit.exe), go to the registry path “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate”, select the relevant registry key, then from the File menu choose the Export option to save as a backup .reg file. This file can be exported later to restore the original settings. Exporting only the specific WSUS registry branch is safer and more manageable than backing up the entire registry.

A specific registry patch can be exported via the command line as well with the reg export command

“reg export HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate C:\Backup\WSUS_Backup.reg /y”

Create a Registry Modification (.reg) File

A .reg file is a plain text file containing registry keys and values in a format that can be used by administrators to create, modify, or remove WSUS settings consistently across multiple devices without manually editing the registry on each machine.

Copy the code snippet into a text file, change the extension to “.reg”, and replace the server URL with your valid server address.
# Code snippet 1

Windows Registry Editor Version 5.00

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

“WUServer”=”https://<serverURL>:8531”

“WUStatusServer”=”https://<serverURL>:8531”

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

“UseWUServer”=dword:00000001

Explanation: The first line identifies the file as a valid Windows Registry file. Each section enclosed in square brackets specifies a registry key, while subsequent lines define the values to be created or modified under that key. String values use quotation marks and the REG_SZ format, while DWORD values are represented in hexadecimal notation.

Following example disables WSUS usage by setting USEWUServer to “0” and removes the configured WSUS server entries.

Windows Registry Editor Version 5.00

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

“WUServer”=-

“WUStatusServer”=-

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

“UseWUServer”=dword:00000000

How registry value removal works: The equal sign followed by a hyphen “-“ instructs Windows to delete the specified registry value during import. This method is commonly used when migrating devices from WSUS server or troubleshooting stale configurations. On the next step, modifying the UseWUServer DWORD value back to “0” directs Windows Update Agent to stop using the WSUS server and now connect to the Microsoft Update server for updates.

Deploying the Registry File

The following is a PowerShell script to deploy the .reg file (created from code snippet 1 in the previous section).

# —————————————————————————–
# WSUS Registry Deployment Script

# Targets: Domain-joined Windows endpoints (workstations and servers)

# Requirements: Domain Admin rights, WinRM enabled on target computers, PS Remoting enabled

# 1. Define the list of remote target computers

$Computers = @(“client1″,”client2″,”server1″,”server2”)

# 2. Define the local path of your .reg file

$RegFilePath = “C:\Registryscripts\example.reg”

# 3. Loop through computers, copy the file, and execute it silently.

foreach ($Computer in $Computers) {

if (Test-Connection -ComputerName $Computer -Count 1 -Quiet) {

Write-Host “Processing $Computer…” -ForegroundColor Cyan

try {

# Copy the .reg file to the remote computer’s temp folder

$TargetFolder = “\\$Computer\c$\Windows\Temp\”

Copy-Item -Path $RegFilePath -Destination $TargetFolder -Force

# Execute regedit silently on the remote machine

Invoke-Command -ComputerName $Computer -ScriptBlock {

Start-Process -FilePath “regedit.exe” -ArgumentList “/s C:\Windows\Temp\wsus_config.reg” -Wait -NoNewWindow

# Clean up the file after import

Remove-Item -Path “C:\Windows\Temp\wsus_config.reg” -Force

}

Write-Host “Successfully applied to $Computer” -ForegroundColor Green

}

catch {

Write-Warning “Failed to deploy to $Computer. Error: $_”

}

} else {

Write-Warning “$Computer is offline. Skipping.”

}

}

# ——————————————————————————-

IIS Settings for WSUS Servers

If the client registry settings look right but updates still fail on client machines, check the server-side configurations. WSUS relies on an underlying Internet Information Service (IIS) infrastructure to deliver update metadata, content files, and client communication services. Even when WSUS registry settings such as WUSserver and WUStatusServer are configured correctly on clients, IIS misconfigurations such as broken IIS virtual directory paths, misconfigured application pool identities, or limited disk space can generate problems that can prevent clients from scanning, reporting status, or downloading updates successfully. WSUS creates and uses several IIS virtual directories, including ClientWebService, SimpleAuthWebService, ServerSyncWebService, DSSAuthWebService, ServerSyncWebService, ApiRemoting30, and Content, to handle client handshakes and file distribution.

Permissions

WSUS relies on IIS application pools and service accounts to access update files and process client requests. The WSUS administration website typically runs under a dedicated application pool “WsusPool” and built-in “NetworkService” account. This account requires explicit NTFS read and execute permissions on the WSUS installation directories and full read access to the local or remote patch storage volume i.e. Wsuscontent. If these permissions are missing or incorrectly configured, clients may receive HTTP/HTTPS errors, synchronization failures, or Update download errors. For example, after moving the WSUS content store from “C:\WSUS” to a new drive, e.g., “D:\WSUS\content,” failing to assign the correct NTFS permissions to the new location may cause update failures on the client side.

Disk Configuration

The WSUS server requires substantial storage to store update binaries, metadata, logs, and temporary files on disk, to update file cache, and to compile compression packages during client scans. When the storage volume runs out of free space, the IIS web server starts dropping incoming client sync calls and halts active upstream patch downloads from Microsoft Update servers. When either the WSUS content volume or IIS temporary folders become full, clients experience download failures, synchronization problems or timeout errors. These symptoms often resemble registry misconfigurations or connectivity issues and may divert troubleshooting efforts in the wrong direction. That’s why it’s critical to always check storage volume first while troubleshooting update failures.

IIS Registry Settings

WSUS interacts with IIS through configuration settings stored within Windows and IIS-related registry locations. One important path is “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC,” which contains configuration information for the World Wide Web Publishing service that IIS uses to host websites and application pools. These registry values control HTTP keep-alive timeouts, maximum concurrent connections, and specialized IIS filter settings that govern how IIS handles simultaneous client connections, queues connection requests, or refuses new requests. Problems affecting the W3SC service can prevent IIS from serving the WSUS virtual directory correctly. WSUS setup writes its virtual directory configuration to the IIS ApplicationHost.config file, which functions as IIS’s equivalent of a registry for site and application configuration. The ApplicationHost.config file serves as an authoritative source for IIS during startup; any corruption or unauthorized modification to this file can break WSUS IIS configurations that remain invisible in registry settings and must be verified from the config file.

Microsoft Configuration Manager (SCCM) Registry Settings

When an organization implements Microsoft Configuration Manager (formerly SCCM and now MECM) for patch deployment, the platform controls the management of client side Windows Update Agent. In a traditional WSUS environment, Client-side registry settings are typically configured through Group Policy, whereas Configuration Manager (SCCM) populates and manages these settings through its Software Update Point (SUP) infrastructure and Configuration Manager client policies. The primary registry location used for Windows Update configuration remains the same: “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate,” and uses the same registry keys and values, i.e., WUServer and WUStatusServer. However, the main distinction is the authorship and management mechanism, WSUS server populate these values through GPO, whereas SCCM populates it through its agent. The WUServer and WUStatusServer string values identify the URL of the server that receives Windows update status and scan reporting information from clients and in Configuration Manager environments they point to the same SUP that is used for synchronization and compliance reporting. Configuration writes its own client-side software update configuration to paths such as “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM” and “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\SoftwareUpdates”. These registry paths contain Configuration Manager client configuration data, scan history, policy information and Software Update Agent settings. In a standard WSUS deployment, administrators manually configure update settings through Group Policy, whereas in a Configuration Manager environment, the same registry values are managed through client policy received from the site infrastructure and Software Update point.

Intune (MDM) Registry Settings

Unlike traditional Group Policy-based Windows update settings, Microsoft Intune manages update policies through Configuration Service Providers (CSPs). These policies are stored under “HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update,” not under the WSUS registry path “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate”. This means both paths can coexist in a co-managed device; SCCM is operating in co-managed mode with Intune.

Traditional GPO registry keys are populated by “gpsvc” during Group Policy processing, where as CSP-backed keys are written by the Windows MDM enrollment stack when device checks in with Intune, and its authority or refresh timing are governed by MDM sync interval, not at logon or background Group Policy refresh.

Understanding PolicyState for Update Policies

When Intune Applies Windows update policies, it creates a companion PolicyState value alongside many CSP backed registry settings. Rather than storing the configured policy itself, PolicyState records the current processing status of that policy so administrators can determine whether the device successfully accepted and forced it.  For every active update policy key enforced by Intune, windows generate a companion subkey or value, this mechanism server as a real-time health indicator as well. For example, if a policy is applied to defer Quality updates, a corresponding “DeferQualityUpdatesPeriodInDays_PolicyState” key is automatically generated to log its deployment status.

The PolicyState key stores an explicit integer value that differentiates between a completely successful policy enforcement, a partial application or a direct conflict with another management tool. This allows administrators to quickly determine if a policy is actually enforced on the hardware or merely present in the registry. For example, A value “1” in the state key confirms that OS successfully parsed and locked down the specific update settings.

Common PolicyState Values

Co-managed (Intune + ConfigMgr) Registry Settings

Co-Managed Windows devices run both the Microsoft Endpoint Configuration Manager (MECM) client , formerly ConfigMgr/SCCM, and the Intune MDM agent simultaneously, allowing both solutions to write to the local registries. During Co-Management, both platforms may write registries, and this architecture can create conflicts with each other’s update configurations. To prevent policy conflicts, ConfigMgr utilizes a specific “Workload” configuration slider that explicitly dictates whether Intune or ConfigMgr is the autoritative source for Windows Update management. Clients monitor this assignment to determine which registry paths and management commands it must honor. For example, an organization moves Windows Update management to Intune while continuing to manage application deployment with Configuration Manager. Clients will contain registry entries from both platforms, but Windows Update settings are enforced only from the Intune-managed CSP registry path

Co-managed Settings Part 1: When ConfigMgr Controls the Update Workload

When ConfigMgr owns the Software Updates Workload, it actively configures traditional Group Policy registry key under “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate”, which forces the client Windows Update agent to look directly into internal ConfgMgr infrastructure for updates. In this scenario, the system populates the WUServer and WUStatusServer string values with the URL of local Software Update Point (SUP), while setting UserWUServer is set to “1”. For example, the registry values of client machines will look like:
WUServer = http://SUP01.corp.local:8530
WUStatusServer = http://SUP01.corp.local:8530
UseWUServer = 1

Administrators can verify if ConfigMgr is authoritative by checking the value of the UseWUServer registry key. If it is absent or value is set to “0”, the device is not honoring ConfigMGR for Update management.

Co-managed Settings Part 2: When Intune Controls the Update Workload

When the Software Updates workload is switched to Intune, Windows update policies are delivered through the Update CSP settings instead of traditional WSUS registry settings. Intune writes policy values under the Configuration service provider (CSP) keys under “HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update”. Intune also creates PolicyState entries that indicate whether each policy has been successfully applied, pending or experiencing a conflict. These companion values, provide administrators additionall insight into policy processing state.

Administrators can verify if Intune is authoritative by inspecting the Windows update policy value under “HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update” and corresponding PolicyState value indicates successful policy application status i.e. PolicyState=1. Switching the workload to Intune does not automatically remove the ConfigMGR clients previously written registry values, administrators have to verify if UseWUServer value is set to “1” or “0”, because if its set to “1” clients will still route to ConfigMgr for updates.

Conclusion

Understanding Windows Update Management registry settings helps administrators quickly identify configuration issues, verify update management ownership, and troubleshoot client communication problems. Since modern Windows environments may use WSUS, Configuration Manager, Intune or ConfigMgr/Intune co-management, known which registry path belongs to each management platform is