Fleet: Agents, Groups, and Rulesets
Central configuration composed from Agents, Groups, and Rulesets — including the six Default rulesets, adding a process to a group, and their patterns.
Central configuration, not per-machine TOML
A fleet of hundreds of endpoints cannot be configured by hand. With use_central_config = true (the default) agents get their tracking config from VerOps automatically. What they track is composed centrally in the UI from three concepts, each building on the last:
| Concept | What it is |
|---|---|
| Agents | The fleet, segregated into Servers and Workstations so you reason about the two device classes independently. |
| Groups | Named segments (e.g. Marketing, Finance, Servers). An agent belongs to a group. |
| Rulesets | Reusable, named lists of match patterns (e.g. Communication). Groups reference one or more rulesets; the union of their patterns becomes the group's targeted set. |
How agents pick up their config
Groups and rulesets are managed in the VerOps UI; agents pick up changes automatically. You never touch per-machine files to change what a group tracks — edit the group or its rulesets in the UI and enrolled agents apply the new set on their own, then report under it. Changes take effect within about a minute.
Default rulesets
When an organization is granted Inventory, the platform's default rulesets are provisioned into it as editable copies tagged "Default". There are no shared, read-only templates to clone anymore — these copies belong to your org from day one. A pattern matches when it appears as a case-insensitive substring of an executable's name or path.
| Default ruleset | Covers | Example patterns |
|---|---|---|
| Design suite | Creative / design apps | photoshop, illustrator, indesign, aftereffects, premiere, figma, sketchup |
| Developer tools | IDEs and dev utilities | idea, pycharm, webstorm, goland, rider, clion, datagrip, code, sublime_text, postman, gitkraken, docker |
| Communication | Chat and conferencing | slack, teams, ms-teams, zoom, discord |
| Remote access | Remote desktop / support | teamviewer, anydesk, rustdesk, vnc |
| Security tools | Endpoint protection / EDR | sophos, crowdstrike, sentinelone, defender, mpdefendercore |
| Microsoft Office | Office productivity | winword, excel, powerpnt, outlook, onenote |
Because they are ordinary org rulesets (just flagged Default), you can edit or delete them like any ruleset you author yourself, and existing groups' attachments point straight at these editable copies — so an edit takes effect without any clone step.
Add a process to a group
You do not have to open the ruleset editor to start tracking one more application. In Inventory → Groups, select a group and use "Add process" to attach a tracked-process pattern directly onto that group — it lands in the group's own editable ruleset. The group detail also shows the effective Tracked processes list (the union of every ruleset attached to the group), so you can see at a glance exactly what that group tracks.
Beyond tracking: collection policy
Groups and rulesets decide which processes are tracked. As of Scout v0.3.0 a second central lever, the collection policy (Inventory → Policy), decides everything else an agent collects and how often: the collector modules (hardware, installed software, users, network), the polling and heartbeat cadence, and the refresh hours for the expensive scans. Like ruleset changes, a policy edit is applied by agents on their next poll — no reinstall. See Collection policy and presence.
Recommendations
- Start from the Default rulesets; edit and trim them in place rather than authoring from scratch.
- Name groups after the org unit (Marketing), not the tooling (Adobe-users), so membership survives tooling changes.
- Keep a Security tools and a Remote access ruleset on every group — those categories matter for risk regardless of department.
Warning: Patterns are substrings — keep them specific. A pattern likeofficeis broader than it looks and can over-match; prefer precise tokens such aswinwordandpowerpnt.