Head office wants one screen for every branch. The naive way — one server polling everything across the WAN — breaks quietly. The probe architecture exists precisely because of that failure mode.
A single office is easy: one OpManager server, one LAN, everything a millisecond away. Add branches and the geometry changes. Having the head-office server poll forty devices in a branch across a VPN or broadband link works on day one and degrades in ways that are hard to see: polling traffic competes with business traffic, a WAN cut makes the branch vanish entirely (is the branch down, or just unreachable?), and every graph from that branch inherits the link’s mood. ManageEngine’s answer, in OpManager’s Enterprise edition, is a two-tier architecture: a central server at head office holding the consolidated console, and a lightweight remote probe installed at each branch that discovers, polls and stores data locally, then reports summaries up to the central server. This page explains how that division works, what it fixes, and when a small network can honestly skip it.
The probe is a full local poller with a reporting habit — not a dumb forwarder.
Understand the failure before the fix. SNMP polling is chatty: dozens of small request-response pairs per device per cycle, plus WMI’s heavier RPC conversation for Windows servers. Across a LAN this is nothing; across a branch link it is a constant tax on the pipe the business is paying for, and every packet loss inflates timeouts — the suggested SNMP timeout of about five seconds turns a congested link into a discovery that never quite finishes. Worse is the blindness problem: when the WAN drops, head office cannot distinguish “branch network dead” from “branch fine, link dead”, and the alarms say the wrong thing with total confidence. Local polling removes both problems at the root.
The probe is a modest installation — a small server, VM or reliable desktop-class machine at the branch that stays on. It runs the same discovery routine from the earlier pages: credentials stored locally (each branch can have its own SNMP strings and WMI accounts), IP-range discovery of the branch subnet, local monitors and thresholds. The probe then connects to the central server over OpManager’s own secured channel — plan the documented connectivity between probe and central (and only that) through the branch firewall. Roll branches out one at a time: prove discovery, monitors and one test alarm at branch one before cloning the pattern.
The central console is where the architecture pays rent: one login, every branch. Consolidated dashboards roll the sites up side by side; the alarm view mixes branches into one queue, so the on-call admin triages the company, not one site at a time; reports can be generated per branch for the local manager or across all branches for head office. Credentials and configuration can be governed centrally in the Enterprise design, which matters more than it sounds — the day the SNMP string policy changes, you change it once, not eleven times in eleven branches. The NOC wall at head office finally tells the truth about the whole estate.
Test this explicitly, because it is the feature you are paying for: with a probe in place, pull the branch’s WAN connection. The probe keeps polling its local devices and storing their data; the central server marks the probe itself unreachable — one honest alarm about connectivity — instead of forty false device-down alarms. When the link returns, the stored data flows up and the branch’s graphs fill in. Compare that with direct polling, where the same event produces a massacre of alarms and a permanent hole in the history. For branches whose internet is a single consumer-grade line, this behaviour alone usually justifies the architecture.
Probes are an Enterprise-edition commitment, and not every multi-site network needs one. If a “branch” is three devices on a fast, reliable site-to-site VPN, letting the central server poll them directly is perfectly defensible — the chatter is trivial and the link’s reliability is proven, not hoped. A single small site can even run its own standalone OpManager (a Standard pack) with its own local admin, if head office does not truly need the consolidated view. The honest dividing line is the cost of blindness: if a branch going dark in your console would cause confusion, missed outages or a pointless site visit, put a probe there. If it would cause a shrug, do not.
The building blocks — credentials, discovery, alarms — are identical at probe scale; the setup video shows them all in one sitting.
▶️ Watch Full VideoThe probes are part of the Enterprise distributed architecture; licensing is by total devices monitored across the estate rather than per-probe fees in the usual model. Confirm the current packaging on ManageEngine’s official pages before budgeting, because edition terms are revised over time.
The probe keeps polling and storing locally, so the history is preserved and forwarded when connectivity returns; the central server shows the probe as unreachable in the meantime. Very long outages can exceed local retention at the edges — another reason the probe machine deserves a real disk, not leftovers.
Yes — a probe discovers and polls whatever it can reach with valid credentials, which typically covers the branch’s subnets. The design rule is geographic, not technical: one probe per site whose local polling you want to survive a WAN cut.