Getting an agent onto a machine works two ways: download the installer and an enrolment file yourself and run them, or point a push job at a list of hosts and let the server do it remotely. Both roads end at the same enrolment endpoint and the same scoped token, so a batch of machines onboarded by push looks no different in Fleet from one installed by hand.
How it works
Every enrolment, whichever way it arrives, needs an install token that says which group the new agent should join. A token is not tied to one machine by name — it is redeemable a set number of times, decremented atomically as agents use it, so the same token can cover a single install or a whole batch depending on how it was minted. The self-service Deploy page mints one sized for a single machine; a push job mints its own, sized to exactly the number of hosts in that job, so a token captured in flight cannot be reused to enrol machines the operator never listed.
Self-service deployment
Deploy gives you the agent MSI and a generated enrolment file together. Picking a target group mints
a fresh token and produces autologon-enroll.xml, containing the server address, agent port, the
token and the CA’s certificate thumbprint. Dropping that file next to the MSI and running the
installer is enough — the installer picks up the sibling file automatically and the agent enrols on
first start, with no command-line arguments needed. The machine appears in Fleet within one poll
interval, or waits under Pending approval if the token required it.
Push deployment
Push targets a list of hosts from the console and installs or upgrades the agent on all of them without touching a keyboard on any of the machines. It runs over WMI/DCOM and SMB rather than WinRM — a deliberate choice, because a WinRM listener depends on a certificate that has to stay current, and on infrastructure old enough to need this kind of remote onboarding, that certificate is often exactly the thing nobody has kept up to date. An agent already installed on a target is upgraded in place: the existing certificate and agent identity survive, so a re-run does not produce a second row in Fleet or force a fresh enrolment. Success is judged by the agent actually checking in afterwards, not by the installer reporting a clean exit code — an installer can exit successfully while leaving a service that never enrols, most often from a bad or exhausted token.
Limits
Push deployment needs administrative credentials on the target and DCOM/SMB reachability, not just network connectivity — a host with WMI or file-sharing locked down by policy needs the self-service path instead, run locally or delivered through your own management tooling.
An installer exit code of 0 is not proof the agent works. A bad or already-consumed enrolment
token still lets msiexec complete cleanly while leaving a service with no working identity;
confirm the machine actually appears in Fleet rather than trusting the install log alone.
A token only ever grants what it was scoped to at creation — the target group, the expiry, and the number of enrolments it allows. Widening any of those means minting a new token; an existing one cannot be edited to cover more machines or a different group after the fact.