A Thousand Hosts, Without a Thousand Sign-Ins

August 13, 2026 · InfraScout Team

Enrolling an agent has been one command for a while now. You run enroll auto, a browser opens, you sign in to Entra ID with a device code, and the host provisions itself and installs its service. It is a good experience — on one host.

On four hundred it is not an experience at all. Nobody sits at a device-code prompt four hundred times, and the machines that need agents most are the ones nobody logs into: golden images, servers built by SCCM, appliances deployed from a template. Interactive enrollment has no answer for those, so the fleet either does not get agents or somebody writes a script that works around the sign-in.

Bulk enrollment keys are the supported answer. One credential, minted once, that a configuration manager can carry to every host without a human in the loop.

What a key is, and what it is bounded by

You mint a key under Admin → Enrollment Keys. It is a bek_… string, and it is deliberately hemmed in on three sides:

• It expires, in thirty days at most. There is no permanent enrollment credential.
• It has a use cap, which is mandatory rather than optional. You say how many hosts this key may enroll, up to two thousand. A key that has enrolled that many stops working.
• Your tenant holds at most a hundred live keys at once, which keeps the set small enough to actually audit.

The key is shown once, at the moment it is created, and never again. InfraScout stores only a hash of it, so this is not a policy that could be relaxed — nothing in the system is capable of showing it to you a second time. Save it into your configuration manager's secret store while the dialog is open.

Anyone holding the key can enroll hosts into your tenant until it expires or runs out. Treat it exactly like the deployment credential it is.

Nothing joins the fleet unasked

A key requires approval by default, and that default is the point of the whole design. A host that enrolls with a bulk key provisions its identity and then waits.

While it waits, it is not partially present — it is absent. It appears on no assessment surface, it belongs to no group, and a command addressed to it fails as though the agent does not exist rather than as though you lack permission. Nothing it reports is accepted. An operator who gets hold of your key can create pending registrations; they cannot put a host in front of your assessments.

Approving is a click, individually or across a whole rollout wave at once. An Agent Waiting for Approval Should Not Be Invisible covers how those hosts surface for review and what approving now does.

Revocation that reaches what the key already touched

Revoking a credential that has already been used somewhere is usually only half a remedy — the credential stops working, and everything it minted keeps going.

Revoking an enrollment key here sweeps forward. The key stops provisioning, the enrollment tokens it already issued are invalidated, and every host still pending approval under it is removed. "Revoked" means the key's effects are gone, not merely that it cannot be used again.

That is backed by provenance. Every key can list the hosts it enrolled, so you can answer "what did this key put on my network" as a question rather than an investigation — and mass-revoke all of them from that same view, behind a typed confirmation, if the answer is not one you like.

Signed installers, and why they install before they enroll

Three installers ship with this: install-agent.ps1 for Windows, install-agent.sh for Linux, and install-agent.yml for Ansible. Each is a thin wrapper over the same enroll auto the interactive path uses, and the PowerShell script is Authenticode-signed by ITdesign Software Projects & Consulting so you can verify it before running it.

They exist for one reason that is worth stating plainly, because it is easy to get wrong when writing your own wrapper.

Installing the agent's service registers the binary at its current path and then runs it as SYSTEM or root. The command the portal used to hand you ran the binary straight out of your downloads directory — which meant every host enrolled that way ended up with a privileged service pointed at a file any local user could replace. The installers move the binary into a directory only administrators can write, C:\Program Files\InfraScout Agent\ or /opt/infrascout-agent/, before enrolling. There is no shim: that path is the one and only location of the binary on every host the scripts touch.

Each script also verifies the download's checksum against the release manifest before it installs anything, and supports pointing at a binary you staged yourself for hosts that cannot reach the internet.

The Ansible playbook reads the release manifest once per play rather than once per host. Beyond saving a few hundred identical requests, that is a correctness fix: a release published part-way through a run could previously hand different hosts different agent versions within a single play.

The em dash that broke an install

One incident from the live dev fleet is worth passing on, because the failure was so far from its cause.

An operator installed the Windows script the natural way: opened it through the browser link, copied the text into Notepad, saved it, ran it. It failed to parse, with Missing closing '}' reported hundreds of lines away from anything wrong.

The published file was byte-perfect the whole time. The damage happened in the copy-paste. Saving from Notepad dropped the file's encoding marker, Windows PowerShell 5.1 then read the bytes as the ANSI code page, and an em dash in a comment decoded into a character PowerShell treats as a string delimiter. Everything after it was one enormous string.

Four things changed so that path cannot bite again. The script is now pure ASCII, and a CI gate rejects any change that reintroduces a non-ASCII byte. Publishing declares the character set explicitly rather than leaving PowerShell to guess. The portal's dialog replaced its buried prose link with a real action row — Copy command · Download script · View source — where Download fetches the raw bytes rather than the text, because reading it as text is exactly what strips the marker and would also invalidate the Authenticode signature.

And the rule the incident taught is now printed next to the buttons: run the downloaded file, not a pasted copy.

Getting the key to the host without writing it down

The command you copy at mint time is paste-ready — the right binary name for the platform and architecture you picked, the correct API address taken from the portal you are signed in to, and the key already in place. A command copied from one environment cannot accidentally point a host at another.

From there, two changes to how the key travels.

The rollout scripts themselves are not a secret — they are public, signed, and identical whatever key you feed them. But they used to be reachable only from inside the one-time mint dialog, which welded the tooling to the credential: an operator holding last week's key had nowhere to go for the Windows script. A Rollout scripts button now sits on the Enrollment Keys page and opens them any time, rendered against a bek_… placeholder. It works on a tenant with no keys at all, which is the state you are in the very first time you want them. It is deliberately not attached to a specific key and never renders a real one, because a per-key button would imply the key could be recovered.

And the manual command no longer passes the key as a flag by default. A key in a command-line argument is visible in the host's process list while the command runs, is written into shell history afterwards — PowerShell's default filter for sensitive values matches on words like password and token, so a flag named --key sails straight past it — and lands in sudo's logs, which are frequently forwarded to a SIEM. The agent has always accepted INFRASCOUT_ENROLL_KEY from the environment instead. The portal now offers that form, so the copyable command keeps your key out of all three places.

One thing a bulk wave does that a trickle does not

Worth knowing before you run one, because it is invisible until it is not.

Hosts enrolled together receive certificates that expire together — a thousand hosts enrolled on a Tuesday afternoon share an expiry to within minutes of each other. Left alone, that means a thousand simultaneous renewals roughly two months later, all landing at once.

Renewal is therefore spread deliberately. Each agent derives its own renewal moment from its own identity, scattered across a window of twenty to thirty days, and it computes the same answer every time regardless of which part of the service it talks to. A thousand-host spike becomes a trickle of about a hundred a day. You do not configure anything; it is worth knowing only so that a staggered renewal pattern reads as correct rather than as drift.

One genuine limit does need planning: enrollment is rate limited per source IP, which works out to roughly 1,820 hosts per NAT before you need to stagger. Sites larger than that should roll out in batches of about a thousand, spaced ten minutes apart. Fleet Rollout has the arithmetic and the troubleshooting.

Getting started

Mint a key, pick the platform, and run one command per host through whatever already reaches your fleet — GPO, SCCM, Ansible, Intune, or a golden image. Then approve the wave.

See Fleet Rollout for the full guide, including the air-gapped path and what each installer parameter does.

Questions or feedback? Reach us at info@infrascout.cloud.