How to Uninstall a Windows Update Across Hundreds of Endpoints

A broken cumulative update rarely announces itself gracefully. A printer driver stops queuing jobs, a VPN client drops mid-session, or a line-of-business app throws a licensing error, and helpdesk tickets start climbing an hour after the patch Tuesday reboot cycle finishes. At that point the task is not “patch faster,” it is the opposite: pull one specific update off hundreds of endpoints, stop it from silently reinstalling overnight, and prove every machine actually landed back on a known-good build. wusa, DISM and PowerShell each remove packages under different rules, cumulative updates cannot always be surgically rolled back, and none of this counts as done until you have machine-level confirmation, not just a green exit code from a deployment tool.

wusa, DISM and PowerShell: what each can and cannot remove

wusa is the oldest of the three and the most limited. wusa /uninstall /kb:5031354 /quiet /norestart only works when the update is still present in the servicing store as a standalone package. The moment a later cumulative update installs on top of it, wusa can no longer see it as a removable unit and returns error 2359302 (“not applicable”). It is fine for a single workstation you are troubleshooting by hand; it is not a scale tool.

DISM operates directly against the component servicing store and is the more reliable option for both online machines and offline images. Start by listing installed packages to get the exact package name, since the KB number alone is not enough:

• DISM /Online /Get-Packages /Format:Table to find the full Package_for_KB5031354~… string
• DISM /Online /Remove-Package /PackageName:Package_for_KB5031354~31bf3856ad364e35~amd64~~22621.2506.1.9 /quiet /norestart
• DISM /Image:C:mountWindows /Get-Packages and the matching remove command when you are servicing an offline WIM instead of a live host

PowerShell mostly wraps the same servicing APIs, which matters because it inherits the same constraints, not different ones. Get-HotFix -Id KB5031354 queries Win32_QuickFixEngineering, which is accurate for standalone security-only patches but frequently fails to report cumulative updates at all, giving you a false “not installed” reading. For cumulative updates, query the servicing store instead: Get-WindowsPackage -Online | Where-Object PackageName -like “*5031354*”, then remove with Remove-WindowsPackage -Online -PackageName <full name> -NoRestart. Servicing stack updates (SSUs) are a separate case: once installed, Windows does not allow them to be uninstalled at all, by any of the three tools.

Cumulative updates: why removal is partial and what that means for exposure

Since the cumulative servicing model became standard, each monthly Latest Cumulative Update (LCU) supersedes and absorbs every prior one for that Windows version. Once a machine has installed this month’s LCU, there is no discrete “KB5031354 only” package left to strip out. DISM and PowerShell can only remove the currently installed LCU as a whole, which rolls the machine back to whatever cumulative baseline preceded it, not to a clean state with just the regression-causing fix missing.

That has a direct security consequence: removing the current cumulative update reopens every CVE it patched, not only the one that triggered the driver or application regression. If this month’s LCU fixed twelve vulnerabilities and broke one printer driver, uninstalling it puts the endpoint back to being exposed to all twelve until a corrected build ships. Before mass-uninstalling, check the KB article’s own “how to get this update” and known issues sections, and Microsoft’s release health dashboard for a documented fix or workaround that avoids full rollback. If a workaround exists (a registry toggle, a driver update, an in-box mitigation), it is almost always lower risk than reverting a month of security fixes across the fleet.

This is also where asset and vulnerability inventory earns its keep: you need to know, per endpoint, which build and UBR (Update Build Revision) it is currently on before you decide whether removal, a workaround, or waiting for an out-of-band patch is the right call for that segment of the fleet. Platforms that maintain a continuously updated asset inventory can answer “how many machines are on the affected build right now” without a separate ad hoc query against every management tool in use.

Removing at scale via ConfigMgr, Intune remediation scripts or an RMM tool

Configuration Manager

Build a device collection from a query against installed updates (Software Update compliance data, or a WQL query against SMS_G_System_QUICK_FIX_ENGINEERING for standalone patches). For cumulative updates, a Configuration Item that runs Get-WindowsPackage -Online and reports compliant/non-compliant is more reliable than the built-in hotfix inventory. Deploy the DISM removal command as a script through Run Scripts or as a Package/Program targeted at that collection, then trigger a Hardware Inventory and Machine Policy cycle so compliance state refreshes without waiting for the next scheduled cycle.

Intune remediation scripts

Pair a detection script that exits 1 when the package is still present (checking Get-WindowsPackage output, not Get-HotFix, for cumulative updates) with a remediation script that runs the DISM removal and exits 0 on success. Assign both to an Azure AD device group scoped to the affected build number, and run the remediation on a recurring schedule, for example every 8 hours, until the Remediations report shows the group at zero non-compliant devices. Devices that stay non-compliant after several cycles usually indicate a pending reboot blocking the removal, or a machine that has gone offline.

