Microsoft releases buggy patches now and then (more commonly now sadly).
Today’s stuff up is KB3097877 which breaks a bunch of things, including things like causing Outlook to crash when reading HTML emails.
Best practise is to have a target group from WSUS that these patches go to first, before going company wide – but either way, you’ll want to remove the patch from the affected PCs.
How do you do this? This is my recommended safe approach:
Step 1. Disable the patch in WSUS.
Just do this now, before anyone else gets it. You’re not going to break anything by choosing the ‘Decline’ option on a patch in WSUS. Make sure you do it to each OS version or product you manage (e.g. Windows 7 32 bit, Windows 7 64 bit, Windows 8 32 bit etc).
Step 2. Test uninstalling the patch manually
Before you go nuts and try to fix all the things at once, do a quick test or two. If you manually uninstall the patch, does it successfully uninstall? Reboot and make sure the PC seems happy (check event viewer!). Reboots may take a while doing system state backups and rolling back the patch.
Step 3. – Set WSUS to Uninstall the patch.
It’s a bit counter intuitive to approve a patch to then set it to remove, but that’s how WSUS works. Find the patch by searching for the KB, and once you right click ‘Approve’, you’ll get the option to choose ‘Approved for Removal’. Make sure you’re targeting the correct Computer Group. If you can’t use WSUS, work out how to get your PCs to run a command like this: “wusa /uninstall /kb:3097877 /quiet /norestart” – without the /norestart, they’ll restart :)
Step 4 – Test Windows Update uninstall
Test another PC’s ability to use Windows Updates to uninstall the patch. ‘Checking for updates’ either through the Windows Update GUI or the good old ‘wuauclt /detectnow’ command will do the trick. Similar to Step 2, check it uninstalls and reboot. You can also check C:\Windows\WindowsUpdate.log to make sure it’s happy (this doesn’t apply to Windows 10 as that log doesn’t exist).
Step 5 – Trigger your PCs to check for Windows Updates
Depending on your group policies, Windows Updates will check at certain intervals and may auto download or auto patch. Easiest thing to do is trigger all your PCs to check Windows Updates now. There’s an easy PowerShell way of doing this here, but requires WinRM to be enabled – you should have this on if you want to be able to do a bunch of cool stuff to your PCs. Otherwise, try psexec which will have the same result. This can take a long time to do! Optional component – WOL your PCs first.
Step 6 – Reboot
Now that you’re ready to clean up, test reboot a PC or two and make sure the patch goes away. If that happens, then schedule all your PCs to reboot. You should have a way of doing this already – SCCM can do it well, you can create a once off scheduled task and push that out to PCs, or a bunch of other ways.
Step 7 – Report in WSUS
WSUS has some nice client reporting options. Search for the KB again, right click and choose ‘Status Report’. This is usually not too lagged in it’s information, and you can check to make sure none of your PCs have the update any more. If there’s only a few, it may be easier to manually fix the remainder.
Happy cleaning up!
2 thoughts on “Rolling back from a bad KB Update”
I now see two versions of this update in WSUS. I have looked everywhere I can think of, and can’t figure out which one is the new one to approve, and which one is the old one to ignore/decline.
Yes this wasn’t a great fix from Microsoft – they normally release a v2 option.
For me the original changed to Not Approved, where I had it Approved – Denied. If it helps, the revision number of the correct update for me is 200, while the bad one was 202, (right click on the KB under search and choose ‘Revision History’). It also shows there which one I denied previously.