Frequently asked questions

Frequently asked questions

Does Scout send my file contents, keystrokes, or screen?

No. Scout observes which applications run and their per-process activity and bandwidth signals. It reports executable names, versions, owners, activity levels, and byte counts — never file contents, keystrokes, or screen data. It is an inventory agent, not an EDR or a surveillance tool.

What's the difference between Scout and the Machine Agent?

Scout is for user endpoints (desktops/laptops) and adds foreground + bandwidth signals; the Machine Agent's inventory module is for servers and reports the same inventory as a server, with activity capped at level 2. One estate, two collectors — see the Scout vs Machine Agent article.

Why does a fresh agent report "0 apps"?

In targeted mode, report [full]: 0 apps in the agent log means none of the group's tracked patterns are currently running — correct behavior, not a fault.

Why is bandwidth always 0?

On Windows, per-app bandwidth (IPv4 + IPv6) needs Administrator — the installed VerOpsScout service runs elevated, so this mainly affects hand-run agents. On Linux (v0.3.0+) it is read from the kernel's per-socket TCP counters via ss and works as the root service. Either way the numbers are a TCP-only lower bound: UDP/QUIC traffic isn't counted, and loopback traffic is excluded.

What is an enrollment token, and what is a device key?

An enrollment token (sce_…, minted under Inventory → Agents → Deploy Scout) is a limited-use, expiring bootstrap secret — the only credential you ever put in a scout.toml. On first start the agent exchanges it for a device key (scd_…) — a private, per-device credential stored in the agent's state file and revocable individually from Inventory → Agents. The token is not needed after enrollment. See Enrollment and device credentials.

Can Scout use an ingest API key instead?

No. Since v0.6.0, enrollment is the only way a Scout authenticates — api_key, username and password were removed from the agent, and a config that still names one makes the agent refuse to start (a configuration error, EX_CONFIG / exit 78, naming the file and the offending keys). Scout v0.5.0 and earlier keep working against the platform, so you can migrate at your own pace — but each machine must move to an enrollment token before its agent is upgraded. Re-deploying from Inventory → Agents → Deploy Scout does it in one step. See Enrollment and device credentials.

Does this mean I should remove api_key from my Machine Agent config too?

No — leave it alone. The Machine Agent (v0.5.0) is unchanged: its inventory module still supports an ingest api_key, and its own machine connection key is untouched. The two agents genuinely differ now; the platform tells them apart by the X-Agent-Kind header each one sends, and refuses API-key auth only for scout.

What happens if I re-deploy Scout to a machine that already has it?

It re-enrols. From v0.6.0 the agent remembers which enrollment token it used and notices when a new package writes a different one, so re-deploying refreshes the credential and applies the new fleet group while keeping the machine's identity and history. Re-running a package with the same token changes nothing, so it is safe to repeat. This is the recommended way to migrate a machine off a legacy configuration or move it between groups.

Can VerOps tell whether a device is in the office?

It reports network-based presence: office (with a location), remote, or unknown, inferred by matching the device's network facts (Wi-Fi SSID/BSSID, IP ranges, gateway MAC) against the trusted office networks your organization defines. It is a network signal — never a guarantee that a person is physically present. See Collection policy and presence.

Can I turn off collection of hardware, installed software, users, or network facts?

Yes — each collector module can be switched off centrally in the collection policy (Inventory → Policy), per organization or per group, applied on the agents' next poll without a reinstall. Local [modules] switches in scout.toml exist too, but the server-side policy wins while central config is active.

How do I track a machine independently of central config?

Set use_central_config = false to return the agent to pure local control via its scout.toml processes list.

How often does the estate update?

Agents report on start, on a regular heartbeat, and immediately whenever something changes, so the estate stays close to live. Central config changes you make in the UI are picked up automatically within about a minute.

What does "Utilization %" actually mean?

It is real active use — foreground, CPU, or network, not just an open window — divided by a standard workday of 8 business hours. So 4 active hours in a day reads as about 50%. Normalizing to a workday lets you compare tools and people fairly regardless of how long an app was left open. Secondary views show the same usage as a percentage of days active or of monitored time.

What window do the Products numbers cover?

Whatever you select — last 7 days, 30 days, 90 days, 6 months, or 12 months. Every column (hours used, days active, sessions, active devices, trend) is measured over that window, and the trend compares the recent half of it against the earlier half.

How do I find tools nobody uses?

Use the "Installed, unused" filter on Products: it lists tools that are installed on devices but saw no use in the selected window — the clearest candidates to remove or reassign. You can also ask Vera which tools are installed but never opened.

What's the difference between Stale and Retired hosts?

Stale is automatic: a host that hasn't reported for more than 14 days is flagged Stale (with the day count) but still counts as installed — it may simply be switched off. Retired is a deliberate admin action with a reason; a retired host drops out of installed/active counts and license reconciliation but keeps its history and can be un-retired at any time.

Does retiring or replacing a device erase its usage history?

No. Historical usage is preserved even after a device is retired. Current views show only active devices, but historical reports still include the retired ones, so trends do not shift merely because a machine was swapped out.

What are tags, and what does the sys: prefix mean?

