TCO cheat sheet

Architecture chain: Tanium Server -> Zone Server(s) -> Tanium Clients. Each client keeps persistent connections to a small number of neighbors, so a few thousand server-side connections can serve a very large estate.

The Tanium Client runs as a service with an always-on session; questions and actions are delivered in seconds rather than on a polling interval.

Core modules: Interact (ask questions) and Deploy (packages and actions). Content modules include Patch, Comply, Threat Response, Asset, Discover, and Trends.

RBAC = role (which actions a user may perform) + content set (which objects a user may see). Both are assigned to user groups; a persona bundles the two.

Content is defined once on the server and distributed down the chain; clients cache sensors, packages, and files locally, so repeated use does not re-consume bandwidth.

Default communication port is TCP 17472 for client-to-client and client-to-zone-server traffic; console and API access use HTTPS on 443.

Content set access decides visibility: a user without access to a sensor's content set cannot see or ask that sensor, even with full deploy permissions.

Tanium is ask-driven: the server stores configuration, question history, and cached results, but no data exists unless a question asked endpoints for it.

A question = one or more sensors + a target (All Computers or a computer group) + optional filters. The ask box autocompletes from sensors available in the user's content sets.

Results are one row per endpoint per unique combination of sensor values; multi-row sensors such as Installed Applications produce many rows for a single endpoint.

Questions expire after a TTL. Endpoints answering before expiry contribute results; after expiry the data is stale and the question must be re-asked or saved.

Filters restrict which returned rows are displayed (for example, OS contains Server). They do not reduce the endpoint work already performed by the sensors.

Targeting rule: use All Computers for estate-wide inventory, and a computer group when the question is expensive or only relevant to a subset.

Cost scales with sensors x endpoints: fewer sensors and tighter groups for frequently repeated questions keep chain load low.

Question status shows endpoints answered versus the estimated total; unresolved endpoints are typically offline or reachable only through a slow link.

Row drill-down exposes full details for a single endpoint and provides a pivot into deploying an action against it.

Results can be exported from Interact to CSV, JSON, or XML for sharing or external analysis.

Package = files + command line + typed parameters. Action = package + target + schedule/expiration + approval state + optional verification.

Parameters are referenced positionally in the command line as $1, $2, and so on; values are supplied at deploy time, so one package serves many cases.

Target selection: endpoints from current question results (a snapshot), a computer group (membership resolves at run time), or all computers.

Deploying from question results reaches only the endpoints present in those results at that moment; endpoints appearing later are not included.

Action lifecycle: pending -> active -> complete (with success and failure counts), expired, or stopped.

Expiration window: the action stays available until its end time, so late-reporting endpoints still run it. Stopping halts further distribution but does not roll back completed runs.

Verification attaches a sensor and expected value as success criteria, so endpoints report pass or fail and you can confirm the change took effect.

If action approval is enabled, an authorized approver must approve before any endpoint receives the action; unapproved actions remain pending.

Package files are uploaded to the server once and distributed peer-to-peer with client-side caching, so redeploying the same package reuses cached content.

A sensor is a named, platform-specific query definition that returns either a single value or many rows per endpoint.

Parameterized sensors accept input at ask time (for example a folder path); the supplied input becomes part of the saved question's definition.

A saved question stores sensors, filters, and targeting, and can be re-issued on demand, run on a schedule, or reused as a data source by other modules.

Scheduling a saved question re-runs it at a fixed interval; each run creates a fresh result set, so the interval governs both data freshness and collection cost.

Sensors belong to content sets; users see and can ask only sensors whose content sets are assigned to them.

Multi-row sensors inflate result volume: filter on the sensor or narrow the target group to keep result sets and chain traffic manageable.

Saved questions are the standard reusable input for Trends panels and Connect sources; consistent naming and descriptions make them discoverable to other admins.

Filters saved with a question are reapplied on every scheduled run, so the result scope of a scheduled question stays consistent over time.

Data flow for dashboards: saved question -> scheduled collection -> Trends source -> panel -> board. If the saved question breaks or is deleted, panels go blank or stale.

Panel collection interval must be chosen against the board's time window: short intervals give detail but multiply collection runs and stored data points.

Interact exports (CSV/JSON/XML) are point-in-time snapshots; for recurring delivery, combine a scheduled saved question with a Connect connection.

Tanium Connect moves data from Tanium sources to external destinations such as S3, ODBC databases, or SIEM platforms on a defined schedule.

Before trusting any compliance percentage, confirm coverage with a client-status count of installed versus connected endpoints, because offline endpoints are absent from results, not counted as non-compliant.

Compare action completion counts (success/failure) against post-action verification sensor results to distinguish 'the action ran' from 'the change took effect'.

Any metric derived from a question describes only the endpoints that answered it; state the answered-endpoint count alongside the metric when reporting.