How every page and setting works.

The at-a-glance state of the organization you have selected (or the whole fleet when no tenant is picked). It exists so an operator opens one screen and immediately sees what is enrolled, what is online, what is being attacked, what is out of compliance and what needs patching — instead of hunting through modules. For the tenant it is their live operations picture: a tenant-scoped account sees only its own organization, and every tile and panel links straight to the view that resolves it, so nothing is a dead end.

KPI tiles

Seven live counters, each clickable to the view behind it: Total Endpoints (with "↑ N this week" → Devices), Online Agents (% of total → Devices), Critical Alerts (N open total → Alerts), Patch Compliance (%, with critical·security counts → Patch Management), Active Packages (of N total → Agent Deploy), Scheduled Jobs (enabled of defined → Scheduled Jobs) and Services Up (up/enabled monitors → App Monitoring).

Security & attacks

Brute-force IPs blocked at the host firewall (total and last-24h), active attacks (IDS / brute-force detections), and open critical and warning alerts. The status pill and each metric deep-link to Threat Blocks or Alerts focused on exactly what it counts; a top-origins line summarises where the blocked attackers came from (RDAP country lookup).

Patch status

Compliance percentage plus Critical / Security / Available / Need-reboot / Non-compliant / Unknown counts, and the next scheduled patch run. Each number opens Patch Management pre-filtered to that set. Shown once scan data exists.

Vulnerabilities

Exploited-in-the-wild (CISA KEV), critical and high CVE counts across endpoints from the offline OSV/KEV scanner, with affected and scanned device counts. Each tile opens those findings. Appears once something has been scanned or the offline CVE database is synced.

Domain controllers

One card per detected DC with dcdiag / replication / DNS failure counts and an aggregate healthy/unhealthy pill; click a controller for its diagnostics. Appears only when the tenant actually has a domain controller.

System Performance

CPU, memory and disk charts for the fleet (or one machine, via the selector), drawn from live heartbeat telemetry across reporting endpoints. The chart type is selectable; "Devices →" opens per-machine performance.

Endpoint Distribution

A chart per platform family (and its SNMP/hardware detail), with selectable chart style and columns-per-row — an honest split of the managed fleet by OS.

Application & Service Health

A grid of per-system mini-dashboards (resources + services + alerts), driven live by the app/deep-DB monitors. Controls: trend chart style, how many systems to show (Auto/4/6/8/12/16/24), a "Systems…" picker, and Priority / Issues / All filters. "Monitors →" manages the checks. Thresholds and the auto-high-risk service list are set in Settings.

Log monitoring

Critical and total OS-log alert matches in the last 24h plus active alert and suppression rule counts; each metric opens Log Monitoring. Requires alert.read.

SentinelOps platform health

The platform’s own services — API, database, message queue, alerts, workers, HA and email — with live status; "Open →" goes to High Availability.

Hypervisor hosts

XCP-ng / Proxmox / vSphere / Hyper-V hosts monitored agentlessly, with live CPU / memory / disk / temperature. Appears when hosts are configured.

Backup health

Failed / Overdue / Unprotected / Not-reporting / Protected counts across managed endpoints, with an at-risk headline; "Open →" goes to Backups. Tenant-scoped.

Profile & service backups

Recent profile/service captures with running/captured/failed counts; shown when you hold file.backup and a tenant is selected.

Device Inventory

The first 10 endpoints with OS, status, CPU/RAM/storage bars, last check-in and open-alert count; click a row for the device drawer, "All devices →" for the full grid. device.token.revoke shows an inline Remove.

Alerts rail

The most-severe-then-oldest open incidents; click one to jump to the affected device, "View all" opens Alerts.

Microsoft 365 & Sign-in activity

When configured for the tenant: a Microsoft 365 panel (users, licences, Secure Score, groups, Entra devices) and a Sign-in activity panel (a 24-hour bar graph and recent sign-ins to servers tagged monitor-logons).

SNMP monitoring

A rollup for SNMP-enabled machines; if endpoints are eligible but have not reported yet it says so and why (older agent build), rather than rendering blank.

Configure

The ⚙ Configure button (top right) shows or hides the standard panels for this dashboard (operator.manage; applies to everyone viewing it) and, under "Your custom KPI panels", lets you build your own panels from live metrics and choose which appear here — personal to you, available to any operator. Custom panels sit at the top of the dashboard and update live; "Reset layout" returns every panel to its default position.

Turns the telemetry each endpoint already reports into threshold and service checks that raise alerts through the same deduplicated, audited pipeline as everything else. It exists so a busy fleet is watched automatically — a sustained CPU/disk spike or a stopped service pages you instead of being noticed only when something breaks. For the tenant it means their machines are proactively monitored on their own thresholds, scoped to just the devices that matter, with no extra tooling to run.

Fleet utilisation

A live table of every endpoint’s CPU, memory and disk (as meters), load average, uptime, status and last-seen — straight from each heartbeat. The summary shows how many endpoints are reporting metrics, active breaches, and the fleet average CPU / memory / disk. Click a row to open that device; device.token.revoke shows an inline Remove.

Checks

Add check (needs rule-manage) opens a rule: a threshold check (e.g. CPU above 80% held for a number of seconds) or a "service stopped" check. A rule can be scoped to a device role, group and/or tags so a Windows-only or server-only check targets just those devices; leave the scope empty for tenant-wide. Only a sustained breach — not a momentary spike — raises an alert. Each rule row shows its condition, scope and for-seconds, and can be disabled or deleted.

Active breaches

Open incidents raised by these checks are listed at the top with their summary and age, so a current problem is visible before you scroll the rule list.

Watched services

A matrix of the last state each endpoint reported for every watched service. "—" means that endpoint has not reported it yet (the agent picks up the watch list on its next heartbeat; very old agents never will) — deliberately not shown as an error. To remediate a stopped service, open the device and use the Service action (start/stop/restart), which is allowlisted on the agent and second-operator approved.

Certificate expiry

TLS endpoints you name with "Watch endpoint" are handshaked every 6 hours and listed soonest-expiry first. Because an agent fails closed on TLS, an expired certificate takes endpoints offline — this warns you first, distinguishing "expired", "days left" and "unreachable" from "not checked yet". "Check now" runs one immediately; Delete stops watching it.

A per-device and whole-tenant health score, worst-first, with the concrete reasons each device lost points. It exists to turn scattered signals — patches, disk, reboots, backups, connectivity — into one ranked worklist so you fix the machines dragging the organization down first. The score is 100 minus weighted deductions, and a device is never penalised for a dimension it was never assessed on, so the tenant number stays honest and defensible for the customer.

Tenant score and bands

The summary shows the overall tenant score and how devices split into healthy (85 or above), attention (60–84) and at risk (below 60). Watch the at-risk band — those are the machines pulling the tenant number down.

What moves the score

Points are deducted for outstanding critical patches, disk pressure, a pending reboot, a failed or missing backup, and being offline. Each is weighted, so a device with a failed backup and critical patches scores well below one with a single minor issue.

Reasons per device

Every device row lists its specific deductions with their point penalties, so you know exactly what to fix — not just that a machine "looks unhealthy". A device with nothing outstanding is shown as healthy rather than given a vague pass.

Drill into a device

Click any row to open that device’s drawer and act on the reasons — apply the patch, clear the reboot, re-run the backup. Fix the highest-penalty items first to lift both the device and the tenant score fastest.

Connectivity and version currency across the managed fleet in one view — how many agents are online, how many are stale, and how many are running an older build than the current one. It exists because an endpoint is only as manageable as its agent: a dead or outdated agent silently stops reporting and stops accepting jobs. For the tenant it is the one screen that proves their machines are actually being managed and lets you repair the ones that are not. Version currency is judged per platform, so a Windows agent is only "behind" a newer Windows build, not a newer Linux one.

Read the KPIs

The tiles show total Agents, Online, Offline/stale (offline + degraded + connecting), Up to date and Behind. The current build for each platform is printed below the tiles — anything on an older build for its platform counts as Behind.

Fix one machine

Click any row to open its details and a one-click fix (force an update or repair). An offline machine’s fix is queued and applies when it reconnects; an online one applies now.

Fix all at once

When machines need attention a "Fix all N needing attention" button appears (needs device.manage). It requests a fix on every flagged agent and, where possible, wakes offline ones — updates then apply now if online or on reconnect if offline.

Stale vs offline

Status is heartbeat-age based. A machine that stops sending heartbeats reads as offline/stale even if it is technically powered on — check the row detail before assuming the box is down.

The central inventory of every managed endpoint, built as a queryable projection rather than a fixed table — you choose the columns, filter with an expression, sort, and save the result as a reusable view. It exists so one screen serves every job, from a quick status glance to a defensible CSV export, and so a single row opens into the full device drawer where every remote action lives. For the tenant it is the single source of truth for their machines, and the launch point for operating any one of them.

Role tabs

All / Servers / Workstations / Mobile filter by the device role, derived from OS and inventory and overridable per device. "Unmanaged" opens network Discovery.

Filter expression

A text query, e.g. "os:linux AND cpu_load_pct > 90" or "NOT tag:decommissioned". Durations like 30d compare age on time columns; versions compare numerically. Press Enter to apply.

Manage columns

Opens the drawer: search 29 columns across Identity, Telemetry, Network, Agent and Security, toggle them on or off, and reorder the shown ones. The same projection backs the API and the CSV export.

Saved views

Save the current columns, filter, sort and density as a private or tenant-wide view. Selecting a view applies all of it.

Sorting & density

Click a header to sort; shift-click to add a secondary sort. The density button cycles comfortable / standard / compact row heights.

Export

Writes the current projection to CSV with a header block recording the filter, count and timestamp, so the file stays defensible evidence.

A device row

Click any row to open the detail drawer: telemetry, jobs, live preview, remote access, files and annotations — and the Quick actions grid below.

Device drawer — Quick actions

The drawer’s action grid is where you operate the machine, each button permission-gated (a limited role sees fewer): Live screen, System info, Update now (force a re-report), Processes, Event log, Local accounts, DNS, Message user, Files, Command, Terminal, Run script, Deploy software, Mount media, Services, Security & activity, Audit & Access, Activity audit, Timeline, System report, Isolate host, Drives, Applications, SNMP, Maintenance lock, Operational status, Wake-on-LAN, Patch this device, Hypervisor power, Scan this segment / Find host & siblings, Wireless scan, Bluetooth (on / off / check, plus “Keep Bluetooth on”, which switches it back on every 2 minutes if it goes off — on macOS the agent needs a one-time approval in Privacy & Security → Bluetooth), Travelling (GeoIP exemption), Local admin (vaulted LAPS), SSH tunnel, Sessions, Reboot, Shut down, Remote session, Restart agent, Back up profile, Move to tenant, Decommission, Remove device, and a per-device Patch policy selector (All updates / Security only / Excluded).

Terminal, Command & Run script

Command runs a single allowlisted command and returns its output. Terminal (needs remote.control; labelled "Terminal (PowerShell / CMD)" on Windows) opens a full interactive xterm.js window with Ctrl-C, a control-key sender, detach-into-its-own-window (⧉) and End session — open several at once (they cascade), and drag-and-drop a file onto it to upload to the shell’s working directory. Run script runs an allowlisted interpreter, second-operator approved. SSH tunnel reaches the endpoint’s own SSH/TCP port through the agent with no open port.

Sessions → working behind the signed-in user

The drawer’s Sessions panel shows who is signed in and lets you work without interrupting them: Backstage tools (terminal, services, files that run without their screen), Run in the user’s profile, and a Second interactive session over the audited tunnel. On client Windows a second desktop logon disconnects the user (an OS limit); on Windows Server it runs alongside them.

Sessions → Concurrent desktop (macOS)

On a Mac (Apple silicon, macOS 14+) Enable & connect turns on Screen Sharing and gives you a vnc:// link. Connect from a Mac’s Screen Sharing app and choose "Log in to a virtual display" to get your OWN desktop while the signed-in user keeps working; any other VNC client shadows their screen instead. Needs remote.control and a Mac admin credential vaulted for the device. Turn Screen Sharing off when done.

Retiring a machine (Shut down → Decommission → Remove)

These live in the drawer and are permission-gated, so a limited role may not see them. Shut down (needs command.execute) powers the box off now or on a schedule — it keeps running SentinelOps. Decommission (needs device.status.change) marks the device decommissioned: alerts, patching and automation pause, and a removal-protected agent is allowed to deregister — it STAYS in inventory; you confirm by typing the device name. Remove device (red, needs device.token.revoke) deletes it from inventory, revokes its agent token AND deletes everything tied to it — GeoIP / log-alert / monitoring rules aimed only at it (shared rules just drop it), its vaulted LAPS and Mac admin passwords, scans, patch state, metrics, blocked-IP records, firewall grants and IP allocations. Retained on purpose: the audit trail, activity evidence, session recordings, tickets and asset records; BMC and hypervisor entries are kept but unlinked. Irreversible, and refused while a legal hold covers the tenant. SentinelOps also sweeps hourly for anything a machine removed some other way left behind. Typical order: shut down if you want it off, decommission to retire it cleanly (keeps everything), then Remove device to delete the record and its related data.

Every device seen on the organization’s networks in one list, grouped by type: agent-managed machines, cameras, switches, firewalls, access points, unmanaged endpoints and other/unknown hosts. It exists so you see the whole estate — not just what has an agent — and can act on each kind in place. The server classifies the devices (so the web console, Android and iOS group them identically), giving the tenant one complete picture of what is on their wire and what is still unmanaged.

Type buckets

Enrolled (agent-managed) devices are combined with hosts found by discovery. Each bucket is a collapsible section with its count (agents and cameras open by default); columns Name, Address, Type and Status are click-to-sort.

Location column

Agent-managed machines show their geo location (public IP or GPS); discovered hosts show the switch port or access point they were last seen on, when known.

Per-device actions

Each row’s actions depend on its type: an agent-managed row has Manage ▸ (opens the device drawer); a camera has Live (view), Web and Forget; a discovered host has Deploy agent (when it is a candidate — jumps to Discovery pre-filled), Web, and Forget. "Forget" removes a discovered host from the list.

Finding more

Group-level buttons help you fill the picture: "Scan for cameras" on the Cameras group, and "Discover more" (opens Discovery) on unmanaged / switches / access points. Empty switch/firewall/AP groups hint to run a Wireless scan or add an SNMP switch.

Plots every geolocated device on a world map, from its public IP address (or a mobile device’s GPS). It exists to answer "where are these machines?" at a glance — useful for spotting an endpoint in an unexpected country or confirming a site’s footprint. For the tenant it is a quick geographic view of their estate; the map ships inside the console, so no external map tiles are fetched and no device coordinates leave the server.

Summary

Three counters head the view: Located (devices with coordinates), Sites (distinct locations after nearby devices are clustered), and No geo (devices with neither a public-IP lookup nor a GPS fix — these are not plotted).

Pins

Each pin is one location with the devices seen there (a numbered dot when several cluster). Click a pin to see the machines at that place; the site table below lists Site, Devices, ISP and Coordinates — click a table row to zoom the map to it.

Navigation

Drag to pan, use the mouse wheel or the +/− buttons to zoom, and Fit to re-centre. Refresh re-reads device locations.

Accuracy

IP geolocation is city-level at best and shows where the internet connection egresses, not the building. The ISP/org is shown where known. Approximate locations are flagged.

Device groups inside an organization — the Tenant → Group → System tree — and who can access them. Groups exist so policy, deployments, access and overrides apply to a set of machines at once instead of one by one, and so engineers’ reach can be ring-fenced to just the groups they manage. For the tenant, a group is the "group" scope used by Self-Healing overrides and maintenance windows, deployments, locks and access grants. Every group belongs to exactly one organization (never global); a sub-group must sit under a parent in the same organization, and a machine can only join a group in its own organization. (User groups — which grant roles to people — are under Administration → Users & Identity → User Groups.)

The tree

Each organization expands to its groups and sub-groups, every node showing its total system count; a running/stopped dot marks each system online/offline. An "Ungrouped" node holds machines in no group. The view scopes to the organization picked in the top bar.

Create / rename / delete

"+ New group" (or a tenant’s own "+ Group") creates a top-level group; "+ Subgroup" nests one under a parent; Rename and Delete manage existing ones. Deleting a group moves its systems to Ungrouped, moves any sub-groups up one level, and removes its rights and its Self-Healing overrides and maintenance window. (All need operator.manage.)

Assign systems

Assign systems chooses which of the organization’s machines belong to the group; a machine is in at most one group.

Locks

The 🔒 Locks button sets a live policy on the group that applies to every current AND future member: Lock commands (no commands, scripts or service actions run on members) and Disable installs (no software installs or patch applies). Reads, screen and inventory are never affected.

Rights

Rights grants or revokes operator access scoped to this group — the ref-counted access control that lets an engineer manage only their groups.

Every machine that has an agent, grouped by server — each group holds all of that device’s DNS: the records the DNS system returns for it, its domain’s records, and the resolver configuration its agent reported. It exists so DNS problems (a stale record, a wrong resolver, a missing PTR) can be diagnosed per machine without leaving the console. For the tenant it is a consolidated, on-demand DNS picture of their whole agent fleet. Mobile and decommissioned devices are excluded.

One group per server

The view lists each agent machine; click one to expand and lazily resolve its DNS (only on first open, so the page stays fast). Its records are resolved live by the server — no agent round-trip for the lookups — and an expanded group’s ↻ button re-resolves just that one. Expanded groups survive the daily refresh and tenant switches.

This host’s records

Forward A/AAAA for the hostname and FQDN, reverse PTR for every known IP, and CNAME — what DNS actually returns for the machine.

Domain records

NS, MX, TXT and SOA for the device’s domain (derived from its FQDN), so you can see the zone it belongs to.

Resolver configuration

The nameservers the machine queries, its search/suffix domains, and its hosts-file overrides — reported by the agent and refreshed when it checks in. Requires a recent agent (0.5.16+).

Also in the device drawer

The same DNS view is available per device from its Quick actions → DNS button.

The enrolled phones and tablets running the SentinelOps app — their status, OS and last check-in, with a live screen view. It exists so mobile endpoints are managed and viewable alongside servers and workstations rather than in a separate silo. For the tenant it brings their phones and tablets into the same fleet; a live screen session is always locally consented, indicated and audited, honouring each platform’s limits.

Summary & devices

Two counters (mobile devices, online) head the list; every enrolled mobile endpoint shows its status, platform/OS version and last-seen. Enrol a device from Mobile Apps → Create enrolment code and it appears here.

Details

Opens the device’s full drawer alongside your servers and workstations, so the same inventory, jobs and (where supported) actions apply.

View screen

Opens a live, locally-consented and audited screen session for Android endpoints (needs the device online and remote.control). iOS/iPadOS devices are shown but "View screen" is disabled — the OS forbids screen capture by a management app, and the button says why.

The live agent connections calling home — which device identity maps to which management session, over what transport, from what source, and when it was last heard from. It exists as the low-level connectivity view behind the fleet: a device that stops appearing here has gone offline. For the tenant it is the plumbing-level proof that their endpoints are connected and reachable.

Agent sessions

One row per connected agent, showing the endpoint, session status, transport (the agent’s long-poll/outbound channel), agent version, source IP, last heartbeat and when it connected. The source address is recorded for troubleshooting only — devices are addressed by device ID, not by IP.

Open a device

Click any row to jump to that device in the Devices view and open its drawer. When nothing is listed, no enrolled endpoint has called home yet.

Authorized interactive sessions — live screen view and control, keyboard/mouse and two-way audio, plus terminals — created by a named operator, with a visible local indicator on the endpoint, an immediate local disconnect, and a full audit trail. It exists to let operators actually fix a machine, not just watch it, while keeping consent and accountability non-negotiable: there is no hidden-session mode. For the tenant it means hands-on support with their consent preserved and every action recorded.

Open terminal

The "Open terminal" button (top right) starts an interactive shell session on a chosen endpoint — a full xterm.js window with Ctrl-C, a control-key sender, detach-to-its-own-window and End session; several can run at once.

Summary & session tables

Three counters (Active or pending, Unattended-enabled, Recent sessions) head the view. An "Active & pending" table lists sessions in progress or awaiting consent, and a "Recent sessions" table shows the last 25; both show Endpoint, Status, Mode, Operator, Reason, Consent and Requested time.

Consent & unattended

A session requires explicit local consent unless the device is enrolled for unattended access (the right setting for a headless server). The endpoint always retains a local disconnect and shows the indicator throughout. If a session is denied because unattended access is off, an "Enable unattended access" button is offered inline (confirmation required).

Live view & control

An active session has a Live view / "Full screen & control" button (and an inline live-screen preview). Inside, Take control drives mouse and keyboard, Hold to talk sends your voice to the endpoint, and Listen plays the endpoint microphone — all under the same consent, indicator and audit. End closes a session (active or pending) at any time. Keyboard and mouse control exist only inside the active session; no keystroke history is retained.

Sizing the live screen

Expand fills the browser window, ⛶ goes full screen, and the bottom-right corner drags to any size. Zoom (− + Fit, or Ctrl/Shift+wheel) magnifies the picture you already have; the resolution selector changes what the endpoint actually captures — raise it for fine text, lower it on a slow link. A monitor selector picks which display to view, and "☀ Wake screen" wakes a black/locked display.

Who is signed in across your fleet right now. The agent reports each machine’s interactive sessions — the user, whether the session is active or disconnected, whether it is a local console or an RDP sign-in, and the source it came from — along with live CPU and memory. It exists to give accountable presence at a glance and to flag a new sign-in on a sensitive server; it reads who is logged on (never keystrokes). For the tenant it is a privacy-respecting record of who is using which machine.

Summary & signed-in users

Three counters (Users signed in, Machines in use, Login-alerting) head the view. Each row is a machine that currently has at least one interactive session — a machine with no one logged in does not appear. The user list shows active vs disconnected and console vs RDP, with the remote source for RDP, plus the machine’s live CPU and memory meters.

Login alert

The per-row "Login alert" toggle (needs enrollment.manage) pages you whenever a NEW interactive or RDP sign-in appears on that machine — it sets the machine’s monitor-logons tag. Use it on sensitive servers so a fresh sign-in is never missed, without flooding a busy fleet.

Coming with the next agent build

Session duration (how long each user has been on) and the current foreground app are reported by a newer agent; until a machine is on that build those columns are blank while the user/source/CPU/memory show today.

Endpoint operational intelligence rolled up across the tenant: disk and RAID/ZFS health, installed printers, and recent errors and warnings from the system logs. It exists to surface the everyday operational problems that do not raise a formal alert but still cause outages — a filling disk, a degrading array, a machine suddenly logging errors. Reported hourly with inventory (so it reflects the last check-in, not this instant), it gives the tenant an early-warning operational sweep of their whole fleet.

Summary KPIs

Four counters head the view: Reporting (machines that have sent this data), Storage issues (machines currently flagged), Printers (fleet total) and Log errors (1h) — a fast read on where trouble is building.

Storage health

The Storage column flags near-full filesystems and unhealthy RAID/ZFS/disk arrays; a healthy endpoint shows "ok", a problem shows a red pill with the detail on hover — a way to spot the server whose array is degraded before it fails outright.

Printers

Each row shows how many printers the endpoint has installed. Useful when a print-server change is suspected, or to confirm which machines still have a decommissioned printer mapped.

Log errors and warnings

Recent error and warning counts from the endpoint’s system logs. A spike in errors on one machine is an early sign of trouble worth opening its device drawer over.

Not reported

A machine that has not sent this data yet shows "Not reported" — it will populate on the next hourly inventory once its agent is current. Everything here is read-only reporting; act through the device drawer or the relevant module.

Durable incidents raised by monitors, offline detection, sign-in monitoring and other rules — deduplicated, tenant-scoped, and routed through the notification pipeline — plus the rules and destinations that drive them. It exists so problems are captured once and chased to closure instead of scrolling past in a log, and so the right people are notified on the right channel. For the tenant it is their incident queue and their own alert rules and delivery targets.

Summary

Three counters head the view: Open incidents, Managed rules, and Delivery failures (incidents whose notification did not get through). A "🔔 Notification settings" button (top) opens your personal notification preferences.

Alert rules

Tenant-scoped rules, each a trigger event (e.g. device.offline, job.failed, file_transfer.failed, agent_token.revoke, agent_certificate.revoke, agent.version_change) with a cooldown that stops immediate reopening. "Add rule" creates one, Delete removes it (existing incidents are kept), and "Send test alert" raises a test sign-in incident so you can confirm the badge, dashboard and your channel.

Incidents

Each open incident stays deduplicated until acknowledged (resolving closes it); both are audited. Per row you can Acknowledge (stops re-notification), Retry delivery (re-runs the bounded webhook attempt) on a failed one, Isolate host (contain the machine the alert is about), and Hide/Unhide a noisy one. "Hide resolved" is on by default and remembered per browser; hidden incidents are never lost.

Notification destinations

Where alerts are pushed: phone push (ntfy), Slack/Teams, Discord, or a custom endpoint — each formatted for its channel with a minimum-severity floor. "Add destination" creates one; Test sends a sample, Delete stops delivery there. This is on top of the server’s configured signed webhook and any operators who turned on their own email alerts.

A once-a-day email summarising every machine with critical issues — pulled from the logs and from Alerts & Threats — with a suggested fix for each, so you start the day with a prioritised worklist instead of hunting through the console. It exists so nothing critical is missed across a busy fleet and so each item arrives already actionable. For the tenant it is a daily, de-duplicated health briefing for their estate. It is off by default and needs SMTP configured (Settings → SMTP) to email; it can always be previewed. Configuring it needs alert.manage.

Preview & Send now

"Preview" shows the exact digest that would be sent right now; "Send now" (when SMTP is configured and you hold alert.manage) generates and emails it immediately to the configured recipients.

Daily digest toggle & schedule

Tick "Email a daily critical-issues digest" to enable it, and set "Send at" (an hour in UTC). The status pill shows ON/OFF.

What it scans

Choose the log level (Critical only, or Error + Critical) and tick which sources to include: critical log events, critical Alerts & Threats incidents, and suggested resolution steps (remediation guidance from a built-in knowledge base). "Live-scan online machines" scans endpoints live for critical logs (more thorough, slower).

Recipients

Comma-separated addresses; leave blank to fall back to your alert recipients. The page shows the recipients that would resolve right now, and warns if there are none.

Always send

Tick "Send even when there is nothing critical" for a daily all-clear; otherwise the digest is only sent when there is something to report. Routine, benign noise (e.g. the agent’s own service restart) is filtered out so the digest stays meaningful.

Right now & Save

A "Right now" panel shows how many machines and critical items a digest would contain this moment, and the last run’s result. "Save settings" persists the configuration.

One place to work with endpoint logs: browse the actual logs from any selected Windows, Linux or macOS machine live, set up alerts and suppressions on log entries, and schedule or export log reports. It exists so you can investigate and watch OS logs without opening a shell on each box, and turn a one-off investigation into standing monitoring. For the tenant it is centralised, read-only access to their machines’ logs with an explain-and-act workflow.

Browse logs

Pick a machine, then a log source — any Windows Event Log channel, Linux journald / a service unit / kernel (dmesg) / a /var/log file, or the macOS unified log (the ↻ button re-scans sources live). Filter by Level (All / Warning+ / Error+ / Critical), a keyword Search, a Since window (hours, default 24), a Max row cap (200/500/1000) and, on Windows, a specific Event ID. Query loads results live from the agent, highlighting matched text.

Explain & act on an entry

Each row has an "Explain" button that opens a plain-language explanation of that log line (what it means, likely cause, what to do) from a built-in knowledge base, with a web-search link. Public IPs in a line show their block status, and a not-yet-blocked attacker IP can be blocked at that host’s firewall in one click.

Export the view

Export the entries you are currently viewing to CSV or plain text with one click — for tickets, evidence, or offline analysis.

Create an alert / save a report from a filter

Once a filter shows what you care about, "Create alert from filter" (needs alert.manage) opens a pre-filled rule so the platform watches for it going forward, and "Save as report" (needs reports.view) turns the same query into a scheduled report.

Alerts & rules tab

Manage alert rules (raise an incident on matching entries) and suppression rules (mute known noise). Recent matches are listed at the top; "Test" evaluates a rule against a live device immediately.

Reports tab

Save a log query as a daily or weekly report that emails a per-device summary, or use "Run now" to generate it on demand. Reports reuse the same read-only query as browsing.

Scheduled, editable application updates on managed Linux/BSD servers — Nextcloud, WordPress, OS packages, Docker images or a custom script — that either auto-apply on a schedule or detect-and-hold for confirmation, with an email report of what changed after every run. It exists so the app-level patching that OS patching misses still happens on a cadence, safely and auditably. For the tenant it keeps their server applications current without someone remembering to log in and run the updater.

Add a scheduled update

Pick a Machine (Linux/BSD devices), an Application (Nextcloud core + apps, Linux OS packages, WordPress core+plugins+themes, Docker images, or a custom script), a Name, a Schedule (Every 6 hours / Daily / Every 3 days / Weekly (default) / Every 2 weeks / Monthly), a Mode (Detect + wait for confirmation — the safe default, or Auto-apply on schedule) and whether it is Enabled, then "Create scheduled update". Nextcloud auto-detects the install and updates core + all apps; the script is editable afterwards.

Scheduled updates table

Each job shows Task (and app), Machine, Schedule (with its mode), On/off, Last run (status + time) and Next run. "Run now" executes immediately (confirmed), "Edit" opens the job, "Report" shows the last run’s output, and ✕ deletes it.

Edit & the update script

Editing a job lets you change its name, schedule, mode and enabled state, and edit the actual update script — which runs on the machine as the agent, so edit carefully.

Auto-apply vs confirm

Auto-apply runs the update on schedule; confirm mode only detects and reports what would change, waiting for you to approve.

Reports

After every run an email summary of what was updated (or what failed) is sent to the configured recipients; the last report is also viewable from the table.

Restrict which countries can reach your internet-facing machines — allow-only (e.g. USA) or block specific countries — per machine, per group or globally. SentinelOps has it because a huge share of attack traffic comes from regions a given client never does business with, and dropping it at the host removes that noise and attack surface outright. For the tenant it is a country-level firewall applied as nftables on internet-facing Linux hosts, with hard safety rails: your LAN, the SentinelOps server, established sessions and your allowlisted admin IPs are always allowed, and a failed country-data download aborts rather than loading a partial list — so a policy cannot lock you out.

Read before enabling

