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 associated Windows packages. The Worklet uses the DISM (Deployment Image Servicing and Management) tool through PowerShell to identify installed packages by KB number and remove them from the online system.

The Worklet creates a hashtable that maps KB numbers to Windows package names using Get-WindowsPackage and DISM commands. You configure which KB updates to remove by entering KB numbers in the $kbNumbers variable. The Worklet supports removing multiple KB updates in a single deployment by separating KB numbers with commas.

The Worklet executes PowerShell in the native context (64-bit or 32-bit) to avoid DISM compatibility errors. After removal, it verifies that each package reaches an "UninstallPending" state and logs the operation to a configurable directory.

Why roll back Windows KB updates

A patch that resolves one security vulnerability might break application compatibility, degrade system performance, or conflict with existing security tools, forcing you to choose between security and stability. Windows updates occasionally introduce unforeseen issues in production environments. When this happens, you need a fast, reliable method to remove the problematic update from affected endpoints.

Automox recommends a 24/72 patching threshold for vulnerabilities, but this aggressive timeline means issues can appear across many endpoints before testing catches all edge cases. Rolling back a patch buys you time to investigate root causes, test alternative solutions, or wait for Microsoft to release a fixed version.

Common scenarios requiring KB removal include driver conflicts that cause blue screen errors, application crashes triggered by updated system libraries, performance degradation from memory leaks, and security patches that interfere with endpoint protection software. The Worklet lets you respond to these issues immediately rather than waiting for manual removal across distributed endpoints.

How Windows patch removal works

1. Evaluation phase: The Worklet queries all installed Windows packages using Get-WindowsPackage in native context, then uses DISM to extract KB numbers from package metadata. It builds a hashtable mapping KB numbers to package names, searches for the KB numbers you specified in $kbNumbers, and exits with code 0 (compliant) if none are found or code 2 (non-compliant) if any target KBs remain installed.

2. Remediation phase: The Worklet invokes Remove-WindowsPackage for each matching KB, passing the package name from the hashtable and a log path for DISM output. After attempting removal, it queries the package state to confirm it reached "UninstallPending" status. If removal fails or the package state does not change, the Worklet writes error details to stderr and exits with code 2375. Successful removal exits with code 0 and outputs a confirmation message.

Windows patch rollback requirements

• Windows 10 endpoints (workstation or server endpoint types)

• PowerShell execution policy allowing script execution

• Administrator privileges to run DISM and Remove-WindowsPackage

• KB numbers for target patches (format: KB1234567)

• Configure $kbNumbers variable with single-quoted KB values separated by commas for multiple KBs

• Optional: Modify $logPath variable to change DISM log directory (defaults to %WINDIR%\Logs\DISM)

Expected endpoint state after KB removal

After successful remediation, the specified KB packages reach "UninstallPending" state and will be fully removed after the next system restart. The endpoint requires a reboot to complete the package removal process, though the Worklet does not force an automatic restart. This staged removal approach allows you to schedule the reboot during maintenance windows.

You can verify removal by checking DISM logs at the configured log path. Each KB generates a separate log file named KB#######.log containing detailed removal operations. If any KB fails to remove, the Worklet outputs error messages identifying which KB encountered issues and points to the relevant log file for troubleshooting.

The system reverts to the patch state that existed before the removed KB was installed. Applications or drivers that experienced compatibility issues with the update should return to their previous working state after the post-removal reboot, restoring endpoint stability without the problematic patch.

How to validate rollback windows patches changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for rollback windows patches.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as Get-WindowsPackage, Invoke-NativePS, Invoke-Command.

4. Validate remediation effects from script operations such as Get-WindowsPackage, Invoke-NativePS, Invoke-Command, then rerun evaluation for compliance.