The server shows the shiny new build, and the next question arrives on cue: do I now have to touch every PC in the building? No — but 'no' is not the same as 'nothing happens'. Here is what the agents do next, and how to prove the fleet caught up.
Notice what the upgrade video never does: it never visits a single workstation. That is by design. Endpoint Central agents learn about the upgraded server when they check in, and bring themselves up to date as part of that normal conversation. This page explains that catch-up honestly — how it works, why a handful of machines always lag, and the short verification round that closes the job properly.
An agent's whole job is to check in with its server, receive instructions and report back. When the server has been upgraded, that check-in is how the agent discovers the new version and updates itself — no desk visits, no manual reinstalls across the fleet.
This is also why the upgrade order in the video is server-only. Your part ends at a verified console; the fleet's part happens automatically, machine by machine, as each one next connects.
The laggards are almost never broken. They are the laptop that is switched off, the work-from-home machine that has not connected today, and the branch PC whose path runs through a distribution server that has not been upgraded yet.
Judge completion over days, not minutes. A fleet of any size always has a tail of offline machines, and their agent versions say more about their power buttons than about your upgrade.
If you run remote offices through distribution servers, upgrade them promptly after the central server. Branch agents receive their world through the distribution server, so leaving it on the old build stretches the catch-up for every machine behind it.
The order is always the same: central server first, verify it, then distribution servers, then simply watch the agent versions settle.
The console's inventory and agent views are your proof. Filter or sort by agent version, confirm the count on the new version is climbing, and spot-check a few machines by name — including at least one remote or branch PC.
Write the result into your change log with the date. 'Upgraded server to the new build; fleet on new agent version except 6 offline laptops' is a complete, professional closing note.
A small number of machines may honestly need attention: an agent so old it predates the automatic path, a broken agent service, or a PC that was reimaged and never re-enrolled. For those, reinstalling the agent on that machine is the fix.
Keep the exception exceptional. Reinstalling agents fleet-wide on day one 'just to be sure' creates the very disruption the automatic design exists to avoid — and buries the genuinely broken machines in noise.
The build check, the service stop and UpdateManager — the server-side job your agents are waiting on.
▶️ Watch Full VideoNo. Agents update themselves when they check in with the upgraded server. Reinstalling is the exception for individual broken or very old agents, not the routine.
Machines that are on and connected usually catch up quickly; laptops and remote machines update when they next connect. Judge completion over days, and chase stragglers from the console's agent version view.
After. The central server goes first and gets verified; then distribution servers, so branch agents receive the new version through their normal path.