The amber banner at the top is the safety brief: allow-only mode drops every country except those you list; before enabling, make sure your own admin IP is on the Blocked-IPs never-block allowlist, and start with the “SSH/RDP/WinRM” port scope (not “all”) on any server that also serves public web or mail.

Create a policy — field by field

Name it. Mode: “Allow only these countries” or “Block these countries”. Countries: ISO codes, comma-separated (e.g. US, CA). Applies to: All external machines (global), A group, or A single machine (the machine dropdown lists Linux hosts only). Enforce on: SSH/RDP/WinRM (admin — the safe default), + web (80/443), or All inbound ports. “Enforce now on save” applies it immediately (you are asked to confirm). Create policy saves it.

Policies table

Each row shows the policy name with its mode and country list, its scope, the enforced ports, state (enforced / off), and the last-apply status (a red detail line surfaces the machine’s own error). Apply now re-applies to its machines on demand, Edit changes mode / countries / ports / enforced, and ✕ deletes the policy and removes its firewall rules from the hosts.

How “applied” is counted

“applied to N host(s)” means the firewall is live on N machines. “0 host(s)” with no error means nothing in scope qualified — offline, internal-only, not Linux, or a hypervisor host (which is never firewalled). A red GEO_ERROR shows the machine’s own error, and a failed refresh never removes rules already in force.

Apply cadence and Windows

Policies re-apply every 12 hours to pick up fresh country ranges and survive reboots; Apply now forces it. GeoIP is NOT enforced on Windows yet — it uses the Linux firewall — so protect Windows hosts with the per-IP auto-block (Blocked IPs) and your edge firewall.

Forward endpoint system logs to a syslog server, with each organization pointing at its own target and forwarding toggled on/off per machine or in bulk. SentinelOps has it because centralised logs are the backbone of both troubleshooting and compliance, and most clients either run a SIEM or need one stood up. For the tenant it either feeds an existing SIEM or turns one of their own Linux boxes into a working collector — no external service required — with the collected logs searchable from the console (Log Search). The target is scoped to the tenant selected in the top bar, or the global default when none is selected.

Syslog target

Where this organization’s endpoints send their logs. Set the Syslog host, Port (default 514) and Transport (UDP is simplest; TCP is reliable and uses a disk-backed retry queue on Linux; macOS forwards over UDP only). Tick “Auto-forward every newly enrolled machine in this scope” to enroll new machines automatically. Save target writes it; Remove target clears it (machines already forwarding keep doing so until you turn them off).

Collector — receive logs on your own box

Turn a managed Linux endpoint into a working syslog server: it collects the fleet’s forwarded logs into /var/log/remote/<host>/ (rsyslog auto-installed if missing, listens UDP + TCP, firewall opened, rotated weekly). Pick the Linux endpoint and a listen port (default 514), optionally tick “Also point this organization’s forwarding target at it” so the target is set to its LAN IP, then “Make this the collector”. A live collector shows a Stop collector control. For endpoints that reach it across the internet, set the target to the collector’s public host/IP and ensure the port is reachable.

Turn forwarding on / off

Applies each OS’s native forwarder — Linux rsyslog, Windows a SYSTEM scheduled-task forwarder, macOS syslogd — pointed at the saved target. Choose a Scope: All my devices, A tenant/organization, A device group, or Specific device IDs; then Turn ON or Turn OFF. The result line reports how many devices were queued.

Per-machine status

A table of every device with its forwarding state and a per-row Turn on / Turn off button, plus a header count of how many of the fleet are forwarding. Hardware without an agent (a firewall, switch or PDU) is pointed at the syslog server through its own settings — this view covers agent-managed endpoints.

Search the syslog collector’s aggregated logs — every forwarded host in one place — from inside the console, behind your login, RBAC and audit. SentinelOps has it so operators can investigate across the whole fleet’s logs without SSHing into a collector or exposing it publicly. For the tenant it is a private, searchable window over the logs their endpoints forward, reachable only through the authenticated console. The collector may live in a different tenant than the fleet it collects, so it is found across all visible devices.

Prerequisite — a collector

Log Forwarding must be set up with a collector first. If none is configured the view says so and points you to Log Forwarding → Collector: make a Linux endpoint the collector, then turn machines ON so their forwarded logs land under /var/log/remote/<host>/ and become searchable here.

Query

Enter search text (case-insensitive substring; blank returns the most recent lines across every host), optionally pick one Host from the dropdown (populated live from the collector’s /var/log/remote directory), and choose Max lines (200 / 500 default / 1000 / 2000). The search runs on the collector through its agent — nothing is exposed publicly. Enter or the Search button runs it.

Results

Matching lines are shown in a table with their source Host, Program, and Message, newest at the bottom, capped at the Max-lines you chose. Narrow the query or pick a host to reach detail beyond the cap.

Unmanaged devices that discovery has seen on the client’s networks, flagged with the signals that make them look suspicious, so you can review and account for each one. It exists to answer "what is on this network that we do not manage?" — the first step in catching an unauthorised host or simply bringing a forgotten device under management. For the tenant it is a running list of unaccounted-for hosts on their wire. Select a tenant to review its networks.

What counts as rogue

These are hosts seen on the wire that SentinelOps does not manage. Each row shows IP, hostname, MAC, vendor/classification and "signals" chips explaining why it was flagged.

Acknowledge the known ones

With device.manage, Acknowledge marks a device as reviewed so it drops out of the active list — use it for the printers, personal phones and appliances you expect to be there.

Keep it current

The counts split unmanaged/rogue from acknowledged. When the active list is empty, every device seen on the networks is either managed or acknowledged — re-run Discovery to refresh what is on the wire.

When a tenant (or the site-wide default in Settings → Features) requires approval, a newly enrolled device is held here — its alerts, patching and automation paused — until an operator approves it. It exists to put a human gate on self-service enrollment, so an unexpected or unauthorised machine cannot quietly join and start being managed. For the tenant it is the review queue that keeps their fleet to machines someone deliberately admitted.

Pending enrollments

Each device that enrolled while approval was required, with its hostname, OS, reported IP(s), tenant and enrollment time. The count also drives the navigation badge.

Approve

Clears the hold: the device becomes a normal managed endpoint and its first patch scan runs immediately. Requires device.status.change.

Reject

Refuses the machine: it is decommissioned (excluded from the fleet and the offline sweep) and its agent-firewall grant is revoked. Requires device.status.change.

Turning it on

Enable "Require operator approval for new enrollments" in Settings → Features for the whole platform, or set it per tenant on the tenant record.

A designated on-LAN agent watches its neighbouring managed machines. When a neighbour stops heartbeating but is still reachable on its subnet, an online peer agent restarts that machine’s agent over WinRM (Windows) or SSH (Linux) with a vaulted credential — and alerts if it can’t. It exists to close the gap where a machine is up but its agent is dead and nothing notices. For the tenant it is self-healing management: a crashed agent on their site is recovered automatically from a neighbour, keeping the machine manageable. It is configured per tenant, so select a tenant first.

Enable & threshold

Tick "Enable watchdog" for this tenant (needs tenant.manage) and set the Offline threshold — how long a machine may be silent before it acts (seconds, 120–86400, default 900). It only acts on machines that were managed and are still reachable via an online same-subnet peer.

Auto-restart vs alert-only

With "Auto-restart" on it runs the restart over WinRM/SSH through the peer using the credential you select; off means it only raises an alert so an operator decides. Restarting recovers a stopped/crashed agent — a fully uninstalled agent needs a redeploy.

Credentials

Pick the Windows (WinRM) and/or Linux (SSH) credential the peer uses to log in and restart the neighbour’s agent, then Save. Without a matching credential the watchdog can only alert for that platform.

Run now & recent actions

"Run now" (needs command.execute) triggers an immediate sweep. The actions table shows each result — restart attempted, alert only, no reachable peer, no credential, or unsupported OS — with the device, the peer used, a detail note and when it happened.

One rollup of everything SentinelOps blocks, monitors and reports across every machine — endpoints and hypervisors alike. SentinelOps has it so an operator opens a single screen and immediately knows where a tenant stands on each security area and where to go next. For the tenant it is the security home page: six live cards that link straight into the detail view that owns each area, plus quick jumps to configure the rules behind them. Scoped to the tenant selected in the top bar, or the whole fleet when none is selected.

The six cards

Blocked IPs (SSH & brute-force) — active blocks, how many would-block candidates, and whether blocking is enforcing or monitor-only. Open vulnerabilities — total CVEs with critical / high / exploited detail. Security posture — the count of attention items. Endpoint security — endpoints at risk on encryption / firewall / AV. Identity security — risky accounts. Hypervisor security — hosts passing of those scanned. A card turns red when its area is non-zero, and clicking any card opens its full view.

Honest when a source is down

Each card is loaded independently; if one source fails it degrades gracefully (shows “—” / “not run”) while the rest still render — the dashboard never blanks because one area is unavailable.

Define what’s monitored & blocked

A row of buttons jumps you to the screens that configure each area: IP blocking & SSH, Hypervisor security, Vulnerability management, Config baselines, File integrity, TLS scanner, DNS monitoring, and Monitor rules & alerts. Use it as the launcher for setting the rules behind the cards.

Brute-force and SSH attack sources dropped at the attacked host’s own firewall, the controls that govern that blocking, and the agent-port firewall allowlist. SentinelOps has it because internet-facing machines are hammered constantly, and the fastest place to stop an attacker is on the endpoint being attacked. For the tenant it means brute-force sources are shed automatically — while your LAN, neighbours, discovered and trusted IPs and the SentinelOps server are always spared — with a console allowlist that can never lock you out. Changing policy needs tenant.manage; blocking/allowing needs command.execute.

Console allowlist — auto-follow a DNS / DDNS name

The console (ports 443/8480) is firewalled to an allowlist. Add a dynamic-DNS name (e.g. your home/office home.example.com) and SentinelOps re-resolves it every 60 seconds and keeps its live IP allowed, so an ISP IP rotation never locks you out. Connecting over the WireGuard VPN bypasses this entirely. Only a global operator can manage this list.

Automatic brute-force blocking

Toggle “Auto-block brute-force sources (incl. SSH)” to enable enforcement. “Monitor only (report, don’t block)” records what WOULD be blocked without pushing any firewall rule — use it to validate before enforcing. Threshold (failed logons) is the trip point, default 10. When a public IP passes it, the attacked machine’s firewall drops it; a private / same-subnet / ARP-neighbour / discovered / trusted IP or the SentinelOps server is never blocked. Save applies the settings live.

Expiry fields

Auto-block expiry (days, 0 = never) lifts an AUTOMATIC block after that many days and removes the host firewall rule too. Candidate expiry (days) drops monitor-only “would block” records after that many days (blank/0 = default 30). Manual blocks never expire.

Allowlist and disabled networks

The never-block allowlist (one IP or CIDR per line) is always spared — put your trusted/admin networks here. “Networks where auto-block is disabled” is only for sparing a specific PUBLIC subnet; internal/private LANs are already exempt automatically because only internet-facing machines are ever auto-blocked.

Manually block / unblock

With command.execute, “Manually block an IP on a device” takes an IP plus a target machine (online, non-mobile) and blocks it on the spot. Every active block in the table has an Unblock button. In monitor-only mode a “would block” candidate also offers “Block now” to promote it to a real block.

Would block / Active blocks tables

The Would-block (monitor-only) table lists candidates that crossed the threshold but had no rule pushed. The Active blocks table lists each enforced block with its source (auto vs manual), the device enforcing it, the reason, the attacker’s origin (flag + city, geolocated in the background), and when it was blocked. Click any IP to trace it — ownership (RDAP), origin, the full cross-fleet attack trail, and to report it to its abuse desk.

Allowed through the agent firewall

The agent port (8480) is locked to an allowlist; this panel lists the IPs SentinelOps let through — a new machine that port-knocked with a valid deployment token, or a cloud VM we provisioned. A “seed” grant is a hand-configured IP and is never auto-pruned; other grants are reaped when their device is decommissioned or the cloud IP is abandoned. With command.execute you can manually Allow an IP (IPv4 or IPv6), Revoke a grant, or tick “never” to pin an IP open permanently (no reaper, device-removal or auto-block ever strips a pinned IP).

Automatically reports the attacker IPs SentinelOps blocks — both agent brute-force auto-blocks and server-side IDS auto-blocks — to the owning network’s abuse contact, looked up live over RDAP. SentinelOps has it because bouncing an attacker off your firewall only moves them along; reporting the evidence to their upstream provider is the one legitimate lever that gets the source actually shut down. For the tenant it means repeat offenders are actioned at origin, with a complete, defensible paper trail of what was reported and whether it was delivered. Off by default; a reporter identity is required before it can be enabled, and SMTP must be configured on the server to send. Changing settings needs tenant.manage.

Settings — identity and mode

Enable automated abuse reporting turns the feature on. Auto-send (no manual review) reports every attack automatically and emails you a digest of what went out; leave it off to hold each draft for review. Reporter organization and From / Reply-To email are your sending identity (required). Escalation address is used when the IP publishes no abuse contact. “Also Cc the registrar / upstream abuse contact” widens delivery. “Write reports in the recipient country’s language” leads the report in the attacker country’s language (for a set of translated languages) with English below; uncheck for English only. Save settings to apply.

Pending review and report cards

