M100544: Best practices for security patch rollback

Rollback of security patches can often be more risky than the installation, but it can be necessary to do so when the installation causes instability in target computer systems. This is a risk inherent in security patches, regardless of the technology used to perform the installation. This document describes some best-practices for rollback of security patches that should minimize this risk.

There are documented cases where rollback of some Microsoft security patches have damaged core software components of computer systems, resulting in instability or even unrecoverable system failure. One example of why this can happen would be if a security patch that is rolled back removes updates to files that another security patch relies on to function correctly. In this case, instability can occur.

The first rule of rolling back security patches is that you should only do this if you absolutely need to. Patches are (generally) well tested by Microsoft and will not often introduce instability. If it is necessary to rollback a security patch using

ManageSoft, you can minimize the risk by following the instructions described in this document.

Security patches targeted to computers via the ManageSoft Security Patch Management portal are automatically marked to not be uninstalled when they are removed from policy at a later date. This is to stop accidental rollback caused by user error. Once a security patch is added to a group policy, you may want to switch to Active Directory Group Policy editor and mark the security patch packages to be uninstalled when they are removed from policy, so you are prepared to rollback the security patch if it causes instability. You can do this by doing the following:

1. Find your security patch policy, possibly using Active Directory Users and Computers.
2. Edit the policy.
3. Navigate to the 'Computer Configuration\Software Settings\Software Management' node.
4. Double-click on each package for the selected bulletin, which opens the ManageSoft package properties dialog box.
5. For each package, select the 'Deployment conditions' tab and ensure that the 'Remove this application when it falls outside the applicable policy' checkbox is checked.

If the security patch rollout causes no instability, then you may want to uncheck the 'Remove this application when it falls outside the applicable policy' checkbox in order to reduce the risk of accidental rollback due to user error. Otherwise, if the security patch causes instability and you need to roll it back, make sure you remove it from policy in your test group first before doing so in production, as it is possible that removing the security patch may cause even more harm to targeted computer systems. Once the rollback has been properly tested, you may use either the Security Patch Management portal or ManageSoft group policy editor to rollback the security patch.

It is strongly recommended that if you do need to rollback more than one security patch, that you do so one at a time with enough time in between to allow the managed devices to update their policy can carry out the uninstall.

There are some security patches that require a reboot before the uninstall of another security patch is attempted, otherwise system instability can occur. ManageSoft for managed devices (for Security Patch Management) will only perform one rollback per policy update, but if the user declines to reboot the computer after the first uninstall, a later policy update may uninstall a second security patch which may result in some instability. Also, if possible try to rollback patches in reverse order from how they were applied, as this has less risk of causing a problem.

Thorough testing of security patch installation over as many different system configurations as possible should make security patch rollback unnecessary, but if rolling back cannot be avoided then it is important that the recommendations in this document should be carried out in order to minimize the risk of damage to computer systems.