Rollback Windows Patches

Why use the Rollback Windows Patches Worklet to remove a Windows 10 patch update?

This PowerShell Worklet makes it easy to remove one or more KBs from a Windows 10 device to restore an earlier version. It’s handy in the instance that a Windows update introduces unforeseen issues. 

How to remove a Windows 10 KB/patch update with this Worklet

This Worklet is designed for Windows 10 and grants an admin the ability to remove one or multiple KBs from a device using a single deployment. The Worklet creates a hashtable with installed KB numbers and associated Windows package names to be used with Remove-WindowsPackage and other code.

To use this Worklet, add KBs by placing the KB number (e.g. KB1234567) between single quotes in the $KBNumbers variable. If adding multiple KBs, make sure each KB is individually contained in single quotes, separated by a comma.

After running the script, the output will confirm if the KB removal was completed successfully.

What is KB in Windows Update code?

KB stands for Knowledge Base but in this context generally refers to a Microsoft Windows update or patch file. A Windows KB##### refers to a given Knowledge Base article, which is a support document provided by Microsoft that contains information, instructions, and troubleshooting guidance related to a specific software update or patch. 

KBs contain new features, bug fixes, and security enhancements to protect a given endpoint and deliver a seamless user experience. However, there may be instances when you need to remove a KB from a Windows 10 device. You’ll need the KB number(s) for the patch updates you’re wanting to roll back to run this Worklet.

Challenges in the management of Windows patching – and why you may need to remove a Windows 10 KB

You may need to remove or uninstall Windows updates and restore an earlier version for any of the following reasons:

Compatibility issues

After installing a Windows patch update, certain software applications or drivers may experience compatibility problems. These issues can lead to system instability, crashes, or other malfunctions. Rolling back the patch allows you to restore the previous working state of the system.

Performance degradation

In some cases, a Windows patch may negatively impact system performance. This could result in slower boot times, decreased responsiveness, or increased resource consumption. If you determine that the patch is causing performance issues, rolling it back can help alleviate the problem.

Application errors or failures

Occasionally, a Windows patch may introduce errors or conflicts with specific applications. This can lead to application crashes, error messages, or functionality issues. Rolling back the patch can provide a temporary solution until a permanent fix or workaround is available.

Security concerns

While it is generally recommended to keep systems up to date with the latest security patches, there may be situations where a particular patch introduces new security vulnerabilities or conflicts with existing security measures. In such cases, rolling back the patch can be necessary to maintain a secure environment until a resolution is provided by the software vendor or Microsoft.

Unforeseen issues

Despite testing, Windows patches can sometimes have unforeseen consequences in specific system configurations or environments. If you notice a critical issue caused by a patch, rolling it back to a previous version can be the quickest way to restore system stability and functionality.

Windows 10 patch management best practices

Windows patch management involves the process of systematically identifying, evaluating, deploying, and managing software updates or patches released by Microsoft to address security vulnerabilities, improve system stability, and enhance functionality. 

Regular patch monitoring, testing, and deployment are crucial to mitigate security risks and maintain system performance and integrity. 

Automox recommends a 24/72 threshold for patching, meaning that all critical vulnerabilities should be patched within 24 hours and all others within 72 hours. The best way to meet this threshold is with automated patch management.