Collection policy and presence

The central collection policy — modules, polling and heartbeat cadence, and refresh hours applied on the next poll, no reinstall — plus the v0.4.0 collector modules including patch posture, and network-inferred office/remote presence against trusted office networks.

scoutpolicymoduleshardwareinstalled-softwareusersnetworkpresenceoffice-networkswifipatch-postureupdate-posture0.4.0

Collection is a policy, not a reinstall

Scout v0.4.0 collects more than process usage — and what it collects is decided centrally, under Inventory → Policy. A policy (an org-wide default, optionally overridden per Group) controls:

  • which collection modules are on;
  • the polling and heartbeat cadence (intervalSecs / heartbeatSecs);
  • the refresh hours for the expensive scans (hardware, installed software, patch posture).

Agents apply a changed policy on their next config poll (about a minute) — no reinstall, no touching per-machine files.

The collection modules

Module What it collects Cadence
Processes Running applications and their activity (the classic Scout signal) Every sampling interval
Hardware CPU model/cores, RAM, disks, GPUs, BIOS, chassis type, battery Refreshed every 24 h (policy-tunable) and on change
Installed software Installed packages — Windows registry, dpkg, rpm — name, version, publisher, install date Refreshed every 12 h (policy-tunable) and on change
Users The current user and logged-in users (Windows Terminal Services sessions; who on Linux) Every heartbeat and on change
Network Interfaces, MACs, IPs, gateway, DNS, Wi-Fi SSID/BSSID, VPN state — the raw facts behind presence Every heartbeat and on change
Patch posture (v0.4.0) OS update state — on Windows the full build including UBR, last update installed, pending reboot, Windows Update service state and hotfix count; on Linux the package manager, upgradable and security-upgradable counts, reboot-required and last package activity. Cached metadata and local logs only — never a network refresh, never an install. Refreshed every 6 h (policy-tunable)

Patch posture is covered in full in Update posture, and the buckets and thresholds the platform derives from it in Patch posture.

Each module can also be switched off locally in scout.toml under [modules] — but when central config is active, the server-side policy wins per-field. Sections are only transmitted when their content changed or a refresh is due, so steady-state traffic stays small.

Stable machine identity

Reports carry a stable machine identity — the OS machine ID (MachineGuid on Windows, /etc/machine-id on Linux) plus the DMI serial number, manufacturer, and model. The estate keys assets on this identity, so renaming a host or re-imaging with the same hardware does not create a duplicate: history, tags, and usage stay attached to the physical machine.

Office / remote presence

With the network module on, VerOps classifies each device's presence as Office (with a location), Remote, or Unknown by matching its network facts against the trusted office networks your organization defines under Inventory → Policy:

Office network definition Matches when the device reports
Wi-Fi SSIDs / BSSIDs A connected SSID or access-point BSSID on the list
CIDR ranges Any interface IP inside a listed range
Gateway MACs The default gateway's MAC on the list

A device on none of the trusted networks — or reaching you only through a VPN — classifies as Remote. Presence changes are recorded on the asset's timeline, and the fleet split is chartable (office / remote / unknown, by location).

Note: Presence is network-inferred — it says which network the device is on, never guaranteed physical presence of a person. Treat it as an operational signal (capacity planning, on-site asset location, remote-work patterns), not an attendance record.

Where the data lands

Hardware, installed software, users, network, and presence all attach to the device's entry in the estate — visible on the host's detail page (Overview, Hardware, Software, Users, Network & Presence, History) and queryable from dashboards. Diffs become timeline events: hardware changed, software installed/removed, user changed, network changed, presence changed.