Tags are key:value labels you attach to hosts — department:marketing, building:london-hq, owner:jsmith — for grouping, filtering, and reporting. Most are free-form and entirely yours. Tags whose key starts with sys: are system tags the platform understands and acts on (such as a host's lifecycle); they are validated, so an unknown key or value is rejected rather than stored. A tag you set in the UI always takes precedence over the same tag pushed by an agent.

What is "weighted usage" and how does it differ from hours used?

Hours used is raw active time. Weighted usage grades that time by how the tool was used — foreground focus counts full (1.0), background CPU counts half (0.5), and a mere network connection counts a quarter (0.25). It gives a truer read of real engagement: an app left connected but unattended scores far lower than one actively worked in for the same wall-clock time.

What do the usage tiers (power / regular / light / inactive) mean?

They classify each device-and-tool pairing by its weighted hours over the window: Power (> 20), Regular (1–20), Light (under 1), and Inactive (none). The product detail shows the breakdown across a product's devices, so a license with mostly light and inactive users — a prime reclamation or downgrade target — stands out instead of hiding inside an average.

How does license reconciliation compute savings?

Each license records owned seats and cost per seat. Reconciliation counts installed hosts (those that have the product) and active hosts (those with real weighted usage), then potential annual savings = unused seats × cost per seat, as a yearly figure. A confidence level (high / medium / low / insufficient), derived from usage across 30-, 90-, and 180-day windows, tells you how safe it is to act on that number.

Why do two licenses for the same product show different utilization?

Because a license can be scoped to a group. A license with a scope group reconciles only against hosts in that group; one with no scope reconciles product-wide. So a 100-seat Marketing license and a 25-seat Workstations license for the same product are each measured against the hosts they actually cover, instead of both showing the same product-wide average.

How does policy enforcement work, and do violations alert me?

Every product has a policy (approved / tolerated / prohibited / needs review). The Violations tab detects where the running estate breaks it — prohibited software on a host, expired or over-threshold tolerations, and dangerous overlaps — re-evaluating on every agent report and nightly. A new violation raises a real alert to your configured channels (email, Slack, Teams, webhook, PagerDuty), deduplicated so it notifies once; the alert clears when the violation resolves. Each violation runs a status workflow (open → acknowledged → in progress → resolved, or waived with a reason) and auto-resolves when its condition clears.

What is time-boxed toleration?

Marking a product tolerated lets you set an expiry date, a maximum host count, and a migration-plan link. It's permitted until the date passes, then it auto-escalates to prohibited and starts raising violations — so a "temporary" exception can't silently become permanent. Going over the host cap raises a threshold violation in the meantime.

What counts as software redundancy, and what's a "dangerous" overlap?

Redundancy is a host running more tools in one category than its threshold allows — four design tools where one is used, say. The Redundancy tab flags these with the overlapping products (active or idle), the excess count, and the cost of the redundant seats. A dangerous overlap is redundancy in a risk-sensitive category — multiple security, VPN, or remote-access tools on one host — which causes conflicts and real operational risk, so it's elevated in red and counted separately. Thresholds are per-category and tunable; uncategorized software is never flagged.

Can I chart inventory usage on my own dashboards?

Yes. Besides the built-in inventory data source, your organization's usage is available as metrics in the inventory_ family (for example inventory_tool_runtime_hours, inventory_tool_active_devices, and inventory_category_runtime_hours, with companion series for sessions and active product/device counts) that you can plot on any custom dashboard alongside your other metrics. They are scoped to your organization and bounded to your top tools plus an "other" bucket, grouped by category and agent type.

Can Vera change my estate on its own?

No. Vera's estate tools are read-only except a single classification action, which is a proposal an admin confirms.

How do I inventory iPads and tablets?

Through MDM ingestion using an Inventory ingest API key — device identity, installed apps, and last-seen. They appear in the estate as Devices. That key belongs to the MDM integration, not to an agent; it is not something a Scout can be configured with.

Is the whole feature optional?

Yes — it is gated by the operator inventory capability. Where it is not enabled, none of these surfaces appear.

Does the update-posture module install updates or change my machines?

No. It reads cached package metadata and local logs only — it never refreshes package indexes over the network, never installs or removes anything, and needs no privileges beyond those Scout already has. On Linux the upgrade counts come from a simulated upgrade against already-downloaded package lists and cache-only package-manager calls; on Windows the build, reboot flags and service state come from the registry and the local update history, and the network-touching update search is never called. It measures; your existing patching tooling acts. See Update posture.

Can Scout update itself?

Since v0.5.0 (the current release is v0.6.1), yes — but only when two switches are on: an admin has enabled a release channel for the organization under Inventory → Agents → Auto-update, and the endpoint's own scout.toml sets auto_update = true. Both default to off, and with no policy row nothing is offered at all, so an existing fleet does not move until someone decides it should. See Automatic updates.

How risky is letting an agent replace its own binary?

Every step is written to fail closed. The target must be strictly newer; the artifact must come from the same origin as the configured backend; its SHA-256 is verified before anything is written to disk; the bytes must be an executable for that platform; and the replacement is run once (--version) and must report the expected version before it is swapped in — while the installed agent is still in place. The previous binary is kept alongside, and a new one that starts but cannot complete a report is rolled back automatically after three attempts. A rollout can also be halted from the console at any time.

I enabled a channel and nothing happened. Why?

Usually one of: the endpoints have not set auto_update = true (they log one line saying so); the rollout percentage is 0 or the agent falls outside it; the agents are already on the channel's version; or VerOps has not published a checksummed download for that exact version and platform yet, in which case the platform declines silently. Each agent's row in the Auto-update dialog shows its exact reason.

Where can I see what changed in each Scout release?

In the product: Inventory → Agents → Release notes lists every release with its date and highlights and marks the current one, and each artifact's drawer under Resources → Downloads carries the same version history.