Reset Windows Update Settings

What the Windows Update reset Worklet does

This Automox Worklet™ resets the Windows Update component stack on endpoints that fail to scan, download, or install updates. The Worklet stops the four services that own the update pipeline (wuauserv, BITS, appidsvc, and cryptsvc), renames the cached state in C:\Windows\SoftwareDistribution and the catroot2 folder under System32 (or sysnative on 64-bit endpoints), restores the default service security descriptors with sc.exe sdset on bits and wuauserv, and restarts the stack so the next scan starts from a clean baseline.

When the optional SFC pass is enabled (the default), the Worklet runs sfc /scannow before resetting the update stack. The scan repairs corrupted system files in the component store that often masquerade as Windows Update errors (TrustedInstaller failures, 0x80073712, and 0x800f081f are the common signatures). SFC takes 15 to 30 minutes on a typical Windows 10 or Windows 11 endpoint and writes its findings to %WinDir%\Logs\CBS\CBS.log.

The evaluation script ships with $AlwaysRemediate set to $true, so every targeted endpoint is flagged for reset on each run. Switching $AlwaysRemediate to $false enables targeted evaluation: the script then checks whether wuauserv and BITS are running, whether SoftwareDistribution exceeds five gigabytes, whether the System event log contains recent Microsoft-Windows-WindowsUpdateClient errors in the last seven days, and optionally whether CBS.log shows corruption markers. Endpoints in a healthy state under that mode are left untouched.

Why reset Windows Update across the fleet

Windows Update degrades quietly. A partially applied cumulative update leaves the SoftwareDistribution download cache in an inconsistent state. A stale catroot2 entry fails signature validation on the next scan. A BITS job hangs because its queue manager data files (qmgr*.dat) are corrupted. The endpoint reports a generic error code like 0x80070643 or 0x8024a105, the user reboots, the error returns, and the laptop falls behind on security patches while the helpdesk ticket sits in the queue.

Running the reset through an Automox policy applies the same recovery sequence a senior support engineer would run manually, then executes it across every flagged endpoint in a single policy run. The agent stops the wuauserv, BITS, appidsvc, and cryptsvc services, renames the SoftwareDistribution and catroot2 folders, re-registers the supporting DLLs, and restarts the services in the right order. Laptops that have been failing to take Patch Tuesday for months return to a state where the next cumulative update can land, with no remote session per endpoint and no per-host helpdesk ticket.

How the Windows Update reset works

1. Evaluation phase: By default the evaluation script runs in $AlwaysRemediate = $true mode, exits 1, and routes every targeted endpoint to remediation. Set $AlwaysRemediate to $false to switch to conditional evaluation: the script inspects four signals on the endpoint, using Get-Service to check the running state of wuauserv and BITS, measuring the size of C:\Windows\SoftwareDistribution against a five-gigabyte threshold, querying the System log for Microsoft-Windows-WindowsUpdateClient Error events in the last seven days, and (when $CheckForCorruption is enabled) tailing CBS.log for corruption markers. Any failing signal flags the endpoint as non-compliant and writes the issue list to stdout.

2. Remediation phase: The Worklet optionally runs sfc /scannow (controlled by $RunSFC, default $true), then runs Stop-Service against BITS, wuauserv, appidsvc, and cryptsvc, deletes %ALLUSERSPROFILE%\Microsoft\Network\Downloader\qmgr*.dat, renames C:\Windows\SoftwareDistribution to SoftwareDistribution.bak and the catroot2 folder under sysnative or System32 to catroot2.bak (so a rollback is a single rename away), removes WindowsUpdate.log, and re-applies the default security descriptors using sc.exe sdset bits and sc.exe sdset wuauserv. It then re-registers 36 Windows Update DLLs (atl.dll, urlmon.dll, mshtml.dll, wuapi.dll, wuaueng.dll, wucltui.dll, wups.dll, wups2.dll, wuweb.dll, qmgr.dll, and the rest), resets WinSock with netsh winsock reset and WinHTTP with netsh winhttp reset proxy, deletes the AccountDomainSid, PingID, and SusClientId values under HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate, and flushes BITS jobs with Get-BitsTransfer | Remove-BitsTransfer. Finally, the Worklet restarts the four services and triggers a fresh detection with wuauclt /resetauthorization /detectnow.

Windows Update reset requirements

• Windows 7 SP1 or later; the Worklet is tested on Windows 10, Windows 11, and Windows Server 2012 R2 through 2022

• PowerShell 2.0 or later (the Automox agent runs as SYSTEM, which satisfies this by default)

• Administrator context for Stop-Service, sc.exe sdset, regsvr32 re-registration, and the netsh winsock and netsh winhttp commands

• Enough free disk space on C: to keep SoftwareDistribution.bak and catroot2.bak alongside the new empty folders until the next disk-cleanup window

• FixNow-compatible: schedule on a maintenance policy or trigger on-demand against the endpoints flagged by your Windows Update scan dashboard

• Reboot recommended after the run, especially when SFC repairs files or WindowsUpdate.log was actively being written when services were stopped

Expected state after the Windows Update reset

Immediately after remediation, the four core services return to the Running state with their default startup types: wuauserv as Manual (Trigger Start), BITS as Manual, appidsvc as Manual, and cryptsvc as Automatic. The renamed SoftwareDistribution.bak and catroot2.bak folders sit alongside fresh empty replacements that Windows Update will re-populate on the next detection. The Automox activity log shows exit code 0, a JSON_RESULT line summarizing sfc_status and wu_reset_completed, and the WindowsUpdateClient event log records a new scan starting within a few minutes of the policy run.

Validate by running Get-Service wuauserv,BITS,appidsvc,cryptsvc on the endpoint and confirming all four are Running. Check (Get-Item C:\Windows\SoftwareDistribution).LastWriteTime against the policy run time to confirm the folder was recreated. Wait two to five minutes after the run, then open Settings to Update and Security to Windows Update and verify that the endpoint either lists available updates or reports You are up to date. For audit evidence, capture the Automox activity log entry and the corresponding events from the Microsoft-Windows-WindowsUpdateClient source. Once the run is confirmed clean on the pilot ring, delete the SoftwareDistribution.bak and catroot2.bak folders during the next maintenance window to reclaim the disk space.