The Update Manager reports a failure and your stomach drops. Take the first piece of good news from ManageEngine's own documentation: a failed upgrade automatically reverts to the previous version. This page is about what to do - and what to never do - in the hour after that message.
A failed Endpoint Central upgrade feels like an emergency and behaves like a drill: the system reverts to the previous version automatically. Your server is almost certainly back where it started - same build, same data - which means the correct response is calm investigation, not heroic repair. There is, however, one move that turns this non-event into a real problem, and it is the move everyone reaches for first: running the same service pack again. Start there.
The rollback is a feature, not a consolation prize. Your job changes from rescue to diagnosis.
ManageEngine states it without decoration: re-applying a service pack is not supported. If the upgrade failed and reverted - or even if it succeeded and you later hit problems - the documented route is to contact Endpoint Central support ([email protected]), not to run the .PPM again and hope. A second attempt on a half-understood failure can convert a clean revert into a genuinely damaged installation.
Start the ManageEngine UEMS - Server service if it is not running, open the console, and check the build number: it should show the previous build, whole and consistent. Log in properly, open a couple of familiar views - computers, a configuration, a report - and confirm the product behaves normally. This five-minute health check tells you whether you are in “diagnose the failure” territory or “restore the backup” territory. It is almost always the first one.
ManageEngine names the leading cause of upgrade failure plainly: file locks from lingering processes. When the service was stopped, did UEMS.exe, wrapper.exe and java.exe actually exit? Next time, stop the service, wait, and verify all three are gone in Task Manager before Update Manager starts. While you are auditing causes, check the others on the pre-flight list: free disk space (the 1.5-times rule), the correct PPM for your build, a valid checksum, and whether anyone opened the console mid-run.
The automatic revert handles the common case. For the uncommon one - the console misbehaving after a revert, data looking wrong - your insurance is the built-in backup taken before the window: restore the application and database together, from the same archive, never one half alone. If you used a VM snapshot as the extra safeguard, note the fleet behaviour before rolling back to it: agents that already upgraded will revert themselves on their next refresh cycle once the server is back on the old build.
Failed upgrades are diagnostic gold - if you capture them. Record the build you started from, the PPM file name, the stage reached, and the exact error text, plus your disk space and process check results. Send that to support and re-plan the window only after the cause is named. The admins who suffer the same failure twice are the ones who treated the first one as weather instead of evidence.
The video shows a clean update run from notification to verified build. If yours failed, watch it once more against your checklist - the skipped step usually introduces itself.
Watch Full VideoNo - if the upgrade fails, the system automatically reverts to the previous version. Verify by starting the service, opening the console and checking that the build number shows your previous build and everything behaves normally.
Do not. ManageEngine states that re-applying a service pack is not supported. Instead, find the cause - lingering UEMS.exe, wrapper.exe or java.exe processes causing file locks are the leading one - and contact Endpoint Central support with the error details.
Only if the console is genuinely unhealthy after the automatic revert. The revert is designed to return you to the previous version. If a restore is needed, restore the application and database together from the same built-in backup archive - never one half without the other.