Tanium Platform Fundamentals
The shape of a Tanium deployment
Every Tanium environment is built around a single lightweight agent, the Tanium Client, installed on each managed endpoint, plus a server tier that answers questions and delivers actions. The server tier has three parts you must keep separate: the Tanium Server (the core service and its database, which holds configuration, saved content, and user accounts), the Module Server (hosts module services such as Deploy, Patch, Comply, Trends and Connect, and does the heavier processing), and the Zone Server (an optional aggregation point for remote or segmented networks).
Clients do not wait for inbound connections. They initiate outbound communication to the server (TCP 17472 by default) and can relay traffic for one another in a peer-to-peer chain, which is why a Tanium deployment scales to large estates without a fan-in of inbound firewall rules on every endpoint. Content - sensors, packages, saved questions - is distributed from the server down to clients and cached locally.
Around this core sit modules (Interact, Deploy, Asset, Patch, Threat Response, Trends, Connect, Reporting and others), computer groups (static lists, or dynamic groups defined by a question/filter), and RBAC constructs: roles, personas, and content sets that limit which users see which content and which endpoints they can target.
Traps to watch: the Module Server is not the database; the Tanium Server does not poll endpoints like a legacy management console; and clients are never required to accept inbound connections. Options describing "the server reaching out to each endpoint" are usually wrong.
Rule of thumb: if a remote site has a slow or unreliable WAN link, the answer is usually a Zone Server - not more bandwidth, and not a second Tanium Server.