Rollback Windows Patches

What the Windows patch rollback Worklet does

This Automox Worklet™ removes specific Windows KB updates from Windows 10 endpoints by uninstalling the underlying Windows package. The Worklet drives DISM (Deployment Image Servicing and Management) through PowerShell to find each installed package by KB number and remove it from the online system.

Internally the Worklet builds a hashtable that maps each KB number to its full Windows package name using Get-WindowsPackage. You list the KB numbers to remove in the $kbNumbers variable, separating multiple values with commas (for example, 'KB5005565','KB5006670'). The Worklet then walks the hashtable and calls Remove-WindowsPackage for each KB the endpoint actually has installed.

Execution runs in the native PowerShell context (64-bit on 64-bit Windows) to avoid DISM compatibility errors that surface when 32-bit PowerShell calls 64-bit servicing components. After each removal, the Worklet verifies that the package reaches the UninstallPending state and writes a per-KB DISM log to %WINDIR%\Logs\DISM or the directory you set in $logPath.

Unlike running wusa /uninstall /kb: manually on a single endpoint, the Worklet pushes the same DISM-based rollback to every targeted endpoint in a policy and reports compliance back to the Automox console.

Why roll back Windows KB updates

A Patch Tuesday update that resolves one security vulnerability can break application compatibility, trigger blue screen errors from a driver conflict, degrade performance through a memory regression, or interfere with endpoint protection software. When that happens, you need a fast, repeatable way to take the bad KB back off every affected endpoint while you wait for Microsoft to ship a fixed revision. Common targets include Print Spooler updates, .NET cumulative updates, and servicing stack updates that change behavior in ways application owners did not anticipate.

Rolling back the KB through a single Automox policy turns a bad Patch Tuesday from a manual per-endpoint task into a targeted fleet operation. The evaluation phase queries every installed Windows package using Get-WindowsPackage; remediation only runs on endpoints that have the KB present. The activity log shows exactly which endpoints rolled back cleanly and which need a follow-up, buying you time to investigate the root cause or wait for Microsoft to publish a replacement.

How Windows KB removal works

1. Evaluation phase: The Worklet queries every installed Windows package using Get-WindowsPackage in native context, then extracts the KB identifier from each package's metadata. It builds a hashtable mapping KB numbers to package names and checks whether any of the KB values in $kbNumbers are still present. The endpoint exits with code 0 (compliant) when none of the target KBs are installed and exit code 2 (non-compliant) when at least one remains.

2. Remediation phase: The Worklet calls Remove-WindowsPackage for each matching KB, passing the package name from the hashtable and the configured -LogPath for DISM output. After each removal, it re-queries the package with Get-WindowsPackage and confirms the state is UninstallPending. A failed removal or an unchanged state writes an error to stderr and exits with code 2375 so the Automox console flags the endpoint for follow-up. A clean remediation exits with code 0.

Windows KB rollback requirements

• Windows 10 endpoints (workstation or server endpoint types). Windows 11 packages follow the same DISM model but should be tested before broad rollout.

• PowerShell execution policy that permits script execution under the Automox agent.

• Administrator privileges to run DISM and Remove-WindowsPackage against the online image.

• KB identifiers for every patch you want removed, in KB####### format (for example, KB5005565, KB5006670, KB5034441).

• Edit the $kbNumbers variable in both the evaluation and remediation scripts, and list each KB as a single-quoted string separated by commas.

• Optional: set $logPath to redirect DISM logs from the default %WINDIR%\Logs\DISM directory.

Expected endpoint state after KB rollback

After successful remediation, each targeted package sits in UninstallPending state and finalizes removal on the next system restart. The Worklet does not force a reboot, so you can stage the restart inside a maintenance window or follow up with a separate reboot policy. Validate the pending state from PowerShell with Get-WindowsPackage -Online | Where-Object PackageState -eq 'UninstallPending'.

DISM writes a per-KB log file named KB#######.log to the log path. Open that file when a removal fails to see exactly which servicing operation rejected the request. Typical failures include a superseded package that no longer has an uninstall scenario, a package locked by a pending operation from a previous Patch Tuesday, and a permanence flag set by Microsoft on a security update that cannot be cleanly reverted.

Once the endpoint reboots, the system reverts to the patch state that existed before the removed KB was installed. Applications, drivers, and protection agents that conflicted with the update should return to their previous working state. Re-evaluate the Worklet after the reboot to confirm compliance, and pair it with a Patch policy exclusion for the same KB so the Windows Update agent does not re-deploy the update on the next scan.