Install the inventory agent

Put VerOps Scout on a workstation: the preconfigured installer from Inventory → Agents → Deploy Scout (recommended), the generic Windows installer, the Linux tarball, or the Machine Agent's inventory module for servers — then verify the machine is enrolled and reporting.

itaminventoryscoutinstallinstallationinstallerwizarddeployenrollmentenrollment-tokenwindowslinuxserviceverify0.6.2cloned-imagesysprepmachineguid

The quickest way to get a machine into the inventory is the preconfigured installer: in app.verops.io open Inventory → Agents and click Deploy Scout. Pick the platform, choose the fleet group the machine should land in, and download the installer built for your organization. It already carries your backend URL, your organization and a limited-use enrollment token — run it and the machine shows up under Inventory → Agents within a few minutes, with nothing to type on the endpoint.

The generic installers below produce exactly the same agent and the same service. Use them when you distribute software through your own tooling and prefer to supply the configuration yourself, or on Linux.

Before you start

  1. The right permission. Minting enrollment tokens and downloading a preconfigured installer requires inventory.manage; seeing the result requires inventory.view.
  2. A fleet group. Decide the group each machine belongs to before you deploy — the group drives collection policy, tracking rulesets and license scoping, and it is set at enrollment. Moving a machine later is possible (re-deploy it), but deciding first is cheaper than re-grouping a thousand machines afterwards.
  3. An enrollment token. The wizard mints one for you. A token has an expiry and a machine limit: each distinct machine that enrolls takes one seat, and re-deploying a machine that is already enrolled does not spend another. Size the limit to the rollout wave it is for, not to the whole estate.
  4. The right agent for the machine. Scout is for workstations and laptops. A server that already runs the Machine Agent should not get Scout as well — enable the Machine Agent's inventory module instead; it reports into the same estate under the same policy.
Watch out: from Scout v0.6.0 the enrollment token is the only credential the agent accepts. An org-wide ingest api_key, or a username / password, in scout.toml stops the agent from starting. If you are upgrading machines configured the old way, read Upgrading an existing fleet first.

Choose your install path

Path Platform You supply Best for
Preconfigured installer (Inventory → Agents → Deploy Scout) Windows Nothing — configuration and token are embedded Almost every rollout. Push it through Intune, SCCM, GPO or any software distribution tool.
Generic Windows installer (Downloads → Fleet Agents) Windows A scout.toml with the backend URL and an enrollment token, or SCOUT_* environment variables Image-based or MDM-scripted deployments where you already manage config files.
Linux tarball (Downloads → Fleet Agents) Linux (x86_64, statically linked — no glibc requirement) The same scout.toml, or flags to install.sh Linux workstations.
Machine Agent inventory module Servers One line in the Machine Agent config Any machine that already runs the Machine Agent.

Install with the preconfigured installer (Windows)

  1. Inventory → Agents → Deploy Scout. Choose Windows, pick the fleet group, and set the token's expiry and machine limit for this wave.
  2. Download the installer. It is a Windows setup wizard named VerOps-Scout-Setup-<version>.exe with your organization's scout.toml inside.
  3. Run it on the machine — interactively, or silently for fleets:
    VerOps-Scout-Setup-<version>.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART

The installer registers the VerOpsScout Windows service (LocalSystem, automatic start, crash recovery), writes your configuration to C:\ProgramData\VerOps\Scout\scout.toml, and restarts the service onto that configuration, so the machine enrolls with your token and lands in your group on the first attempt. On first start the agent exchanges the token for its own per-device credential, which it keeps locally; the token is irrelevant to that machine from then on.

Re-running the installer on an enrolled machine is safe. The agent notices the token changed, re-enrolls, and keeps its identity and history — that is the normal way to move a machine to another group or refresh its credential.

Install with the generic Windows installer

  1. Download VerOps-Scout-Setup-<version>.exe from Downloads → Fleet Agents and run it. The service is registered and started; until it has a token it idles and retries, logging why.
  2. Start Menu → VerOps Scout → Configure Scout opens C:\ProgramData\VerOps\Scout\scout.toml. Set backend_url and an enrollment_token minted under Inventory → Agents → Deploy Scout, and optionally a group:
    backend_url = "https://app.verops.io"
    enrollment_token = "sce_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    group = "Workstations"
  3. Restart the service — scout.toml is read once at startup: Start Menu → Enable & Start Scout, or sc stop VerOpsScout & sc start VerOpsScout.

