A Patch Broke Something Rollback and Uninstall the Right Way
The update installed yesterday; today the billing app will not open. Before you blame the patch, prove it — then remove exactly that one update, and make sure your own automation does not quietly put it back tonight.
By Technical AnshuManageEngine Endpoint CentralFor IT Admins
Watch the full video — ManageEngine threat detection and patching, shown live on the console
'The patch broke it' is a hypothesis, not a diagnosis. Sometimes it is true — bad patches are real, and rollback is a legitimate admin tool. This page runs the proper sequence: confirm the culprit, identify the KB, uninstall cleanly, and decline the patch in ManageEngine Endpoint Central so the next automated deployment does not reinstall the problem while you are asleep.
Rollback Checklist — The Order Matters (example KB)
Symptom startRight after patch window
Suspect updateKB5042XXX (example)
TestOne machine, uninstall, retest
Fleet actionUninstall task + Decline patch
Reinstall tonight?Blocked by Decline
Example KB number for illustration — always use the real KB number from your own deployment history.
1
Confirm the Patch Is Really the Culprit
Uninstalling updates on a guess costs you a security fix and fixes nothing. Two quick checks turn suspicion into evidence.
Timing: did the problem start for several machines right after the same deployment window — and on no machines outside it?
One-machine test: pick one affected PC, remove the suspect update (steps below), reboot, and test the exact failing task
Problem gone on the test machine and present everywhere else? You have your culprit
Problem unchanged after removal? Stop — it was not the patch; reinstall the update and debug the real cause
2
Find the Exact KB Number
You cannot uninstall 'the Tuesday update'. You uninstall a specific KB, and you need its number from records, not memory.
In Endpoint Central, open the deployment task's status/history for that window and note which patches went to the affected machines
On the PC itself, check Settings → Windows Update → Update history for what installed on that date
Cross-check with Microsoft's release health notes — if the issue is listed as a known issue, your rollback is already validated
Write the KB number, the symptom and the date in your change log before you remove anything
3
Uninstall the Update Cleanly
Use the supported routes, in this order. Some updates — especially servicing stack updates — cannot be removed at all; the console and Windows will tell you.
Where Endpoint Central offers patch uninstall for the deployment, prefer it — the action is logged and reported centrally
On a single machine: Settings → Windows Update → Update history → Uninstall updates, select the KB, uninstall, reboot
Command route for a specific KB (replace the number with your real one): wusa /uninstall /kb:5042000 /quiet /norestart — then reboot at a controlled time
For package-level removal on stubborn cases, list packages with dism /online /get-packages and remove by exact package name only if you are certain — this route is easy to get wrong
Retest the broken workflow on the machine before touching the rest of the fleet
If the update cannot be uninstalled, the honest options are: wait for Microsoft's fix (often days), use a Known Issue Rollback if one is published, or restore the machine from a pre-patch image/backup. Do not hack the component store.
4
Decline the Patch So Automation Does Not Reinstall It
This is the step everyone forgets — and the reason the same breakage returns tomorrow morning. Your APD task sees a missing, approved patch and does its job.
In Endpoint Central, find the patch and set it to Decline — temporarily, with a note, while the issue is investigated
Pause or adjust the APD task if the uninstall rollout itself needs a window
Deploy the uninstall to the affected group only — machines that never had the symptom and never got the patch need nothing
Put a diary date on the decline: when Microsoft ships the corrected update, un-decline, test on the pilot ring, and close the gap — a declined security patch is a known hole with your name on it
Honest note: rolling back a security patch re-opens the vulnerability it fixed. That is sometimes the right trade for a business-stopping breakage — but it is a trade, made knowingly, with a date to revisit it. A rollback with no follow-up plan is just an unpatched fleet in slow motion.
Watch the Complete Process in the Video
Threat detection, vulnerability scanning and patch deployment in ManageEngine — every step shown live, in the video linked below.
No. Servicing stack updates and some cumulative updates cannot be removed once installed. Windows will simply not offer the uninstall option. In those cases the fix is a corrected update from Microsoft, a Known Issue Rollback, or restoring from backup/image.
Why did the bad patch come back after I uninstalled it?
Almost always because the patch was still approved in the patch management system, so the next automated deployment reinstalled it. After any rollback, Decline the patch in ManageEngine until the corrected version is released and tested.
Should I roll back the whole fleet at once?
No. Prove it on one machine first, then uninstall for the affected group. Machines without the symptom keep the security fix — a fleet-wide rollback on suspicion trades a local problem for a fleet-wide vulnerability.
This guide is based on the ManageEngine threat detection and patching video by Technical Anshu • Stuck on a step? Ask in the video comments — answers happen there.