When Auto-send is off, a draft card appears whenever an attacker is auto-blocked. Each card shows the attacker IP, org/country, an escalation badge (first notice vs ESCALATION #n for repeat offenders), the To: abuse contact, attempt count, service and target device, and the full drafted subject/body. “Review & Send” emails it (disabled until a recipient is resolved and SMTP is configured), “Edit” lets you change recipients/subject/body before sending, and “Dismiss” drops it.

Reported IPs — delivery status

A scannable table of every IP actually attempted, with honest delivery state: “Delivered” means the abuse desk’s mail server accepted the message (the furthest point observable), “failed” means the send errored and did NOT reach the destination, and “held — no contact” means there was no abuse address to send to. Tiles count each state.

Toolbar actions

Email me a summary sends your account a summary of every report sent with each attacker IP. Report all recorded attacks drafts (and, if Auto-send is on, sends) a report for every currently-blocked attacker IP. Re-report webmail contacts re-files reports to a provider (Google, Microsoft…) where a network published a personal webmail as its abuse contact. Resend sent reports re-sends earlier reports to their real abuse desks (some older ones bounced on mail format, since fixed; personal-webmail contacts are skipped). All four are confirmed before running and require SMTP.

Responses — the abuse auto-responder

Reports go out from the abuse mailbox (e.g. abuse@yourdomain) as From and Reply-To, so abuse desks answer there. SentinelOps checks that mailbox over IMAP every few minutes, matches each reply to its report (by our message ID, the AR- reference, their ticket number or the IP), sorts it — acknowledged, asked for information, resolved, declined, bounced — and records their ticket number on the report. It then answers automatically: the full evidence when they ask for more (for refused mail it explains there are no message headers because the connection was refused before any message was sent), a one-time confirmation when they open a ticket, thanks when they act. With the AI assistant on, each answer is written for what they actually asked, in their language, from the report’s evidence only; anything hostile, legal or not about our report waits for a person. Every automatic reply says it is automatic, replies are capped per report, and no-reply/mailer-daemon addresses are never answered. Mail older than the retention period (30 days by default) is deleted from the mailbox. Click a row to read it, reply by hand or mark it handled. Mailbox settings also choose how much email you get: one summary a day, none, or one per batch.

Who is never reported

The operator’s own home/office addresses and internal-LAN sources are exempt everywhere — only genuine external attackers are ever reported. The per-IP trace (click any blocked IP) shows a “Protected address” banner for an exempt IP.

Fleet CVE exposure from TWO sources: CVEs the OS updater attaches to patches you have not applied, and an offline scan that matches each machine’s installed packages against a locally-synced OSV + CISA-KEV database (so it finds CVEs even when no patch is on offer). SentinelOps has it because knowing you are behind on patches is not the same as knowing which of those gaps attackers are actually exploiting. For the tenant it is a prioritised remediation queue — exploited-in-the-wild issues first — with a one-click fix on each finding. Works across the fleet, or scoped to the selected tenant.

The exposure KPIs — click to drill in

Four tiles: Unique CVEs, Exploited in wild (CISA Known Exploited), Critical, and Affected devices; the exploited and critical tiles warn when non-zero. Clicking a tile filters a highlighted panel to the matching findings from the offline scanner (exploited / critical / high / all), or, for Affected devices, the endpoints with findings — each row opens the device. A “clear ✕” link removes the filter.

From missing patches

The first table is CVEs the OS updater ties to updates you have not applied, with severity, an “exploited” pill, the affected-device count (the blast radius) and the products affected. Each CVE links to its NVD detail page. Empty here means no CVE-tagged missing patches — run a patch scan to refresh.

Offline CVE-database scan

The second panel matches installed packages against the synced OSV + CISA-KEV database and rolls findings up by CVE across machines (exploited and highest-severity first). Linux distro packages are matched today; Windows third-party apps need the NVD/CPE follow-up. The panel header shows the database size, how many are known-exploited, and when it was last synced.

Scan now / Sync CVE database

Header and panel buttons: “Scan now” (needs device.read) re-scans installed packages against the database and reloads the view; “Sync CVE database” (needs operator.manage) re-downloads the offline OSV + KEV database (a few minutes) — run Scan after it finishes. If the panel says the database is not synced yet, Sync first, then Scan.

Fix a finding

Every finding has a “Fix ▸” button that opens remediation: the severity, package → fixed version, a summary, step-by-step “How to fix”, reference links, and where available a generated fix script you can Copy. With command.execute you can “Run fix on <device>” (it then nudges a fresh inventory and auto re-scans so the finding clears on its own), “Repair install (clean reinstall)” when a broken updater can’t advance the app, and on Windows “View install log” to read the endpoint’s SentinelOps install/update log without visiting the machine.

Agentless security checks for the hypervisors that cannot run the SentinelOps agent — XCP-ng, Proxmox and ESXi. SentinelOps has it because the hypervisor is the highest-value host in a client estate yet is exactly the box you can’t install an agent on, so its exposure is easy to overlook. For the tenant it closes that blind spot: each registered hypervisor is probed over the network for exposed management ports, weak TLS on its management UI/API, and a reported version matched against known-vulnerable ranges. Scoped to the selected tenant, or the whole fleet when none is selected.

Findings table

One row per registered hypervisor: host name / address and kind, an at-risk vs ok status pill, the open management ports seen, the TLS state on the management UI, the specific findings (severity-coloured pills), and when it was last scanned. “never” means it has not been scanned yet.

Run scan now

With device.read, “Run scan now” probes all in-scope hosts immediately; results fill in as hosts respond (the view reloads itself shortly after). Otherwise hosts are re-scanned on a schedule.

Adding hosts

Hosts are not added here — they come from Infrastructure → Hypervisors (or as a device / BMC). Register an XCP-ng / Proxmox / ESXi host there and it appears in this scan. With no hosts, the view explains where to add them.

What it is and isn’t

This is an external, agentless posture check — exposed ports, weak TLS, vulnerable versions — not an in-guest agent. It complements the agent-based Endpoint Security view, which covers machines that can run the agent.

A live, aggregated security overview for the selected tenant, assembled from the underlying security modules. SentinelOps has it so an operator can triage a tenant’s whole security picture from one screen instead of visiting eight views. For the tenant every number is computed from real state — nothing assessed yet is shown as such rather than assumed safe — and each card is a one-click launcher into the view that owns the fix. Pick a tenant first.

Attention items

The pill at the top counts what actually needs you now: open critical + high risks, expired security exceptions, critical patches, and live privilege elevations. Green (“0 attention items”) means nothing is outstanding.

The posture cards

Each card is a live rollup: Open risks (by severity), Security exceptions (active / expired), Critical patches (with security + reboot-pending detail), Live elevations (active JIT / break-glass grants), Poor-health devices (of total, with offline count), Firmware updates available, Hardware changes (board/serial/RAM swaps), and Endpoint security gaps (unencrypted / no-firewall / no-AV, or “no agent reports yet”). A card turns its number red when that area is non-zero.

Cards are clickable

Most cards jump straight to the view that owns the detail — Open risks and Exceptions → Risk & Exceptions (governance), Critical patches → Patching, Live elevations → JIT Access, Poor-health → Health, Firmware → Firmware, Endpoint security gaps → Endpoint Security. Use them as a triage launcher. (Hardware changes is informational and does not link.)

Compliance and worst offenders

The Compliance coverage strip shows each assessed framework’s score with its assessed/total count (click to assess controls). Below, Active privilege elevations lists who currently holds elevated access (subject, JIT vs break-glass, permissions, expiry), and Lowest-health devices lists the machines dragging the tenant down with their score and top reason — both panels link to their full views.

Fleet-wide endpoint security posture as reported by the agent: disk encryption, Secure Boot, TPM, host firewall and antivirus/EDR. SentinelOps collects it so nobody has to log into each machine to confirm a laptop is encrypted or a server has its firewall up. For the tenant it is the single screen that answers “which of our machines are exposed, and how?” and turns it into a click-to-filter remediation list. Pick a tenant first. Posture arrives with the hourly inventory, so a freshly enrolled or just-updated endpoint shows “Not reported” until its next check-in.

The dimension tiles

The top row summarises each dimension across the tenant — Encryption shown as on / off / partial / unknown, then Secure Boot (on/off/unknown), TPM (yes/no/unknown), Firewall and AV/EDR. Two leading tiles, “Reporting” vs “Not reported”, tell you how much of the fleet has sent posture at all; a device that predates this feature counts as not reported until its agent is updated.

Risk tiles — click to filter

The second row counts machines at risk on each dimension: Unencrypted (encryption off), Secure Boot off, No TPM, Firewall off, No AV/EDR (no product and not on). A tile turns warning-coloured when non-zero. Click any tile to filter the table to just those machines (the tile outlines to show it is active); a “✕ Clear filter” tile appears to return. Example: click “Unencrypted” to get the exact list of laptops to remediate before they leave the office.

Per-device table

One row per endpoint with each dimension as a coloured pill, plus the tool that reported it where known — e.g. BitLocker or LUKS under Encryption, the TPM version, the firewall tool, and the AV product name next to its state. “unknown” means the agent could not determine that dimension, which is treated differently from a confirmed “off”. A device too old to report shows “Not reported — agent update required”.

Getting posture to report

If everything shows “Not reported” and nothing is reporting, the view says “Awaiting agent data” — update the agents and posture appears on the next hourly inventory, not instantly. This view is read-only reporting; act on findings through the device drawer or the relevant module (disk encryption, firewall, AV).

SentinelOps watches the apps you care about on every managed endpoint and puts one back if it goes missing — so a removal (a bad uninstall, a failed patch, a CVE remediation that removed a broken app) does not leave a machine without it. It only ever restores an app the device actually had before, and the reinstall it runs is verify-or-rollback: if the fresh install fails it restores the previous copy, so a machine is never left with nothing.

Enable self-healing

When on, every managed endpoint’s installed-software inventory is checked on a schedule against the watched-apps list. If a watched app that was previously present disappears, a Self-healing alert is raised and (if Auto-restore is on) a reinstall is dispatched. Apps the device never had are never installed.

Auto-restore

Automatically reinstall a missing watched app when SentinelOps has a clean-reinstall recipe for it (Google Chrome today). The reinstall is verify-or-rollback: it downloads and size-checks the installer first, tries an in-place upgrade before any removal, backs up the existing install, and if a removal+reinstall ever fails it restores the backup — the endpoint is never left without the app. Watched apps with no recipe raise an alert to redeploy from the Software Library instead.

Watched apps

Comma-separated name patterns matched against installed-software names (e.g. “google chrome”). Default watchlist covers apps with an auto-restore recipe. Add your own to get missing-app alerts for them even without an automatic reinstall.

Recent self-heal activity

A log of what the guardian did: Missing (a watched app vanished), Auto-restore dispatched (a reinstall was queued), Recovered (the app came back), Blocked (could not auto-restore — e.g. installs are locked on the device, the device is offline, or no recipe exists). Blocked reasons tell you exactly what to fix.

When a device needs hands-on help

If an endpoint’s Windows Installer subsystem is itself damaged (msiexec runs but installs nothing), auto-restore is blocked and the reason is logged — that box needs a servicing-stack repair (DISM/SFC, msiexec re-register, or a reboot) before any install, SentinelOps or otherwise, can succeed.

Opt one machine out (stop the alerts for it)

If a machine legitimately has a watched app come and go — for example Chrome that updates itself on a box whose installer can’t be repaired — the daily “managed app is missing” alert is just noise for that one machine. Open its device drawer and set App self-healing to “opt out” (this adds the no-selfheal tag). That machine is then skipped entirely by the guardian — no missing-app alerts and no auto-reinstalls — while the rest of the fleet keeps healing. Turn it back on from the same place any time. This is separate from Auto-heal (the log-driven rules engine, the no-autoheal tag) right above it in the drawer.

Log-driven auto-remediation. SentinelOps reads each online endpoint’s recent logs and, when a vetted rule matches a known problem, runs a safe, pre-approved fix through the ordinary job system and then verifies it worked — so recurring faults heal themselves instead of waiting for a human. Safety is the whole point: only vetted built-in rules auto-apply, and only genuinely safe, idempotent, reversible fixes; anything with outage potential ships monitor-only. The AI only suggests fixes for errors no rule covers — it never runs them. Every machine can opt out with a tag, a tenant on legal hold is frozen, and every single decision is recorded and auditable. This is a separate engine from App Self-Healing, which restores removed applications.

The safety model (read this first)

Four layers protect you. (1) Only vetted BUILT-IN rules auto-apply, and the catalog is deliberately conservative — a fix that could cause an outage or touch data ships monitor-only until you deliberately enable it. (2) The AI never acts: it only proposes a rule for your approval. (3) Any machine tagged no-autoheal is skipped entirely (set it from the device drawer). (4) A tenant on legal hold has all auto-changes frozen for preservation. On top of that, every rule has a cooldown and a daily attempt cap so a flapping fault can never loop.

Global controls

Enabled is the master switch — off means nothing is detected, suggested, applied or emailed. Monitor-only mode makes the WHOLE engine detect-and-email but change nothing, which is the safe way to watch what would happen before letting fixes run. AI suggestions lets the assistant propose fixes for unknown recurring errors (they queue for approval, never run). Email reports sends a batched digest of activity and pending suggestions to your alert recipients (needs SMTP configured). These four are platform-wide, not per-organization, and only a platform-wide operator can change them.

Schedule & email (platform-wide)

Under the engine switches, “Schedule & email” sets: how often machines are checked (default every 10 minutes, 5–1440) and how many machines per check (default 60 — raise it for large fleets); how often the digest is sent (default hourly) or sooner once N events queue (default 25); extra digest recipients, optionally REPLACING the alert recipients instead of adding to them; and which no-action observations get emailed — critical only (default), warning and above, everything, or never. Fixes applied, verified or failed are always emailed regardless. Leave a number blank for the default. Changes take effect on the next check with no restart.

Where each setting applies — organization, group, device

Pick an organization in the top bar, then choose the scope under “Per-rule overrides apply to”: the whole organization, one device group, or a single device. For that scope you can turn each rule off, make it observe-only, and set its cooldown and daily cap (blank = inherit — the greyed number shows what it inherits and from where). The most specific setting wins in both directions: device beats group beats organization beats the global rule, so a device can turn back ON a rule its group turned off, or use a shorter cooldown. Deleting a device, group or organization removes its overrides too.

Maintenance windows

Next to the scope picker, “Set window” restricts WHEN fixes may run for that organization, group or device — for example weekdays 22:00–06:00 in America/Los_Angeles (an end earlier than the start is an overnight window; the days are the days it starts). Outside the window a matched problem is recorded as “deferred” and fixed on the first check inside the window if it is still being logged; detection, observe-only and email carry on at any time. The most specific window wins, and “Fix any time” lets a device or group opt out of a broader window. Remove a window to follow the broader scope again.

Email per organization

With an organization selected, “Self-Healing email for …” sends that organization its own digest covering only its machines. A platform-wide operator can also take the organization out of the platform-wide digest (it then goes only to its own recipients) and give it its own severity threshold. Customer-scoped operators can manage their organization’s recipients but not those two settings.

Rules

Each rule watches a log regex on a chosen OS/role scope and, when it matches enough times in its window, runs its fix. Toggle Enabled and Monitor-only right in the list. Built-in rules carry a badge and are maintained by SentinelOps — a platform-wide operator can tune their toggles, severity, cooldown and daily cap (Tune), and they cannot be deleted (disable instead). Severity decides whether the rule’s no-action observations reach the email digest. Your own rules get a full editor and a delete. Use + Rule to add one: name it, give a regex pattern, scope it by OS/role, set the trigger count/window, choose the action (restart a named service, or run a script/command, or just suppress a benign alert), add a verify step, and set the guardrails. The action editor warns you that it runs on real machines — leave a new rule monitor-only until you have watched it behave.

AI suggestions

When AI suggestions is on, the assistant looks for a recurring error that no rule covers and proposes ONE safe fix, with the sample log lines and its rationale. It never runs anything. Approve turns the suggestion into an operator-owned rule that starts monitor-only — so it records what it WOULD do without acting — and you turn monitor-only off once the activity log convinces you it is safe. Dismiss discards it.

Activity log

Every decision, newest first: detected (matched, nothing done yet), monitor-only (would have acted but monitor-only is on), applied (fix dispatched as a job), verified (fix confirmed to have worked), failed (job or verification failed), suppressed (a benign/known-noise match, no alert, no action), deferred (a fix is waiting for the machine’s maintenance window), recurring (the same fix was needed on this machine at least the recurring threshold — default 3 — times in 24 hours: it works each time but the cause keeps coming back, so investigate). When a fix is verified, Self-Healing also closes the matching log alerts on that machine and, unless turned off under Schedule & email, emails a “Resolved by Self-Healing” notice right away. The trigger column shows the matched log line with secrets redacted.

Per-machine opt-out

On any device’s drawer there is an Auto-heal control. Opt a machine out and it gets the no-autoheal tag — the engine then skips it entirely (no detection, no fixes) while still healing the rest of the fleet. Turn it back on to remove the tag. This needs enrollment.manage (the same permission that sets device tags).

An account-hygiene review of the selected tenant’s SentinelOps operator accounts — it flags only the accounts that need attention (missing MFA, dormant, locked, never signed in, stale passwords) and leaves clean ones off the list. SentinelOps has it because the accounts that manage the fleet are themselves a prime target, and a privileged login with no second factor is the shortest path to a breach. For the tenant it is a standing checklist that keeps operator access tight. This view is per-tenant — pick a tenant first.

Read the KPI strip first

Tiles count Accounts, Privileged, No MFA, Priv. w/o MFA, Dormant, Locked, Never signed in and Stale passwords. A tile turns warning-coloured when its count is non-zero, so a red “Priv. w/o MFA” tile is your highest-priority fix — a privileged account with no second factor.

Work the “needs attention” table

Rows are sorted highest-risk first and show the account (with privileged / disabled pills), role, MFA state, flag chips (dormant / locked / never signed in / stale pw) and last sign-in (with failed-login count where any). Clean accounts are omitted by design, so an empty table means every operator has MFA and is active.

Know how the flags are defined

Dormant = no activity in the configured window (90 days by default); stale password = unchanged in the configured window (365 days by default). Both thresholds are printed under the KPI strip so you can read a flag correctly.

It reports, you remediate

This view surfaces the risk; fix it in the tenant’s Users / Identity screens — enable MFA, disable or remove dormant accounts, unlock or reset as appropriate. Requires permission to read identity data; a 403 shows “Not permitted”.

Defines the critical file paths each endpoint should watch for changes. SentinelOps has it because a quiet edit to a config file, an account file or a web root is a classic sign of compromise or an unapproved change — and you want it recorded, not discovered later. For the tenant it is a lightweight file-integrity monitor: changes under a watched path are captured in the agent’s tamper-evident, hash-chained file-audit log, giving a defensible record of what changed and when. Pick a tenant first. Editing the watch list needs system.manage.

Set the watched paths

Enter one path per line — files or directories — in the text box, then “Save watched paths”. Examples: /etc/ssh/sshd_config, /etc/passwd, /var/www, C:\inetpub\wwwroot. The list is tenant-wide; each endpoint watches these paths once File & Activity Audit is enabled for that device. The footer confirms how many paths are currently watched.

Enable the audit per device

Watching only produces records where File & Activity Audit is turned on for the endpoint — the watch list names the paths, the per-device audit does the capturing. Without the per-device audit enabled, a path can be listed but nothing is recorded for it.

Where changes show up

This screen only defines what to watch; it does not display events. Review actual changes under Endpoint Activity / File Audit for the device, or in the audit log. The hash-chained log makes tampering with the record itself detectable.

What it is good for

Catch edits to security-sensitive files: an unexpected change to sshd_config, a new entry in passwd, or a file dropped into a web root. Read-only here; without system.manage the box is disabled and shows “system.manage required to edit”.

CIS-style hardening checks scored live against each managed device from the telemetry the agent already reports — there is no separate scan to schedule or push. SentinelOps has it so a tenant can prove, at any moment, which security controls (encryption, Secure Boot, firewall, AV and more) are actually in force across the fleet rather than assumed. For the tenant it turns “are we hardened?” into a concrete, per-device worklist. Pick a tenant first.

The KPI tiles

Three tiles summarise the tenant: Devices failing (warning-coloured when non-zero), Devices checked, and the number of Checks evaluated. Read them first to size how weak or strong the tenant is before drilling in.

Checks — fleet rollup

The first table lists every check with its category and, per check, how many devices Pass, Fail and are N/A. This is the control-centric view: one row per hardening control so you can see which single setting is weak across the whole tenant.

Devices with failing checks

The second table is the device-centric view: devices with at least one failing check, worst (most failures) first, capped at the top 40. Each row names the specific failing checks with any detail string, so you go straight to the machine and the exact setting to fix.

Why “n/a” is never a pass

A check reads “n/a” when the device has not reported the data it needs yet — for example endpoint-security posture that requires the latest agent. An un-reported check is never scored as a pass, so the rollup stays honest rather than flattering coverage. Update the agent and the next hourly inventory fills it in.

Grades the TLS posture of hosts you add as targets. SentinelOps has it because a weak cipher, a deprecated protocol still accepted, or a certificate about to expire is both common and easy to miss until something breaks or is exploited. For the tenant it is a standing watch on its TLS endpoints — an at-a-glance A–F grade per host and an early warning before a certificate lapses or a protocol weakness is found. The server performs a read-only handshake; nothing is changed on the endpoint. Pick a tenant first; adding targets needs tenant.manage.

Add a target

With tenant.manage, “+ Target” prompts for a host and a port (default 443). It is scanned immediately on add, and a letter grade (A–F) summarises protocol, cipher, certificate and certificate expiry.

Read the grade card

Each target card shows the negotiated protocol and cipher, the certificate subject and issuer (with a self-signed flag), the first few SAN / DNS names, and days to expiry — coloured red when expired, amber under 30 days, green beyond.

Weak-protocol warning

If the host still accepts deprecated protocols (e.g. TLS 1.0 / 1.1), a red “weak” badge lists them next to the protocol — a clear signal to disable old protocols on the endpoint.

Rescan and remove

Rescan re-runs the handshake on demand — use it after renewing a certificate or disabling old protocols to confirm the fix. Remove drops the target. A target that fails to connect is graded F with the connection error shown on the card.

Two things in one view: the live DNS for every agent-managed machine (grouped per server), and optional domain monitors that re-resolve a tenant’s domains hourly and flag any record change. SentinelOps watches DNS because a hijacked MX, a fat-fingered edit or an expired record is both easy to miss and expensive — mail stops, a site goes dark, or traffic is silently redirected. For the tenant it is an audit trail of what DNS said and when it changed, so a bad change surfaces fast and a legitimate one is provable. Pick a tenant first for domain monitors; adding or removing one needs tenant.manage.

Per-machine DNS (top section)

One group per agent-managed server, shown whether or not a tenant is selected. For each machine the server resolves — live, no agent round-trip — the host’s forward A/AAAA (hostname and FQDN), reverse PTR for its known IPs, and CNAME; its domain’s NS/MX/TXT/SOA; and the resolver configuration the agent reported (nameservers queried, search/suffix domains, hosts-file overrides — needs agent 0.5.16+). Refresh re-resolves one group. The same view is available per device from Quick actions → DNS.

Add a domain monitor

Use “+ Monitor domain” (tenant.manage). Enter a domain (e.g. example.com). For record types, leave it BLANK to watch ALL records — A, AAAA, CNAME, MX, NS, SOA, TXT, SPF, DMARC, CAA, SRV, PTR — or type a comma-separated subset. Example: watch just MX and TXT on the primary domain to catch mail-routing or SPF/DKIM tampering.

Reading a monitor card

Each card lists the current values per record type, when it was last checked, and how many changes have been logged. A record type that failed to resolve shows an “error” pill carrying the resolver message (on hover) rather than a silent blank.

Recent changes

When a record moves, the card shows a Recent changes log (last 8, newest first) — old values in red, new values in green, with a relative timestamp — so you see exactly what changed and roughly when. This is the evidence you hand to whoever confirms the change was intended.

Check now, and the hourly pass

Monitors re-check automatically every hour; “Check now” forces an immediate re-resolve and tells you at once whether anything changed (it toasts the number of changed record types). Use it right after a legitimate DNS edit to re-baseline, so the next scheduled pass does not alarm on your own change. Remove deletes a monitor after a confirmation.

Every installed application seen across the fleet, with how many machines carry each title and which versions are present — built from the software each endpoint reports in its inventory. SentinelOps has it to answer "what is actually installed out there, and at which versions?" without touching each machine. For the tenant it is the software census behind licence, patch and standardisation decisions: it shows version sprawl and unexpected installs at a glance. It is read-only reporting, scoped to the selected tenant.

Titles and reporting devices

Two KPIs: how many distinct software titles are known, and how many devices have reported software at all. A device that has not sent an inventory yet is not represented — so read the reporting-devices count as the coverage of this picture.

Filter to find a title

The filter box narrows the list by name (case-insensitive substring) — e.g. "chrome" to see every Chrome variant and its version spread. The list caps at 400 rows, so filtering is the way to reach anything beyond that.

Read the version spread

The Versions column shows every version in the field for that title. A title running many differing versions is a good patch/standardisation candidate — pair it with Software Policies to require a version or prohibit an app, and with Software Library to push the wanted build.

The operational patch view: what is missing, critical, failed, or needs a reboot across the fleet, built from the structured scans agents report rather than scraped text. SentinelOps has it so patch exposure is a single honest number instead of a per-machine guess — offline or never-scanned devices show as offline/unknown, never falsely compliant. For the tenant it is the live read of how exposed their fleet is to known-bad updates and the one place to scan, schedule and push fixes; with a tenant selected everything is scoped to that organization, with none selected it spans the whole fleet.

KPIs & compliance (click to filter)

Nine cards across the top: Compliance %, Available, Critical, Security, Failed, Reboot required, Non-compliant, Offline and Unknown. Critical, Failed, Reboot, Non-compliant and Unknown turn warning-coloured when non-zero. Click any card to filter the device table to just those machines (the card outlines to show it is active); arriving from a Dashboard patch card pre-selects the matching filter.

Automated patch deployment banner

A banner reads "scheduled" (green) or "not configured" (amber) with a note — it answers "why was this not patched automatically?" and points you at Auto-Patch Policy to set the per-tenant rules.

Patches by operating system

A per-OS strip (Windows / Linux / macOS …) where each chip shows device count, available count, and crit / sec / upgrade / reboot pills plus a compliance %. Click a platform to highlight it and show only its patches in both the critical list and the device table; click it again, or "All platforms", to clear. "Upgrade" counts big feature/version jumps, not routine patches.

Severity & Compliance panels

Severity lists each class (critical, high, …) with its patch count and affected-device count. The Compliance bar splits the fleet into compliant / at risk / non-compliant / offline / unknown, and the legend defines them: Compliant = up to date, At risk = security updates pending with no critical, Non-compliant = critical or failed updates, Unknown = never scanned.

Compliance by tenant

When the view spans more than one tenant, a table breaks compliance %, critical, security, non-compliant and reboot counts down per tenant so you can see which organization is furthest behind.

Critical patches requiring action

One row per patch with its affected-device count, known-exploited (KEV) first so the most dangerous are at the top. "Compliance report" opens a printable per-fleet compliance summary.

Recent deployments

Visible with patch.deploy or patch.global_view: scoped patch rollouts (from "New deployment"), each row clickable for per-machine status.

Devices needing attention

Worst-first table: device, tenant, OS, compliance pill with its reason, available / critical / security / failed counts, a reboot pill (click to reboot the machine now when you have command.execute), the live apply status, and last-scan age. Honours the KPI and OS filters above.

Scan fleet

With patch.scan, queues a read-only patch scan on every online endpoint; the dashboard populates as agents report. Nothing is changed on the endpoints.

New deployment

With patch.deploy, roll patches out to a device, group, site, tenant or dynamic query — with a preview of who is targeted and an optional schedule — rather than applying to everything at once.

Apply patches

With command.execute, downloads and installs available updates on online endpoints using each one’s native updater — Windows Update on Windows; apt/dnf/zypper/pacman/apk on Linux. If an OS family is highlighted it applies to just that platform. It runs in the background and progress (applying → completed, with a reboot flag when pending) shows per device in the Apply column. Applying changes endpoints, so by policy it may require a second approver (administrators and engineers are exempt).

A per-organization policy that auto-schedules critical/security patches on any OS, force-applies them once a deadline passes, and controls what happens when a reboot is needed. SentinelOps has it because patches that wait on a human tend to sit unpatched — this guarantees a qualifying fix is applied within a fixed window of being detected. For the tenant it turns patching into a standing SLA ("critical fixes land within N days") instead of ad-hoc effort; it is disabled by default and you must pick an organization to configure it.

Enable automatic patching

The master switch (checkbox) for this tenant. While off, nothing is ever force-applied — you can still patch by hand from Patch Management.

What to auto-schedule

Three checkboxes choose which update classes are picked up automatically: Critical updates (highest-severity fixes), Security updates (security-classified patches), and ALL available updates (aggressive — everything the scanner finds, not just critical/security). Tick only what you want forced.

Force-apply deadline

A number field (1–365 days, default 5) — the grace window after a qualifying patch is first detected before it is pushed. The countdown starts the moment the patch is seen; until the deadline the device shows an "action due in N days" status.

When a reboot is required

A dropdown with four behaviours: Alert the operator (do not auto-reboot) — the default; Reboot automatically if required; Always reboot after patching; Never reboot (and do not alert). Choose per how disruptive a restart is for that fleet.

Save policy

Writes the policy for the tenant. The deadline is clamped to 1–365 days on save.

Pending & scheduled table

A live per-device countdown: machines that currently have qualifying pending patches, with their Critical and Security counts, whether a reboot is pending, and an auto-apply status — "due in N days (date)" or "forcing now / overdue". This is where you confirm what the policy will actually do before it does it.

What is never auto-patched

Mobile devices and pinned (no-auto-update) devices are always excluded. A maintenance window can be attached via the API (the window field) so forced patches land only inside an agreed window.

Lists and applies OS and third-party updates through each endpoint’s own update tooling, both as a fleet job across a group/tag selection and per-endpoint. SentinelOps has it so you can report and remediate updates centrally without logging into each machine, while keeping a human approval on anything that actually changes a box. For the tenant it is the hands-on patching console — read-only reporting is free, applying is approval-gated so an update is never pushed to their servers unreviewed.

Fleet patch — selectors

Target a selection, not everything: Device group (a dropdown of the groups in use, or "Any group") and Tags (comma-separated, all must match). A live counter shows how many endpoints match before you queue anything.

Fleet patch — operation

The Operation dropdown chooses List available updates (patch.list, read-only — no changes) or Apply updates (patch.apply). "Specific packages" (comma-separated, enabled only for Apply) limits the apply to named packages; leave it blank to apply all available updates. "Queue patch job" fans the job out to the matching endpoints — an Apply gets an approval-gated job per endpoint that a second operator must approve.

Per-endpoint actions

The Per-endpoint panel lists every enrolled machine with two buttons: "List updates" queues a read-only report (results appear on the device once the agent reports back), and "Apply…" prompts for optional package names and queues an approval-gated apply on just that machine.

Maintenance window

Devices outside their maintenance window are skipped automatically, and the toast tells you how many — so a server fleet can be gated to a window while workstations patch immediately.

Last rollout

After a fleet dispatch, a rollout panel lists each endpoint’s job and status; "Refresh status" re-polls the jobs so you can watch them move from awaiting-approval to succeeded/failed without leaving the page.

Current versus target firmware/BIOS across managed devices, with a warning when a device is behind its target. SentinelOps has it because firmware is the most-ignored patch surface — real BIOS versions come from SMBIOS/dmidecode/WMI and the "Scan" action runs the vendor tool to discover available updates, so the picture is grounded, not assumed. For the tenant it surfaces which machines carry outdated or exploitable firmware and lets you drive the vendor update remotely. Scoped to the selected tenant; editing targets and dispatching updates needs firmware.manage.

Reading the table

Each device shows its model (with manufacturer, service tag, the vendor tool in use and, for whitebox builds, the motherboard make/model), current BIOS, the target you have set, and a status pill: "up to date", "update available" (with its severity and an "N update(s)" badge listing current → available per component), "no target set", or "virtual BIOS" for a VM. The panel heading counts how many devices are behind target.

Set a target

"Set target" opens a form — Device model, Target BIOS version, and Severity if behind (Medium default, or High / Critical / Low). It records the expected BIOS for a model, and every device of that model running older firmware is then flagged update-available. Example: set OptiPlex 7090 to 1.24.0 at High.

Scan for updates

On update-capable physical devices, "Scan" dispatches a firmware.scan job that runs the vendor tool (Dell Command Update, fwupd) to discover available firmware; results appear here when it finishes and the status then lists the specific updates with current → available versions and severity.

Update… (the guarded flash)

On a device that supports it, "Update…" opens a workflow that shows current vs newest-available BIOS, lets you pick the source (the vendor’s own pending update or an uploaded firmware file), and plan safeguards (back up first, notify the client) — then a separate explicit confirm with a "do not power off" acknowledgement actually dispatches the flash. Nothing flashes until that last step, and every action is audited.

What cannot be flashed

Virtual machines show a virtual BIOS — it belongs to the hypervisor and is not flashable. Monitors and direct-attach cables cannot be flashed remotely either, so no Scan/Update buttons appear for them.

Dispatch one script across a group/tag selection of endpoints at once, with each job gated by approval, and keep a reusable library of scripts. SentinelOps has it so ad-hoc remediation scales to many machines without losing the two-person control and audit on executing code. For the tenant it is how a fix or check is rolled out fleet-wide safely; the selector is scoped to the current organization and the script is staged to a private temporary file on each endpoint, never inside a managed root.

At a glance

The summary tiles count Endpoints, how many are Online, and how many Groups exist — the pool you can target.

Dispatch a script — selectors

Device group (a dropdown of groups, or "Any group") and Tags (comma-separated, all must match) choose the targets. A live counter under the body shows how many endpoints match the selector, and Dispatch is disabled until at least one matches.

Dispatch a script — interpreter & lifetime

Interpreter is sh, bash, powershell or python3 (only interpreters an endpoint’s administrator allowlisted will actually run). Job lifetime is 1 hour, 6 hours or 24 hours — after which an unrun/unapproved job expires. The Script body is the code to run.

Approval model

If you are an administrator or engineer, the script.run jobs dispatch immediately under your authority and are audited under your name. Otherwise each job requires a second operator to approve it before it executes. Devices outside their maintenance window are skipped, and the toast says how many.

Script library

The built-in catalogue plus your own saved scripts, searchable. "Use" loads a script into the dispatcher above (and sets the matching interpreter); "Edit" changes the saved script; "New script" creates one. This is the same library shared with Automation.

Last rollout

After a dispatch, a panel lists each endpoint’s job and status; "Refresh status" re-polls them so you can watch the rollout move from awaiting-approval through succeeded/failed.

A library of vetted script templates you can run on an endpoint now or on a schedule, carrying an approval lifecycle so impactful scripts are reviewed before they execute. SentinelOps has it to turn routine operator work into reusable, governed building blocks rather than copy-pasted one-offs. For the tenant it is a curated, auditable catalog of what can be run against their machines, with an optional second-operator gate on every run. Templates and settings are per-tenant.

At a glance

The summary tiles count Templates, how many Categories they span, and whether Change approval is On or Off for this tenant. "Seed built-in catalog" adds the built-in templates to this tenant (existing ones are left untouched).

Change management

A checkbox — "Require approval for automation runs on this tenant". When on, every automation run needs a second operator to approve it before it dispatches; the setting saves immediately.

Template library

Platform tabs (All, Linux, Windows, macOS, Android, Cross-platform) each with a count — a specific-OS tab also surfaces cross-platform templates, and "All" groups each script under its OS then by category. Each template shows its name, OS, interpreter, description and an approval badge (approved / in review / rejected / draft).

Review a template

With automation.manage a "Review…" button moves a template through the Draft → Submit for review → Approve / Reject lifecycle with an optional note. An author cannot approve their own script; an unapproved script cannot be run without the execute-unapproved permission, so review is the gate that makes a template runnable by everyone.

Run a template

"Run…" opens a dialog: pick the Endpoint (the list is filtered to OS-matching devices), fill any template parameters, and optionally set a Schedule (leave blank to run now). The run is dispatched, scheduled, or queued for approval depending on the per-tenant setting, and is audited. "Edit" changes the saved template (shared with the Scripts library).

Every job dispatched across the fleet in one place — its type, target device, status and any error — so you can see at a glance what ran, what is queued and what failed. SentinelOps has it because actions (patches, scripts, restarts, scans) all run through one job system, and this is the single pane that proves they landed. For the tenant it is the after-action record: scope it to their organization to confirm a rollout reached their machines, or leave the tenant blank to watch the whole fleet.

Filter with the status tiles

A total tile plus one tile per state that has jobs — queued, pending_approval, running, completed, failed, error, rejected, expired. The tiles are clickable: click one to filter the table to that status, and a ✕ "clear" tile appears to drop the filter. Failed and error tiles turn warning-coloured when non-zero.

Read the results column

Each row shows the job type, the device, a status pill (green for completed, red for failed/error/rejected/expired), when it was created and by whom, and the error text in red for anything that failed — enough to triage without opening the device.

Scope by tenant

With a tenant selected the list is scoped to that organization; with no tenant it spans the whole fleet. Use it right after a bulk action or rollout to confirm the jobs landed and none rejected or expired.

Set up recurring emailed fleet summaries and watch the network-topology trend that SentinelOps snapshots over time. SentinelOps has it so stakeholders get a regular pulse without logging in, and so topology growth/shrinkage is tracked as history rather than a single live view. For the tenant it is the standing reporting and change-over-time record — the topology trend is scoped to the selected tenant.

Schedule an emailed report

With reports.view, "+ Scheduled report" asks for a report Name and a Recipient email and creates a recurring (weekly) fleet-summary email. Reports go out via the server’s SMTP relay, so SMTP must be configured for delivery to work.

Manage the schedule

The table lists each report’s name, cadence, recipient and when it last sent; the ✕ removes one. "Last sent" showing "not yet" means it has not reached its first send.

Topology trend

The network map is snapshotted every 12 hours; this panel shows the latest device, online and discovered counts plus how many snapshots exist, so you can see the network growing or shrinking over time. The first snapshot is taken within 12 hours of setup.

Run one maintenance, tenancy or lifecycle action across many machines at once, instead of opening each device drawer. SentinelOps has it so routine fleet work — scan, patch, restart, retire — scales without dozens of clicks, while every selected device still goes through its own per-device guard, permission check and audit entry. For the tenant it is the fastest safe way to act on a whole set of their machines together. Mobile devices (Android / iOS) and already-decommissioned machines are excluded from the list.

Select and run

Tick devices (or "Select all"), choose an action from the dropdown — Scan for patches, Apply patches, Restart agent, Update agent now, Security audit scan, or Firmware scan — and click "Run on selected". You confirm before it queues, and the result line reports how many were queued; some actions may be held for approval depending on policy.

Move devices between tenants

With device.manage, tick devices and use "Move selected to tenant" to reassign them to the chosen organization. The devices then appear under the target tenant; their group / site / network assignments are cleared while tags follow the device. You confirm first, and the result reports how many moved and how many were skipped.

Decommission a device (per row)

The per-row "Decommission" (needs device.manage) marks that machine decommissioned — alerts, patching and automation pause — but it stays in inventory. It requires typing the device name to confirm, because it is a real state change, not a maintenance action.

Power & lifecycle on selected

Tick machines, then use the Power & lifecycle row to act on all of them at once: Reboot or Shut down (needs command.execute — Reboot shows a one-minute warning to signed-in users; Shut down powers the machine OFF and it will not restart on its own), Approve decommission (device.manage — authorizes each agent to deregister on uninstall for the next hour; it does NOT change device status), or Remove device (device.token.revoke — deletes them from inventory together with everything tied to each machine; irreversible). Each runs the same per-device endpoint with its own guards and audit; the result line reports how many succeeded and names any that failed.

Finds unmanaged machines on the network an enrolled agent sits on, so you can bring them under management. Why it is here: you cannot protect what you cannot see, and this surfaces the gaps without touching the endpoints — the scan is on-demand and read-only, it fingerprints hosts and never logs into anything. Tenant benefit: it turns a customer’s unknown LAN into a triaged list of real agent candidates, with firewalls, printers and NAS shown but never targeted.

Scan a network

Runs a one-time, read-only TCP-connect scan from a chosen online agent across its own private network. It is bounded so it cannot flood the network or reach the internet. The KPI strip shows Discovered, Deployable (agent-port candidates), Wireless scan results and Already managed.

Deployment credentials

Admin/root credentials you store, encrypted at rest, used by an on-LAN agent to log in and install. They are never shown again after saving and never leave the server except to a proxy at deploy time. If you lack credential.manage the credential column and the Deploy action are hidden and only the manual token-installer handoff remains.

Discovered machines

Each host is classified by type. Only workstations and servers are offered for deployment — firewalls, access points, printers and NAS are shown but never targeted. Filters let you show only candidates, hide already-managed hosts, or show only wireless-scan finds.

Deploy

Authorises installing the agent on one candidate via an on-LAN proxy using a stored credential. Per-machine and audited; no default-password guessing and no automatic spreading. The server enforces job.execute on every dispatch.

A triage worklist of the hosts network discovery keeps finding that are neither managed nor ignored. Why it is here: repeated scans otherwise re-list the same hosts forever, so this is where you clear them down — approve a host to move it toward deployment, or ignore one you never intend to manage so it stops resurfacing. Tenant benefit: it keeps a customer’s “unmanaged” list down to genuine agent candidates instead of permanent noise from their printers and phones.

What lands here

Every discovered host that is not yet managed and has not been ignored. The counters show how many await triage and how many of those are deploy candidates — hosts where an agent port was seen, so an agent can plausibly be pushed.

Reading a row

IP, hostname, and the best guess at vendor / classification / role from the scan. The Deployable column reads “deploy candidate” when the host looks agent-installable, or “no agent port” when it does not — a switch, printer or appliance typically shows the latter.

Approve vs Ignore

Approve marks the host for deployment follow-through; Ignore drops it from the queue so repeated scans stop re-listing it. Example: Ignore the office printer and the guest-Wi-Fi phones so the queue only ever shows real candidates for agent rollout.

Keeping the queue clear

An empty queue means discovery has found nothing new to triage — run Discovery again to sweep for more. Ignoring is reversible through the discovered-hosts data if a host later needs managing.

A live, scalable topology of the client network drawn from discovery and SNMP. Why it is here: a picture of how a site actually hangs together — what connects to which switch port, and what is down — is faster to reason about than a table. It stays smooth at 1,000+ devices: the canvas is larger than the screen and you pan and zoom rather than cramming everything in. Tenant benefit: it gives you (and a customer) an at-a-glance map of their estate, with every device typed from its SNMP signals (router, switch, firewall, AP, server, printer, UPS, camera, phone, hypervisor, NAS…).

Run discovery first

The map is built from discovered hosts, so it is empty until you run a network scan from Discovery. Once a scan exists, every device it found is plotted. (Admins can seed a 500-device demo topology with the “Mock 500” button to see it at scale.)

Pan, zoom and fit

Drag to pan; wheel, pinch or the +/− buttons to zoom; “Fit” frames the whole network. The minimap at the bottom-right shows where you are — click it to jump. Your zoom, position and layout are remembered per browser.

Zoom shows more detail

Zoomed out, devices group into collapsible subnet bubbles showing a device count and overall health — click a bubble to expand it, or use “Collapse” to collapse/expand all. Zoom in and you get icons with hostnames, then full detail (IP, type, status). This keeps labels readable at every level instead of overlapping into clutter.

Device types and status

Every device shows a type icon (unknown devices show “?” with their sysDescr in the tooltip) and a coloured status ring — green up, amber warning, red down — plus a red badge for its open alert count. Classification is data-driven; if a device is mis-typed, open it and set a manual type override (auto, or any of the known types).

Links

Links are drawn from real LLDP / switch-FDB data where available (a device to the switch port it is learned on, and switch-to-switch uplinks); devices with no learned switch location fall back to their segment gateway, which links up to the internet. A down link is dashed red.

Toolbar — search, filter, layout, export

Search by hostname/IP (it centres and highlights the match once you type 2+ characters), filter by device type or by status (up / down / warning / unmanaged), and switch between Clustered and Tiered layouts. Export the current map to PNG or SVG. Click a device to open the side panel (identity, vendor/model, status, sysName/sysDescr, type confidence and source, plus the type-override).

Fleet health rolled up by physical location, so you can see at a glance which site is healthy and which needs attention. Why it is here: for a customer with several offices, a per-location roll-up tells you where to send effort before you open a single device. Tenant benefit: it turns the tenant’s scattered devices into a per-office scorecard, so a site-wide outage stands out immediately.

One card per site

Each site shows total Devices, how many are Online, how many Offline, and Open alerts. The Offline and Open-alerts tiles turn to a warning colour when the count is non-zero, so a struggling site is obvious.

Sites come from Sites & Networks

A site only appears here once you have created it under Sites & Networks and assigned devices to it. An empty dashboard means no sites are defined yet — add them there first, then come back.

Use it for multi-location triage

For a client with several offices, scan the Offline and Open-alert counts to decide which location to work first — e.g. a branch showing 8 offline of 10 devices likely has a site-wide outage (link or power), not eight separate faults.

Answers one question for every machine: can SentinelOps log into it later without a domain controller? Why it is here: after a rebuild, a password change or on a workgroup box with no DC to fall back on, you can be locked out of your own endpoint — this surfaces that risk before it bites. It also keeps a read-only census of the accounts and credential slots each machine has (names only — never the passwords). Tenant benefit: it proves a customer’s fleet has a known-good way back in, and closes gaps with a rotated, vaulted credential SentinelOps owns.

Fleet coverage & KPIs

The tiles count Machines, how many Have a managed credential, and Coverage gaps (gaps shown in red). The table lists machines with no SentinelOps-owned credential first — those are the ones you could be locked out of. Columns: Machine (with OS), Status (online/offline), Coverage (Covered / No credential, plus how: “managed admin” and/or “N vaulted”), and a Census summary (accounts · Credential-Manager entries · service logons).

Census all online / per-machine Census

“Census all online” queues a credential-surface scan on every online machine (offline ones are skipped and reported). The per-row “Census” does one machine. It collects account names, Credential Manager entry names and service logon accounts only — it never harvests existing passwords (extracting them would be credential dumping; Windows stores hashes).

Manage → Enroll a managed admin

Open a machine with Manage. Set the managed-admin username (default sentineladmin) and a rotation period in days (default 30, 0 = manual), then Enroll/Update — SentinelOps sets, vaults and rotates that local admin’s password on the endpoint, giving you a reliable login into a workgroup box with no DC. “Reveal password” shows the current one on demand (audited).

Manage → Vault a known credential

For a login you are authorized to use on the machine, enter username, password, scope (machine-local / domain / other) and an optional note, then Vault credential. It is sealed at rest and revealed only on demand (audited). Vaulted entries can be revealed or deleted from the same panel.

Credential census (per machine)

Shows the collected surface with its collection time: Local accounts (name, enabled/disabled, admin), Credential Manager entries (names only), and Service logon accounts (service → runs-as). “Census now” refreshes it. Account and slot names only — never secrets.

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.

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.

Install common apps straight from a built-in catalog, or upload your own installer once and push either to a device, group or whole tenant with a button. SentinelOps has it so software roll-out is a central, repeatable, audited action instead of RDP-and-click on every machine. For the tenant it means apps arrive consistently and silently across their fleet; deploying changes endpoints, so it needs software.manage and may require a second approver by policy.

At a glance

The summary counts catalog apps, uploaded packages, how many packages are ready to deploy, and total deployments — so you can see what is available to push and what has been pushed.

Software catalog

A browsable, grouped-by-category list of common apps installable with no upload — driven by each machine’s own package manager (winget on Windows, the native package manager on any Linux distro, Homebrew on macOS). Incompatible machines are skipped automatically. "Install" on a card (or "Install from catalog") opens the deploy picker; "install any app by name" handles anything not listed.

Uploaded packages

"Upload installer" adds your own MSI / EXE / PKG / DEB / RPM / script, stored server-side and SHA-256 verified. Each row shows platform, size and status (ready / uploading % / failed, plus an "internal" badge for internally-owned packages). Deploy (enabled only when ready) pushes the file to each target and runs it silently, tolerating reboot-required exit codes; Edit changes its metadata; Delete removes it from the library (existing deployments are unaffected).

Scheduled deployments

Queue a rollout for later or on a cadence — Once, Hourly, Daily or Weekly — showing next run and enabled/paused state. Pause/Resume toggles it; Delete stops future runs (past deployments are unaffected). A schedule always fires for the package’s current version.

Recent deployments

Per-target status chips update automatically; click a row for the per-machine detail. The ✕ removes only the history record — it does not uninstall anything from any machine.

Deploy scope & approval

Deploying targets a device, a group or a tenant. Because it changes endpoints it requires software.manage and, by policy, may need a second approver before it runs.

Server-side maintenance that runs on a timetable instead of when you press a button — for example a nightly “Rebuild endpoint agents” job. Why it is here: recurring housekeeping should happen on its own and stay visible, so a job that has been failing quietly is caught. Tenant benefit: jobs are created against the tenant in context, and the last-run status keeps that organization’s routine upkeep honest and auditable rather than depending on someone remembering to run it.

The job table

Each row shows the Job name and its task type, how often it runs (Every), its State (enabled / off) and the Last run — status pill (ok / error / never run), any detail line, and the timestamp. “Rebuild endpoint agents” recompiles agents where a build toolchain is present; otherwise it records that agents ship with the SentinelOps package.

New scheduled job

Enter a Name, choose a Task from the server-provided task types, and a Runs cadence (hourly / daily / weekly). Leave “Enabled” ticked to have it start running on schedule, then click Create job. It is created against the current tenant.

Run now, Enable/Disable, Delete

“Run now” executes a job immediately and reports its status and detail. Enable/Disable turns the timetable on or off without deleting the job. Delete removes it (confirmed first) so it no longer runs.

Keeps every endpoint’s clock correct and shows each organization’s true local time across the console. Accurate time is a prerequisite for Kerberos/AD auth, TLS, correlating logs across machines and trustworthy audit trails, so SentinelOps both deploys an NTP policy to endpoints and tracks per-tenant time zones. For a tenant this means its servers and workstations stay synced (new machines auto-apply the policy on enrollment) and schedules, reports and the header clock read in the client’s own local time.

Organization time zones & clocks

A live, to-the-second clock per organization. Pick each organization’s IANA time zone from its dropdown (DST is handled automatically) so its real local time shows in the header clock, schedules and reports. Choosing “— set time zone —” (blank) clears it; the row then reads “time zone not set”.

Deploy now — field by field

Push a time-server config to running endpoints immediately. NTP servers: the list to apply. Scope: All my devices / a tenant / a device group / Domain controllers (authoritative — sets the DC as a reliable w32time source) / specific Device IDs — selecting one reveals its tenant/group/device-ID input. Linux NTP client: Auto (distro default), systemd-timesyncd, chrony, or classic ntpd — which daemon to configure on Linux. “Also save as the policy for this scope” (on by default): persists the setting so future enrollments auto-apply it, not just a one-off push. Click Deploy time servers; a per-device result table shows each machine queued or skipped.

What it configures (and what it can’t)

It configures the OS time service so the clock stays synced going forward — Windows w32time, Linux systemd-timesyncd/chrony/ntpd, macOS. Agent-managed endpoints and virtual hosts are covered here; hardware with no agent (a firewall, switch, WAP or PDU) must be pointed at an NTP server through its own management channel.

Puts the trust a Korthveil firewall needs onto the machines behind it. TLS inspection only decrypts traffic from devices that trust the firewall’s inspection CA; NAC (802.1X Enterprise Wi-Fi) only admits devices that trust the NAC CA and hold their own certificate from the firewall. One profile per CA, deployed to Windows, macOS and Linux with or without the agent.

Certificate profiles

Add certificate profile: paste or pick the CA file Korthveil gives you (Security › TLS inspection › Download CA certificate, or the download icon on the nac-ca row in System › Certificates). Only the public certificate is stored; anything with a private key is refused. Compare the SHA-256 shown with the one on Korthveil’s install page. “Install on every new machine” adds the CA to each machine that enrolls later. A NAC profile also needs the Wi-Fi name and the RADIUS server name from the nac-radius certificate.

Machines with the agent

Install, Check or Remove on every machine, an organization, a group, or ticked machines. Windows: Trusted Root (machine) and Firefox enterprise roots. macOS: the System keychain; when macOS insists on local approval, the user gets a profile to approve and the result says “Waiting for the user”. Linux: the distro trust store, Chrome/Chromium NSS databases and a Firefox policy; missing tools are installed automatically.

NAC device certificates

Pick every device’s .p12 at once. Files are matched to machines by name (laptop-1.p12 → laptop-1), and you enter each one-time password. Each file and password goes only to that machine’s agent as a sealed secret over stdin; neither is stored, logged or shown again. The agent installs the certificate, the CA and the Enterprise Wi-Fi profile (Windows machine authentication, Linux NetworkManager, macOS profile the user approves). Needs agent 0.5.38 or newer.

Issue device certificates from the firewall

Easiest for NAC (Korthveil 1.1.53+). Edit a NAC profile and choose the firewall and its CA name (usually nac-ca). On the firewall, give SentinelOps commit authority (System › SentinelOps RMM) and allow that CA under system.certificates.remoteIssue. Then “Issue device certificates from the firewall” gives each chosen machine its own certificate (named sops-<machine ID>, common name = the machine’s DNS name). The key travels only as a sealed secret to that machine’s agent, which installs it with the CA and the Wi-Fi profile. Running it again renews. “Revoke device certificates”, or removing the machine from SentinelOps, revokes it on the firewall and NAC refuses the machine at once. “Give every new machine its own certificate” does this on enrollment.

Windows domain (Group Policy)

For domain PCs without the agent: the agent on a domain controller creates the “Korthveil certificate - <profile>” Group Policy at the domain root. Its startup script adds the CA, so PCs trust it after their next restart. “Remove from domain PCs” turns the script into a removal; delete the Group Policy afterwards.

Machines without an agent (SSH / WinRM)

An online agent on the same network logs in with a stored credential (Agent Deployment › Credentials) and runs the same install, check or removal. One line per machine: address and os (windows, linux or macos). Only private addresses. NAC device keys are never sent this way.

Results

One row per machine, updated every 5 seconds: Installed, Waiting for the user, Not installed, Removed, Queued or Failed, with what the machine reported.

Out-of-band server management over Redfish: control power and reach the console of a physical server through its baseboard management controller (iDRAC / iLO / generic Redfish), which works even when the operating system is hung, crashed or powered off. SentinelOps keeps this because recovering a down server otherwise means a site visit. For a tenant it means a dead or unresponsive server can be power-cycled, reinstalled or driven to its console remotely, with every action audited.

Add BMC endpoint — field by field

Name (e.g. dc1-idrac-01); Address (IP or host:443); Vendor (Auto-detect, iDRAC, iLO or Redfish); Link to device (optional — ties the controller to an enrolled machine); Username and Password for the controller. Tick “Accept the BMC’s self-signed certificate” for the typical lab/appliance cert. The password is sealed in the vault (AES-256-GCM) and never returned. Adding requires credential.manage.

Endpoints list

Each registered controller shows its name, address, vendor and linked device. Status reads live power state and hardware health from the BMC on demand. Delete removes the endpoint and its sealed credential.

Power

Power… opens a Redfish reset: Power on, Graceful shutdown, Force off, Restart, Force restart, Power cycle — each affects the physical power state and asks for confirmation. It also has “Boot to PXE next (once) & reboot”, a one-time network boot that reverts afterward; arm a PXE boot server targeting the machine’s MAC first (see PXE Netboot). Power actions require command.execute and are audited.

Serial console & KVM

Serial console… reports whether Serial-over-LAN is enabled and gives the attach command; KVM… reports whether the graphical console is available and launches the HTML5 KVM viewer — so you can watch POST/boot and operate the machine with no OS.

Virtual media

Virtual media… mounts an ISO to the server over Redfish so you can boot an installer or recovery image remotely, the OOB equivalent of walking a USB stick to the rack.

Register the virtualization hosts your tenants run (XCP-ng/XenServer, VMware vSphere, Proxmox, Hyper-V, VirtualBox). Why it is here: the hypervisor is the rung above the guest OS agent, so SentinelOps can monitor host health and force power actions on a VM even when its guest is hung or off. Tenant benefit: a customer’s virtual estate gets agentless host monitoring plus last-resort power control and guest-agent deployment, all audited.

Hosts

Each hypervisor/manager you have registered. Credentials are sealed in the vault; Test verifies reachability. Network hosts (XCP-ng/vSphere/Proxmox) are reached by API; Hyper-V and VirtualBox run through the SentinelOps agent enrolled on the host.

Host monitoring (live health)

Every registered host is polled every 2 minutes and its CPU / memory / storage / temperature stored — so a host shows on the Dashboard’s “Hypervisor hosts” panel and inline here as “● Up · CPU x% · Mem y% · Disk z%” (or “● Unreachable”), with an alert raised if it goes unreachable or storage hits ≥90%. “Metrics…” opens the full live view. Collection per type: XCP-ng via XenAPI + the RRD feed (CPU/memory/storage; temperature where the hardware exposes a sensor — many mini/consumer hosts do not, shown blank honestly); Proxmox via the node status API; Hyper-V/VirtualBox from the host’s own agent; vSphere lists hosts + connection/power state via REST and live CPU/memory via the SOAP quickStats. No agent is installed on dom0/ESXi — this is agentless.

ISO storage — create, increase, add ISOs

XCP-ng hosts: “ISO storage…” on the host (also linked from Create VM → Boot ISO) lists every ISO library with its size, used space and ISO count. Create ISO storage carves a FIXED-size library (e.g. 100 GB) out of a local LVM or EXT disk on the host: it is formatted, mounted at every boot and registered as an ISO SR, so it appears in Create VM → Boot ISO and in each VM’s CD drive. “Increase size…” grows a SentinelOps-created library online (no downtime); a plain-folder library already uses the free space of the disk it lives on, so it has no size to grow. “Add ISO from URL…” makes the host download an .iso straight into the library in the background. Requirements: changes need root on the host, so they run through the host’s dom0 SentinelOps agent (Edit… → dom0 agent) and need command.execute; every change first proves that agent is really on THIS host and aborts without touching anything if it is linked to the wrong machine.

Deploy an agent to a node (guest VM)

To manage a *guest* fully (patching, shell, files, native metrics), install the SentinelOps agent inside it: on the host’s VMs… list use Deploy agent, or go to Deploy Agent and target the guest’s IP. Linux guests get a fully-static (musl) build that runs on any glibc — including older ones (Debian 11/12, RHEL/Rocky, and XCP-ng dom0 itself), which a glibc-linked build cannot. Requirements: the guest must reach the server on 8480 (a first enrolment from a new IP is allowed automatically, or add it under Agent allowlist), and outbound 443 for the self-heal tunnel. Agents self-update from the server, so a version bump reaches the fleet on its own. Example: XOA (Xen Orchestra) is a Debian guest — it runs the agent and is monitored like any endpoint.

Detected VMs

Guests the agents report as virtual. Map one to a host to enable “Force reset via hypervisor” on its device drawer. For XCP-ng the VM UUID matches the guest system UUID, so it maps automatically.

Power

Force reset / power on / off / graceful shutdown, straight to the hypervisor. Every action is audited. Requires command.execute.

VM console & boot log

On an XCP-ng host’s VM list: Console opens the live noVNC screen (see it boot); Boot log shows the text side — power state, start time, uptime from the pool master (works with no guest agent, e.g. mid-install) plus this VM’s action history. Both refresh live.

Create, monitor and operate Azure virtual machines for a tenant directly from SentinelOps, using an app registration (service principal) that authenticates app-to-app — no interactive login, no MFA prompt. Why it is here: it lets you stand up and run cloud compute for a customer without leaving the console. Tenant benefit: each tenant carries its own Azure subscription and sealed credential, so a customer’s Azure estate is managed in isolation. Pick a tenant first.

1 · Register an app in Azure (one-time)

Azure portal → Microsoft Entra ID → App registrations → New registration. Name it (e.g. "SentinelOps"), Register. Copy the Application (client) ID and Directory (tenant) ID. Then Certificates & secrets → New client secret → copy the secret VALUE (not the Secret ID). The same app and secret can serve both Microsoft 365 (Graph) and Azure (ARM) — SentinelOps requests the right scope per token.

2 · Grant it the Contributor role

Portal → Subscriptions → your subscription → Access control (IAM) → Add role assignment → Contributor → assign to the app you registered. Without this the credential authenticates but cannot create or manage VMs.

3 · Connect it here

Paste Subscription ID, Directory (tenant) ID, App (client) ID and the client secret VALUE, then Save & connect. If you already stored the secret for this tenant’s Graph app, tick "Reuse the secret already stored" and leave the secret blank. SentinelOps seals the secret in its vault — the plaintext is never shown again.

4 · Create a VM

Click + Create VM. Choose a name, OS (Linux/Windows), size, location and a resource group. Provide an SSH public key (Linux) or admin password (Windows) — it passes straight to Azure and is never stored. SentinelOps provisions in order: resource group → network security group (SSH 22 / RDP 3389) → virtual network + subnet → public IP → NIC → the VM, waiting for each to succeed. The VM appears in the list within a few minutes.

5 · Monitor & operate

Load / refresh VMs shows each VM’s power state, size/OS and its public + private IPs. Start, Restart and Stop (deallocate) act through the Resource Manager API and are audited. Stop = deallocate, which stops Azure compute billing for that VM.

⚠ Before you create a VM — read this

Creating an Azure VM on a new subscription is frequently blocked by Microsoft-side account limits, NOT by SentinelOps. Expect this and plan for it: (1) a brand-new subscription is a free trial and must be upgraded to Pay-As-You-Go before ANY VM or quota increase (it stays free — credit kept, free-tier VM activated); (2) every VM family starts at 0 vCPU quota, so the first create fails until you raise the family quota; (3) small quota increases can take minutes to hours, and some subscriptions require a support ticket that Microsoft reviews; (4) requesting quota too many times in a short window gets the quota API throttled by Azure for up to 24 hours. So: raise the quota you need ONCE, then wait — do not retry in a loop. The free-tier size is currently Standard_B2ts_v2 (Microsoft replaced B1s and did not announce it).

Capacity / quota note

New subscriptions often have a per-VM-family vCPU quota of 0, so Azure refuses every size and reports it as "SkuNotAvailable / Capacity Restrictions" (misleading — it usually means quota, not real capacity). Use Diagnostics & Azure restrictions → Check quota to see the real numbers, request an increase with POST /v1/azure/quota (once), or file a portal support ticket. A quota error like "exceeding approved standardBsv2Family quota" means the size HAS capacity and only needs its family quota raised.

If the quota request keeps failing — troubleshooting

Being on Pay-As-You-Go lets you REQUEST quota but does not bypass a 0 family cap — a VM still needs its family limit ≥ its vCPU count (the smallest available burstable, Standard_B2ts_v2, needs 2). Some subscriptions reject the self-service quota API outright: the request shows "Failed" in Diagnostics with no limit change, even for 1–2 vCPU. When that happens the reliable path is a PORTAL SUPPORT TICKET: Help + support → New support request → "Service and subscription limits (quotas)" → "Compute-VM (cores-vCPUs) subscription limit increases" → your region → the family (e.g. Standard Bsv2 Family) → the vCPU count. Free under Basic support, usually minutes–hours. Note there is often no 1-vCPU B-family available (only the v2 burstables, min 2 vCPU). To validate an agent on a cloud VM meanwhile, use a different connector (e.g. Linode): spin the smallest instance, it auto-enrols via cloud-init, confirm it, then delete — the SentinelOps agent is provider-agnostic.

Create, monitor and operate Linode instances (and LKE Kubernetes) for a tenant using a Linode Personal Access Token. Why it is here: it gives you token-gated cloud compute whose VMs enrol themselves — new VMs auto-install the SentinelOps agent on first boot and self-enroll through the agent firewall. Tenant benefit: the Linode token is stored per-tenant and sealed in the vault, and every VM you create lands in the tenant you choose and appears in Devices within minutes. Pick a tenant first (top pulldown or the tenant strip).

1 · Get a Linode API token (one-time)

Linode Cloud Manager → Profile → API Tokens → Create a Personal Access Token with Read/Write scope. Copy it. Example: create it under the account that owns the VMs you want SentinelOps to manage.

2 · Connect it here

Select the tenant (e.g. Linode SYS) → Infrastructure → Linode Cloud → paste the token → Verify & connect. SentinelOps checks it against Linode, then seals it in the vault (never shown again). Use "Edit token" later to replace or disconnect. The Tenant pulldown at the top of the page switches which tenant’s Linode account you manage — it works even under "All Tenants".

3 · Create an instance (auto-agent)

Click + Create instance. Choose: Enroll into tenant (where the agent lands — defaults to the current tenant); Region; Plan (each shows $/mo — Nanode is $5/mo); Image/OS (leave Ubuntu 24.04 — the agent needs glibc ≥ 2.38, so avoid Ubuntu 22.04 / Debian 12 / Rocky 9); Root password (leave blank to auto-generate a strong one, shown once and also saved to the tenant’s credential vault); keep "Auto-deploy the SentinelOps agent" checked. Click Create.

4 · Watch it come up

The instance list auto-refreshes (a "● live" marker). It progresses provisioning → booting → running, and the In SentinelOps column goes not enrolled → enrolling… → ✓ <tenant> in ~2 minutes. It then also appears in Devices under that tenant. No manual steps — the deploy uses a Linode StackScript, and SentinelOps authorises the new VM’s IP on the agent firewall automatically.

5 · Cost & tenant match

Each running instance shows its Cost/mo plus an estimated monthly total. The In SentinelOps column shows exactly which SentinelOps tenant each VM is enrolled in — matched by the Linode instance ID stamped on the device (falls back to IP/label). To move a machine to another tenant later: its device drawer → Move to tenant, or Bulk Actions → Move selected to tenant.

6 · LISH console & custom OS (FreeBSD)

Console on a row opens Weblish (serial shell) and Glish (graphical). Linode has no FreeBSD image — to install FreeBSD or a fully custom OS, create the instance, then use Glish + Rescue mode to install it by hand.

7 · Kubernetes (LKE)

+ Create cluster under LKE: label, region, Kubernetes version (1.36/1.35), node plan and count. Kubeconfig downloads once the cluster is ready. Bigger spend than a single VM (≈$12/mo per node + control plane).

If a VM does not enrol

Rare, but: click Deploy agent on the un-enrolled row for the exact one-line command, open the instance Console → Weblish, log in as root (the saved root password) and paste it. Make sure the OS is a modern release (Ubuntu 24.04+, Debian 13, Rocky/Alma 10, Fedora).

Connect an AWS IAM access key per tenant, then list, launch, power and terminate EC2 instances — launched instances self-enroll the SentinelOps agent on first boot (cloud-init user-data). Why it is here: it brings a customer’s AWS compute under the same enrol-and-manage flow as every other cloud. Tenant benefit: the access key + secret are verified against AWS then sealed in the vault per-tenant (secret never shown again), so a customer’s EC2 estate is isolated and every launched VM enrols into their tenant. Pick a tenant first.

1 · Create an IAM access key (one-time)

AWS Console → IAM → Users → your user → Security credentials → Create access key (or create a dedicated IAM user with an EC2 policy such as AmazonEC2FullAccess). Copy the Access key ID and Secret access key. The secret is shown only once by AWS.

1b · Or use temporary SSO/STS credentials

Instead of a long-lived key you can paste temporary credentials from AWS SSO or an assumed role (access key ID starting ASIA…, secret, and a session token). Run "aws sts get-session-token" or copy them from the AWS access portal / "aws configure export-credentials", then paste all three (including the Session token) into the connect form. Temporary creds expire — typically ~12h — and the panel shows a "temporary" badge; when EC2 calls start failing with an auth error, reconnect with a fresh session token.

2 · Connect it here

Select the tenant → Infrastructure → AWS EC2 → paste the Access key ID + Secret access key + a default Region (e.g. us-east-1) → Verify & connect. SentinelOps validates it with DescribeRegions, then seals the secret in the vault. Requires tenant.manage. Use Disconnect later to remove it.

3 · Launch an instance (auto-agent)

Click Launch instance. Enter a Name, an AMI ID for your region (find it in the EC2 console → AMIs — e.g. an Ubuntu 24.04 or Amazon Linux image; the agent needs glibc ≥ 2.38 so avoid old images), pick an Instance type, optionally a Key pair name for SSH, and keep "Install the SentinelOps agent on first boot" checked. Click Launch — it self-enrolls in ~1–2 min via cloud-init.

4 · Watch it enroll

The instance list shows Status and the In SentinelOps column. A fresh instance has no public IP for a moment; refresh and it fills in, and once the agent phones home the row shows the tenant it enrolled into. The new instance also appears in Devices. SentinelOps authorizes the VM’s public IP on the agent firewall at create time.

5 · Power & terminate

Per-row Start / Stop / Reboot map to EC2 StartInstances / StopInstances / RebootInstances. Terminate calls TerminateInstances and then decommissions the matching SentinelOps device and revokes its firewall grant — it does not delete the device record (audit trail preserved).

If a VM does not enroll

Confirm the AMI is a modern Linux (glibc ≥ 2.38), that the instance got a public IP (or is reachable), and that outbound 8480 to the server is open in its security group. You can also SSH in with your key pair and run the one-line install command from the Downloads portal manually.

Connect DigitalOcean, Vultr or Hetzner Cloud with a single API token per tenant, then create VMs that install the SentinelOps agent on first boot and self-enroll through the agent firewall (port-knock). Why it is here: it extends the same token-gated, auto-enrolling cloud lifecycle as the Linode connector to three more providers, unified under one view. Tenant benefit: a customer’s VMs on any of these clouds come under management automatically, each matched back to the tenant it belongs to.

Pick a tenant first

Cloud connectors are per tenant — select a tenant in the top bar, then choose a provider tab. Each tab shows whether that provider is connected for this tenant.

Connect a token

Paste the provider’s API token (DigitalOcean personal access token, Vultr API key, or Hetzner Cloud project token). It is verified, then stored encrypted in the vault and never shown again. Requires tenant.manage.

Instances

Lists each VM with status, IPv4, estimated monthly cost, and which SentinelOps tenant it is enrolled in (matched by IP, then name). Reboot or delete with command.execute — deleting decommissions the device and revokes its firewall grant.

Create VM

Choose region, plan and image; leave agent install on to have the VM self-enroll. Its public IP is authorized on the agent firewall at create time and it also knocks on first boot.

A cross-cloud rollup of estimated monthly spend per tenant, summed from every connected cloud connector. Why it is here: once you create VMs for customers across clouds, someone has to see what it costs — in one place. Tenant benefit: each customer’s cloud spend is attributed to their tenant and totalled honestly; figures come from each provider’s published plan pricing, and providers billed by consumption that cannot be priced yet show "n/a" rather than a guessed number, so the total is never fabricated.

Estimated monthly total

A headline card: the summed monthly spend across every tenant you manage and every connected provider that can be priced, with the currency and the number of tenants it covers.

Per-tenant table

Each tenant with a connected cloud, the providers in play (each as a chip showing its own monthly estimate, or "n/a" with a reason when it cannot be priced), and the tenant’s total. Linode is priced from its plan pricing today; other connectors populate as they gain pricing support. An empty table means no connected cloud has billable instances yet.

Requires billing.view

Cost figures are gated behind the billing.view permission, like the Microsoft 365 / Services bill.

Network-install machines that have no BMC. You drive it from anywhere, but PXE is a local-network protocol: SentinelOps arms an online Linux endpoint on the SAME LAN segment as the targets and it serves the boot there — there is no netboot across the internet. For a tenant this means bare-metal or wiped machines can be (re)imaged at a site without a technician carrying install media, optionally fully unattended, and diverting only one target so a live network is safe.

One-time setup

Upload the iPXE firmware (undionly.kpxe for BIOS, ipxe.efi for UEFI, from ipxe.org) and your OS ISO into the ISO library — the Arm form reads both from there.

Arm boot server — field by field

Boot-server endpoint: an online Linux endpoint ON the target LAN segment. OS image: the install ISO from the library. BIOS firmware / UEFI firmware: select at least one iPXE firmware. Target machine MAC (optional): if set, ONLY that machine is diverted to the installer and everything else on the segment boots from local disk. Unattended install profile (optional): an answer file for a hands-off install. Armed window (minutes, default 30, 1–720): the session self-expires at the end. Segment note (optional): a label like “Branch office VLAN 40”. SentinelOps pushes the files to the endpoint and runs a time-boxed proxyDHCP + TFTP + HTTP boot server; proxyDHCP COEXISTS with the site’s DHCP and never assigns addresses.

Boot servers table

Armed sessions show the endpoint, image, status (arming → active → failed/expired) with the expiry time and any detail. Boot log opens the targeted machine’s live boot timeline — DHCP → firmware → kernel/initrd → answer-file fetches → installer steps, refreshing while open. Disarm stops a session early.

Unattended install profiles — field by field

New profile (or Edit): Name; OS family (ubuntu/debian/rhel/windows/generic); Kind (autoinstall/preseed/kickstart/cloud-init/unattend); the Answer file body; and optionally Kernel (vmlinuz) + Initrd chosen from the ISO library plus a Kernel-args override (`{base}` = the boot-server URL). With a kernel + initrd attached the install is fully hands-off; without them the machine boots the ISO and the installer must fetch the answer file itself (the table’s Kernel-boot column shows “yes” vs “sanboot only”).

Boot to PXE next & boot media

To make a machine PXE-boot once without touching it: BMC / iDRAC → Power → “Boot to PXE next”, or an enrolled Linux box’s device drawer → “Boot to PXE next” (UEFI BootNext + reboot); otherwise Wake-on-LAN a machine already set to netboot. For hardware/VMs with no PXE ROM, download ipxe.iso / ipxe.usb (uploaded to the ISO library) from the Boot media panel, burn/attach it, and it finds the armed boot server automatically.

Limits

One armed endpoint covers one segment; boot-server endpoints must be Linux; the ISO must be iPXE-sanboot-able; the window self-expires and Disarm stops it early.

Recover a machine that is off, hung or wedged without anyone on site, by controlling a switched PDU’s outlets or reading a UPS over SNMP. SentinelOps keeps it as the bottom rung of the power hierarchy — for kit that has no BMC. For a tenant it means a frozen appliance can be hard power-cycled remotely and a site’s UPS health (battery, runtime, load) is visible before an outage, with every switching action audited.

PDUs

Add a switched PDU to turn individual outlets On / Off / Cycle. Each outlet shows its live state (on/off/unknown); Off and Cycle ask for confirmation because anything plugged in loses power immediately. The SNMP community/secret must have WRITE access to actually switch outlets.

UPS

Add a UPS (RFC-1628 UPS-MIB) and “Refresh status” reads battery status, charge %, minutes of runtime, load % and output source. Status only — a UPS has no outlets to switch here.

Add power device — field by field

Name (e.g. “Rack A PDU”); Address (IP/host) + Port (default 161); Type (PDU switched, or UPS); Profile (built-in APC rPDU, a Generic PDU, or UPS RFC-1628 — selecting UPS forces the RFC-1628 profile); SNMP version (v2c → Community with write access; or v3 → user, Auth proto SHA/MD5 + pass, Priv proto AES/DES + pass); Outlet count for a PDU (default 8). A Generic profile also asks for the Control OID base (the outlet index is appended) and the integer values it expects for On/Off/Cycle. Note is optional. An address is required; the community/v3 secret is sealed in the vault and never returned.

Refresh status & remove

Refresh status re-reads the device over SNMP. Remove takes the PDU/UPS out of SentinelOps only — the hardware itself is untouched. Every power action is audited (operator, device, outlet, result).

Which tool to reach for

Wake-on-LAN powers a machine on; a PDU hard-cycles a wedged one; a BMC does both plus bootable media (see BMC / iDRAC); PXE / BMC virtual media reinstall it. Wake-on-LAN policy classes (device drawer → Wake-on-LAN → Policy…) auto-enable WoL on the ticked device classes — Windows/Linux servers and workstations, macOS, hypervisors — or on devices carrying a listed tag.

Brings devices that can’t run an agent — switches, firewalls, printers, UPS units, PDUs — into the same monitoring, rules and alerts as everything else, by polling them over SNMP. Enrolled machines report SNMP-equivalent MIB data through their agent automatically; agentless gear is added as a per-organization paid add-on. The benefit to a tenant is one health picture across managed and unmanaged network kit, with polling run from a collector on the customer’s own LAN so SNMP traffic never leaves it.

Managed machines

The top table lists every enrolled endpoint in scope — these report SNMP-equivalent MIB data through their agent with no target to configure. Click a row to highlight it, then “View SNMP →” (or press Enter) to open that machine’s live stats and readings.

SNMP targets table

Each agentless target shows its address:port, version, whether it is polled by the server or “via agent”, how many features/custom OIDs it collects, an on/off state, the last poll status (ok/error/never) with any error, and the latest values read. Values feed the same per-tenant monitor rules and alerts as agents do.

Add SNMP target — field by field

Organization: which tenant owns the target (SNMP must be enabled for it — see Add-on). Name: a label, e.g. “Core switch”. Address + Port (default 161): the device to poll. Version: v2c (enter a Community string) or v3 (authPriv — v3 user, Auth protocol SHA/MD5 + Auth password, Priv protocol AES/DES + Priv password). Secrets are sealed in the vault and never shown again. Features to collect: tick the metrics under each category (vendor/custom scopes noted). Advanced → custom OIDs: one `metric_key = OID` per line for anything not in the feature list. Interval (default 60s): how often to poll. Collector: “Server polls directly”, or pick an on-LAN agent so polling originates inside the customer network. Enabled: start polling immediately. You must give at least one feature or one custom OID. Click Add target.

Per-target actions

Features edits which metrics that target collects; Disk/Apps configures disk-space and running-application checks for it; Poll forces an immediate read and shows the result; Disable/Enable pauses or resumes polling; Delete stops polling and removes the target’s synthetic device.

MIB Workbench & Manage MIB features

MIB Workbench (top-right) is the power tool: probe a single OID live (GET or WALK, read-only), bulk-create MIB features by pasting `metric_key = OID` lines from a vendor MIB, assemble named MIB sets and deploy them across a tenant or the datacenter, and build a monitor rule aimed at specific machines. Manage MIB features edits the catalog of features the Add form offers.

Add-on gating

Agentless SNMP targets are a subscribed feature enabled per organization. If the chosen organization doesn’t have it, the Add form blocks with a notice; an operator with the right permission gets an “Enable SNMP add-on” button inline. Managed-machine SNMP (via the agent) is not gated.

Maps what is plugged into which switch port — and which access point a Wi-Fi client is on — read read-only from a switch over SNMP (its MAC-address table plus LLDP) or from a UniFi controller, then correlated back to your known devices. SentinelOps keeps it so an operator can answer “where physically is this device?” and trace a cable without walking the rack. Each device’s switch+port (or AP) then also shows on its Discovery row. Nothing is ever written back to the switch.

Scan a switch (from the server)

Pick an SNMP target — a switch added under Infrastructure → SNMP — and click “Scan from server”. The server walks it over SNMP (this can take a moment) and builds the port map.

Scan from an agent

For a switch or AP the server can’t reach (a remote site), pick an on-LAN online agent, enter the switch/AP IP and a read-only SNMP community, and “Scan from agent” — the agent on that LAN walks it and reports back. A Wi-Fi client learned on an AP radio is located to that AP.

Wi-Fi controllers (UniFi)

Add a UniFi Network controller to locate Wi-Fi clients to their AP, SSID and signal. Fields: base URL (:443 for UniFi OS UDM/CloudKey, :8443 for self-hosted), username, password, site (default), and the “UniFi OS” checkbox. Test verifies the connection and reports client/AP counts; Add saves it (read-only — it only reads the client + device tables); Sync now refreshes; Remove deletes it and its client locations. Use a read-only/limited admin account.

Read the port map

Each port shows its name/alias, up/down status, any LLDP neighbour (and its port), and the connected device(s) matched from the MAC table. “+N unmatched MACs” means MACs seen on that port that don’t map to a known device; a device tagged “(discovered)” was seen on the network but isn’t an enrolled endpoint.

Rescan when things move

Each mapped switch’s header shows port/MAC/matched counts and when it was last scanned; Rescan refreshes it after re-cabling or moving equipment.

IP security cameras detected on a tenant’s networks — wired and wireless — recognised by MAC vendor and RTSP/ONVIF ports. SentinelOps keeps it so the cameras on a client site are inventoried and viewable alongside everything else it manages, rather than being an unmanaged blind spot. For a tenant it surfaces every camera with its physical location and a one-click way to view it, snapshot it or reach its web UI.

Scan & summary

“Scan for cameras” re-runs detection through an on-site agent (a Wi-Fi machine finds wireless cameras; any agent finds wired ones). The summary tiles count cameras, distinct brands, wireless cameras and how many are managed; brand chips show the vendor spread.

Camera list

Each row shows the camera’s name/brand (with a “(likely)” note when confidence is lower), its IP / hostname / MAC, and its location from Switch Ports / UniFi mapping where known.

View actions

Live streams the camera via an on-LAN agent (ffmpeg → HLS); Snapshot grabs a still through an on-LAN agent; Web UI opens the camera’s own page; RTSP copies the vendor RTSP stream URL. RTSP URLs are vendor templates — some models use a different path, which you can override per camera.

Edit a camera

Edit sets the Name, a Location note, an RTSP path override, a Saved credential (a “Camera / NVR login” stored encrypted under Users & Identity → Deployment credentials, reused for snapshots and live view), free-form Notes, and a “Not a camera — hide from this list” checkbox to dismiss a false positive.

VoIP phones and PBXes, the network services running on each host, and the software census across the fleet — in one read-only view. SentinelOps keeps it so an operator can see a tenant’s telephony estate, what each host is actually exposing, and which software is installed where, without a separate scanner. It is strictly read-only: SentinelOps detects and manages VoIP devices, services and metadata but never intercepts or records call audio. Use Refresh to reload; the data comes from network discovery and agent inventory.

VoIP tab

Three groups: IP phones (identified by vendor — Polycom, Yealink, Grandstream… — or SIP ports 5060/5061, with their IP, brand, SIP ports, location and managed/seen status); PBX / SIP servers (Asterisk, FreePBX, FreeSWITCH, 3CX); and Softphones found in installed-software inventory (Zoom, Teams, Zoiper, Bria, MicroSIP…) with how many devices carry each. Empty groups explain how to populate them — run a network scan from an on-LAN agent.

Services tab

One row per host with detected open services: hostname/IP, an identity guess (vendor · role), the open services as port pills, and any HTTP-server or SSH banner. Populated by running a network scan from an on-LAN agent (Discovery → scan).

Software tab

The installed-software census across managed endpoints — each product with how many devices carry it and the versions in the field, sorted by install count. Endpoints report this on heartbeat once the “Installed software” collector is enabled; full detail is also in the Software Catalog view.

A per-tenant inventory of client firewalls with live health — management-plane reachability and latency, and, when linked to an SNMP target, model, uptime, interface up/down counts and CPU. SentinelOps keeps it so a firewall that silently dies is caught before the client reports an outage. This is monitoring, not rule management; adding a firewall requires the credential.manage permission.

Reachability and latency

Each card shows an UP / DOWN / “not polled” pill and the management-plane latency in milliseconds, with when it was last polled — a quick health signal from the management interface answering, even without SNMP.

SNMP health

Link an SNMP target and the card fills in model, uptime, interfaces up/down and CPU percent. Without a linked target those tiles read “—” and the card notes that model/uptime/interface/CPU health needs an SNMP target.

Poll, scope and remove

Poll re-checks a firewall on demand rather than waiting for the automatic cycle. This view is monitoring only — deep, per-vendor rule management shows “integration required” and isn’t wired in. Remove takes the firewall out of SentinelOps but changes nothing on the device.

Synthetic uptime checks for the applications and services a tenant depends on — the server actively probes each target on a schedule and records whether it responded, with uptime history. SentinelOps keeps it so a dead web app, database port or mail service is caught by proactive probing rather than a user complaint. For a tenant it means a live up/down + latency picture of its key apps, and (where priced) a per-product monitoring cost that feeds its bill. Creating and editing monitors needs the alert.manage permission.

Monitor a machine (from the catalog)

Pick a system that has an agent installed, then “Manage applications →” to browse and toggle the applications to monitor on it — no typing. This is the easiest path: choose, for example, Microsoft SQL Server on a host and the probe type and port are filled in for you.

Add a standalone monitor — field by field

+ Monitor opens a form: Application (optional — pick from the catalog to pre-fill type/port/expected-status); Name; Type (http, https, tcp, sql, postgres, mysql, smtp, redis, ldap, rdp or ssh); Target (a URL for web checks, or host[:port] for a service check — a catalog pick completes a bare host with its default port); Expect HTTP status (0 = any 2xx/3xx); Interval in seconds (default 180); and “Body must contain” for an HTTP keyword check. HTTP/HTTPS issue a real GET; other types are a TCP connect to the port.

Read a card

Each monitor is a card: type and target, an OK / FAIL / “not checked” pill, when it last ran, any detail/error line, and tiles for status, latency, HTTP code (web checks) and uptime percent. Uptime is colour-coded — green at 99%+, amber down to 95%, red below — over the sample count shown.

Check on demand & drill in

Check runs that probe immediately instead of waiting for the next scheduled run — handy right after a fix. Opening a monitor shows its latency chart, up/down timeline and recent checks, plus “Inspect now” which asks the endpoint for live connection counts and (on a MySQL/MariaDB or Redis deep check) service stats.

Monitoring cost

With billing.view a cost panel sums enabled monitored products × their per-product monthly price, per tenant, and merges into each tenant’s Billing view. With billing.manage, “Edit prices” sets the currency, a default price and per-product prices.

Monitor a tenant’s database servers across the fleet and run READ-ONLY queries against them. Checks run on the endpoint via its agent and credentials are vaulted — the password is never placed on a command line. SentinelOps keeps it so DB liveness and key metrics sit alongside the rest of the fleet’s health and an operator can inspect data without a separate tool or a direct network path. It is deliberately read-only: nothing here can change a tenant’s data. Managing databases needs alert.manage; the query console needs database.query.

What it monitors

Full metrics (liveness, version, connections, size, uptime) and a read-only query console for the deep-supported engines: MySQL/MariaDB, PostgreSQL, SQL Server, Redis and MongoDB. Oracle, Db2, Elasticsearch/OpenSearch, InfluxDB, CouchDB, etcd, Neo4j, Firebird, SQLite, DuckDB and H2 are monitored for reachability and version (cards tagged “reachability”); deeper support comes later.

Status and metrics

Cards are grouped by engine family and show UP / DOWN / ERROR with latency, key metric chips (DBs, size, connections, uptime, keys) and trend graphs from the rolling check history. SentinelOps re-checks on the interval you set and raises an alert when a database stops responding.

Read-only query console

On a deep-supported engine, “Query” opens a console that runs only read statements (SELECT / SHOW / EXPLAIN / INFO …). Writes — INSERT/UPDATE/DELETE/DROP/FLUSHALL and the like — are refused, and every query is audited. Use a read-only database account for least privilege.

Per-card actions

Check queues an immediate re-check; Edit reopens the form (engine and machine are fixed after creation); ✕ removes the monitor after confirmation — the database itself is never touched.

Caps how fast agents pull large transfers — agent self-updates and software downloads — so a fleet-wide rollout doesn’t saturate a thin or metered site link. The cap is a per-tenant policy pushed to every agent on its next heartbeat. SentinelOps keeps it so maintenance never knocks a client’s internet offline; the tenant benefit is that a rollout to a small-pipe site stays in the background instead of starving everything else. Changing it needs the tenant.manage permission.

Set the cap — the field

Download cap (KB/s, 0 = unlimited): enter a number and Save cap. The agent enforces it on large downloads only; heartbeats and job polls are never throttled. For reference 1024 ≈ 1 MB/s, 5120 ≈ 5 MB/s, and 256 suits a very thin link. The panel shows the current cap in human terms and when it was last updated.

How it applies

The saved cap is not instant everywhere — each agent picks it up on its next heartbeat, so allow a short delay before a rollout is actually rate-limited.

When to use it

Reach for a cap before pushing an agent update or a large software deployment to a site on a slow or metered connection, then set it back to 0 afterward if you want full speed for normal operation. Without tenant.manage the cap is read-only.

Download once per site: designate a reliable always-on agent as a cache peer and its neighbours on the same LAN pull artifacts from it (hash-verified) instead of each fetching over the internet. SentinelOps keeps it so a rollout to a site with many machines doesn’t multiply its internet usage. For a tenant on a thin or metered link it means one download per site rather than one per machine. Designating a peer needs the tenant.manage permission.

Designate a peer — the field

With tenant.manage, pick a dependable always-on machine (a server is ideal) from the dropdown and click “Make cache peer”. Only eligible machines appear: an agent must report a private LAN IP, which needs the peer-cache-capable agent build — machines without one are listed as ineligible.

How members pull

Each peer serves co-located agents on its /24 subnet. Members download from the peer over the LAN, verify the hash, and fall back to the SentinelOps server automatically if the peer is missing the artifact or is offline.

Site cache peers table

Each peer shows its name, LAN IP, derived /24 subnet, port, online status and member count. Remove takes a machine out of the peer role.

What it covers today

The cache currently backs the agent self-update channel, with the same peer path extending to software deployments. End-to-end verification needs two agents on one LAN.

Gives SentinelOps a secure way into a client network by turning an on-site agent into a site gateway: it tunnels out to the SentinelOps hub and routes into the LAN subnet(s) it advertises. SentinelOps keeps this so an operator can reach devices that have no agent (printers, switches, appliances) behind a customer’s firewall without port-forwarding. It is strictly tenant-scoped — a gateway only ever exposes its own tenant’s subnets.

How a gateway works

You pick an online, non-mobile foothold agent on the client’s network. The agent generates its own keys (the private key never leaves it), installs WireGuard if needed, makes an outbound tunnel to the hub, and advertises the subnet(s) you named. Because the tunnel is outbound it works through NAT/firewalls with nothing to open inbound.

Site gateways table

Each gateway lists its device, overlay IP, the advertised LAN(s), and status: up / bringing up… / error / down. An error row shows the last error (hover for the full text) so you can diagnose a tunnel that won’t come up. The header also shows the hub endpoint the gateways connect to.

Remove & platform support

Remove tears the tunnel down after confirmation; the LAN is no longer reachable through that gateway. Linux gateways are verified; Windows (WireGuard service + NAT) and macOS (wg-quick + pf) are supported and being validated.

One encrypted WireGuard overlay per organization. When enabled, every eligible agent in the tenant joins it and gets a stable overlay IP, so machines on different networks — different offices, home workers, cloud VMs — can reach each other directly by that IP. SentinelOps keeps it so a tenant’s fleet behaves like one flat private network regardless of where each machine physically sits, with keys generated on each agent and traffic hub-relayed so it works through any NAT. Configured per tenant; off by default.

Pick an organization first

The mesh is per tenant. Choose an organization in the header selector; without one the page just asks you to pick a tenant.

Enable / disable

The header toggle turns the mesh on or off for the tenant. Enabling enrolls every eligible (non-mobile, non-pinned) agent — a real network change, so it confirms first; agents join as they check in. Disabling tears every member’s tunnel down. The subheading shows the overlay subnet, how many members are up, and whether it is machines-only or site-to-site.

Site-to-site LAN routing

When enabled, the “Also route each machine’s LAN across the tenant” checkbox controls scope. Off (the default) = machines-only: each machine is reachable by its overlay IP. On = also advertise each member’s LAN subnet across the mesh; a subnet that overlaps another member’s is flagged “LAN conflict” and not advertised, though that machine is still reachable by its overlay IP.

Members table

One row per agent: machine, overlay IP, advertised LAN(s), status (up / bringing up… / error / down, with the last error on hover), and last handshake. Only non-mobile agents join, and any device you’ve pinned (no-auto-update) is skipped since bringing up a tunnel is a real change.

A single on/off litigation-hold switch for the whole tenant that freezes destructive management actions so records are preserved. Why it is here: when a matter requires preservation, retention and clean-up must stop immediately and provably across the organization. Tenant benefit: while active, SentinelOps refuses to decommission devices, delete records or prune storage for that customer, so evidence cannot be quietly removed — and it is a management-plane lockdown only, so it never locks users out of their machines. (For case-by-case preservation with matters, holds, custodians and evidence, use Litigation Holds.)

Place a hold

Enter a required Reason (a case number / matter reference) and Place hold — confirmed first, and audited with who placed it and when. The summary then reads ACTIVE.

While a hold is active

Destructive management actions on this tenant’s devices — decommission, record deletion, storage pruning — are refused; removing a protected device is blocked until the hold lifts. Normal management and user activity continue.

Release hold

Release (confirmed first) lifts the lockdown and allows destructive management actions again. The release is audited.

Case-by-case evidence preservation: a Matter owns one or more preservation Holds, each Hold covers Resources (devices, mailboxes, users) and Custodians, and preservation is reference-counted so a resource stays preserved until the last hold covering it is released. Why it is here: real legal matters need scoped, custodian-aware preservation and a defensible chain of custody, not just a blanket freeze. Tenant benefit: a customer’s devices under an active hold are exempt from retention and cannot be decommissioned, and collected evidence is hashed and logged end to end. (For a simple whole-tenant freeze, use Legal Hold.)

Dashboard & matters list

The KPIs count Active matters, Active holds, Devices on hold, Evidence items and Pending overrides. The Matters table shows Ref, Name, Status, Type, Jurisdiction and Created — click a matter to manage it. Creating a matter needs legal.matter.manage.

New matter

Capture the Matter name, Type, Priority (Normal / High / Critical), Tenant (when managing several), Jurisdiction and Description. Every action on the matter is written to its own append-only trail.

Preservation holds

Inside a matter, create holds (legal.hold.manage), Activate or Release them, and add devices/resources to an active hold. While a resource is covered it is exempt from retention and cannot be decommissioned — removing such a device is blocked until the last hold lifts.

Custodians

Add the people responsible for the preserved data (legal.custodian.manage), each with name, email, department and job title, so the matter records who holds what.

Evidence & chain of custody

With legal.evidence.collect, “Collect evidence” snapshots endpoint activity and device inventory for every device under an active hold into sealed, hash-verified evidence (SHA-256). Each item shows an integrity-ok / INTEGRITY FAIL pill. Viewing evidence needs legal.evidence.view.

Timeline

With legal.audit.read, the matter shows a timeline of every action (what, who, when, result) so the chain of custody is auditable from open to release.

The attributable record of operator and agent activity — who connected, who ran what, files transferred, settings changed, and the result. Why it is here: auditability is a first-class goal, so every privileged action is recorded and tamper-evident (the underlying log is SHA-256 hash-chained; verify it under Data & Audit). Tenant benefit: it gives a customer and their provider a defensible, searchable history of everything done to their estate.

Filter

A single search box narrows the list by action, actor, device id, source IP or result; the header shows “X of Y events”. The newest events are shown first. Clear the box to see everything again.

Reading an event

Each row shows the action and timestamp, then the actor and — where relevant — the device id, source IP, and a red result when the action did not succeed.

Exporting as evidence

This view is read-and-filter only (there is no export button on this page). To export the trail as evidence, use Reporting (the “Audit export”, which needs the audit permission) or the tenant/system export under Data & Audit. The chain-integrity check also lives under Data & Audit.

Generate reports from live fleet, activity and audit data, save them as reusable templates, schedule them and review past runs. Why it is here: customers and internal reviews need point-in-time exports built from what you can already see, scoped to the right tenant. Tenant benefit: every report is scoped to the tenant in context, so you hand a customer defensible figures (inventory, health, audit evidence) without hand-assembling them.

Generate a report

Pick a Report type and a Format (CSV or JSON). “Preview” renders it inline with a row count; “Download” saves the file; “Save as template” keeps the configuration for reuse. Reports are built from data you can already see, scoped to your tenant.

Report templates

Saved report definitions. The table shows Name, Report type, Format, Schedule and Last run. “Run” generates a run now; a template with a daily or weekly schedule generates runs automatically. Delete removes the template (its run history is kept).

Scheduling

When saving a template, type daily or weekly to schedule it, or leave it blank for on-demand only. Scheduled templates produce runs without anyone pressing a button.

Run history

The recent runs (Report, Format, Rows, By, When) so you can see what was generated, by whom and when. Exporting the audit trail specifically needs the audit permission.

Assembles per-customer business reviews from real managed-device, patch, security, network and Microsoft 365 data, with honest scoring that never dresses up gaps as compliance. Why it is here: a quarterly/periodic review is how an MSP shows value and plans work, and it must be defensible rather than optimistic. Tenant benefit: it gives a customer a health score and narrative built only from devices SentinelOps actually manages, with offline/unassessed devices shown as coverage gaps — so “no issues” is never confused with “no data”.

Create a review

Pick a customer in the tenant selector (required), then “Create QBR”, choose a period (recent quarters) and a report type (Standard, Executive, Technical, Security or vCIO). It is created empty; generate it to assemble the data.

Honest scoring

Only devices SentinelOps actually manages are included, and offline or unassessed devices are shown as coverage gaps — never counted as compliant. Each metric carries a freshness/coverage chip (current / delayed / stale / no data / not configured), and when some sources are not connected the confidence is marked provisional rather than shown as “Excellent”.

Open a report

The list shows each review’s Period, report type, Status, overall health (score + band) and when it was Generated. Click a row to open the full report; regenerate it to pull current numbers.

Status lifecycle

Reviews carry a status (draft through published/presented, or cancelled). Use the list to track which periods are done and which still need generating and presenting. Creating and managing reviews needs qbr.manage.

A compliance log of recorded remote sessions. Why it is here: a recorded remote session is sensitive, so SentinelOps keeps the audit trail of who recorded what — but the video itself lives on the operator’s machine or your configured cloud, never on this server. Tenant benefit: a customer gets a defensible record of every recorded session on their devices without the footage ever being centralised where it could leak.

What the log shows

Each row lists the device, operator, start time, length, file size and where the media is stored (“operator machine” or an “in cloud” link). A session still in progress shows a “recording…” pill. The log is scoped to the organization in context.

Where the video lives

The recording is saved to the operator’s machine or your cloud, so this server holds only the metadata. If a cloud URL is present you can open the media from the Location column.

Start a recording

Recordings are begun with the ⏺ Record control on a live remote session — there is no start button here. This view is purely for reviewing the resulting log.

Deleting a log entry

The ✕ removes only this audit record; it does not touch the actual video file on the operator machine or in the cloud. You are asked to confirm because it deletes the compliance trace, not the footage.

Where devices physically live inside an organization: sites (offices/locations) and the networks (subnets/VLANs) within them. Why it is here: location structure drives the Site Dashboard roll-up and powers per-network automation like auto-deploy, auto-join and network pivot. Tenant benefit: it lets you model a customer’s real estate and then have new machines on a given subnet enrol, domain-join and spread reach on their own — all placement is optional, so a device with no site still works.

Site cards

Each site shows its name, location, the owning organization (when viewing all tenants) and its device count, with a table of its networks (Network, CIDR, VLAN, Devices). A network with auto-deploy credentials assigned carries an “auto-deploy” badge. Edit or Delete a site (deleting removes its networks and unassigns devices).

Add site

Enter a Name (e.g. “HQ — Dallas”) and a Location. When no tenant is selected in the top bar you also pick the Organization. Click Add site; then use “Add network” on the card to add subnets.

Auto-install agent on this network

Tick one or more installable (Linux/Windows/macOS) deployment credentials and an on-segment agent that scans this network will automatically log into unmanaged machines it finds and install the agent — once per host, matched to the credential’s target type, every install audited. Leave all unchecked to keep deployment manual. The section is hidden if you lack credential.manage. (Credentials are added under Discovery → Deployment credentials.)

Auto-join Windows workstations

After the agent enrols on a Windows workstation here, join it automatically (servers are never auto-joined; each join runs once and is audited). Join to Active Directory needs a Domain + optional OU + a domain-join credential. Join to Entra ID / Microsoft 365 needs an uploaded provisioning package (.ppkg from the Entra admin center; upload it inline).

Auto-pivot: reach networks behind this one

Tick “Scan a device’s segment when it enrols here” so reach spreads hop by hop — a VM here finds its hypervisor host, and once that host enrols it finds the LAN behind it. Discovered machines auto-enrol only where a credential is assigned above; otherwise they appear in Discovery to deploy by hand. A new segment is only scanned once you opt it in here.

Optional, sandboxed extensions that add third-party capability to the console without changing the core product: console panels, integrations (outbound event webhooks), automation packs and agent helpers. Why it is here: it lets you wire SentinelOps to your own tools (chat, SIEM, ticketing) safely — a plugin runs in a sandbox and cannot reach the console’s credentials or act outside its own panel. Tenant benefit: you can extend what operators see and where alerts flow without trusting arbitrary code with your data.

Install plugin

Click Install plugin and paste the plugin’s manifest (JSON). It installs disabled so you can review its requested permissions first, then Enable it. For an integration, a one-time signing secret is shown on install — save it; your receiver verifies the X-SentinelOps-Signature header with it. See docs/PLUGINS.md for the SDK and examples.

Reading a plugin card

Each card shows the name, an enabled/disabled pill, the type (Console panel / Integration / Automation pack / Agent helper), version, vendor and id, the description, and the exact permissions it requested. Integrations also show their subscribed events → webhook URL; console panels show their panel URL.

Per-plugin actions

“Open panel” (enabled console plugins) renders the plugin in a sandboxed iframe — allow-scripts and allow-forms only, no same-origin, so it cannot read the console’s session or storage. “Send test” (integrations) delivers a test event to confirm the webhook works. Enable/Disable toggles it live. Remove uninstalls it and deletes its configuration (confirmed first).

Sandbox guarantees

A console plugin is iframed with no allow-same-origin and referrerpolicy=no-referrer, and every plugin is confined to the permissions in its manifest — it cannot reach the console’s credentials or act outside its own panel.

The health of SentinelOps’ OWN services — not the managed fleet. It shows the API, the database (with a live probe), the event stream / message queue, the alert engine, the background workers, high availability and email, plus a database detail card. Use it to confirm the platform itself is healthy and, on a multi-node deployment, that each node is doing its job.

Service list

Each row is one internal service with a colour dot: green = OK, amber = Degraded, red = Down, grey = N/A (not applicable, e.g. HA on a single node). A standby honestly shows its Alert engine and Background workers as “Deferred” — they only run on the primary, so this is expected, not a fault.

Database card

Backend (file = single node, or the SQL engine), live connection health, the connection pool (open / in use / idle / max), the event fan-out mode, and the self-heal probe settings. On PostgreSQL the fan-out is push-based (LISTEN/NOTIFY); on a single file node it is in-process only.

Email / alert delivery

Shows whether SMTP is configured. This matters because the HA and database self-heal alerts are delivered through it — if it reads “Not configured”, self-heal events will only appear in the console, not your inbox. Configure it under Settings → SMTP.

SentinelOps’ OWN Microsoft 365 estate — the MSP’s internal tenant — imported and kept in one place: directory ID, licence key, users, groups, licences, Secure Score, service health and devices. Why it is here: the provider needs to run and bill its own 365 the same way it does customers, without mixing it into any tenant view. This is engineer-only, and it powers the internal bill and the service-connection toggles. (This is the provider’s own estate; a customer’s 365 lives in their portal’s Microsoft 365 tab.)

Sync now / Re-sync

Imports the estate into SentinelOps and persists it, so every panel works off stored data. With a live Entra app configured it pulls real Graph values (users, groups, licences, Secure Score, service health, devices); otherwise it imports a clearly-labelled example estate you can replace later without the dashboard changing.

Directory ID & licence key

Once synced, the Directory (tenant) ID and Subscription licence key are shown with Copy buttons.

Connect a live Entra app

To replace example data with real values, configure the app’s client_id, directory (tenant) id and secret via the 365 Graph settings (the same app registration used for Azure works — the Graph scope is requested per token). Once configured, Sync pulls live values.

Microsoft services

A per-service table (Exchange, Teams, SharePoint, Intune, …) with a Connect/Disconnect toggle each, plus Connect all / Disconnect all. The header shows how many of the services are connected.

Bill & menu visibility

The internal bill panel renders from the synced estate. "Menu visibility" jumps to Settings to show or hide this engineer-only menu; it does not affect client-facing tenant views.

Server-wide configuration, stored in the database so an upgrade never loses it. Global-administrator only. Each panel has its own Save button — you can change one panel and save it without touching the others, and changes apply live with no restart unless a field says otherwise. Secrets (passwords, tokens, signing keys) are sealed in the vault: a saved secret shows as “· set” and the field stays blank; leave it blank to keep the existing value, or type a new one to replace it.

Email (SMTP) — what it is

The outbound mail relay SentinelOps uses for welcome emails to new operators and for every alert/notification email (auto-block alerts, incident digests, self-heal reports, scheduled reports). Until this is configured, nothing is emailed — alerts appear only in the console. The green “configured” pill means a host is saved.

Email (SMTP) — the fields

Host: your mail server hostname (e.g. smtp.example.com or mail.example.com). Port: 587 for STARTTLS (typical), 465 for implicit TLS, 25 unauthenticated. Username: the SMTP login, or blank for an unauthenticated relay. From address: the address alerts are sent as (e.g. ops@example.com) — make sure your relay is allowed to send as it. Password: the SMTP auth password (sealed; blank keeps the current one). Alert recipient emails: one address per line — these get EVERY alert email, on top of any operator who turned on their own email alerts in their profile.

Email (SMTP) — how to set it up

1) Fill Host and Port. 2) Add Username + Password if your relay requires auth. 3) Set the From address to something your relay will accept. 4) Add at least one Alert recipient. 5) Click “Save email settings”. 6) In the “Verify delivery” box below, type any address and click “Send test email” — a success line confirms the relay works; an error tells you exactly what failed (auth, TLS, connection). Always save before testing.