For unattended installs, push a pre-filled scout.toml to C:\ProgramData\VerOps\Scout\ before or after the silent install and restart the service, or set the equivalent SCOUT_BACKEND_URL, SCOUT_ENROLLMENT_TOKEN and SCOUT_GROUP environment variables for the service.

Install on Linux

verops-scout-linux-<version>.tar.gz contains install.sh and a systemd unit. It places the binary at /usr/local/bin/verops-scout, the config at /etc/verops/scout.toml, and installs the verops-scout service enabled and started:

# One-shot: install, configure, enroll and start in a single command
sudo ./install.sh --org acme --enroll-token sce_xxxx --group Workstations

# Or interactively: install, then edit the config and restart
sudo ./install.sh
sudo nano /etc/verops/scout.toml     # set backend_url + enrollment_token
sudo systemctl restart verops-scout

# Remove the agent, service and config
sudo ./install.sh --uninstall

Follow the log with journalctl -u verops-scout -f.

Verify it works

  1. The service is running. Windows: Start Menu → VerOps Scout → Scout Status should report STATE: RUNNING. Linux: systemctl status verops-scout.
  2. It enrolled. In the log (View Scout Log on Windows, journalctl -u verops-scout on Linux) look for a line like
    applied config 83c4c528: mode=targeted patterns=5 interval=15s heartbeat=300s
    followed by its first report. A report [full]: 0 apps line is correct when nothing tracked is running — it proves targeting works, not that the agent is broken.
  3. It is in the inventory. Inventory → Agents lists the machine as online and enrolled, in the group you chose. The host itself appears under Inventory → Devices, and the token's Machines count on the Deploy Scout dialog has gone up by one.

If the machine does not appear, or shows Not enrolled, the token is the first thing to check — expired, or at its machine limit — and the agent log names the reason. A machine flagged Re-enrolling on the Agents tab cannot save its state file (%ProgramData%\VerOps\Scout\scout-state.toml or /etc/verops/scout-state.toml) and enrolls again on every restart; fix the permissions or anti-virus exclusion on that machine, because every re-enrollment of a machine that lost its state spends a token seat. The full list is in Troubleshooting.

Upgrading

Upgrading an enrolled agent needs no re-enrollment: the device credential survives, and the installer restarts the service for you. From v0.5.0 the agents can update themselves once an admin enables a release channel under Inventory → Agents → Auto-update and the machine's config says auto_update = true — both switches are required, both are off by default. See Automatic updates. The current release is Scout v0.6.2; the version each machine runs is shown on the Agents tab and in the hosts inventory report export.

Machines imaged from one golden image

Windows deployed from a single image without sysprep /generalize gives every machine the same MachineGuid. Scout uses that GUID as the machine's stable identity, so until v0.6.2 such a fleet could collapse into one asset: each machine's report overwrote the previous one's hostname, user and software list, and the machines revoked each other's device credential in a loop. The platform now tells clones apart by their hardware serial, then by the SMBIOS system UUID, and Scout v0.6.2 reads both from firmware so they are always present. To check a fleet, run this on any two machines and compare — the same GUID with different serials is the signature:

"$env:COMPUTERNAME  MachineGuid=$((Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Cryptography').MachineGuid)  Serial=$((Get-CimInstance Win32_BIOS).SerialNumber)"

Regenerating the image with sysprep is still the right long-term fix — other software keys on that GUID too — but VerOps no longer depends on it.

Next steps

  • Deploying Scout at scale — the rollout order (import first, then agents), pilot groups, coverage checks, and retirement with credential revocation.
  • Enrollment and device credentials — the two credentials, revocation, and migrating a config that still names api_key.
  • Scout installation reference — every configuration key, the SCOUT_* overrides, where the agent looks for its config, and running in the interactive session for foreground-focus detection.
  • Presence: office and remote — set your trusted office networks so presence is measured from day one.