1.2 Tanium Platform Components, Client Registration and Linear Chain Peering

1.2 Tanium Platform Components, Client Registration and Linear Chain Peering

Quick overview: Tanium's speed at scale comes from a small number of server-side components and one lightweight client that talks to its neighbours rather than to the server. Endpoints form linear chains inside a subnet. A backward leader and a forward leader terminate each chain and are the only clients that hold direct server connections outside registration. Everything else — questions, answers, action files — travels over the LAN between peers on TCP port 17472.

---

Why the architecture matters for an operator

Every operational behaviour you will be tested on is downstream of this design. Results arrive in seconds because sensors run locally and answers aggregate along the chain. Some endpoints never answer because they are offline, not because the query failed. A 2 GB software payload can reach 5,000 branch-office endpoints without saturating the branch's WAN link because only one client pulls it across the link. Learn the components once and the operational behaviour stops being surprising.

---

Server-side components

Tanium Server (or Tanium Cloud)

The Tanium Server is the control plane. It holds the object database — sensors, packages, saved questions, computer groups, content sets, roles and users — issues questions, aggregates answers, and signs content before distribution. Tanium Cloud is the Tanium-hosted equivalent; from the console the operator experience is the same, and the TCA credential is explicitly scoped to Tanium Cloud environments.

Tanium Module Server

The Module Server hosts the solution modules — Deploy, Patch, Asset, Comply, Threat Response, Reporting, Discover and the rest — plus their services and stored data. Separating module workloads from the core query engine keeps question handling fast while a module runs a heavy background job.

Tanium Zone Server and Zone Server Hub

The Zone Server sits in a DMZ or public-cloud perimeter and accepts connections from clients that cannot reach the internal Tanium Server directly — roaming laptops, third-party-managed networks, isolated sites. The Zone Server Hub sits inside the trusted network and connects outbound to the Zone Server, so no inbound firewall rule from the DMZ into the internal network is required. Zone Server traffic uses the same TCP port 17472.

Satellites

A satellite is a specific Tanium Client that you designate to run targeted, secure workloads on behalf of the Module Server — for example non-line-of-sight scans in Discover, or remote authenticated scans in Comply. Because the server may send sensitive data such as credentials to a satellite, satellites are verified explicitly, and that sensitive data is never sent through the linear chain nor stored on disk on the satellite.

---

The Tanium Client

The Tanium Client is a single lightweight agent that runs as a service or daemon on Windows, macOS, Linux, AIX and Solaris. One agent covers inventory, patching, compliance, threat detection and response, so endpoints do not accumulate one agent per function.

---

Registration: how a client stays current

Registration is the mechanism that keeps a client's settings, peer list and content definitions fresh. There are two kinds, and the intervals are worth committing to memory because they explain the lag you will see in the console.

[!IMPORTANT] In large environments, normal registrations are the primary way Tanium Clients receive new questions, actions and settings — not the linear chain alone. This is why a newly deployed scheduled action can take up to about 90 seconds to reach a quiet endpoint even though the fleet is healthy.

---

Linear chain peering

Clients in the same subnet form a linear chain: a sequence of peers holding continuous connections to their immediate neighbours. During registration the server hands each client a peer list, and the client uses it to select the most optimal neighbours.

Forward and backward leaders

                 Tanium Server / Zone Server
                    |                    ^
     questions,     |                    |   answers, scheduled
     sensors,       v                    |   action statuses
     scheduled   +----------+   +--------+-+   +----------+   +----------+
     actions --> | BACKWARD |-->|   peer   |-->|   peer   |-->| FORWARD  |
                 |  LEADER  |   |          |   |          |   |  LEADER  |
                 +----------+   +----------+   +----------+   +----------+
                 lowest IP in                                 highest IP in
                 the chain (typical)                          the chain (typical)
                 <------------------ LAN peer connections ------------------>

By design, one forward leader and one backward leader terminate opposite ends of the linear chain. Other than at registration, only leaders establish direct connections with the Tanium Server or Zone Server.

• The server passes sensors, questions and scheduled actions to the backward leader, which passes them to its forward peer, and so on along the chain until they reach the forward leader.
• The forward leader returns the question answers and the scheduled action statuses to the server.
• The backward leader typically has the lowest IP address in its chain; the forward leader typically has the highest.

Forward and backward reflection

Peering has to survive endpoints appearing, disappearing and being firewalled. Forward reflection occurs when a client cannot establish an outgoing connection to a forward peer: it connects forward to the server instead and becomes a forward leader. Backward reflection is the mirror case — the client connects backward to the server and becomes a backward leader. Reflection is a recovery behaviour, not a fixed role; a subnet with many leaders usually means peering is being blocked and is worth investigating.

Neighborhood leaders

When a linear chain reaches its maximum size, additional clients are designated neighborhood leaders, which keeps individual chains bounded in very large flat subnets.

---

File distribution and chunk caching

Actions frequently carry files — an installer, a patch, a script bundle. Tanium does not push those files to every endpoint.

1. The Tanium Server sends the files only to the backward leader of each linear chain (through a Zone Server where one is deployed).
2. Each backward leader relays the files over the LAN from one forward peer to the next until they reach the forward leader.
3. Files move as small pieces called chunks. Each client keeps a local cache of chunks the chain has already distributed, so when the same files are requested again — a recurring action, for example — clients reuse cached chunks instead of asking the server to redistribute.

The operational payoff: the WAN link to a branch office carries roughly one copy of a payload rather than one copy per endpoint.

---

Real-time answers versus stored answers

An operator chooses live questioning when ground truth right now is what matters, and TDS-backed views when the question is "what does the whole fleet look like, including the laptops that are shut". Chapter 5 covers TDS and module history in detail.