Deploy Software to a Branch Office over Slow WAN with a Distribution Server
Sending a 500 MB installer down a thin branch link forty times is how WAN links die. A distribution server flips the maths — the file crosses once, and every branch PC installs from a copy in its own building.
🎥 Watch a remote office deployment being set up in the video
ManageEngine's own training example makes the problem vivid: 100 PCs in a remote office and a 50 MB file means 5 GB of WAN traffic if every PC downloads from the central server. The distribution server — one always-on machine in the branch — downloads each package once and serves it locally. Branch PCs then install at LAN speed, and the WAN carries console traffic and that single copy.
network — before and after a distribution server
Without DS50 MB × 100 PCs = 5 GB over the WAN
With DS50 MB × 1 to the branch, then LAN speed
ReplicationHappens before the install window opens
Install source for branch PCsLocal distribution server
The entire point of a distribution server in one panel — the WAN sees the package once.
1
Decide Whether the Branch Actually Needs One
Count the PCs and the link honestly: under ten PCs on a healthy link may not justify a dedicated machine
The classic triggers are more than a handful of PCs, a slow or metered WAN, or regular large deployments like office suites and CAD tools
The distribution server itself can be a modest, always-on PC or server in the branch — it stores packages and serves them; it does not need to be powerful
Name the branch as a remote office in Endpoint Central and assign its computers to it, so their traffic stays local by design
2
How Replication Actually Flows
When you deploy to a remote office, the central server replicates the package to the distribution server first. Only when the copy is confirmed does installation begin on branch PCs — deployments to a remote office effectively pause until replication completes. That pause is a feature: it guarantees no branch PC ever pulls a half-arrived package across the WAN.
Deploy to branch offices earlier than head office, so replication finishes before the install window
Watch the remote office's replication status instead of guessing from PC-level progress
Large first-time packages are the slow ones; later deployments reuse what is already replicated
3
Schedule Around the Link You Actually Have
Replication still crosses the WAN once — choose when. If the branch link is shared with business traffic all day, replicate overnight and set the install window for the following evening. If the branch works Saturdays and head office does not, that quiet window is yours. And keep the branch's own business hours in mind: an install window set in head-office time can land in the middle of the branch's busiest hour.
4
When Branch Deployment Stalls — the Short Checklist
Is the distribution server machine on and its agent healthy? A switched-off DS silently stalls the whole branch
Can branch PCs reach the DS on its HTTPS port 8384? A blocked port shows up as connection failures on every branch PC at once
Did replication actually finish? Check the remote office status before debugging individual PCs
Is the DS machine's disk full? It caches every package you send the branch — old packages accumulate
Same failure on every branch PC means the DS or the link; failure on one PC means that PC
5
Keep Branch Users in the Same Safety System
A distribution server changes the plumbing, not the discipline. Branch rollouts still get a pilot ring — two or three branch PCs first — because the branch's oldest machine and strangest local software live there, not at head office. The reports still roll up to the one console, so your morning-after check covers every site from a single screen.
🌐 The one-sentence case for a distribution server: if a deployment would cross your WAN more than a few times, it should cross it exactly once. Everything else — the slow mornings, the timed-out installs, the angry branch manager — is the sound of skipping that sentence.
🎥 Watch the Full Deployment in the Video
Watch remote office and distribution server concepts in the full video.
Any always-on Windows machine in the branch with enough free disk for your packages can serve. Pick a machine that nobody switches off at night and nobody uses as their daily desktop — stability matters more than speed.
Do branch PCs ever download from the central server directly?
In a remote office managed by a distribution server, branch PCs take packages from their local DS — that is the design. If the DS is down, deployments wait rather than flooding the WAN, which is why the DS machine's health is worth a daily glance.
How do I know replication has finished?
Check the remote office's status in the console before the install window. Deployments to a remote office pause until the required packages are replicated, so if branch installs have not started, replication is the first place to look, not the PCs.
This guide is based on the Technical Anshu video on remote software deployment with ManageEngine Endpoint Central • Stuck on a step? Ask in the video comments and you will get a reply 🙏