The agent will not enrol

Enrolment failures have a small number of causes and diagnosing them in order takes minutes. Diagnosing them out of order can take an afternoon, because the network is the most tempting suspect and the least frequently guilty.

Start with the token. Expired tokens are the most common cause by a wide margin, followed by tokens that were copied with a trailing space or truncated when pasted through a chat client. Regenerate the token and retry before investigating anything else — it is a thirty-second test that eliminates the majority case.

Then check the server address. It must be the console host, reachable over HTTPS from the endpoint, complete with scheme. An address that works from your browser on the office network does not necessarily resolve from a machine on a segregated VLAN.

# From the endpoint itself
curl -v https://<your-console-host>/api/ 2>&1 | head -20

A TLS error here rather than a connection failure is its own useful signal: it usually means an intercepting proxy is presenting its own certificate, and the agent will need to trust that proxy's certificate authority.

Next, confirm the service is actually running. An install can complete without the service starting, and the resulting silence is easy to mistake for a network fault.

# Linux
systemctl status aegisone-agent --no-pager
journalctl -u aegisone-agent -n 100 --no-pager

On Windows, check for endpoint protection interference. Security software quarantining an unfamiliar newly downloaded binary is common enough that it should be a standard check rather than a last resort, and it typically produces a silent failure rather than an error.

Finally, verify the architecture on macOS. An agent built for the wrong architecture may install and then behave oddly, and the symptom rarely points at the cause. Run `uname -m` on the target and confirm it matches the build you deployed.