Set up the 27th server exactly like the first

Installing an agent on one machine is easy. Doing it on twenty-seven, with the same thresholds, the same alert channels, the same escalation ladder and the same runbook attached — that is where monitoring projects quietly fail. Not because it is hard, but because it is tedious, and the twenty-third machine gets configured at 5 PM on a Friday by someone who is nearly done caring.

The drift you do not notice

Hand-configuring each node produces a fleet where every machine is slightly different. Nobody set out to do it. It just happens:

• The first five have a disk threshold at 85%. The rest have whatever the default was.
• Three of them page the on-call rotation. The others email one person who left.
• Two have a runbook attached. Nobody remembers which two.
• One has no alert channel at all, so it has been silently unmonitored since June.

That last one is the one that gets you, and you find it during an incident, when the machine you were counting on to page somebody did not.

One template, applied at birth

A beacon node creates its own monitor the first time it checks in. A template decides what that monitor looks like the moment it appears — before anyone has a chance to forget.

Make one in the portal as a monitor of type Beacon — template, configure it the way you want every machine of that kind to behave, and it seeds:

Choosing which template

One line in the agent config decides. It takes a template name or its id, and it is case-insensitive:

Which means a fleet can carry several profiles at once — the ones that page loudly and the ones that do not:

Three behaviours worth knowing exactly

• Say nothing and you get the newest template. If the agent sends no template line, the workspace’s most recently created template is used. A workspace with exactly one template therefore just works, with nothing in the config at all.
• Name one that does not exist and the node is created blank — deliberately, rather than silently falling back to something that might page the wrong people. The node’s own event says so: no beacon template named X, created blank. If a machine shows up unconfigured, that line tells you why.
• Templates seed, they do not sync. This is the big one.

Seeding is not syncing

A template applies once, when the node’s monitor is created. Editing the template later does not reach back and change the machines it already seeded.

That is a deliberate trade, and it cuts both ways. In your favour: a per-machine tweak you made deliberately is never quietly overwritten by someone editing a template. Against you: fixing a threshold in the template does not fix the fleet, and expecting it to is the mistake to avoid.

For an existing fleet, change the monitors with a bulk edit — select them and set the field once — and change the template so new machines are born right. Two actions, on purpose.

A rollout that actually holds

1. Configure one machine by hand until its alerting is genuinely how you want it.
2. Create a template of type Beacon — template matching it.
3. Put the template name in your install config, or your configuration-management role, or the image you clone from.
4. Install on the rest. Each arrives fully configured and already paging the right people.

The test of whether it worked: pull the network cable on the newest machine and see whether the right person hears about it. If the fleet is templated, machine 27 behaves exactly like machine 1, including at 3 AM.

Agent documentation · Windows servers · Custom metrics