The difference between an admin who has seen this upgrade before and one who has not is one rehearsal. A lab VM restored from your own backup lets you meet the new build - and every surprise in it - a week before your users do.
Production is a terrible classroom. The same Update Manager run that is routine on a test VM becomes a career moment on the only server that manages five hundred endpoints. ManageEngine's flow makes rehearsal unusually easy, because the built-in backup is also the staging tool: restore your production archive onto a lab machine and you own a faithful copy of your server - same build, same data shape, same upgrade path. This page covers the rehearsal, and then the special case that is not a rehearsal at all: upgrading a real failover (Primary/Secondary) pair, which has its own documented order.
A lab exists to absorb surprises. A failover secondary is not a lab - it is the other half of production.
Install the same build as production on a spare VM, then restore your latest built-in backup (application and database together) onto it. Now rehearse the exact window: service stop, process check, UpdateManager.bat, every PPM stage in your sequence, service start, build verification. Time each phase. The lab's timings turn next week's window estimate from a guess into a measurement - and any build-specific oddity in the Readme stops being theoretical.
Not the installer - ManageEngine tests that. You are testing your environment against the new build: your configurations open correctly, your reports render, your Distribution Server talks, a test agent checks in. Keep the lab isolated so its agents can never reach production endpoints. When the rehearsal passes, the production window shrinks to a procedure you have already performed once - which is the entire point.
If you run the Primary/Secondary failover setup, the documented sequence is specific. Stop the Secondary server's UEMS - Server service first. If the server version is 10.1.2137.03 or higher, run SecondaryServerPPMHandler.bat from UEMS_CentralServer\bin on the Secondary. Then stop the Primary, run the Update Manager and the PPM on the Primary, and start the Primary fully. Only then start the Secondary - it synchronizes the updated files and database changes from the Primary automatically on startup.
Secure Gateway Server follows a rule that feels wrong to tidy minds: upgrade it only when the console tells you an SGS upgrade is required after the server upgrade - never automatically, never “while I am here”. Treat it as the separate component upgrade ManageEngine describes: record the SGS build before, confirm the compatible target, do it in the same window if prompted, and leave time afterwards to validate remote connectivity through it. An unprompted SGS upgrade is change without a reason.
After production succeeds, file the lab notes with the change record: timings per stage, the process that took longest to exit, the Readme warning that mattered. The next upgrade - and the next admin - starts from your evidence instead of from folklore. Staged upgrading is not really about this service pack; it is about making every future one boring.
The video runs the standard single-server update end to end. Use it as the script for your lab rehearsal before the production window.
Watch Full VideoInstall the same build on a spare VM and restore your latest built-in backup - application and database together - onto it. That gives you a faithful copy with your configurations and data shape, ideal for rehearsing the exact upgrade path before touching production.
Stop the Secondary first and, on builds 10.1.2137.03 or higher, run SecondaryServerPPMHandler.bat on it. Then stop the Primary, apply the PPM with Update Manager, and start the Primary fully. Start the Secondary last - it synchronizes the updated files and database changes from the Primary automatically.
Only if the console prompts that an SGS upgrade is required after the server upgrade. ManageEngine treats SGS as a separate component upgrade: do not upgrade it automatically with every server update, and after a prompted SGS upgrade, validate remote connectivity.