VerOps Scout — overview
A lightweight endpoint agent that turns real application activity into utilization and adoption analytics — which tools are used, how much, and how that changes over time — plus hardware, installed software, users, presence and OS update posture. Current release: v0.6.1, enrollment-only authentication.
What VerOps Scout is
VerOps Scout is a lightweight agent for Windows and Linux desktops, laptops, and workstations. It watches which applications actually run and correlates each one's real activity — foreground focus, CPU, network connections, and per-application bandwidth — and reports a compact software inventory to VerOps. As of v0.3.0 it also collects the rest of the device picture: hardware, installed software, logged-in users, and network facts that power office/remote presence — all governed by a central collection policy. As of v0.4.0 it also reports OS update posture — how far behind the machine is on operating-system updates, read from cached metadata only, never triggering a network refresh and never installing anything (see Update posture). As of v0.5.0 an agent can also update itself — opt-in on both sides, verified and reversible (see Automatic updates). As of v0.6.0 a Scout authenticates by enrollment only: shared org-wide keys and user logins were removed from the agent entirely (see Enrollment and device credentials). The platform turns that into a governed software estate with utilization & adoption analytics: normalized products and how much each one is actually used over time — hours, utilization, days active, sessions, and trends — that you can query, dashboard, and ask Vera about.
The problem it solves
Most organizations cannot confidently answer three questions: which tools are actually used, how much, and how is that changing over time? Spreadsheets go stale; endpoint tools report what is installed rather than used; SaaS tools see only what flows through single sign-on. Scout is the usage-first view that closes that gap — unifying endpoints and servers, normalizing raw executables into the products humans reason about, and measuring real adoption so you can see what is heavily used, what is fading, and what was installed but never opened.
How it fits together
The capability has three tiers, all reading from one governed estate:
| Tier | What it is | Role |
|---|---|---|
| Collectors | VerOps Scout (workstations) · Machine Agent inventory module (servers) · MDM export (tablets) | Observe activity, report device and software inventory |
| VerOps platform | The hosted service behind app.verops.io | Normalize executables into products, accumulate usage over time, maintain policy |
| Surfaces | Products · Devices · Review queue · Policy · Dashboards · Vera | Turn the estate into decisions |
What you get
- Products — usage analytics: one row per product (not per executable) showing hours used, utilization %, days active, sessions, active/installed devices, last used, and a usage trend, over a window you choose (last 7 days through 12 months).
- Overview — usage tiles (hours used, fleet utilization, unused tools) with a most-used-tools list and an estate trend, so you see adoption at a glance.
- Devices — every device with its hardware, installed software, current user, and network-based office/remote presence — plus MDM-ingested tablets (iPads) governed alongside agent-reported hosts.
- Update posture — every machine bucketed as current, behind, critical or unknown, with a host column, a filter, a KPI tile and an alertable fleet threshold. See Patch posture.
- IT Asset Management — assets and lifecycle, licenses and compliance position, financials and depreciation, CSV/API import and scheduled reports, all built on the same estate. See the IT Asset Management category.
- Dashboards — a first-class inventory data source; build a Software Estate dashboard with no SQL, and chart your usage metrics alongside your own.
- Vera — the platform AI answers usage and adoption questions and writes tool-sprawl reports from the same estate.
Deployed in minutes, governed centrally
Scout enrolls with a limited-use, expiring token that it exchanges once for a revocable per-device credential — the only way it authenticates, and the only credential you ever distribute (see Enrollment and device credentials). On Windows there is a preconfigured setup wizard that makes install-and-enroll a single double-click, and re-deploying a machine simply re-enrols it, identity and history intact. What each agent collects, and how often, is a central collection policy applied on the next poll with no reinstall (see Collection policy and presence). Keeping the fleet on a current build is central too: an admin can enable a release channel and roll a new version out by percentage, and opted-in agents replace their own binaries — verified, smoke-tested and automatically rolled back if the new one cannot stay up (see Automatic updates).
One estate, two collectors
The same inventory capability is available on servers through the Machine Agent's optional inventory module, which feeds the same governed estate using the same VerOps Scout v0.4 inventory contract. Scout is the low-footprint agent for user endpoints (with foreground + bandwidth signals); the Machine Agent already runs on servers and can additionally report inventory. See the Machine Agent docs and the Fleet and Discovery vs Targeted articles in this category.
Release notes and version history
The current release is Scout v0.6.1 (the server-side collector, the Machine Agent, is at v0.5.0). Every release, its date and its highlights are listed in the product under Inventory → Agents → Release notes, and in each artifact's drawer under Resources → Downloads.
v0.6.1 makes the preconfigured installer restart the service after it writes your configuration, so a freshly deployed machine enrols with your token and joins your fleet group on the first try. v0.6.0 is a breaking change for legacy configurations: an agent still configured with an org-wide api_key, or with username / password, will not start after the upgrade. Scout v0.5.0 and earlier keep working against the platform, so the migration can be paced — but each machine must be moved to an enrollment token before its agent is upgraded. See Installation and enrollment. The Machine Agent is unaffected and still supports an ingest api_key.
Note: The whole capability is gated by the operator inventory feature. Where it is not enabled, none of these surfaces appear.