Administration Guide

About Audit Services

An Audit Service is the in-network worker process that an AlloyScan Site uses to scan address ranges and to audit individual devices that the agentless audit method covers — Windows hosts via WMI / WinRM, Linux and macOS via SSH, hypervisors, SNMP devices, and the cloud APIs (AWS / Azure / Google).

The instance itself never connects directly to your endpoints. It instead routes scan and audit tasks to the registered Audit Service, which executes them locally and returns the result. This keeps every credential and every payload inside the customer network.

Where Audit Services live in the Admin Center

You manage Audit Services per Site, in two interchangeable entry points:

  • Admin Center > Site Settings > Tasks and services > Audit services
  • Network > Audit services

The list shows one row per registered service with Name, Id, IP address, Registration date, Last active, Updater last active date, Version, Updater version, and Expiration date. Open a row to see the Audit Service detail modal, which is split into three tabs: General, Credentials, and Tasks.

Health states

Every Audit Service moves through a small, observable lifecycle:

  • Active — the service has sent a heartbeat recently and is doing work.
  • Outdated — the service is behind the instance version. This is a soft state and a non-fatal warning. The modal title carries the suffix - outdated and the row icon shows a status marker. The service keeps running.
  • Inactive — the service has not sent a heartbeat for longer than the inactivity window (RetiredPeriod, default 30 days at this build level).
  • ScheduledForDeletion — set either automatically after the inactivity window expires or explicitly by an admin via the Schedule for deletion button on the General tab. A service that comes back online while in this state self-uninstalls; otherwise it is deleted after a further inactivity period (roughly 60 days end-to-end).

A background process named RetiredAgentsAndServices runs periodically and applies the inactivity-driven transitions. Manual deletion produces the same target state as inactivity-driven deletion, only sooner.

Versioning, separately from health

Outdated is independent of Active / Inactive. A healthy service that is behind the instance version is still Active but flagged as outdated. The exact threshold at which the instance flips a service to Outdated may vary by deployment; treat the flag as advisory and as a prompt to upgrade rather than as a hard failure.

Credentials live inside an Audit Service

Each Audit Service maintains its own credential pool, accessed through the Credentials tab on the service detail modal. See About Credentials for the full model.

How an Audit Service relates to Audit Agents

The Audit Service performs agentless audits — it logs in to the target on demand and pulls inventory. The Audit Agent is a separate worker that runs on the endpoint itself and pushes inventory back to the instance on a schedule. The two are complementary; they share the same task pipeline and surface in the same Audit log, but they are deployed and managed independently.

Limitations

  • The Audit Service detail modal does not expose configuration of the inactivity window. The RetiredPeriod default of 30 days is a per-site setting documented at the spec level; how to change it through the UI may vary by deployment.
  • The exact version-lag threshold that flips a service to Outdated is not documented at this build level.