Install the agent

Agent Deployment

Install the SentinelOps agent on any reachable host by IP, straight from the server — no on-LAN proxy and no prior discovery. Linux uses SSH (the SentinelOps deploy key or a stored SSH credential); Windows uses WinRM with a stored Windows credential. Why it is here: it lets you onboard servers and cloud VMs you can route to but cannot walk up to, and run it once, at a set time, or on a recurring schedule. Tenant benefit: every host you deploy enrols into the tenant selected in the top bar, and each target’s progress is tracked live so a customer’s fleet comes under management without hand-running an installer on each box.

New deployment — the fields: Name labels the job. Method is Linux — SSH or Windows — WinRM. Target IPs takes one or many (one per line or comma-separated). Login user (SSH) defaults to root. Credential picks the stored SSH or Windows credential to log in with (SSH can instead use the SentinelOps deploy key). “Fresh install (new host)” is ticked by default — untick it to replace the binary on an existing agent rather than do a clean install. WinRM port defaults to 5985. A banner confirms which organization the hosts enrol into.
Deploy key: The server’s own SSH key, reusable across hosts. Authorize its public key once on each Linux host’s authorized_keys and SentinelOps can deploy there without a password. The key is shown in the New deployment form.
When — Now / At / Recurring: Runs immediately (Now), at a set date-time (At), or repeatedly (Recurring with an hourly / daily / weekly cadence). The list auto-refreshes in place and each host shows pending → running → installed / failed with the reason; “Run now” re-runs on demand. Needs credential.manage.
Never deploy to: IPs/CIDRs listed here (one per line) are never deploy candidates and every deploy path refuses them — a deployment targeting one fails for that host with “on the never-deploy list”. Use it for your own workstation. Same list as Deploy Agent → Never deploy to and the Agent Launcher.

Deploy agent

Generates the installers that enrol a new endpoint, plus the tools to push the agent onto a machine you can reach. Each installer already knows this management server and carries a single-use, expiring, revocable enrolment token, so a customer’s device joins the right tenant the moment it runs with nothing to configure by hand. Why it is here: enrolment is the front door to everything SentinelOps does, so it is deliberately least-privilege and revocable. Tenant benefit: one reusable, tenant-stamped installer per customer means every machine lands under the correct organization automatically.

Endpoint agents panel: Lists the agent binaries this server serves, per platform, with size, build time and a build fingerprint so you can confirm exactly which build endpoints receive. “Force update all” pushes every endpoint on an older build to the current one now instead of waiting for its self-update timer; “Rebuild agents” recompiles them where a build toolchain is present (otherwise it reports that agents ship with the package). A red “stale” warning means a deployment updated the server and left older agent artifacts behind — fix it before generating installers so endpoints are not handed an out-of-date agent.
Deployment package: Defines what a new device inherits: the OS, the filesystem roots the agent may manage, the group and tags, and how many times the token may be redeemed. Create one, then generate its installer. Treat the resulting URL as a credential and revoke the package after a rollout.
Installer: A one-line command (shell or PowerShell) or, on Windows, a bundled .exe with the token embedded. Hand out the downloaded file, not the URL — the URL embeds the enrolment credential.
This tenant’s agent installer: The one stable installer for the tenant selected in the top bar (no selection = the default tenant; the panel names the tenant it actually stamps). Every device it installs enrols into that tenant. It is reusable and never expires (auto-renewed), so you can keep one .exe per customer. Pick Windows / Linux / macOS: Windows gives a click-to-run .exe plus a PowerShell command; Linux and macOS give a shell command. The link embeds an enrolment credential — hand out the downloaded file, not the URL. To retire it, revoke the “Tenant installer” row under Deployment packages; the next visit mints a fresh one. Needs enrollment.manage.
Windows .exe and Defender: The .exe sets a Windows Defender exclusion for the agent before it installs, so Windows 11 does not quarantine it mid-install. It is not code-signed yet, so SmartScreen shows “Windows protected your PC” — choose More info → Run anyway, as administrator. It installs to C:\Program Files\SentinelOps, registers the SentinelOps Agent service and enrols.
Self-enrollment port-knock (the banner): A green “Self-enrollment is on” banner means the installers include a port-knock: a machine on a brand-new IP (a cloud VM, a remote site) presents its deployment token, authorizes itself on the agent firewall and enrols with no manual firewall change. If the banner says it is not active, a machine on an IP the agent firewall does not already allow is blocked until its IP is authorized (a cloud VM SentinelOps provisions is authorized automatically). The site-wide toggle lives in Settings → Features.
Agent Launcher / Deploy to a host by IP (the buttons): With command.execute you get two actions in the header. Agent Launcher takes one or more targets (IP, DNS name, range or CIDR), probes each to auto-detect the OS and transport, then deploys and opens the firewall automatically. “Deploy to a host by IP” installs from an online agent on the host’s LAN using a stored credential — no installer run by hand. The OS picker does not follow your browser, so choose Windows explicitly to get the PowerShell command and the Download .exe button.
“Binary only” is not an installer: The per-agent “Binary only” button downloads the agent program on its own — it does not register a service or enrol the machine, because it carries no server address and no token. Use it for imaging or a manual install where you supply those yourself. To actually enrol an endpoint, create a deployment package and run the installer it generates.
Pinned SSH host keys: The first time SentinelOps connects to a machine over SSH (agent install over SSH, HA node deploy, database provisioning) it remembers that machine’s SSH host key. Every later connection must present the same key, or it is refused before any password or key is sent, which protects vaulted credentials from a spoofed or hijacked address. If a machine was really reinstalled (new keys), click Forget on its row and retry; the next connection pins the new key. A refusal names both fingerprints and is recorded in the audit log. Needs credential.manage.
Never deploy to: A list of IPs and CIDRs (one per line) SentinelOps must never install an agent on — use it for your own workstation and any other machine that must stay unmanaged. Listed machines are never offered as deploy candidates in discovery, and every deploy path refuses them server-side: direct SSH, direct WinRM, proxy-assisted deploy, auto-deploy on discovery, scheduled Agent Deployments and the Agent Launcher. Saving also clears the candidate flag on hosts already discovered. The same list is editable here, in Agent Deployment and inside the Agent Launcher. Invalid lines are rejected with the offending entry named. Needs credential.manage.

Next: Find your way around →