×
×
×
×

Reverting Changes After Patch Failure

Last Updated On: 26 Oct 2026|
6 minutes read |

Scenario

A windows10.0- filename prefix alone does not mean that a package is unsuitable for Windows Server 2016. Windows 10 version 1607 and Windows Server 2016 share the RS1 servicing family. See Microsoft's Windows version and update table. Before deployment, verify the KB's supported products, architecture, and target OS build. If installation rolls back, follow Windows servicing troubleshooting and review the installation logs.

Compare the package with the vendor KB or applicability information for the target OS build, edition, and architecture. The package filename alone is not a supported-platform check. If the update rolls back after reboot, retain the agent installation result and the Windows servicing logs for the same attempt.

A patch deployment can be reported as successful in Patch Manager Plus. After the computer restarts, the patch can still be Missing. That result means Windows rolled back the update during the reboot. The execution remarks can show Patch installed successfully, but rolled back on reboot. This result is usually an environmental issue on the endpoint. It is not a deployment failure in Patch Manager Plus.

Cause

Patch Manager Plus downloads the patch and starts the installation. After the installation reaches the reboot stage, Windows Update servicing completes the remaining commit operations.

If Windows finds a problem during those reboot operations, Windows rolls back the update and restores the previous system state. This rollback runs in Windows servicing after Patch Manager Plus has completed deployment. Treat it as an operating system (environmental) issue, not as a Patch Manager Plus deployment failure.

This Windows rollback is separate from Uninstall Patch. Uninstall Patch is a manual-deployment action. It is available only when Patch Uninstallation for that patch is supported. See Uninstall and rollback limitations.

A restore point exists only when a pre-deployment script created one before deployment. The script does not stop a restart that Windows has already started. See Can we create a restore point before deploying a Windows update?.

Common environmental factors include:

  • Corrupted Windows components
  • Windows servicing issues
  • Incompatible drivers
  • Pending operations
  • Insufficient system resources
  • File access or permission issues
  • Other Windows Update-related problems

Resolution

If Component Store Cleanup is absent from Supported Patches, open Patch Database Settings > Windows and enable Optional Updates. Search Supported Patches again, then follow the cleanup procedure below. See patch-category selection.

If the update continues to roll back, record the Windows build, KB or Patch ID, full error, and reboot result. Follow Windows Update error troubleshooting and select the relevant servicing checks. A rollback remark alone does not confirm component-store corruption. It also does not guarantee that a repair patch will resolve the issue.

  1. Deploy the Component Store Cleanup patch (Patch ID: 105979) from the Supported Patches view.
  2. After the cleanup patch is installed successfully, reboot the system and redeploy the failed patch.
  3. Exclude the agent folder from antivirus: C:\Program Files (x86)\ManageEngine\UEMS_Agent.
  4. If Windows servicing or component-store corruption persists, follow the Windows component repair procedure.
  5. Restart the endpoint when required by that procedure and retry the failed update.

If the rollback continues after these steps, collect the Patch Manager Plus agent logs and the Setup logs in Event Viewer:

Event Viewer → Windows Logs → Setup

Related