Operating System Inventory

For every managed machine, Athena records what operating system it runs — the product name and edition, the version and build number, the CPU architecture, when it was installed, its domain membership, and whether it is a server or a desktop edition. That gives you a single, fleet-wide answer to questions like "how many machines are still on an old Windows build?", "which servers run which edition?" or "which Linux distributions are in the estate?" — without logging in to each device.

What's collected#

Each machine reports a single operating-system record with the following fields. Any field the machine can't provide is simply left blank rather than guessed.

Where to see it#

Open a machine from the Agents list, then in the agent detail view's left-hand navigation choose the Operating System section (under the System group, alongside Overview, Hardware and Boot & Security). It lists the product name, edition, version, build, architecture, install date and domain for that machine.

As with the rest of inventory, the values reflect the machine's last successful collection on its regular reporting cadence rather than a live query at open time. For the wider inventory surface and refresh behaviour, see Inventory.

Platform coverage#

The operating system is inventoried on both Windows and Linux endpoints using each OS's own native facilities, so a mixed fleet answers the same questions consistently — though a few fields are naturally platform-specific.

Auditing across the fleet#

The operating system is one of the most useful things to target on, and Athena exposes it as filter fields you can build fleet-wide rules and reports on:

• OperatingSystem matches on the OS family (for example Windows vs a Linux family) — use it for broad "all Windows machines" style targeting.
• OSVersion matches on the more specific version string, so you can isolate an exact release or build.

Use these in dynamic collections, automatic tagging rules, device monitors and the report builder's row filters. For the exact operator-per-field rules and the difference between OS family and version, see the Filter Field Reference. Because these fields are shared, a collection of, say, "all Windows Server machines still on an older build" can drive a deployment, a compliance baseline, or a scheduled report.

Reading it over the API#

The operating system has its own inventory endpoint. Request it for one agent and read the returned record:

# Fetch the operating-system inventory for one agent
$headers = @{ Authorization = "Bearer $token" }

$os = Invoke-RestMethod `
  -Uri "https://athena.example.com:8443/api/agents/$agentId/inventory/os" `
  -Headers $headers `
  -SkipCertificateCheck

$os.data |
  Select-Object productName, displayVersion, osVersion, osBuild, osSku, architecture, domain, isServerOs

From the PowerShell module, the same data is available with a dedicated cmdlet, which also accepts an agent from the pipeline:

# Same data via the module
Get-AthenaAgentOperatingSystem -AgentId $agentId

# Summarise the OS product and build across the whole fleet
Get-AthenaAgent | ForEach-Object {
  $o = Get-AthenaAgentOperatingSystem -AgentId $_.Id
  [PSCustomObject]@{ Hostname = $_.Hostname; Product = $o.ProductName; Build = $o.OsBuild }
}

The same OS record is also included in an agent's full inventory document (GET api/agents/{agentId}/inventory) under the operatingSystem object. Reading inventory requires the Helpdesk role or higher. The endpoint returns 404 when a machine has not yet reported its OS data. For the full inventory surface and the module reference, see Inventory and the PowerShell Module.