Install Endpoint Central Agent in Remote Offices with a Distribution Server

The Distribution Server (DS) is a designated computer at the remote office that stays in contact with the central Endpoint Central server. Content the branch needs — the agent package for installations, and afterwards patches and software packages — is replicated to the DS, and the branch PCs collect it from the DS over the fast local network instead of every PC pulling across the WAN. Agents in that office are configured for that office, so they know to talk to their local DS. It is a cache and relay with a job, not a second management server: all decisions, policies and reports still live on the central server.

For a small branch — a handful of PCs on a decent link — skip the DS entirely. Download that office's agent package from the console, and install it by whichever route suits the branch: pushed from the console if the machines are reachable, a GPO if the branch is on the domain, or manually by the one technical person there. Each agent then communicates directly with the central server. The honest costs: the initial installs and every large patch cycle cross the WAN per PC, and if the link drops, the branch PCs simply queue their reports until it returns. For five PCs, that is a perfectly rational trade.

With a DS, the order matters. First the DS itself is set up at the branch and registered with the central server. Then agents are installed on the branch PCs using that office's package — again by console push, GPO or manually — and those agents take their instructions and content through the DS. The benefit compounds over time: it is not the one-time agent install that saves your link, it is every Patch Tuesday after it. Forty PCs downloading the same updates once through the DS instead of forty times across the WAN is the difference between a link that survives patch week and one that does not.

A DS is one more machine to keep alive, patched and monitored, so it must earn its place. As a working rule: a branch with a thin or metered link and enough PCs that duplicated downloads hurt earns one; a branch with three PCs on fibre does not. Also consider people: a DS needs a machine that stays switched on — a repurposed desktop that someone turns off at night is a distribution server that distributes nothing. If no always-on machine exists at the branch and the link is decent, direct agents are the honest choice. Decide per branch; Endpoint Central lets each remote office make its own call.

A DS that silently stops replicating looks, from the branch, like 'Endpoint Central is slow' — PCs wait on content that never arrives locally. Check the DS the way you check the agents: it should appear healthy in the console, its replication should be current, and the machine itself needs disk space for the content it caches. Give the DS a fixed address on the branch network, exclude its content folders from aggressive antivirus cleanup, and include it in your patch routine like any other infrastructure machine. If the DS dies, branch agents do not lose management forever — but they lose their local source, so treat DS downtime as a real ticket, not background noise.

Put together, a clean branch rollout runs like this: create the remote office in the console; decide DS or no DS per the rule above; set up the DS first if there is one; download the office's agent package fresh; pilot on two or three branch PCs (one of them the least technical user's); confirm those PCs report in, take a patch scan and accept a test configuration through the DS or directly; then roll to the rest by GPO or console push; finish with the failure ladder for the stragglers. That order — pilot before bulk, proof before pride — is what separates a branch that 'just works' from a week of trans-WAN troubleshooting.