RMM tooling

Most RMM platforms (ConnectWise Automate, NinjaOne, Datto, N-able) already pull WMI hotfix data into their inventory view, which you can filter to build a target device group. Push the same DISM or PowerShell removal command as a scheduled script, log output to a shared path or the RMM’s own script-run history, and track completion against the total count of targeted devices rather than assuming a “success” status on the script itself means the update is gone, since a script can exit cleanly while DISM reports “not applicable” underneath it.

Regardless of which of these three you use, the removal step is only half of an incident response workflow. It needs to be triggered by an accurate list of exposed endpoints and followed by confirmation that the fix landed, which is the same discovery-to-closure loop a patch management workflow is built around. In an autonomous vulnerability pipeline, the discovery and scanning phase is what identifies which endpoints still carry the specific KB or CVE in the first place, and platforms such as SITEY hand that list to whichever of ConfigMgr, Intune or an RMM the organization already runs, rather than requiring a parallel, one-off script to be maintained outside existing patch tooling.

Blocking reinstallation until a fixed build ships

Uninstalling without also blocking reinstallation just buys until the next scan-and-install cycle, which on a default Windows Update schedule can be hours. The blocking mechanism depends on how the fleet is managed:

• WSUS: decline the update (right-click it in the Updates node and choose Decline) so it stops being offered to any client target group. Declining does not retroactively remove it from machines that already installed it, it only stops new installs, so removal and decline are two separate actions that both need to happen.
• Windows Update for Business / Intune: set a quality update deferral period on the affected device group’s update ring, or apply a temporary pause with Pause Quality Updates (up to 35 days), configured through the Update rings profile or the PauseQualityUpdatesStartTime policy CSP. This buys time without touching WSUS approvals.
• Group Policy (non-cloud-managed estates): Computer Configuration > Administrative Templates > Windows Components > Windows Update > “Select when Quality Updates are received,” set a deferral of enough days to skip the current release, then reduce it back to your normal cadence once the fix ships.
• Standalone or ungoverned endpoints: the PSWindowsUpdate module’s Hide-WindowsUpdate -KBArticleID KB5031354 -Confirm:$false hides the specific update from the local Windows Update scan on machines that are not centrally managed, useful for small branch offices or lab segments outside the main fleet.

Whichever mechanism applies, scope the block to the affected device group only. Blanket-pausing updates fleet-wide to avoid one bad KB just delays every other pending security fix for machines that were never affected by the regression.

Verifying every machine is actually on the intended build afterward

A script that exits 0 confirms the command ran, not that the removal succeeded, that the reboot completed, or that the machine did not silently re-download the same update from a peer cache before the block took effect. Verification has to check the actual build state, not the deployment tool’s own status field.

After the reboot window closes, query the build and revision directly rather than relying on Get-HotFix:

• Get-ItemProperty ‘HKLM:SOFTWAREMicrosoftWindows NTCurrentVersion’ | Select-Object CurrentBuild, UBR gives the exact build and revision, which changes with every cumulative update and is the most precise single value to compare against your known-good baseline.
• For fleet-wide fan-out without an MDM in place: Invoke-Command -ComputerName (Get-Content targets.txt) -ScriptBlock { Get-ItemProperty ‘HKLM:SOFTWAREMicrosoftWindows NTCurrentVersion’ | Select-Object PSComputerName, CurrentBuild, UBR }, exported to CSV and reconciled against the original target list so machines that never reported back are flagged for manual follow-up rather than silently assumed fixed.
• In ConfigMgr or Intune, re-run the compliance check or Configuration Item evaluation rather than trusting the deployment status tile, since a deployment can show “succeeded” while the underlying package removal still failed.

Treat the incident as open until either every targeted endpoint reports the expected UBR, or the exceptions are explicitly listed and tracked (offline devices, decommissioned assets, machines pending a manual visit). This is also where a re-test step matters more than a deployment status: platforms that automate this phase, such as SITEY, re-run the actual scanner check against the KB and build number during the retest and closure phase, instead of closing the finding on the patch command’s exit code alone. A retest and closure step that queries the real endpoint state is what turns “we pushed the removal” into “we confirmed the fix,” which is the distinction that matters when the same regression, or the reopened CVEs from the rollback, show up in the next audit. For teams that need to show this evidence trail to an auditor rather than just to their own ticketing system, mapping the remediation timeline against a framework like ISO 27001 or PCI DSS is easier when the platform already tracks compliance mapping alongside the technical fix.

One last practical note: keep the removal and the block as two logged, separate steps in your change record. When the vendor ships a corrected build, you will need to re-enable the update for the exact same device group without having to reverse-engineer which machines were touched and which were left on the older baseline by exception.

About SITEY

SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.