Tanium Core Platform Servers overview

This guide describes requirements and procedures for installing the following Tanium™ Core Platform servers on customer-provided Windows infrastructure.

  • Tanium™ Server
  • Tanium™ Module Server
  • Tanium™ Zone Server (including the Tanium™ Zone Server Hub)

Tanium Infrastructure types

Tanium Core Platform servers support the following infrastructure options:

  • Hardened physical or virtual Tanium Appliance (recommended): See the Tanium Appliance Installation Guide.
  • Windows installation on customer-provided hardware, as described in this guide.

Tanium Server

The Tanium Server is the server that communicates with Tanium™ Clients, other Tanium Core Platform servers, and the content.tanium.com servers that host Tanium content packs. Tanium Clients communicate with the Tanium Server directly or through a Tanium Zone Server that acts as a proxy. The Tanium Server also runs the Tanium™ Console and API services.

You can install the Tanium Server on a dedicated host that is separate from the Tanium Module Server and database server, or on an all-in-one host that all three servers share. Use a dedicated host for enterprise production and lab environments (see Tanium Core Platform topology); the all-in-one architecture is just for proof-of-concept deployments.

You can deploy two Tanium Servers in an active-active high availability (HA) cluster to ensure continuous availability in the event of an outage or scheduled maintenance. HA deployments have the following characteristics:

Tanium Client connections

Tanium Clients use a Tanium Server list to automatically find a backup server if the primary Tanium Server assigned to them is unavailable.

Shared database

Tanium Servers in an HA cluster read and write to one shared database. Each server creates an entry for itself in the tanium database that identifies it to the other servers in the cluster. Follow database administration best practices to ensure availability of the database server and to ensure that the Tanium databases and related database objects are backed up routinely.

Tanium Console

Each HA cluster member has a Tanium Console with its own URL.

Tanium™ solution modules

The modules are installed on a Tanium Module Server that all the Tanium Servers in an HA cluster share. However, to make the modules available in all the Tanium Servers, you must import the modules through the Tanium Console of each cluster member. The Module Server does not support HA.

HA cluster communication

Each Tanium Server passes Tanium messages (such as answers to questions) and package files to the other HA cluster members over port 17472. When you upload package files to a Tanium Server, it automatically synchronizes the files to the other HA cluster members.

HA clustering is not required to scale Tanium capacity or improve performance. You can resize the host system hardware and operating systems of standalone Tanium Core Platform servers to meet your capacity and performance requirements. For details, see Reference: Host system sizing guidelines.

To install a standalone (non-HA) Tanium Server on a dedicated Windows Server host, see Installing the Tanium Server. To install Tanium Servers in an HA deployment, see Installing the Tanium Server in an active-active HA cluster.

Tanium Module Server

The Tanium Module Server runs application services and stores files for Tanium solution modules, such as Tanium™ Patch. Tanium administrators can use the Tanium Console to manage and use solution modules. The Module Server communicates directly only with the Tanium Server. Endpoints receive packages through the Tanium Server or Zone Server.

In production deployments, you install the Module Server on a dedicated host (not shared with the Tanium Server) to prevent intentional or accidental scripts from having a direct impact on the Tanium Server. For the procedure, see Installing the Tanium Module Server.

In a limited proof-of-concept (POC) deployment only, you can install the Module Server and Tanium Server on the same host.

Tanium Zone Server

In Tanium deployments, Tanium Clients initiate connections with the Tanium Server. However, enterprise network security policies typically do not allow endpoints that reside in an external, untrusted network to initiate connections to resources such as the Tanium Server that reside in a trusted, internal network. To enable the Tanium Server to manage external endpoints, deploy one or more Tanium Zone Servers in your DMZ to proxy communication from the external endpoints. For the procedure, see Installing the Tanium Zone Server.

The following figure illustrates Zone Server communication. The Zone Server is installed as a service, typically on an existing, shared device in the DMZ. It communicates with the Tanium Server through a Tanium Zone Server Hub process that you install on a host computer in the internal network, typically the Tanium Server host computer. You configure Tanium Clients on external endpoints to register with the Zone Server as if it were the primary Tanium Server.

Figure  1:  Zone Server deployment

To optimize Tanium system performance, the Tanium Zone Server caches sensor definitions, configuration information, package files associated with actions, and files requested through the Tanium Client API. It provides these resources to Tanium Clients without having to re-request them from the Tanium Server. If necessary to prevent over-consumption of disk space on the Zone Server, you can configure a maximum cache size: see Limit Zone Serve cache storage.

When using Tanium to manage external endpoints, be mindful that they might not have the same access to internal resources as internal endpoints. Target actions so that Tanium Clients on external endpoints do not attempt to access resources on the internal network, like an Active Directory server, or package files staged on an internal URL.

Tanium Core Platform topology

In an enterprise production deployment, the Tanium Server, Tanium Module Server, and database server must reside on separate hosts, as illustrated in the following figure. In a limited proof-of-concept (POC) deployment, these three servers reside on the same host. However, the POC architecture is intended for demonstration purposes only and does not support enterprise deployments. As a best practice, use the production environment architecture for the enterprise lab environment that you use to qualify software upgrades and test content solutions.

Figure  2:  Enterprise production or enterprise lab deployment

Other resources

Release Notes

Support Knowledge Base
(login required)

Last updated: 11/12/2019 3:30 PM | Feedback