The server build number has changed and five hundred agents have not. Before you start planning a giant push deployment, read this: the fleet upgrades itself, in a specific order, on a specific clock - and your only job is to not get in its way.
New admins often expect to leave the maintenance window with every endpoint on the new agent version. That is not how Endpoint Central works, and it is by design. Once the Central Server is upgraded, Distribution Servers upgrade first, at their next replication cycle. Agents follow, at their next refresh cycle - every 90 minutes by default - and only after their own Distribution Server has upgraded. Nothing needs to be pushed, packaged or scheduled by you. This page explains the wave, and the two mistakes that disturb it.
An ordered wave, not a switch. A laptop that is off tonight simply joins the wave when it wakes.
The chain is strict: an agent can only receive its upgrade after its Distribution Server has upgraded, because the DS is the agent's source. Each DS starts its own upgrade at its next scheduled replication cycle, as defined in your replication policy. If one branch's agents seem to lag the rest, check that branch's DS first - the answer is almost always there, not at the endpoints.
Once their DS is ready, agents initiate their upgrade at their next refresh cycle - every 90 minutes unless you changed the policy. So the honest picture after a server update is a rolling wave over hours, not a flag day. Machines that are off, asleep or off-network join when they return; there is no missed deadline to rescue. Judge completion the next day, with a version report, rather than refresh-by-refresh during the night.
ManageEngine adds a detail that saves real confusion: the DS and agent upgrades trigger only when a version change is detected. If the server build you just installed carries the same Distribution Server and agent version as already installed, no upgrade is initiated at all - the existing components continue with full compatibility. A fleet that “did nothing” after a minor server update may be a fleet that correctly had nothing to do.
ManageEngine's post-upgrade guidance is explicit: only after agents are successfully upgraded should you resume activities such as patching, software deployment and remote control, and you should avoid scheduling patching until the agent upgrade completes, because it can delay the process. Keep the central server's bandwidth in mind too - it must distribute upgrade files to Distribution Servers and direct agents, so a simultaneous giant patch rollout turns one wave into two traffic jams.
A reassuring symmetry: if a VM snapshot rollback of the server is ever performed after agents have already upgraded, ManageEngine notes those agents will automatically revert on their next refresh cycle. The fleet takes its version from the server - in both directions. Which is one more reason rollback decisions belong to the whole system, not to one panicked machine.
Watch the video for the server side of the update, then let this page set your expectations for the hours afterwards - the fleet finishes the job itself.
Watch Full VideoIt rolls out in waves: Distribution Servers upgrade at their next replication cycle, then their agents at the next refresh cycle, which runs every 90 minutes by default. Online machines settle within hours; machines that are off upgrade when they return. Check with a version report the next day.
First check their Distribution Server - agents upgrade only after their DS has. Then check whether the new server build actually changed the agent version: if it did not, no agent upgrade is triggered, by design, and the existing agent remains fully compatible.
ManageEngine advises against scheduling patching until the agent upgrade is complete, because it can delay the upgrade process. Keep patch and software deployments paused, then resume once the fleet has settled on the new agent version.