SMS gateway — what it is and how to set it

Sends 2FA codes and SMS alert notifications through an HTTP webhook (your own gateway or a provider). Webhook URL: the endpoint SentinelOps POSTs the message to (e.g. https://sms-gateway/send). Authorization header: the full header value your gateway expects, e.g. “Bearer abc123” (sealed; blank keeps it). How to: paste the URL, paste the Authorization header, click “Save SMS settings”. Leave both blank to disable SMS entirely.

Alert webhook — what it is and how to set it

A signed outbound webhook that POSTs a JSON event to your system (SIEM, chat, ticketing) for every alert. URL: your receiver (e.g. https://receiver/hook). Signing secret: a shared secret of at least 32 characters — SentinelOps signs each payload with it so your receiver can verify the call really came from SentinelOps (sealed; blank keeps it). How to: paste the URL, paste a ≥32-char secret, click “Save webhook”. Verify the signature on your side using that same secret.

SCIM provisioning — what it is and how to set it

Lets an identity provider (Okta, Entra ID, etc.) create, update and deactivate operator accounts and groups automatically via SCIM 2.0. Issuer: the IdP issuer URL. Tenant ID: the SentinelOps tenant these provisioned users belong to (ten_…). Group→role map (JSON): maps IdP group names to SentinelOps roles, e.g. {"Admins":"admin","Helpdesk":"helpdesk"}. Bearer token: the ≥32-char token your IdP presents on each SCIM call (sealed). How to: fill all four, click “Save SCIM”. Point your IdP’s SCIM connector at /scim/v2 on this server using that bearer token. The pill shows “active” once provisioning traffic is seen.

General — Public URL

The canonical address of this console (e.g. https://console.example.com). Used to build links in emails and enrollment one-liners, and as an allowed origin. Set it to the exact scheme+host+port users and agents reach — a wrong value breaks email links and some cross-origin calls. Save with “Save general”.

General — Session length

How many hours an operator sign-in stays valid before re-authentication (1–24, default 8). Lower it for tighter security on shared machines; raise it for convenience. Takes effect for sessions created after the change.

General — Self-enrollment token uses / lifetime

The budget baked into a cloud-VM auto-provision and the port-knock install one-liner. Uses (1–10000, default 5): how many times one enrollment token may be redeemed — one real enrollment needs a few (download + enroll + retries), so 5 covers a single machine; raise it for a fleet rollout from one link. Lifetime (seconds, 60–86400, default 3600): how long the token is valid after it is minted. Tighten both to lock enrollment down; loosen for a big rollout.

General — Extra console origins

Additional browser origins allowed to call the API cross-origin (comma separated, e.g. https://alt.example.com). Add an entry only if you serve the console from more than one hostname; otherwise leave blank. Save with “Save general”.

Profile & service backups — sizes and retention

Defaults applied to NEW endpoint-capture backups (Windows user profiles, Linux/BSD service configs). Max archive size (MB, 0 = default 20 GB): caps one archive; a capture that would exceed it fails rather than fill the disk. Archive retention (hours, 0 = default 168 = 7 days): how long finished archives are kept before automatic cleanup. Default download format: tar.gz / tar / zip for the download button.

Profile & service backups — capture behaviour

Four defaults for new captures (each can be overridden per capture): “Skip caches” omits Temp, browser caches and cloud placeholders (keeps archives small); “Use a VSS snapshot” captures in-use Windows files like registry hives (recommended on Windows); “Allow live fallback” lets a capture proceed without a snapshot when VSS is unavailable (files a user holds open may be missed); “Require a second approver” forces a scoped operator’s capture to be approved by another operator (engineers/administrators are always exempt). Cache-exclude directories: profile-relative folders to skip (one per line; blank = built-ins).

Profile & service backups — include/exclude paths

These apply only to captures that do NOT use a Backup selection. Always include: absolute paths added to every such capture (Windows e.g. C:\ProgramData\MyApp, or Linux /opt/app/config). Always exclude: absolute paths removed from every such capture (e.g. /var/cache, C:\Temp). WHAT a selection-based backup captures is chosen in Backups → Backup selections (per tenant/group/device); this panel only sets the no-selection defaults. Save with “Save backup settings”.

Features — optional console areas

Toggles that show or hide whole areas for everyone. “Microsoft 365 (SentinelOps)” shows the engineer-only internal 365 estate menu. “Self-service enrollment port-knock” lets a new agent on an unknown IP present its deployment token to auto-open the firewall and enroll (the pill shows whether the listener is actually running). “Require operator approval for new enrollments” holds every newly enrolled device (alerts/patching/automation paused) until approved under Enrollment Approvals — a tenant can override this on its own record. “Self-service download portal (/download)” gives any firewall-allowed browser an OS-detecting page to install/update its own agent (those enrollments join the default tenant). Tick what you want, click “Save features”; hidden areas disappear from the nav.

Port-Knock & Sequence

Defense-in-depth: require a secret port-knock sequence AND the token before enrollment. Enforce the port sequence: when ticked, a client must knock the sequence before its token is accepted — this applies live. Secret sequence ports: the ports to knock, in order, comma-separated (changing them takes effect on the NEXT restart, and you must open them in the host firewall). Knock listener port + Knock public URL: where the knock service listens and how clients reach it (restart to apply). If no sequence is active yet, set the ports first, open them in the firewall, then enable enforcement. Save with “Save knock config”.

Application & Service Health card

Controls the dashboard’s system-health grid. Systems shown (max charts): how many machines to chart at once (e.g. 8). Trend metric: which metric the sparklines track. High-resource thresholds: the CPU/memory/disk percentages above which a machine is flagged. Auto high-risk services: service names (comma/newline separated) that, when running, auto-rate a machine high-risk so it is watched and charted first. Save with “Save system-health settings”.

Engineer-only limits and cadences that keep the server fast as the fleet and its history grow. Every numeric field is optional: leave it blank (or 0) to use the environment variable or built-in default — the grey note under each field shows what is in force right now. One “Save operations settings” button saves the whole page, and changes apply live with no restart. To reset a field to its default, blank it out and save. Bootstrap/security-root settings (state path, listen address, TLS files, credential & session keys, admin/enrollment tokens, database URL) are deliberately NOT here — the server needs them to boot and they are the security root, so they stay environment-only.

State & job history — Max retained finished jobs

Caps how many completed jobs are kept in state so state.json cannot balloon and slow the global lock (the amplifier behind past operations lock-ups). Blank = the default, which scales with RAM (~250 per GB, clamped 500–5000). Lower it on a small box with a busy fleet; the grey note shows the value in force now.

State & job history — Log/job retention (hours)

Finished jobs and their logs older than this are pruned even if the count is under the cap. Blank/0 = keep by count only. Set e.g. 168 (7 days) to stop very old logs accumulating — truncating old logs is what keeps operations fast on a long-lived server.

State & job history — Stale job reap (hours)

A job still queued or running after this many hours is force-marked failed so it stops blocking its device (a device won’t take a new job while one is “running”). Default is conservative; lower it if stuck jobs are wedging devices, raise it if you legitimately run very long jobs.

Record retention — the four ages

An hourly sweep deletes finished records older than these ages. Closed alert incidents (days, default 30): acknowledged/resolved incidents. Finished records (days, default 90): ended remote sessions, finished patch/software deployments, join attempts, remote operations, remediation attempts. File-transfer grace (hours, default 24): a transfer and its stored file are removed this long after it expires. Access-session log (days, default 365): the “who connected when” audit of access sessions. Never removed regardless: open incidents, live sessions, and anything in a tenant/device/transfer under a legal or preservation hold. The main audit log and endpoint-activity evidence are not affected by this panel at all.

Fleet self-heal safety — Automatic agent updates

The master kill-switch for the fleet auto-updating itself. Leave it CHECKED for normal operation. UNCHECK it during an incident or right after shipping a build you’re unsure of — agents then stay on their current version until you re-check it. This is the first thing to toggle if a rollout misbehaves.

Fleet self-heal safety — the caps

Auto-update batch (per 10-min tick, default 25): the most agents queued to update each tick; the rest follow on later ticks, so an update rolls out in staggered waves instead of all at once. Peer-watchdog restarts per sweep (default 20): the most remote agent-restarts one watchdog sweep will issue per tenant — a circuit-breaker so a flapping condition can’t restart the whole fleet in a loop. Raise for large fleets, lower to be more cautious.

Background-loop cadences

How often the housekeeping loops run, in seconds. Longer = lighter server load; shorter = faster reaction. Alert reconcile (default 240, min 60): the auto-resolve sweep. Alert stale-expiry (default 86400, min 600): auto-close a one-off alert on a now-healthy device after this long. Patch rescan interval (default 180, min 60): how often flagged devices are re-scanned for patches. Auto-patch policy interval (default 3600, min 60): the auto-patch deadline sweep. Leave them blank unless you have a specific reason — the defaults are tuned.

Authentication limiter

Auth failures before block (default 30, range 1–10000): how many failed sign-ins from a single IP are tolerated before that IP is temporarily blocked. Applies live. Lower it to harden against brute force; raise it if a shared NAT’d office is tripping it. Known-good admin IPs should go in Settings → Trusted IPs so they’re never limited at all.

Remote live view — target FPS

Live screen target FPS while watching (default 15, max 30): the capture rate used ONLY while an operator is actively watching a screen; it drops to ~1 fps when nobody is, to save the endpoint. Higher = smoother but more endpoint CPU and bandwidth (matters most over a WAN) — dial it down for slow links. This applies fully to Windows (in-process capture); Linux and macOS are always capped at ~8 fps because they spawn a capture process per frame and higher rates bog the machine down.

Remote live view — Capture method

How frames are grabbed on Linux/macOS (Windows always captures in-process, so this is a no-op there). Downscale (default): resize each frame to the target width — smallest and fastest over a WAN. Downscale + cursor: same, but also draws the remote mouse pointer so your mouse moves are visible (the agent installs ffmpeg/maim if needed). Full resolution: the sharpest, legacy full-size grab — the heaviest to capture and upload. Applies on the next frame.

Fleet lifecycle — Auto-decommission

Auto-decommission offline systems after (days): a system with no heartbeat for longer than this is automatically labelled Decommissioned, so a long-dead box stops raising alerts and skewing counts. Blank/0 = off. Removal-protected devices (pinned servers/DCs) are never auto-decommissioned, and a system that heartbeats again auto-revives, so this is safe to enable.

Fleet lifecycle — Reconcile re-added machines

When CHECKED (default), a machine re-added under a new agent is matched to its previously-decommissioned record (by system UUID or hardware MAC, within the same tenant), reuses its old name, and the duplicate is removed instead of creating a second entry — so reinstalling an agent doesn’t clutter the fleet with twins. Uncheck only if you deliberately want every re-enrollment to be a brand-new record.

How SentinelOps sends text messages — operator two-factor sign-in codes and SMS alert notifications. Why it is here: SMS is a fallback channel that reaches an operator when email or the console cannot, so it is configured once, centrally. Pick one provider; every secret is sealed at rest and never shown again. Tenant benefit (platform-wide): operators who protect their account with SMS 2FA, or who want to be paged on alerts, get those texts through whichever gateway you configure here.

Status

A live readiness panel: Configured / Not configured, the effective provider, the gateway device (with online/offline) when you use a device-based gateway, and how many operators have SMS alerts enabled. Below it, a recent-sends log (When, To, Provider, Result) with per-row Delete and a “Clear log” button — deleting a still-queued message also cancels its send.

Provider & its fields

Choose one SMS provider (or “disabled — no SMS”). The form then shows just that provider’s fields with a setup/requirements guide: webhook (Webhook URL receiving POST {to,text}, optional sealed Authorization header), Twilio (Account SID + sealed Auth Token), Vonage (API key + sealed secret), AWS SNS (region, access key ID + sealed secret), or a self-hosted gateway device (pick an enrolled Android → SmsManager, or Linux+modem → gammu). A “From number / sender ID” is used where the provider needs one. A saved secret shows a “saved — leave blank to keep” placeholder.

Save & Send test

Save gateway stores the configuration (secrets sealed). Enter a destination number and Send test to confirm delivery before relying on it for sign-in codes; the attempt then appears in the Status log’s recent activity.

Where SMS is used

Two-factor sign-in (operators who enroll SMS 2FA get their login codes here) and alert notifications (operators with an SMS alert preference and a phone number on file are texted when alerts fire). Set an operator’s phone number under Users → the operator → Basic details, and enable SMS under their 2FA / alert preferences.

Run the SentinelOps console from a phone or tablet, install the native operator apps, or enrol a handset as a managed device — all from one page. It exists so an operator can triage the fleet from anywhere and so a phone or tablet can be brought under management the same way a laptop is. For the tenant it is both the on-the-go operator experience and the path to enrolling Android handsets as endpoints.

Install the console (PWA)

The console is a progressive web app that installs to a home screen and caches only its shell, never fleet data. On a supported browser an Install button appears; on iPhone/iPad, Safari has no install button, so use Share → Add to Home Screen. Installing requires HTTPS — reach the console over its public URL, not a plain-HTTP address. Dashboard, devices, alerts, monitoring and audit reflow to one column; remote screen control works but is meant for a tablet or desktop.

Enrol a phone or tablet

Create enrolment code (needs enrollment.manage) generates a QR good for a batch of devices for a limited time. Scan it from the Android app (More → Manage this device → Scan enrolment QR) to enrol the handset and start its agent in one step — or type the shown enrolment link by hand if it cannot scan. Android only: iOS permits no management agent, so an iPhone or iPad runs the console app rather than being managed by it.

Native operator apps

Android (Kotlin / Jetpack Compose) and iOS (SwiftUI) operator apps, read-only by design — fleet health, devices and alerts only; scripts, remote sessions and file transfers stay in the full console where a confirmation step and a full-size screen exist. The operator token is held in the Android Keystore / iOS Keychain, excluded from backups. Android is sideloaded (Download APK, enable "Install unknown apps" for your browser); iOS comes from the App Store for this deployment where configured, otherwise install the console from Safari.

Managing phones as endpoints

Separate from the operator app: Android endpoints (a foreground service with scoped storage and per-session screen-capture consent) are planned but not implemented yet, and iPhone/iPad endpoints are not possible — iOS forbids background daemons and process execution, so managing them means Apple MDM, a separate protocol rather than this agent.

The customer-facing portal: a read-only overview of what your provider manages for you and your Microsoft 365 estate. Why it is here: a managed customer should be able to see their own posture at a glance without being able to change it. What it does for you (the tenant): it shows your managed devices and your Microsoft 365 summary as last synced — everything is read-only, so to change anything you contact your provider.

Tabs

Three tabs: Overview (this page), Managed devices, and Microsoft 365 / Services. The header names your organization and primary domain.

Overview KPIs

Managed Devices (with the servers / workstations split), Online Now (and how many are offline), Microsoft 365 Users (with licences assigned of total), and your Secure Score from Microsoft when 365 is connected.

Example data notice

On the shipped demo organization the Microsoft 365 section is populated with clearly-labelled sample data to show the layout; a real organization with no 365 connected shows an empty, clearly-not-connected section rather than anyone else’s data.

The Managed devices tab of your portal: every machine your provider manages for you, grouped by what it is, with its current state and compliance. Why it is here: as a customer you can confirm your estate is covered and online. What it does for you (the tenant): a read-only, plain-language inventory — to make changes, your provider does it for you.

Grouped by kind

Devices are grouped the way you think about them — Servers, Workstations, Mobile devices, Network devices and Other managed devices — with a count on each group. Servers and workstations are shown first.

Each device

Shows the device name (and hostname if different), operating system and version, an online/offline status pill, a compliance pill (compliant / not compliant / not assessed), and when it was last seen.

Read-only

This is a view of your estate. Changes are made by your provider — contact them to enrol, retire or reconfigure a device.

The Microsoft 365 tab of your portal: your 365 estate as SentinelOps last synced it — subscriptions and seat usage, users, groups, access policies and registered devices. Why it is here: it puts your licence position and directory in front of you without a trip to the Microsoft admin center. What it does for you (the tenant): a read-only picture of your 365 tenant, with anything your Microsoft consent did not cover clearly marked rather than shown as empty.

Licences

Each subscription/SKU with seats Assigned, Total and Available, so you can see where you are over- or under-provisioned.

Users, Groups, Access policies, Entra devices

Users (name, sign-in name, enabled/disabled, licensed), Groups and teams (name, mail, whether it’s a Team), conditional-access policies (name, on / off / report-only, last updated) and Entra-registered devices (name, OS, compliant, last sign-in).

Service health

The current health of your Microsoft 365 services, when reported.

"Not shared"

A section marked "not shared" needs the matching Microsoft consent before SentinelOps can read it — it is named explicitly so an un-consented dataset is never mistaken for an empty tenant.

Your own account security: your sign-in password and your second factor. Why it is here: protecting your own login is something only you can do, so the portal gives you a self-service place to do it. What it does for you (the tenant): you can turn on two-factor authentication and change your password yourself — your organization may require 2FA.

Two-factor authentication

Shows whether a second factor is registered on your account. "Set up two-factor" starts an authenticator (TOTP) enrolment; "Turn off" removes it. Strongly recommended, and your organization may require it.

Password

If you sign in with a password, "Change password" lets you change it. If your account is managed by an identity provider (SSO), the page says so and the password is managed there instead.

Install the SentinelOps app on your phone or tablet, then sign in by scanning a code — no password typed on the device. Why it is here: the app gives you the same view of your managed estate and Microsoft 365 on the go, and code sign-in keeps your credentials off the handset. What it does for you (the tenant): a quick, secure way onto your own portal from a phone or tablet.

1 · Install — Android

If a Google Play link is published for your deployment, use "Get it on Google Play"; otherwise download the app directly and open it to install. Android asks permission the first time — when it says your browser isn’t allowed to install apps, open Settings, turn on "Allow from this source", then tap the download again. The app is signed by us, so Play Protect may ask you to confirm; that’s expected for an app installed outside the Play Store.

1 · Install — iPhone / iPad

If an App Store (or Mac App Store) link is published you can install it there. If the iOS app isn’t published on your deployment you cannot install it yourself — your IT provider installs it on a managed device, so ask them. Meanwhile you can add this page to your home screen (Safari → Share → Add to Home Screen) and it opens full-screen like an app.

2 · Sign in

Click "Show my code" to generate a sign-in code and scan it with the app. The code lasts 15 minutes and replaces any earlier one. Signing in shows you the same view you see here — what your provider manages for you and your Microsoft 365 details.

Shows who is currently signed in to the selected organization and lets you force an account off. Console sessions are stateless signed cookies rather than a server-side session table, so this lists the accounts that have been active in the recent window instead of individual sessions. It exists so an administrator can see live operator presence and immediately revoke access for a departing or compromised account — for the tenant it is the fast kill-switch when a login must be cut off now. Pick a tenant first.

Read the table

Each row is an account active in the last N minutes (the window is stated in the summary line): User (full name and username), Role, 2FA (an "on" pill, or a "none" warning pill where the account has no second factor), State (signed in vs idle) and Last activity. The bold count at the top is how many are signed in right now.

Sign out

The per-row Sign out button (shown only with manage permission) invalidates every session for that account immediately — the next request from any of its devices is rejected and the user must sign in again. You confirm first. Use it the moment an operator leaves or an account looks compromised.

Why no session list

Because sessions are stateless signed cookies there is no per-device session to revoke individually — signing an account out rotates what makes its cookies valid, so all of them stop at once. That is by design and keeps sign-out instant and complete rather than partial.

Controls which source addresses may reach the admin console and API, so management access is locked to the places you trust even as those addresses change. Why it is here: the management plane is the keys to every tenant, so it is gated to known admins and known IPs rather than left open. Tenant benefit: it keeps the platform that manages customers reachable only from trusted locations, while making sure a legitimate admin on a changing home IP is never locked out.

Dynamic hostnames (recommended)

Register an admin’s dynamic-DNS name (e.g. admin-home.dyndns.net). Its live IP is re-resolved every minute and kept allowed automatically — it follows the admin’s ISP changes, never expires, and that IP is also exempt from auto-block, abuse reports and auth alerts. Add a hostname with the field; Remove drops it (if an admin’s current access came only from that name, they lose it until they re-knock or it is re-added). Best for an admin with a stable dyndns name.

Authorized admin IPs (port-knock)

An admin authorizes their current IP by knocking with their operator token — the console and mobile app do this automatically. The table lists each IP with the admin, the source, when it was last seen, and when it auto-revokes (after the server’s configured idle period; a pinned entry never expires). To get back in from a new IP, just knock again — no help desk needed.

Revoke

Use Revoke on a port-knock IP to cut its management access immediately; the admin can re-authorize by knocking from that IP again. Pinned entries show as “pinned” and have no revoke button.

Never lock yourself out

The operator’s own home address is exempt everywhere and is never blocked. Review the list before tightening it, and keep at least one durable allow entry (a dynamic hostname) so you always have a way in.

The Users list filtered to administrator accounts — the people who can change this organization. It is the same Users screen with a role filter applied, provided as a shortcut so you can review and manage privileged accounts without scanning the whole directory. For the tenant it answers "who holds the keys here" at a glance and lets you act on those accounts in place.

Same view as Users

Everything here is the Users screen with a role filter applied — the table, the Create user button and every per-account action (reset password, reset 2FA, edit permissions, disable, delete) behave identically. Only the rows shown are narrowed to administrator-type roles.

Why review this list

Administrators can change tenants, users and fleet configuration, so this is the list to keep short and current — remove accounts that no longer need that reach, and confirm each one has a second factor (the 2FA column) before relying on it.

Connects the in-console AI assistant to an Anthropic provider so it can answer questions and help you work inside SentinelOps. It exists so operators get grounded, in-context help without leaving the console or pasting fleet data into an outside chat tool. For the tenant it is an opt-in org add-on: the assistant is scoped to this organization, the API key is sealed in the credential vault and never shown again after you save it, and configuring it requires the ai.manage permission.

Enable the add-on

The assistant runs as an org add-on. If it is off, the panel shows a notice; an operator with operator.manage can click Enable AI add-on, otherwise ask an administrator to turn it on. Nothing below works until the add-on is enabled.

Get and paste a key — field by field

Create a key at console.anthropic.com → API Keys, then fill the form: API key (the secret you paste — it is sealed on save and the field then shows only that a key is set); Model (e.g. claude-sonnet-5 — the exact model name the assistant calls); and optionally an API base URL (default https://api.anthropic.com, change it only for a proxy or gateway). Click Save to store them.

Test the connection

After a key is stored, Test connection sends a tiny prompt and shows the model’s reply (or the exact error). Use it to confirm the key, model name and base URL are all valid before relying on the assistant — a wrong model name or an expired key surfaces here rather than mid-conversation.

Rotate or remove the key

To change the key, type a new one and Save (leave the key field blank to keep the existing one while editing the model or base URL). Remove key clears the stored secret — the assistant stops working until a new key is set.

The sign-in policy for this organization: passwords, two-factor, SSO, session length and account lockout. SentinelOps gives each tenant its own policy — stricter than the platform baseline but never looser — so a customer with tighter requirements can enforce them while the platform floor protects everyone. For the tenant it is the single screen that decides how hard it is to get into their console and mobile app, and what happens when someone fails.

Sign-in toggles — field by field

Checkboxes set the policy: Password sign-in enabled; Require two-factor for every user; SSO enabled; SSO required; Keep local emergency sign-in (so a provider outage cannot lock everyone out); Mobile app allowed; and Require two-factor on mobile. Any control the platform has pinned shows a "platform policy" badge and is read-only here — the server refuses to loosen it.

Sessions and lockout — field by field

Session timeout (minutes) ends an idle session — it cannot exceed the platform maximum shown beside it. Maximum failed sign-ins and Lockout (minutes) are enforced per account (not just per source IP), so a targeted account locks even from many addresses. A platform maximum is displayed where one applies.

Allowed second factors

Tick which methods accounts may register — totp, sms, webauthn. A method the platform baseline excludes is disabled here. Save policy writes the whole set; without manage rights the panel is read-only and says so.

Why stricter-not-looser

The platform baseline is the floor. A tenant can demand more (require 2FA, require SSO, shorter sessions) but every attempt to go below the baseline is both greyed out in the form and rejected by the server, so a customer policy can never weaken the platform’s guarantees.

What this is: rules that automatically run an approved fix script when a specific alert fires, bounded by attempt ceilings, cooldowns and escalation. Why SentinelOps has it: the same alert (a stopped service, an offline box) often has the same known fix, and a person doing it by hand at 3am is slower and more error-prone — but an unbounded auto-fix could loop forever, so every rule is fenced. What it does for the tenant: faster recovery of common faults with hard guardrails, and a guarantee that a problem it cannot fix still reaches a human. Needs remediation.manage to edit.

Only approved scripts run

A remediation rule can only execute a script that has been approved in Automation → Review. Unapproved templates are shown but will not run unattended — approve the script first.

Create a rule — the fields

With remediation.manage, "+ Rule" asks for a Name, the alert event action that triggers it (for example service.down or device.offline), the remediation script Template, a Max-attempts ceiling and a Cooldown in minutes. New rules are created disabled.

Enable when ready

Rules start off; enable one only when you trust it. Each row shows its trigger, target script, status and limits, and Disable/Enable and ✕ let you toggle or remove it.

Limits and escalation

The cooldown stops a flapping alert from re-firing the fix back-to-back, and once a rule hits its attempt ceiling the incident is escalated to a person instead of looping. The "Recent attempts" panel logs each dispatch, skip or escalation with its reason and job id.

Composes approved scripts and actions into guarded IF / THEN / WAIT workflows, driven manually, on a schedule, or by an alert. SentinelOps has it so routine, multi-step remediation runs the same way every time with conditions and approvals built in, rather than as ad-hoc scripts someone remembers to run. For the tenant it is safe fleet automation: only reviewed script templates can be used as actions, and every workflow is scoped to the selected tenant. Pick a tenant first; editing needs automation.manage.

The KPI tiles

Four counters head the view — Workflows (total), Enabled, Scheduled and Alert-driven — so you can see at a glance how much automation is live and how it is triggered.

Triggers

A workflow runs manually against a device you pick, on a schedule (hourly/daily/weekly across all live devices), or on an alert (against the incident’s device, optionally matched to a specific alert action such as device.offline).

Build the steps

In the editor set Name, an optional Description and the Enabled checkbox, pick the Trigger, then add steps with "Add step": IF (condition) that halts the run if it fails, THEN (action) that does the work — run an approved script template, set device status, or send a message — and WAIT (a delay in seconds). Steps are evaluated top to bottom; editing requires automation.manage.

Run and watch

Use Run… on a workflow to fire it against a named device (you pick from the list); the run history opens so you can watch progress. Runs shows past executions and their outcomes for any workflow.

Enable state and last run

The list shows each workflow’s trigger, step count, on/off state and its last run time and status. Only approved script templates are offered as actions, so a workflow can’t run an unreviewed script.

What this is: a reusable definition of exactly what a SentinelOps profile backup captures — which folders, whose data, and within what size budget. Why SentinelOps has it: a blind whole-profile grab either misses what matters or fills the endpoint’s disk, so there is no hidden default here — a new selection starts empty, you tick only what you want, and the agent measures the selection before copying anything so an over-size backup fails fast instead of mid-stream. What it does for the tenant: precise, per-OS control over what leaves each machine, assignable fleet-wide or per device, with every change audited. Reading needs device.read; creating, editing, deleting and assigning need enrollment.manage.

Areas per OS

Documents, Desktop, Downloads, Pictures, Music and Videos map to each user’s own folders: Windows known folders (following OneDrive/folder redirection when the user is signed in), macOS ~/Documents … ~/Movies, Linux XDG user dirs (xdg-user-dir / ~/.config/user-dirs.dirs). Email = Outlook data (OST/PST) + Thunderbird on Windows, ~/Library/Mail on macOS, Thunderbird/Evolution on Linux. Browsers = Chrome, Edge, Firefox, Brave (and Safari on macOS) profile folders. App settings = AppData\Roaming on Windows, ~/Library/Preferences + Application Support (minus iPhone backups in MobileSync) on macOS, ~/.config on Linux.

Phone areas

Phone photos, documents, downloads, music and movies are captured by the SentinelOps Android/iOS apps. A desktop ignores them; a selection with only phone areas and no include path does nothing on a computer (the job says so).

Whose data

All users on the machine, only the signed-in user, or named users (account names). macOS scheduled captures always use the signed-in user — the Mac agent can only read that user’s home.

Include and exclude

Include paths add folders on top of the areas: absolute (/srv/share, C:\Data) or ~/Projects for the same folder in each selected user’s home. Excludes can be a name (node_modules), a glob (*.iso), a relative path (Library/Caches) or a full path. Skip caches drops browser/app caches, Temp and Trash.

Size cap and preflight

Before staging anything the agent adds up the selected folders (respecting the excludes) and stops with “selection is N GB, over the cap of M GB” if it is over. 0 uses the server default (SENTINELOPS_MAX_PROFILE_BACKUP_BYTES / Settings → max archive size, 20 GB by default). Narrow the selection or raise its cap if a capture is refused.

Where a selection applies

Assign a selection as the tenant default, to a group, or to a single device. A device uses its own selection first, then its group’s (the nearest group up the tree), then the tenant default. A device with no selection keeps the legacy whole-profile capture. Deleting a selection clears its assignments; removing a device or group removes its assignment.

Manual backups

Back up profile in the device drawer (and New capture in Profile & Service Backups) lets you pick the device’s selection, any saved selection, or build a custom one in the same area editor — or run the legacy whole current-user capture.

API

GET/POST /v1/backup-selections, GET/PUT/DELETE /v1/backup-selections/{id}, PUT /v1/backup-selections/assign {scope, target_id, selection_id}, GET /v1/backup-selections/assignments, GET /v1/devices/{id}/backup-selection. The mobile apps use the same API.

What this is: the record of which backups have actually been test-restored, kept separate from whether a backup job merely ran. Why SentinelOps has it: a backup that has never been restored is not a proven backup, and a green job status hides that gap — so this screen refuses to let an untested or failed-restore backup pass as safe. What it does for the tenant: an honest, defensible answer to "could we actually recover this machine?", with a stale clock so a once-proven restore does not stay trusted forever. Pick a tenant first.

Read the posture tiles

The tiles count Restore failed, Never verified, Stale (a verification older than the stale window, default 30 days), Verified, and Unprotected devices — those with no backup at all. Worst posture is listed first in the table.

Backup job vs restore verified

The Backup job column reflects what the device’s backup product reports (ok / warning / failed and when it last succeeded). The Restore verified column is separate — a green backup job only means a job ran, not that a restore works.

Record a verification — the fields

With device.status.change, click Record verify… on a row. You enter a Result (verified / failed / not_verified), a Method (test_restore / checksum / manual / automated) and optional Notes — this logs that a restore was actually proven (or failed) and resets the stale clock from now.

Unprotected devices

A device that reports no active backup shows as unprotected and needs a backup put in place before verification even applies. The muted line under the tiles calls out how many have no backup at all.

What this is: backup health across every managed endpoint in the tenant, worst posture first, built from what the agent and your backup products actually report. Why SentinelOps has it: a backup nobody is watching is the one that has quietly failed — so this screen never invents a green state, counting a silent device as "not reporting" rather than assuming it is protected, and turning failed/overdue backups into incidents through the alerting engine. What it does for the tenant: a single honest answer to "is every one of our machines actually being backed up, and current?" plus the knobs to enforce it. Pick a tenant first.

Read the posture tiles

Failed (the backup product reported a failure), Overdue (a protected device with no successful backup inside the tenant’s overdue window), Warning, Unprotected (no backup at all), Not reporting (no collector has reported), and Protected. The muted line summarises how many of the managed endpoints are at risk.

How status gets here

The native agent reports its backup product’s result on the heartbeat, and a script or integration can report via POST /v1/devices/{id}/backup-status (needs enrollment.manage). Mobile devices are excluded — they are consoles, not backup-protected endpoints.

Alert policy — the fields

With enrollment.manage you can set the Overdue-after window (1–2160 hours, i.e. up to 90 days) — a protected device with no successful backup inside it counts as Overdue — and toggle whether failed/overdue backups raise incidents. The setting is saved per tenant in the database; a background sweep re-checks every 30 minutes and re-raises at most every 12 hours so a persistent problem nags without spamming.

Backups vs Backup Verification

This screen tracks whether backups are running and current. Backup Verification is the separate proof that a backup can actually be restored — a green job here is not a proven restore.

Automatic capture — the fields

Capture every N hours queues a SentinelOps profile backup on each eligible online endpoint without a recent one (a failed one is retried after 2 hours). Devices tagged no-backup are never captured. WHAT is captured comes from the device’s backup selection; a device with no selection keeps the legacy whole-profile capture in the Scope chosen here (the Scope control picks what the legacy capture grabs). macOS always captures just the signed-in user.

Backup selections

The Backup selections panel is where you choose WHAT gets backed up: tick areas per OS (Documents, Desktop, Downloads, Pictures, Music, Videos, Email, Browsers, App settings — and Phone areas for the mobile apps), whose data, extra include/exclude paths, skip-caches and a size cap. Nothing is pre-selected. Assign a selection as the tenant default, to a group, or to one device; the device drawer shows which one applies. Press ? on the panel for details.

What this is: the home for everything backup-related in one place — fleet backup posture, on-demand profile/service captures, and restore verification. Why SentinelOps has it: backup, capture and proof-of-restore are three different questions, and bouncing between screens to answer them loses the thread, so this landing page lines them up and links each to its own area. What it does for the tenant: one glance that answers "are our machines protected, can we capture what we need now, and can we actually restore it?" — the top-right button runs a one-click current-user backup across every online endpoint. Pick a tenant first.

The three layers

Backup Health tracks whether third-party backup jobs (Veeam, Windows Backup, restic…) are current. Profile & Service Backups is SentinelOps capturing Windows profiles or Linux/BSD service configs itself — encrypted, downloadable later with a passphrase. Restore Verification proves a backup can actually be restored, not just that a job ran. Each card jumps to its own area.

Recent captures

The table shows the latest profile/service captures with their type, status, capture mode (VSS snapshot vs live, or systemd) and size. Open Profile & Service Backups for the full list, to start a capture, or to download an archive.

Projects how many days until each device’s disk fills, built from real persisted utilisation history rather than a single snapshot. SentinelOps has it so a filling disk is caught weeks ahead — as a planned clean-up or expansion — instead of as a 2 a.m. out-of-space outage. For the tenant it turns raw disk usage into a ranked, days-to-full worklist of the machines that will run out first. No forecast is invented from thin data: a device needs enough hourly samples before any projection is shown. Pick a tenant first.

Read the projection

Each row shows disk used now, the daily trend (e.g. +0.4 %/day) and a projection. A projected device shows "~N days to full", colour-coded — red at 30 days or less, amber to 90, green beyond. A device whose usage is flat reads "stable".

Collecting vs projected

A device new to monitoring shows "collecting (x/N)" until it has accrued the minimum number of hourly samples. Until then no days-to-full figure is shown — the forecast waits for enough history rather than guessing, so the numbers you act on are real.

At-risk tile

The At risk tile counts devices projected to fill within 90 days, and those rows also carry an "at risk" flag. Use it to spot the disks that need clean-up or expansion before they fill and cause an outage, and act through each device’s drawer.

What this is: a record of planned changes for a tenant, each carrying its type, risk, maintenance window, owner and rollback plan, moving through an approval lifecycle. Why SentinelOps has it: unplanned or unreviewed changes are a leading cause of self-inflicted outages, so the platform makes "what are we changing, when, and how do we undo it" an explicit, approved artifact before the work. What it does for the tenant: a disciplined change trail that proves changes were planned and authorised, and makes a bad change reversible. Creating and approving changes needs the change.manage permission. Pick a tenant first.

Log a change — the fields

Click + Change and capture the Title, Description, Type, Risk, Maintenance window and — importantly — a Rollback plan. A change with no rollback plan is flagged in amber, because "how do we undo this" is exactly what you want decided before, not during, the work.

Lifecycle and approval

Changes flow draft → submitted → approved → scheduled → implementing → completed (or rolled_back). Approve appears on a draft or submitted change. Emergency changes may be approved directly, while normal changes are expected to be approved before they are scheduled.

Type and risk at a glance

Type is emergency, normal or standard, and risk is high / medium / low, both shown as pills. The KPI tiles count changes by state (draft, submitted, approved, scheduled, completed, rolled back) so you can see where the pipeline is backed up.

What this is: a per-tenant workspace to assess control frameworks and track coverage honestly. Why SentinelOps has it: a compliance score that assumes unassessed controls are fine flatters the picture and hides real gaps — so here an unassessed control counts against you rather than being treated as compliant. What it does for the tenant: a true, defensible reflection of assessed posture against each framework, with every assessment stamped to who made it. Assessing controls needs the tenant.manage permission. Pick a tenant first.

Pick a framework

The chips across the top are the available frameworks, each showing its current coverage score and how many of its controls are assessed (e.g. "12/60 assessed"). Click one to load its controls below.

Assess a control — the fields

Click Assess on a control and set its Status — compliant, partial, non_compliant, not_applicable or unassessed — with optional Notes and an Evidence reference (a manual pointer to where the proof lives). Your assessment is stamped with who made it and when.

How coverage is scored

Coverage never assumes compliance: an unassessed control is scored against you and a partial control scores half. That keeps the percentage a true reflection of assessed posture rather than an optimistic default.

What this is: a journal of configuration changes made through the console — what changed, by whom, when, and (where supported) how to undo it. Why SentinelOps has it: console settings get changed by different operators, and increasingly by the assistant on an operator’s behalf, so a tamper-aware trail with one-click revert turns "who broke this?" into a quick answer rather than an investigation. What it does for the tenant: accountability for every setting change on their estate and a safe, recorded way to roll one back. The most recent changes are kept with enough detail to undo them; secrets are never recorded.

History

Each change lists When, the Change (its summary, kind and any target id), By (a person, or an "assistant" pill when the assistant applied it on an operator’s behalf, with the actor identity), the Action, and an "undone" pill if it has since been reverted. Only the most recent N changes (shown in the header) are retained with full before/after detail.

Filter the journal — the controls

Two dropdowns narrow the list: All kinds (or a specific change kind) and Anyone / Assistant only / People only. Use them to answer, for example, "what has the assistant changed?" or to isolate one kind of setting.

Revert, Reapply, Detail

Where a kind is revertable and the change is not already undone, Revert puts the object back to how it was before (the revert is itself journaled, so it can be undone in turn); Reapply re-applies a change. Detail shows the before/after context. Revert and Reapply need revert permission and ask you to confirm first.

Secrets are never recorded

Before/after context never stores passwords or keys, so a restored object keeps whatever secret is configured now rather than resurrecting an old one — the revert fixes the setting, not the credential.

The customer contacts and third-party vendors for the selected tenant — the people you call and the suppliers who serve them. SentinelOps keeps them beside the fleet so the human and vendor context an incident needs (who approves, who to escalate to, the ISP account number) is one click away rather than in a separate CRM. For the tenant it is their service directory: the right person reached first and the right supplier reached with the right account in hand. Pick a tenant first. Editing needs tenant.manage; a vendor account identifier is sealed in the vault and only revealed on demand (credential.manage), with the reveal audited.

Contacts

Add a contact with + Contact — name, email, phone and a type (technical / billing / emergency / approver / general). The Esc. column is the escalation order, low to high, so you know who to reach first. These are the same contacts On-Call Escalation engages, so keep them current.

Vendors

Add third parties serving this tenant with + Vendor — ISP, VoIP, EHR, printer, security, software, hardware and so on — with a support phone, a portal URL and an optional account number or portal id. Example: the ISP account number for the site so anyone opening a circuit ticket has it to hand.

Sealed vendor accounts

A vendor account identifier you enter is stored encrypted, never shown in the table. When an operator with credential.manage needs it, "Reveal account" decrypts it for that moment and records the access in the audit log. Operators without that permission see only "sealed".

Removing entries

Remove on a contact or vendor deletes it after a confirmation. There is no soft-delete here, so remove only when the relationship has genuinely ended.

Surfaces money the tenant could stop spending — unused Microsoft 365 licenses, hardware marked retired but still consuming a management seat, and support/warranty renewals coming due. It exists so recurring waste is found and reclaimed as a routine review rather than discovered in an annual audit. For the tenant it is a concrete, per-item savings worklist drawn from its own data, and it is honest when a source is not connected — showing a note instead of a fabricated saving. Pick a tenant first.

Unused M365 licenses

For each SKU it shows assigned vs total seats, how many are unused, and the monthly waste where the SKU is priced. The tiles roll this into an estimated monthly and annual license spend you could reclaim — reassign or drop those seats.

Retired hardware still enrolled

Devices marked retired or decommissioned but still enrolled keep consuming a management seat. This list flags them so you can deprovision and reclaim the seat.

Warranty / support renewals

Devices with a support or warranty date within 90 days (or already expired) are listed with days remaining, vendor and asset cost, so you can decide renew, replace or retire before the date passes.

Honest when unconnected

If Microsoft 365 is not connected or asset warranty dates are not filled in, the panel says so rather than inventing opportunities — connect the source and populate the data to surface more. Nothing here is estimated into existence.

What this is: the controls for how long SentinelOps keeps records and the proof that the audit log has not been tampered with. Why SentinelOps has it: a management platform must be able to both age out old data on a defensible schedule and demonstrate that its own trail is intact — otherwise retention claims and the audit log are just assertions. What it does for the tenant: enforceable retention windows (pruned automatically) and a cryptographically verifiable audit log, so a customer’s compliance and disaster-recovery story holds up. Editing retention needs the system.manage permission.

Data retention — the fields

Set how many days to keep Audit log entries and Finished jobs, then Save retention. 0 means keep indefinitely. The pruner runs hourly, so records past the window are removed automatically rather than by hand.

Audit-log integrity

Every audit entry is SHA-256 hash-chained to the one before it. The Chain status tile reads INTACT or BROKEN; Re-verify now re-walks the chain. If tampering is detected it names the exact entry where the chain breaks.

Backup & disaster recovery

Global operators get a DR panel: Download full backup takes an off-box snapshot of everything, and Export this tenant produces a single-tenant export for offboarding or migration. Sealed secrets stay encrypted in both.

Reports Active Directory health for a tenant — domain and forest, the domain controllers, FSMO roles, object counts and replication/DNS status. SentinelOps has it because a broken DC or a silent replication failure degrades every logon and group policy in the organization, and it is the kind of fault that stays invisible until something breaks. For the tenant it is standing AD health monitoring: known DCs are re-checked automatically every 6 hours and failures raise alerts, so a problem surfaces on its own. Pick a tenant first.

Read the fleet health

The tiles count Domain controllers, Unhealthy DCs, Replication issues and DNS issues. The DC table shows per-controller failed tests, replication failures, DNS problems and when it was last checked, healthy first vs "issues".

Detect a new DC

Pick a Windows server under "Check a Windows server for DC role" and click Run diagnostics. This runs the health check plus a directory inventory; if the box is a DC it is detected and added to ongoing 6-hourly monitoring. Run now on an existing DC re-checks it on demand.

Drill into a DC

Details on a DC opens its full results — the individual tests, DNS tests, any replication failures (partner and detail), and the FSMO role holders — so you can see exactly which check failed rather than just a count.

Automatic alerting

Because known DCs are re-checked every 6 hours and failures open alerts, you do not have to sit on this screen — a new replication or DNS break surfaces as an alert. Come here to investigate and to onboard servers not yet detected as DCs.

What this is: an operator-defined record of which devices depend on which — a workstation on its gateway, an application on its database. Why SentinelOps has it: when one upstream device fails, everything behind it alarms too, burying the real cause in noise — so the map lets alerting tell a root cause from its downstream fallout. What it does for the tenant: cleaner, correlated alerting that points at the one thing to fix, plus a clear picture of each device’s blast radius. Editing needs the device.status.change permission. Pick a tenant first.

Add a dependency — the fields

Click + Dependency to record that one device relies on another, choosing the Kind: network, power, service, application or storage. For example, mark a set of workstations as depending (network) on their site gateway, or an app server on its database.

Read the blast radius

Dependencies are grouped by the upstream (depended-upon) device, so each panel shows one upstream and everything that would be affected if it failed — the blast radius — with the dependent device, type and notes.

Alert correlation

The map feeds alert correlation: when an upstream device goes offline, alerts for its downstream dependents are suppressed as noise and attributed to the real root cause. A banner flags how many devices are currently impacted and how many downstream alerts are being suppressed.

Living, per-tenant documentation — runbooks, network notes, contacts, procedures — organised into sections. SentinelOps has it so the knowledge an on-call operator needs at 2 a.m. lives beside the fleet it describes, not in scattered files or someone’s head. For the tenant it is a maintained, Markdown-based knowledge base that can be drafted automatically from live inventory and kept current as the network changes. Pick a tenant first. Editing needs tenant.manage.

Sections and pages

Pages are grouped under sections such as Overview, Networks, Firewalls, Servers, Applications, Backups, Procedures and Emergency Information. Add a page with + Page: choose a section, give it a title, and write the body in Markdown. Example: an "Emergency Information" page with after-hours contacts and the escalation path.

Auto-generate network doc

Auto-generate network doc drafts a Network page from the tenant’s sites, networks and discovered infrastructure, so you start from real inventory instead of a blank page. An auto-generated page carries an "auto" badge; edit it freely afterward to add the context inventory can’t know.

Editing and history

Edit reopens a page in the Markdown editor; each page shows when it was last updated. Keep procedures here rather than in scattered files so the on-call operator finds them in one place.

Removing a page

Remove deletes a page after a confirmation. Auto-generated pages can be removed and regenerated when the network changes — regenerating drafts fresh from current inventory.

Tracks a tenant’s internet-domain portfolio: registration expiry, registrar, nameservers, DNSSEC and basic DNS health, cross-referenced against the tenant’s Microsoft 365 verified domains. SentinelOps has it because a lapsed registration or a broken delegation takes a client’s mail and website down, yet renewal dates are exactly the thing nobody is watching. For the tenant it guarantees no client domain quietly expires or stops resolving unnoticed. Pick a tenant first. Adding or removing needs tenant.manage.

Track a domain

Add a domain or subdomain (e.g. acme.com or mail.acme.com) and SentinelOps queries registration data over RDAP: expiry date, registrar, nameservers and DNSSEC status. A subdomain is tagged with its apex domain since it has no registration of its own.

Expiry at a glance

The KPI tiles count domains expiring within 45 days and already expired, plus domains with DNS issues. Each row shows an expiry pill and the days left, so the ones about to lapse stand out. Example: a domain showing "expiring 12d" is your cue to confirm auto-renew with the registrar before it drops.

DNS resolution check

The DNS column shows whether the domain currently resolves ("resolves") or not ("no DNS"), and the row lists the first couple of nameservers. A domain that stops resolving is flagged so you catch a broken delegation early.

Microsoft 365 cross-reference

When the tenant’s Microsoft 365 (Entra) is connected, verified 365 domains are listed and any that are verified in 365 but not yet tracked here appear as one-click "add" pills — so a domain your client actually uses for mail doesn’t go unmonitored. Recheck on a row re-queries RDAP and DNS on demand; all domains re-check daily.

The Users list filtered to engineering and operator accounts — the people who work on the fleet day to day. It is the same Users screen with a role filter applied, so you can manage the staff who run jobs, deploy agents and operate devices without wading through every account. For the tenant it is the roster of who can actually touch their machines.

Same view as Users

Everything here is the Users screen with a role filter applied — the table columns and every per-account action work exactly as they do under Users. Only the rows are narrowed to engineer/operator roles.

Capped engineers

An Engineer whose permissions were pinned below the full role reads as "engineer" but will not see everything the role implies. Open the account and use Edit permissions → "Use the role’s permissions" to restore full access, or leave it capped deliberately for a tenant-scoped engineer.

The platform’s capability catalog and honest delivery tracker — every capability with its build status, its licence tier, and a platform-wide on/off switch. SentinelOps keeps it as the single source of truth for what the product actually does and does not do today, so a sales promise or a support answer is grounded in reality rather than a marketing list. It is platform-wide (not per-tenant): the status and toggles apply across the whole deployment, and toggling a capability needs system.manage.

Delivery status

Each capability carries an honest status: implemented, partial, planned (not built yet), or blocked (waiting on something external). The summary tiles total each state across the whole registry, so you can see real coverage at a glance rather than a marketing list.

Grouped by category

Capabilities are grouped by category and each row shows the feature name, its spec number where it has one, and a short description. Use this to answer "does the platform do X?" precisely — the status pill tells you whether it is shipped, partial or still planned.

Licence tier

The Licence column shows which tier a capability belongs to, so you can see what a given plan includes versus what an upgrade would add.

Enable / disable

With system.manage you can toggle a capability on or off platform-wide via its checkbox; without that permission you see a read-only on/off badge. A blocked capability can’t be toggled — it shows n/a until whatever it depends on is in place.

Confirms which Group Policy Objects actually applied on each Windows endpoint — the reality on the machine, not what the domain intends. SentinelOps has it because a linked GPO does not guarantee an applied GPO: scoping, inheritance, WMI filters or an errored refresh can silently leave a policy off a machine, and "we linked it" is not the same as "it landed". For the tenant it is proof that a security or configuration policy reached every workstation. Pick a tenant first. Data is collected from the endpoint (gpresult), so a device shows "not collected" until a collection has run.

Fleet summary

The KPIs count Windows devices, how many have collected GPO data, and how many haven’t. Start here to see whether you have enough coverage to trust the picture before drilling into a specific policy.

Per-device results

Each row shows the device, whether it’s online, how many GPOs applied, when policy last applied, and any errors. An "err" badge means gpresult reported problems applying policy on that machine — worth investigating regardless of the count.

Verify a specific GPO

Type a GPO name (e.g. Default Domain Policy) and Check to see, per device, whether that exact policy is applied or missing, with tenant-wide "applied" and "missing it" counts. Example: after linking a new security GPO, confirm it actually reached every workstation rather than assuming it did.

Refresh a device

Refresh on a row triggers a fresh collection from that endpoint (a gpupdate-style refresh); results appear a few seconds later. Use it after a policy change so verification reflects the new state rather than the last cached run.

The federated (OIDC) identities provisioned for sign-in, mapped to a tenant and role, with immediate session revocation. SentinelOps keeps this central list so an external identity can be pre-authorized or cut off in one place, and so disabling an identity kills its live sessions at once rather than waiting for a token to expire. For the tenant it is the control that decides exactly which federated subjects may sign in, under which tenant, and with what role — the authorization side of the SSO you configure under SSO Providers / Per-tenant SSO.

OIDC memberships

Each row is a federated identity: its subject (the IdP’s sub/oid claim), the issuer, the tenant it belongs to, its granted roles, and a revision number. Only identities in scope for the tenant you are viewing are listed. A global operator also sees an SSO settings button to open provider configuration.

Add an identity — field by field

Add identity asks, in turn, for the OIDC subject (the sub claim from your provider, e.g. auth0|abc123), the Tenant it belongs to (e.g. ten_default), and a Role (administrator, operator, helpdesk, file-operator or auditor). This pre-provisions the person so they can sign in through SSO without waiting for just-in-time creation.

Enable / disable

The per-row toggle enables or disables an identity. Disabling it immediately revokes every existing session for that subject — the fast way to cut off a federated user — and re-enabling restores access. Every change bumps the revision and is audited.

Confirms that Intune apps and configuration actually reached your Windows devices — not just that Intune reports them assigned. SentinelOps has it because the two often disagree: a policy marked assigned in the portal can stall on the endpoint, and the only ground truth is the Intune Management Extension (IME) state read from the machine itself. For the tenant it proves delivery from the device end: per-device IME state is read from each agent now, and tenant-wide numbers fill in when Microsoft Graph is connected. Pick a tenant first.

Endpoint state vs. Graph

The banner shows whether Microsoft Graph is connected for tenant-wide reporting. Even without Graph, the per-device table works from what each agent collects locally from the IME — enrollment, AAD-join, last sync and app counts.

Read the KPI tiles

Windows devices, IME collected, enrolled and not-collected are counted at the top. A warning-coloured "Not collected" tile means those machines have not reported their Intune state yet — use Collect on each to pull it.

Collect on demand

The Collect button on a device row asks that agent to re-read its IME state; results appear a few seconds later (the view refreshes itself). Use it after you push an app or policy and want to confirm delivery.

Spot failed apps

The Apps column shows the installed count and, in red, any failed apps for that device — a quick way to find machines where a deployment did not land.

Tracks a tenant’s subnets and IP allocations and reconciles them against what network discovery actually saw on the wire. SentinelOps has it so the record of "which address is what" stays truthful — duplicate assignments, drifted documentation and untracked hosts are caught by comparing the plan to reality rather than trusting a spreadsheet. For the tenant it is an accurate, self-checking address map of their network. Pick a tenant first; editing needs tenant.manage.

Subnets come from Sites & Networks

IPAM builds on the networks you record under Sites & Networks — add a network with a CIDR there and its subnet, utilisation bar and hosts appear here. With no networks recorded the view is empty by design.

Reconcile against discovery

Each allocation shows an "on wire" pill if discovery has seen that address, and every host discovery found but that you have not recorded is listed as "untracked". Click the + on an untracked row to record an allocation for it (IP, hostname, MAC prefilled).

Resolve conflicts

When one IP is allocated more than once a conflict banner lists the offending addresses and the rows are highlighted with a "dup" chip. The Conflicts KPI tile turns warning-coloured whenever any exist.

Add and remove allocations — field by field

With tenant.manage, "+ Allocation" prompts for IP, hostname, kind (static / dhcp / reserved / gateway / dynamic), MAC and a note; saving an already-allocated IP warns you it is a conflict. The ✕ on a row removes an allocation.

Orphan allocations

Recorded IPs that fall outside every known subnet are grouped separately as orphans — usually a wrong CIDR or a missing network. Fix the subnet or add the network so they slot back into place.

Watches the reachability and latency of a client’s public WAN endpoint as seen from the internet, with uptime history over time. SentinelOps has it so an ISP or circuit outage is caught from outside the building — the view a customer’s users actually get — and backed by an uptime record you can take to the carrier. For the tenant it is independent, external proof of whether their internet link is up and how it performs. Pick a tenant first; adding a target needs tenant.manage.

Add a WAN target — field by field

With tenant.manage, + WAN target takes the client’s public endpoint (IP or hostname) and a port — for example their firewall’s WAN IP on 443. It is probed on add and on a schedule thereafter.

Read the status tiles

Each target shows UP/DOWN, last latency in milliseconds, and uptime percentage over the collected samples (green ≥99%, amber ≥95%, red below). A probe error is shown inline when the connect fails.

Probe on demand

Use "Probe now" to force an immediate timed TCP connect — handy for confirming a link is back after an ISP outage without waiting for the next scheduled check.

What it does and doesn’t see

Probes originate from the server (internet-side), so they measure the WAN link’s external reachability. An on-site agent would additionally see the LAN-side path; this view is the outside view.

Just-in-time privilege elevation: an operator requests extra permissions for a specific task and an approver grants a window that auto-expires. SentinelOps has it so nobody carries standing high-risk rights — elevation exists only for the minutes it is needed and vanishes on its own, which is the audit answer to "who could do what, when, and why". For the tenant it means powerful actions on their fleet (run commands, manage files, reveal a local-admin password) are always tied to a named request, an approval and a reason, never to a permanently over-privileged account. Pick a tenant first.

Request access

Click Request access, tick the permissions you need (e.g. command.execute, file.manage, localadmin.reveal), and describe why. The request sits as "requested" until an approver acts. Choose only the permissions the task actually needs — the grant is least-privilege by design.

Approve, deny or revoke

An operator with approval rights sees Approve / Deny on a requested grant, and Revoke on anything active or pending. Approving prompts for a duration in minutes (default 60, max 480). Revoke ends an active elevation immediately.

Break-glass emergency access

The red Break-glass button (needs access.breakglass) self-activates elevation right away for a short window — max 60 minutes — for when no approver is reachable. A reason is required and every use is audited. Use it only as a genuine last resort.

Live expiry

An active grant shows the time left (e.g. "42m left" or "1.5h left") and flips to expired on its own — the countdown is recomputed in the browser so a just-expired grant reads correctly without a refresh.

Watches the OS logs on your endpoints — the Windows Event Log, Linux journald or /var/log files, and the macOS unified log — and raises an alert when matching entries appear. SentinelOps has it so a failing service, a disk error or a security event buried in the logs becomes a proactive alert instead of something found during a post-mortem. For the tenant it is fleet-wide log alerting with a companion suppression rule kind that mutes known-benign noise so it never alerts. Evaluation runs server-side by re-using the agent’s read-only log query — nothing new is installed on the endpoint.

Alert rules

An "alert" rule watches for log entries at a level (Warning/Error/Critical) and/or containing a keyword, on the devices its scope selects. When at least the minimum number of matches appear inside the window, it raises a deduplicated incident (routed through Alerts like any other).

Suppression rules

A "suppress" rule mutes matching entries so they never alert and never inflate the dashboard — the fix for recurring noise (e.g. postfix "aliases.db" spam). It needs a level or keyword; a rule with neither is ignored so it can never silence a whole fleet.

Scope & OS

Target all devices in the organization, a single device, or a group, and optionally restrict to one OS. Device-scoped rules follow that device’s organization.

Source selection

Windows rules can name any Event Log channel; Linux rules read journald (optionally one unit) or a /var/log file path. Leave the source blank to watch the whole journal / default log.

Test a rule

Use "Test" to evaluate a rule immediately against a matching online device and see how many entries match right now (and how many the suppressions removed) — before you rely on it.

Recent matches

The top panel lists the most recent matches with device, rule, level and a sample line; click a row to open that device. Evaluation runs server-side about every 10 minutes by re-using the agent’s read-only log query.

Build one from the log browser

In a device’s Quick actions → Logs, set your filters then click "Monitor this…" to open a pre-filled rule for exactly what you were looking at.

Manages mobile devices through Microsoft Intune (Endpoint Manager) — enrolled devices with compliance state and live device actions, driven through the tenant’s existing Microsoft 365 / Entra app registration — plus an Apple Business Manager credential connector. SentinelOps has it so phones and tablets are visible and actionable in the same console as the rest of the fleet, reusing the Graph connection you already set up rather than a second MDM tool. For the tenant it is a compliance-and-control view of their mobile estate. Pick a tenant first.

Where the Intune data comes from

Intune devices are read from the tenant’s Microsoft Graph app — the same connection that powers Microsoft 365 sync. If the banner says a scope is needed, grant DeviceManagementManagedDevices.Read.All on the Entra app registration and admin-consent it, then run a Microsoft 365 sync. The list reflects the last sync; there is no separate credential to set up.

Read the fleet

The KPI tiles count enrolled devices, noncompliant (highlighted), compliant, and company- vs personal-owned. The table lists each device’s OS, compliance state, owner/enrollment type, assigned user and last check-in — noncompliant devices sort to the top so they’re the first thing you see.

Device actions

With command.execute you get per-device actions that run live against Graph: Sync (force a check-in), Lock (remote lock), Reboot, Retire (remove management + company data), and Wipe (factory reset). Retire and Wipe ask for confirmation and additionally require the DeviceManagementManagedDevices.PrivilegedOperations.All scope consented — Graph returns a clear error if it is missing.

Apple Business Manager

ABM is a per-tenant credential connector: store the ABM API Client ID, Key ID and downloaded .p8 private key (sealed in the vault) to prepare Apple device inventory. This build does not run the live Apple orgDevices sync and never shows fabricated Apple devices — meanwhile SentinelOps manages macOS/iOS endpoints directly through its own agent. A full Apple MDM enrolment server is out of scope.

Reports the identity-security posture of the tenant’s Microsoft 365 / Entra: Conditional Access policies, MFA registration coverage and Identity Protection risky users. SentinelOps has it because identity is where most 365 breaches begin — an admin without MFA or a report-only CA policy is a gap you want flagged, not buried in the Entra portal. For the tenant it is a single posture screen pulled from their own 365 estate, honest about what has not been assessed. Pick a tenant first.

Connect and sync first

The data comes from a connected, synced Microsoft 365 tenant — if 365 is not connected, or has never been synced, the view tells you so instead of showing stale numbers. Run a 365 sync to populate it.

Conditional Access enforcement

Policies are listed with their state; a "report-only" pill means the policy is evaluated but not enforcing. The "CA report-only" KPI turns warning-coloured so you can find policies to promote to enabled or retire.

MFA registration and admins

The MFA panel shows registration coverage percent, registered/total users and — most important — admins without MFA, which is called out as its own KPI and warning-coloured when any exist.

Risky users

Identity Protection risky users are listed highest-risk first with risk level and state. The high-risk count is a top-level KPI so a spike is visible immediately.

Admin-consent gaps

Some datasets need extra Graph admin consent; where a scope is missing the panel shows a "consent required" note and an "Admin consent needed" list of the exact scopes to grant, so you know why a section is blank.

Enrolment of the SentinelOps mobile operator app, one record per person. The app lets administrators and engineers manage the fleet from a phone or tablet, so a mobile account is offered only to staff roles — a customer-portal account never gets one. SentinelOps separates it from the console login because a phone is enrolled with its own operator token and device limit, which must be issued, masked afterwards, and resettable when someone changes handset. For the tenant it is the controlled way their field staff carry management access without sharing console passwords.

The table

One row per person: User (and role), Username, Platform, Devices enrolled, Enrollment status ("pending" means nobody has enrolled a device against it yet), the operator Token (shown in full only when first issued, masked as ABCD-****-7F92 afterwards), assigned Profile and Policy, 2FA, SSO and Last seen. A banner warns if mobile access is switched off for the organization (and whether platform policy locked it that way).

Create a mobile account — field by field

Create mobile account opens a form: User (only users without a mobile account already), Platform (iPhone / iPad / Android, or decide at enrolment), an optional Mobile profile and an optional Security policy drawn from this tenant’s policies. It creates the account in "pending" until a device enrols against it.

Enrol a device

Open an account and use Generate enrollment QR or Create operator token (both need mobile.operator_tokens.create). The token and its scannable QR — carrying the server address and the token — are shown exactly once; the person scans it in the app or opens the enrollment URL. Copy the token then, because it is never recoverable afterwards.

Reset, disable and delete

Reset enrollment revokes every mobile token and returns the account to pending — do this when someone changes phone. Disable mobile access turns the app off and revokes its tokens; Enable turns it back on. Delete removes only the mobile account (the person keeps their console login) and revokes its tokens. The enrollment history panel logs every issue, reset and enrolment with who did it and when.

Your own personal KPI dashboards, built from live fleet metrics — for the tenant selected in the top bar, or across all tenants when none is selected (global operators). SentinelOps lets each operator assemble the numbers they personally care about instead of being limited to the fixed dashboard. For the tenant it means an engineer can pin exactly the health signals that matter to their work and keep them one glance away. Only you see your own dashboards.

Create a dashboard

Click "＋ New dashboard", name it, then click metrics in "Add a metric" — each card shows its current value, so you see what you are adding. Rename, reorder (↑ ↓) or remove widgets before saving. Up to 24 widgets.

Show on the main Dashboard

Tick "Show on Dashboard" (here in the builder, or in Dashboard → Configure → Your custom KPI panels) and the board appears at the top of the main Dashboard, updating live with it.

Widgets are live and clickable

Every widget shows the metric’s current value and refreshes with the page; click one to open the matching page (Devices, Alerts, Tickets, Backups…) already in context.

Edit or remove

Edit reopens the same builder with your widgets loaded; the ✕ deletes the dashboard. Changes affect only your own view.

A read-only list of the devices assigned to you — the end-user’s view of their own enrolled machines and their current status. SentinelOps gives each person this so they can confirm their own hardware is enrolled and reachable without seeing (or being able to act on) the rest of the fleet. For the tenant it is the self-service "are my machines online?" view, with no management controls attached.

What you see

Each row shows the device name, platform/OS, online status and when it was last seen. This is your personal list only, not the full fleet, and there are no actions — it is purely informational.

Status and last seen

The status pill and "last seen" tell you whether a device is currently reachable; a machine that has not checked in recently shows as offline with an older last-seen time.

Nothing assigned

If the list is empty, no devices are assigned to your account yet — ask your IT team to enrol one for you.

A customer’s own read-only window on their Microsoft 365 estate — user, group and device counts and their licence subscriptions — inside the tenant portal. SentinelOps surfaces it so a portal user can see what the MSP sees of their directory without being handed admin access to anything. For the tenant it is a self-service snapshot of their M365 footprint and licence usage. A global operator landing here is instead pointed to the Tenants view to pick a customer.

Object counts

Four tiles summarise the synced Microsoft 365 directory: Users, Groups, Devices and the number of licence SKUs. These come from the connected M365 tenant and are read-only.

Licence details

A table of each subscription with Purchased, Assigned and Available seats, so you can see where licences are over- or under-used. A line records when the licence data was last synced; if nothing is connected the panel says there is no Microsoft 365 data yet rather than inventing figures.

The organizations you personally are assigned to, each showing what needs attention — open alerts, offline devices and device count. SentinelOps gives engineers and platform staff this as a fast switcher and triage board across the customers they cover. For the operator it is the quickest way to see where the fires are and jump straight into the right tenant’s context; selecting one moves the whole console into that organization.

Your assignments

Only the tenants you are assigned to appear, and the server re-checks that on every request — this list is a convenience, not the access control itself. Each card shows the organization name, its primary domain or id, and pills for open alerts, offline devices and total devices.

Switch context

Click a card to switch the console to that tenant and open its dashboard. Every view then scopes to that organization until you change it.

What this is: the policy for who gets engaged, and after how long, when an alert goes unacknowledged — plus a live view of which incidents are climbing the tiers right now. Why SentinelOps has it: an alert nobody acknowledges is as bad as no alert, so the platform needs a defined, time-based path that reaches progressively more senior people until someone responds. What it does for the tenant: a dependable guarantee that their incidents are chased up the right chain at the right hours, not left sitting. Pick a tenant first. Editing the policy needs alert.manage; contacts come from Contacts & Vendors.

Business hours — the fields

The policy has a Timezone, business Start/End hours and business Days. The KPIs tell you whether you are in business hours right now, which can change who is on the hook. Example: set 9–17 America/Los_Angeles, Mon–Fri, so after-hours incidents follow the on-call path rather than the daytime one.

Escalation tiers — the fields

Each tier fires after a set number of Minutes without acknowledgement and engages one or more Contacts (by contact id). Tier 1 might page the primary on-call after 15 minutes, Tier 2 the manager after 45. Edit policy walks you through enabling escalation and defining the tiers.

Live status

The lower panel lists unacknowledged incidents with their age, the tier they’ve reached, and who is being engaged right now — so during an event you can see the escalation actually progressing rather than hoping it is.

Root-cause analysis

Analyze on an incident runs an AI root-cause analysis to help the engaged responder orient quickly. It is an aid to triage, not a substitute for acknowledging and working the incident.

The bearer credentials issued for this organization — console API keys and mobile-app enrolment tokens — listed, auditable and revocable in one place. SentinelOps keeps them here because a long-lived credential is a standing risk: it must be masked after issue, expire, carry a device limit, and be killable the instant it leaks. For the tenant it is the ledger of every non-password way into their console and fleet, with full visibility of what each token is, who created it, when it was last used and how often.

The table

Each token shows the User it is tied to, a masked value (ABCD-****-7F92), Type (console or mobile), Platform, Status, Created and Expires dates, Last used, use count, Device limit and who created it. A token’s full value exists only in the response that created it — the list never shows it again.

Generate a token — field by field

Generate token opens a form: User (or "not tied to a user"), Type (Mobile enrolment or Console API), Platform (Any / iPhone / iPad / Android), Valid for (hours, default 720, max 8760) and Device limit (default 1; 0 = unlimited). The token inherits the chosen user’s permissions, capped at your own, and is displayed once — with a QR for a mobile enrolment, or to copy for a console key.

Regenerate and new QR

Regenerate revokes the current token and issues a replacement immediately (anything using the old one stops working). New QR likewise issues a fresh token with its QR — because an issued token is never recoverable, a new QR necessarily means a new token and revokes the old one. Both actions confirm first.

Revoke and activity

Revoke (needs the revoke permission) kills a token at its next request. Activity opens the audit entries that mention the token — the action, the actor, the source IP and the result — so a suspicious use can be traced before or after revoking.

Lets a customer sign in to their own tenant portal with their own identity provider (bring-your-own Entra ID / OIDC), scoped strictly to that one tenant. SentinelOps keeps customer SSO completely separate from operator SSO so a customer’s federated users land only in their read-only portal and can never reach the operator console or another tenant. The MSP sets it up on the customer’s behalf; for the customer it means their staff use their familiar corporate login and see only what you manage for them.

Pick the organization

Choose the customer organization from the dropdown; its current SSO configuration loads below. Each tenant’s SSO is independent — configuring one never touches another or the operator SSO.

Configure it — field by field

The form has: SSO enabled for this organization (a checkbox); a Provider preset (Entra / Google / Okta / Auth0 / Keycloak / Other OIDC) that pre-fills fields and shows provider-specific notes; Issuer (e.g. https://login.microsoftonline.com/<directory-id>/v2.0); Client ID; Client secret (stored write-only — blank on edit keeps the existing one); and Role claim (default "roles", which must carry a portal role such as tenant-portal). Save may return a warning worth reading.

Hand-off to the customer

The page prints a Redirect URI for the customer’s Entra admin to add to their app registration, and a customer Login link to share with their users — both with Copy buttons. These let the customer’s IdP admin complete their side without MSP access.

Authorize the users

No one auto-provisions. After the IdP side is set up, authorize each customer user on Federated Identities: subject = their Entra user object id (oid/sub), tenant = this organization, role = tenant-portal. Only explicitly authorized users can sign in, which is what keeps a tenant’s SSO isolated to that tenant.

What this is: SentinelOps capturing all (or selected) user profiles off a LIVE Windows endpoint — plus Linux/BSD service configs and the macOS signed-in user’s home — for later recovery. Why SentinelOps has it: ordinary file copies skip in-use files (registry hives, mail stores) and hit access-denied on other users’ profiles, so it reads through a Volume Shadow Copy using SeBackupPrivilege to capture everything cleanly. What it does for the tenant: a recovery copy of a user’s data that SentinelOps takes itself, encrypted at rest and downloadable later under a passphrase, independent of any third-party backup product. Needs the file.backup permission. Pick a tenant first.

What to back up

Pick a saved backup selection (Backups → Backup selections) or Custom to tick areas now — the capture then takes exactly those areas on Windows, macOS or Linux, under the selection’s size cap (checked before anything is copied). Legacy uses the fields below instead: Windows profiles/folders, Linux/BSD service configs, or the macOS signed-in user’s home.

Start a backup — the fields

Choose a Windows endpoint, optionally name which profiles (blank = all) and which folders within each profile (blank = the whole profile), and whether to skip caches (Temp, browser cache, cloud placeholders — on by default to keep archives sane). Because it captures bulk PII, a scoped operator’s job waits for a second approver; engineers/administrators run it directly.

Where it goes

The archive is streamed to SentinelOps and stored encrypted at rest. You download it later choosing the container format (zip / tar / tar.gz) and a passphrase — the passphrase protects the archive that leaves SentinelOps and is never stored, so a lost one is unrecoverable.

Honest status

The Windows agent capture is rolling out. A job sent to an agent that does not yet support it reports that plainly — it never shows a fake success, and no data is read until the capture actually runs.

Backups vs Backup Verification vs this

Backups tracks whether third-party backup jobs are current; Backup Verification proves a backup can be restored; Profile Backups is SentinelOps capturing the profiles itself for recovery.

Configure defaults

Settings → Profile &amp; service backups sets the max archive size, retention, default format, the skip-caches / use-VSS / allow-live-fallback / require-approval defaults, and the cache-exclude directory list — applied to every new capture. All DB-backed and effective immediately.

Troubleshooting

Capture mode is shown per row: "snapshot" = a VSS shadow copy (in-use files included); "live" = VSS was unavailable so it copied live in backup mode (files held open by a signed-in user may be missing — allow this in Settings, or turn it off to fail instead). Common failures: "could not create a VSS snapshot" — the Volume Shadow Copy service is disabled or the SKU/build cannot snapshot (the live fallback covers this); "archive exceeds the maximum transfer size" — raise the max archive size in Settings; "at-rest encryption failed" — the server credential vault (SENTINELOPS_CREDENTIAL_KEY) is not configured. A job that reaches an agent too old to support capture reports plainly and never fakes success. Archives auto-expire per the retention setting.

What this is: reusable per-organization configuration — maintenance windows, patch policy, alert thresholds and retention — that other subsystems read rather than you setting the same thing in a dozen places. Why SentinelOps has it: policy belongs to the organization, not to a single screen or device, so the subsystem that cares about patching or alerting looks up the tenant’s policy instead of carrying its own copy. What it does for the tenant: one authoritative place to define how their fleet is maintained, patched, alerted and retained, applied consistently and never shared across tenants.

New policy — the fields

Add one with + Policy: Organization (shown only when no tenant is selected — a policy always belongs to exactly one), Type (from the server’s list — maintenance_window, patch, alert, retention and any others offered), Name (e.g. "Weeknight maintenance"), a Config (JSON) body, and an Enabled checkbox (on by default). The Config box shows a per-type placeholder as a starting shape — e.g. maintenance_window takes days/start/end/timezone, patch takes auto_approve_critical/reboot/delay_days/exclusions, alert takes cpu/mem/disk thresholds, retention takes audit_days/metrics_days. Invalid JSON is refused with a warning.

Type

What the policy governs. Each subsystem reads only the type it cares about — the patch engine reads patch policies, the alert engine reads alert policies, and so on — so an unused type simply sits until something consumes it.

Scope

A policy belongs to one organization and is never shared across tenants. Switching tenant shows that tenant’s own policies; with no tenant selected the table also names each policy’s organization.

Manage a policy

The Policies table shows each policy’s name, type, on/off State and actions. Edit opens its Name and Config (JSON) for changes; Disable/Enable toggles whether the subsystem honours it without deleting it; Delete removes it after a confirmation (the organization then loses that policy).

What this is: a standing, prioritised feed of the next best actions for the selected tenant, every item derived live from real state. Why SentinelOps has it: findings scattered across security, patching, backup and health screens are easy to miss, so they are distilled into one ranked worklist — and because each item is computed from live signals, fixing the underlying condition makes it drop off on its own rather than lingering as a stale to-do. What it does for the tenant: a single, self-clearing answer to "what should we do next here, and in what order?"

Priority order

Items are grouped open-first then by severity (critical, high, medium, low), each with a category and a short explanation of what to do. The KPI strip counts them by severity so you can size the backlog at a glance.

Open the fix

Where a recommendation maps to a screen, "Open" jumps you straight to the relevant view (and the specific device when applicable) so you can act without hunting for it.

Acknowledge, dismiss, reopen

With tenant.manage you can Ack an item you are working, Dismiss one to hide it until the condition recurs, or Reopen a previously actioned item. Dismissed items dim but stay listed.

Self-clearing

Because items are recomputed from live signals (security posture, patches, backups and more), you do not close them by hand — resolve the real problem and the recommendation disappears; the header notes how many cleared since your last visit.

A safe remote regedit for managed Windows endpoints — browse, search and edit registry values on a live machine without an RDP session. SentinelOps has it so a one-key fix or policy tweak can be applied (and audited) from the console instead of remoting into each box, with guardrails regedit itself has none of: a backup is taken before every write, boot- and security-critical hives are guarded, and every change is audited. For the tenant it is controlled, traceable registry change management across their Windows fleet.

Pick an endpoint and browse

Choose a Windows machine, a hive (HKLM, HKCU, HKCR, HKU, HKCC) and a key path, then Browse. Click subkeys and breadcrumbs to navigate; values show name, type and data. For example, open HKLM and SOFTWARE\Microsoft\Windows\CurrentVersion to inspect that key.

Edit safely

With registry.edit you can add, edit and delete values. Each write backs up the key first and is audited. REG_MULTI_SZ takes one entry per line and REG_BINARY takes hex; without edit permission you have read-only (registry.read) access.

Protected-path guard

Boot- and security-critical hives are guarded — changing them requires ticking the explicit "override protected-path guard" checkbox, so you cannot brick a machine by accident.

Search under a path

Search looks for a pattern across keys, value names and data beneath the current path (bounded). Narrow the key path first for a faster search on a big hive.

Apply to a group

With edit rights, "Apply to group" fans one value change out to every Windows endpoint in a tenant or device group — same guardrails as a single edit (per-machine backup and audit). Track the result on each device’s job list.

What this is: a per-tenant risk register and a log of documented security exceptions — what could go wrong, and where the tenant knowingly deviates from a security standard. Why SentinelOps has it: risks and signed-off deviations tend to live in one person’s head or a stray spreadsheet, where they are forgotten until they bite, so they are captured here with owners, severities and expiries. What it does for the tenant: a standing record that feeds the Quarterly Business Review, turning "known issues" into part of the client conversation rather than tribal knowledge. Pick a tenant first. Adding or removing needs tenant.manage.

Risk register — the fields

+ Risk records a risk with a Title, Severity (low/medium/high/critical), Owner and Mitigation, plus likelihood/impact and status. Rows sort highest-severity first. Example: "Legacy app requires SMBv1" at High, owner named, with the compensating control in the mitigation field.

Security exceptions — the fields

+ Exception documents an approved deviation — Title, Reason, Owner, Approver and an optional Expiry date. This is the paper trail for "we know this isn’t to standard, and here’s who signed off and why".

Expiry guarding

An exception past its expiry date is flagged EXPIRED and counted, so a temporary waiver can’t quietly outlive its justification. Review expired exceptions and either renew them with a fresh approval or remediate the underlying issue.

Feeds the QBR

Both registers surface in the tenant’s Quarterly Business Review, so risks and exceptions become part of the client conversation rather than living only in an operator’s head. Remove deletes an entry after a confirmation.

What each kind of account may do, expressed as a named set of permissions. Built-in roles are fixed and ship with the platform; you can also define custom roles for this organization. SentinelOps centralises this so access is granted by job function rather than by hand-picking permissions per person, and so a tenant can never create a role more powerful than the person who created it. For the tenant it is how "help desk" or "read-only auditor" becomes a reusable, least-privilege building block they assign to users and groups.

Built-in roles

Shown with their exact permission set: Engineer is the top operating role; Administrator runs tenants and fleets; Auditor is read-only. Each is tagged platform or tenant-scoped. These cannot be edited or deleted — they are the fixed baseline every custom role is measured against.

Create a custom role — field by field

Create role opens a form: Name, Description, and a checklist of Permissions. Only the permissions you hold yourself are listed, because the server caps a new role at the creator’s own authority on save. You must tick at least one permission. The role then applies to this organization and can be assigned to users directly or through a user group.

Delete a role

Delete removes a custom role, but the server refuses while any account still uses it — move those accounts to another role first. Built-in roles have no delete.

One search box that queries across every entity type in the selected tenant — devices, tickets, contacts, vendors, changes, risks, DNS/TLS monitors, docs, sites and networks. SentinelOps has it so you reach a known item by name in seconds instead of guessing which menu owns it. For the tenant it is the fast cross-module jump point into their own data, scoped so results never leak across organizations. Pick a tenant first.

Pick a tenant first

Search is scoped to the current tenant, so select one before typing — otherwise the results panel asks you to. Type at least 2 characters and results appear as you type (there is a short debounce).

Read the grouped results

Matches are grouped by type with a count per group, each row carrying an icon and a sublabel. The muted "view →" on the right tells you which screen the row will open.

Click a result to jump there

Clicking a hit navigates to the owning view — e.g. a device hit opens the Devices view and pops that device’s drawer; a ticket hit takes you to Tickets. It is the fastest way to reach a known item without hunting through menus.

When nothing matches

A "No matches" line means the query didn’t hit any indexed field for that tenant. Try a shorter or partial term — for example "acct" instead of the full account name.

What this is: response and resolution compliance for the tenant, scored live against per-priority targets from imported service-desk tickets. Why SentinelOps has it: an MSP commits to response and resolution times, and a commitment nobody measures is just a promise — so this turns the ticket history into a measured, per-priority compliance number with a breach list. What it does for the tenant: proof of how well their SLAs are being met, and early sight of where they are slipping. Scoring is measured only over tickets that actually reached each stage, so the percentage is honest.

The compliance KPIs

First-response and resolution percentages are measured only over tickets that actually reached each stage, alongside a breach count and how many tickets were scored. Below 85% turns to a warning.

By-priority table

Each priority (critical / high / normal / low) lists its response and resolution targets and the compliance achieved. A "no tickets" dash means nothing at that priority has been measured yet.

Edit your targets — the fields

With tenant.manage, use "Edit targets" to set the first-response and resolution goal in minutes for each priority (0 = not tracked). Until customised, sensible default targets are used and marked as such.

No tickets imported

SLA is computed against imported tickets — if none are imported the screen says so. Import them via QBR → Tickets; the targets remain editable in the meantime.

Breach list

When there are breaches, the worst overrun is listed first with target versus actual time and the overage, so you can see exactly which tickets blew their SLA and by how much.

What this is: a declaration of which applications must be present, may be present, or must not be present on a tenant’s machines, scored live against each device’s reported software. Why SentinelOps has it: unmanaged or forbidden software (an unapproved remote-access tool, a missing required agent) is a real security and licensing risk, and spotting it by eye across a fleet does not scale. What it does for the tenant: an at-a-glance compliance read and a drift list naming exactly which machines break which rule, so you can act on the actual violations. Pick a tenant first; adding policies needs automation.manage.

Compliance KPIs

The tiles show total Policies, total Violations, Compliant devices, and how many have No software list — a quick read on both the rules and the fleet’s adherence before you drill in.

Dispositions

Each policy sets an app as required (must be installed), optional (allowed), or prohibited (must not be installed). The app name is matched as a case-insensitive substring of reported software — e.g. "TeamViewer" flags any TeamViewer build.

Add a policy — the fields

+ Policy (needs automation.manage) prompts for the Application name (the substring to match), the Disposition (required / optional / prohibited), the Scope (tenant / device / group), and — when the scope is device or group — the Device ID or Group ID, plus an optional Note. A tenant-scope policy applies to every machine; a narrower scope targets just that device or group.

Read the drift table

The Drift section lists devices out of compliance with the specific violations (e.g. a prohibited app present, or a required app missing). "No software list" means that device hasn’t reported its software yet, so it can’t be assessed. The ✕ on a policy removes it after a confirmation.

A read-only summary of the single sign-on posture for this organization: whether SSO is on, whether it is required, whether local emergency sign-in is kept, and how many users actually sign in through the provider. SentinelOps shows it here so an operator can confirm the SSO state of a tenant at a glance without touching provider secrets. For the tenant it is the assurance that staff sign-in is federated and that a provider outage cannot lock everyone out. The provider itself is configured on the platform’s SSO settings (SSO Providers); multiple staff providers are managed there.

Posture fields

Three read-only fields — SSO enabled, SSO required, and Local emergency sign-in — reflect the current Authentication policy, alongside a count of how many users of the total sign in through the provider.

Provider and secrets

The identity provider is configured on the platform’s SSO settings, which apply to every organization that uses it. Provider secrets are write-only: once saved they are never returned here or by the API. A global operator with sso.manage sees a Provider settings button that jumps to the Federated Identities / provider configuration.

Emergency access

Local sign-in is deliberately kept available so an SSO provider outage cannot lock everyone out. Keep at least one local emergency administrator until SSO is proven in production.

Configure single sign-on for your MSP/operator staff — let the team sign in with your own identity providers (Entra ID / Azure AD, Google Workspace, Okta, Auth0, Keycloak or any OIDC) instead of local passwords. SentinelOps supports as many providers as you need, each with its own login link, because a mixed team may use different IdPs. For the tenant-running operator it means staff access follows your directory and offboarding in the IdP removes console access too. A staff role granted here confers full operator access, so treat the role claim as privileged. The single default SSO under Authentication → SSO keeps working alongside these.

Redirect URI

A single Redirect URI is shown at the top with a Copy button — register it in every provider’s app/client configuration. It is the callback every IdP must be told to return to.

Add / edit a provider — field by field

Add provider opens a form: Name (your label); a Provider preset (Entra / Google / Okta / Auth0 / Keycloak / Other OIDC) that pre-fills the issuer and role claim and shows setup notes; Issuer (the base that serves /.well-known/openid-configuration); Client ID; Client secret (stored write-only — leave blank on edit to keep the existing one); Role claim (the token claim carrying a staff role, e.g. administrator; defaults to "roles"); an optional Tenant claim; Auto-provision users from the role claim (JIT); and Enabled. Save validates and may return a warning you should read.

Reading a provider card

Each card shows the name, an enabled/disabled pill, the issuer, the role claim, whether auto-provision (JIT) is on, and the provider’s own Login link to share with the staff who use that IdP.

Delete

Delete removes a provider after confirmation — staff who signed in through that IdP can no longer do so. The built-in Keycloak setup guide (free, self-hosted) is linked on the page for a zero-licensing-cost option.

Scope

These are for SentinelOps staff/operators only. A customer bringing their own IdP for their tenant portal is configured separately under Per-tenant (Customer) SSO.

Each customer is an isolated tenant — devices, views, credentials, jobs and audit are all scoped to one and never bleed across. SentinelOps is multi-tenant by design so an MSP can manage many customers from one console while keeping each one’s data walled off; MSP-level roles can see across tenants and every cross-tenant read is logged. For the customer it is the guarantee that their estate and secrets are theirs alone. Reached from the Dashboard → Tenants tab (global/MSP operators).

Tenant list

One row per visible tenant with its id and creation time. Each offers Manage (opens the tenant’s organization profile and Microsoft 365 view), View machines (jumps to Devices filtered to that tenant), Rename, and — for non-default tenants — Delete. Clicking the row itself opens Manage.

Add a tenant

Add tenant creates a new isolated organization from a name — from that point its devices, jobs, credentials and audit are kept separate from every other tenant.

Migrate resources

The Migrate resources action (top right) moves resources between tenants in a controlled way — used when reorganising customers or correcting where something was enrolled.

Removing a tenant

The red Delete removes a tenant (needs operator.manage). Deletion does NOT cascade and is refused while the tenant still owns any device, job, credential or audit record, or has an active legal hold — so first move or remove those (decommission then Remove its devices, disconnect its cloud connectors, clear its credentials). When the server refuses it returns the exact dependency breakdown so you can clear the blockers. The default tenant cannot be deleted.

What this is: a native service desk for the tenant — track work through open → in progress → waiting → resolved → closed, with priorities, assignees and a comment thread. Why SentinelOps has it: issues surface from alerts, endpoints and the client, and routing every one to a separate PSA loses the link to the device and the audit trail, so SentinelOps keeps a first-class ticket of its own. What it does for the tenant: a single place to track their work with device-linked context, and the response/resolution timestamps that feed SLA scoring.

Filter by status

The chips across the top filter the list — Open combines open/in-progress/waiting, and each chip shows its live count. "All" shows everything regardless of status.

Create a ticket — the fields

With ticket.manage, + Ticket prompts for Subject, Priority (low/normal/high/critical), an optional Description and Assignee. New tickets land in the Open view.

Work a ticket

Click a row to open its detail: change status, priority and assignee, and add comments. Tick "internal note" for a comment the client shouldn’t see. First-response and resolved timestamps are captured for SLA scoring.

Device-linked tickets

A ticket tied to a device shows the machine name under the subject, and the row flags a comment count — handy when a ticket came out of an alert on a specific endpoint.

Second-factor coverage across this organization and, specifically, the accounts still without one. It is a focused slice of the Authentication policy: a worklist rather than a settings page. SentinelOps surfaces it because an account with only a password is the weakest link, and the fastest way to close the gap is a list of exactly who to chase. For the tenant it turns "are we all on 2FA?" into a short, actionable roster.

Coverage

A one-line count of how many accounts out of the total have a second factor registered. When everyone is covered the view says so plainly instead of showing an empty table.

Accounts without 2FA

A table of the accounts still missing a second factor — name, role and last login — each with a Manage button that opens the account. Enrolment is always done by the person themselves (an administrator cannot scan a code into someone else’s authenticator), so from the account you set whether 2FA is required and they complete it at next sign-in.

Setting the requirement

Whether 2FA is required for everyone is set under Authentication → Require two-factor; per-account exceptions are set on the user. This view is the coverage report that tells you where to apply those settings.

Collections of people, so a role, a mobile profile or a security policy is assigned once to the group instead of account by account. SentinelOps has it because access and configuration drift when they are set per person — a group keeps a team’s rights consistent and makes onboarding or offboarding one membership change. For the tenant it means "clinical staff" or "help desk" can be defined once and every member inherits the same grant. A group can only ever ADD permissions, never remove them, and membership takes effect immediately. (Device groups — which machines sit together — are under Devices & Access → Groups.)

Create a group — field by field

Create group opens a form: Name, Description, Grants role (only roles you could grant directly are listed — a group’s role is capped the same way as a direct grant), an optional Mobile profile and an optional Policy (security or compliance) drawn from this tenant. Role, profile and policy are all optional — a group can be purely organisational.

What membership grants

Members gain the group’s role permissions on top of their own; the group never takes anything away. The mobile profile and policy are applied to members’ mobile accounts that have none of their own, so a per-person setting always wins over the group default.

Manage members

Members opens a picker of every user in the organization with Add / Remove per person; each change saves immediately. The card shows the member count, the granted role and the first few member chips. Delete removes the grouping only — members keep their own roles.

Every person with access to this organization — operators, engineers, administrators and customer-portal accounts — in one table scoped to the tenant selected in the top bar. SentinelOps keeps it here so access is granted, scoped and revoked from a single place rather than spread across the systems people use. For the tenant it is the definitive record of who can sign in, what they may do, which devices are theirs, and whether they are protected by a second factor. Creating a user issues a temporary password they must change at first sign-in, and every action is audited against this tenant.

The table, column by column

Each row shows Name/email, Username, Role (with account type), Status, Mobile account + Platform, 2FA (the registered methods, or "none"), SSO (linked or local), Devices assigned, Last login and Last seen. "Pending" status means the account has not yet signed in and changed its temporary password. Click a row, or Manage, to open the account.

Create a user — field by field

Create user opens a form: Full name, Username (required), Email, Phone and Role (only roles within your own authority are listed). "Add from a directory…" fills Name/username/email from an existing Microsoft 365 user instead of retyping. For a staff role a Mobile access section appears — tick it to create a mobile operator account, pick a device platform, and (with mobile.operator_tokens.create) generate the operator token + enrollment QR now, setting its valid-for hours and device limit. A temporary password is issued and shown once; the token and QR are shown once too. The mobile app is for staff, so the section is withdrawn entirely for a customer-portal role.

Manage an account

The detail panel shows role, status, 2FA, SSO, device count and last login, plus the assigned Devices (assign or unassign). Two-factor requirement can be set per account to follow the organization policy, be required, or be exempt — enrolment itself is always done by the person. Edit permissions pins permissions on the account (only permissions you hold yourself are offered, the same ceiling the server enforces). Tenant access (for a non-portal account) ticks additional tenants an engineer may work in.

Account actions

From the detail panel: Reset password (issues a one-time temporary password and signs them out), Unlock (clears a lockout after too many failed sign-ins), Reset 2FA (removes their second factors so they can sign in with a password until they re-enrol), Sign out everywhere (kills every session), Enable/Disable account, and Delete user (removes the account, deletes its mobile account, revokes its tokens and unassigns its devices — the audit trail is kept). Each is permission-gated and confirmed.

What this is: warranty posture and asset records for every device in the tenant, sorted soonest-expiry first. Why SentinelOps has it: a lapsed warranty is only discovered when a machine dies and there is no cover, so the platform keeps the asset facts (serials, suppliers, costs, warranty dates) and counts down to each renewal. What it does for the tenant: renewals that never sneak up, an honest view of where asset data is missing (never assumed covered), and the figures that feed renew/replace/retire decisions. Sorted soonest-expiry first.

The posture summary

Header stats count devices in warranty, expiring within 90 days, expired, and unknown. A device with no warranty date is shown as "unknown" — it is never assumed covered.

Read the table

Each row shows the device model and serial, warranty status pill, warranty end date, days left, and support vendor. "expired" in the Left column means the coverage has already lapsed.

Edit an asset record — the fields

Click any row to open the asset editor — Asset tag, Serial, Supplier, PO number, Purchase date, Cost, Warranty start/end, Support vendor, Assigned user, Location and Notes. Filling in the warranty dates is what drives the status pill and the expiry counts.

Feeds cost decisions

Because unknown is never treated as covered, this view honestly shows where you lack data. Warranty renewals due also surface under Cost Optimization to help decide renew, replace or retire.