Patch Rollback and Failed-Update Remediation in Hexnode UEM

Rollback support by update type

Reversibility is a property of the platform’s update mechanism, not of Hexnode — no management tool can uninstall an update the operating system provides no removal path for. Here is the honest support matrix:

Rollback procedure

Rolling back a third-party application patch:

1. Identify the failed version and the last known-good version in the patch/app views. (Previous validated versions remain available in the catalog)
2. Target the known-good version at the affected devices — the same scoping mechanisms as any deployment (device groups, policies), so a rollback can be scoped to exactly the devices that took the bad version.
3. Deploy the rollback. The agent stages and installs the prior version through the same validated pipeline as any patch (see Patch delivery architecture) — a rollback binary is hash-verified like a forward deployment.
4. Verify in Action History that the reinstall succeeded, and confirm the version in device inventory after next check-in.

Rolling back a Windows quality update:

1. From the affected device (or device group), initiate the update uninstallation.
2. Schedule the accompanying restart — most KB uninstalls require one; use the maintenance window unless urgency overrides it.
3. After restart and check-in, the next patch scan re-evaluates the device: the uninstalled update reappears as applicable (or its superseding successor does).
4. Block reinstallation while the problem is investigated: exclude the KB from automation/approval so that the auto-patch cycle doesn’t immediately redeploy what you just removed.

Step 4 is the step teams forget: rollback without a reinstall block is a loop, not a fix.

What happens to devices mid-install

A rollback or deployment pause issued while a wave is in flight lands on devices in different states:

• Not yet started: The device never receives the deployment — cancelled cleanly.
• Actively installing: The in-progress installation completes — interrupting a package mid-write risks a corrupted state worse than the bad patch. The device then appears in the rolled-back cohort and receives the reversal action afterward.
• Installed, pending restart: The pending restart is not cancelled. Once the device boots back up and checks in, Hexnode automatically initiates the rollback sequence to remove the update.

App patches vs. OS patches: why uninstall behaves differently

The asymmetry admins must plan around:

• Application patches are version-replacements. “Rollback” means installing the previous version — a forward-looking deploy of an older artifact. It’s clean because the whole application is the unit; nothing of the newer version lingers (exceptions: apps whose installers refuse downgrades, or that migrate data schemas irreversibly on first launch — the two cases where even app rollback needs testing, worth stating honestly).
• OS patches are deltas into a shared system. Uninstalling a KB removes that package’s changes but the OS retains state created while it was installed; and cumulative updates mean the “previous state” is the previous cumulative, not a pristine baseline. This is why OS rollback is a remediation tool, not an undo button — and why staged rollout (rings, pilot groups) is the primary safety mechanism, with rollback as the backstop.

Structured remediation for failed or stuck updates

Work the list in order; each step is cheaper than the next.

1. Failed with an error code:

   Check Action History for the failure detail. Installer exit codes are platform-truthful: disk space, missing dependency, conflicting process. Fix the stated cause and redeploy — most “failed patches” are environmental, not patch defects.

2. Stuck in downloading/pending:

   Confirm the device is online and checking in (last check-in time). For DAFS sites, confirm the site’s DAFS server is reachable — a down distribution server presents as fleet-of-stuck-downloads at one site (see Patch delivery architecture). Force a sync from the UEM app on the local device.

3. Stuck installing for an abnormal duration:

   Do not power-cycle managed devices mid-install as a first resort. Check whether the installer is waiting on something silent — a prompt suppressed in quiet mode, a locked file, a pending prior restart. A pending-restart backlog is the most common cause of “hung” installs: clear the restart, rescan, redeploy.

4. Installed but the device still reports the old version / still non-compliant:

   Scan for staleness first — rescan and re-check. Then verify the patch actually targets the installed product variant (architecture, edition, install path). Then check for a supersedence mismatch.

5. Failing repeatedly across many devices:

   Stop the wave (pause the deployment/automation) before diagnosing — a patch failing at scale is exactly what pause exists for. Diagnose on one held-out device, and if the patch itself is defective, roll back the devices that took it and report the title to Hexnode support so the catalog team can re-validate the package.

Related documentation

• Patch delivery architecture
• The Hexnode patch catalog: curation and validation pipeline
• Patch by CVE: CVE-driven patch automation
• Maintenance windows and patch scheduling