Endpoint visibility when your estate is spread across dozens of sites

Managing four hundred endpoints in one building is a different job from managing four hundred across thirty sites, even though the number is the same. The techniques that work in a single location fail quietly at distance, and the failure is usually invisible until something goes wrong at a site nobody had thought about recently.

Three problems dominate.

Problem one: nobody is looking at the small sites

Attention follows incident volume, and incident volume follows headcount. Your largest sites generate the most tickets, so they get the most attention, so their problems get found early. A six-person office generates almost no tickets, gets almost no attention, and accumulates issues nobody notices until they become urgent all at once.

The uncomfortable version of this is that a small site with no tickets is ambiguous. It might be running perfectly. It might also be that the people there have concluded raising tickets is not worth the effort and have been working around a problem for eight months. Ticket volume cannot distinguish these two, and it is the metric everyone uses.

What distinguishes them is data the site does not have to volunteer. Endpoint health and connectivity history is collected by the agent regardless of whether anyone at the site says anything. A site with steadily degrading connectivity over two months is telling you something specific, and it is telling you without anyone having to decide to complain.

Problem two: reading shape instead of reading rows

With one location, a list of problems is manageable — you work down it. With thirty locations, the list is long enough that working down it is the wrong strategy, because the individual rows are much less informative than their distribution.

Several endpoints at one site going offline together is a site event: connectivity, power, or a change someone made locally. Chasing those machines individually is the classic way to lose a day to something one phone call would have identified. Endpoints across many sites going offline together points at something in the middle — a proxy change, a certificate, DNS, or something on your side. A single endpoint offline alone is the genuinely per-machine case, and it is the rarest of the three.

The skill in a distributed estate is reading which of those three shapes you are looking at before doing any work. It sounds obvious written down and it is consistently skipped, because a list of individual problems invites you to start at the top.

Problem three: the devices with no agent on them

Agent-based inventory has a structural blind spot. It can only tell you about machines that have an agent. Everything else on a site network — printers, switches, access points, cameras, appliances, and the machine somebody plugged in without mentioning it — is invisible to it.

In a single office this matters less, because someone walks past the equipment. At distance nobody does. A remote site can acquire hardware over years that appears in no inventory, has never been patched, and is discovered during an incident or a security assessment.

Network discovery is the answer, and the first scan of a site you have managed for years is routinely the most informative thing you do that week. What it finds is rarely exotic: some machines nobody mentioned, network equipment absent from the handover documentation, and at least one device whose purpose nobody at the site can explain.

Keep discovered devices in a separate register from managed endpoints. The moment the two share a list, someone reports the combined number as devices under management and it reaches a customer.

The structural fix

Model sites properly from the beginning, because everything downstream inherits it. A site is a location where endpoint behaviour differs because local conditions differ. That is the right granularity for "why is this office worse than the others", and the natural unit for dispatching someone.

Resist over-modelling. A site per floor produces a tree nobody can navigate and reports nobody reads. Remote staff are usually best handled as one logical site per client rather than a site each.

Then keep ownership current. An endpoint with a named owner is one you can ask about. An unowned endpoint at a remote site accumulates uncertainty until eventually someone proposes decommissioning it and nobody is confident enough to agree — and it sits there for another two years, patched by nobody, doing something nobody remembers.

One honest caveat

None of this notifies you. AegisOne has no alerting engine — health and connectivity history are collected, retained and surfaced, but nothing evaluates them against thresholds and pages anyone. In a distributed estate that gap matters more than it does centrally, because there is nobody at the site to notice.

The practical answer today is to poll the API from whatever already handles your on-call routing and evaluate the conditions there. Plenty of teams prefer that arrangement regardless, since escalation policy and rota stay in one system rather than being duplicated across every tool. But it is a thing you have to arrange, and it is better to know that before you deploy than after.