Troubleshooting

This section identifies resources that you can use when troubleshooting issues with the Tanium Client deployment.

Basic tips

Tanium Client installation paths

The following table lists the default installation paths for the Tanium Client on each operating system (OS). If you troubleshoot issues for an installation that uses a non-default path, note this when contacting Tanium Support.

 Table 1: Tanium Client default installation path
OS Installation Directory
Windows 32-bit \Program Files\Tanium\Tanium Client\
Windows 64-bit \Program Files (x86)\Tanium\Tanium Client\
macOS /Library/Tanium/TaniumClient
Linux, Solaris, AIX /opt/Tanium/TaniumClient

If your environment requires a different installation location for applications, see the Tanium Knowledge Base article How to: Using a symlink to a custom location.

Tanium Client settings

Initially, you set Tanium Client settings when installing the client. TaaS The Tanium Server or Zone Server sends setting updates when the client registers. The location of the settings varies by operating system.

Windows

On Windows endpoints, Tanium Client settings are Windows registry settings. The path to Tanium Client registry keys is HKEY_LOCAL_MACHINE\Software\Wow6432Node\Tanium\Tanium Client. Use the CLI on Windows endpoints to configure Tanium Client settings.

The Tanium Client registry key includes subkeys: Sensor Data, Status, and ValueSystem. Typically, the subkey values are set during client installation and are not subsequently modified except when Tanium actions or sensors are updated. The Status subkey holds the information that the client receives from TaaS the Tanium Server during registration.

Do not edit the values for these subkeys. The information might help you understand expected behavior when troubleshooting peering. Contact Tanium Support for more assistance.

Non-Windows

The settings are stored in an SQLite database. Use the Tanium Client CLI on Non-Windows endpoints to configure the settings.

Settings reference

Tanium Client settings are initialized upon registration or service restart.

 Table 2: Tanium Client settings
Setting Name Type (Windows) Description Modify
ComputerID REG_DWORD Value that TaaS the Tanium Server assigned to the client to uniquely identify and track each managed endpoint. No
DatabaseEpoch REG_SZ Typically, this setting indicates the date and time when TaaS the Tanium Server was deployed. No
EnableRandomListeningPort REG_DWORD TaaS does not support this setting. Enables (1) or disables (0) the randomized selection of a new listening port at intervals. The client uses the port for communications from peer clients. If another application is already using the selected port, the client selects another port immediately instead of at the next interval. For details, see Randomize listening ports. By default, EnableRandomListeningPort is disabled and the client uses a fixed listening port (default is 17472). As necessary
EnableSensorQuarantine REG_DWORD Add this setting and set the value to 1 if you want to enable the enforcement of sensor quarantines on a particular endpoint. By default, the setting is not present and enforcement is disabled. If you already added the setting, you can disable enforcement by setting the value to 0. You can also use the Tanium Console to enable or disable enforcement for all endpoints. For details, see Enable or disable enforcement of quarantined sensors. As necessary
FirstInstall REG_SZ Date and time of the initial Tanium Client installation. No
HostDomainName N/A - non-Windows only Required only when the client does not return the domain name correctly in question results. The value that you specify for this setting overrides the data that the client OS would otherwise return.

Specify just the domain portion of the fully qualified domain name (FQDN). For example, if the FQDN is host.example.com, specify example.com.

As necessary
HostFQDN N/A - non-Windows only Another option (besides HostDomainName) for cases where the client does not return the hostname and domain name correctly in question results. The value that you specify for this setting overrides the data that the client OS would otherwise return.

Specify the complete FQDN, including hostname, such as host.example.com.

As necessary
LastInstall REG_SZ Date and time of latest Tanium Client installation. No
LastGoodServerName REG_SZ The name of the TaaS instance the Tanium Server or Zone Server with which the Tanium Client last connected successfully. If the client cannot reach an instance server that the ServerNameList or ServerName setting specifies, the client tries to connect to the instance server that LastGoodServerName specifies. You do not set LastGoodServerName; the client defines it automatically.

To avoid this fallback behavior during testing, troubleshooting, or migration scenarios, delete the LastGoodServerName value.

No
ListenPort REG_DWORD This setting indicates the port (17472) on which the client listens for communications from peer clients. The default is 17472. However, if you install the client on the Tanium Server or Zone Server (Windows deployment only), the default port is 17473. If you enable EnableRandomListeningPort, do not configure ListenPort because the client overwrites the value whenever it selects a new port.
Changes to ListenPort automatically affect the Tanium Client API port, which is one port number higher. For example, if you set ListenPort to 17473, the client API port becomes 17474.

ListenPort overrides the ServerPort setting for client-client communication.

As necessary
LogFileSize REG_DWORD The size threshold in bytes that Tanium Client logs must reach before the client rotates them. As necessary
LogPath REG_SZ By default, the Tanium Client writes its logs to the <Tanium Client>/Logs subdirectory. You can use the LogPath setting to define an alternative absolute path for the logs. For example: LogPath=/tmp. As necessary
LogVerbosityLevel REG_DWORD By default, this setting is not present if you did not set the logging level when deploying the Tanium Client.

The following decimal values are best practices for specific use cases:

  • 0: Disable logging. This is the best practice value for clients installed on sensitive endpoints or virtual desktop infrastructure (VDI) endpoints.
  • 1: This is the best practice value during normal operation.
  • 41: This is the best practice value during troubleshooting.
  • 91 or higher: Enable the most detailed log levels for short periods of time only.
As necessary
Path REG_SZ (Windows only) Path to the Tanium Client installation directory. If none is specified, the Tanium Client assumes the default path for the OS.

For AIX, Linux and Solaris, you can use symbolic links. See the article on using symbolic links in the Tanium Support Knowledge Base (sign in required).

As necessary
ProxyAutoConfigAddress REG_DWORD (Windows only) The URL and file name (in the format http[s]://<PAC file URL>/<PAC file name>.pac) of a proxy auto configuration (PAC) file that the Tanium Client can access. The PAC file defines how clients connect to TaaS the Tanium Server or Zone Server: directly or through a Hypertext Transfer Protocol Secure (HTTPS) proxy server. The client downloads the file from the URL that you specify and runs a script that the file contains to select the correct proxy for connecting to a particular server. If no proxy is available, the client falls back to connecting directly with TaaS the Tanium Server or Zone Server. For details, see Configure proxy connections with a PAC file. As necessary
ProxyServers REG_DWORD The IP address or FQDN, and port number, of the HTTPS proxy server through which the Tanium Client connects to TaaS the Tanium Server or Zone Server. You can specify multiple proxies as a comma-separated list in the format "<proxy1>:<port>,...,<proxyN>:<port>". The client tries to connect to the proxies in the order that you list them. After any single connection succeeds, the client stops trying to connect with more proxies. If no proxy is available, the client falls back to connecting directly with TaaS the Tanium Server or Zone Server. For details, see Configure proxy connections without a PAC file. As necessary
RandomListeningPortExclusions REG_DWORD TaaS does not support this setting. Specifies ports that the client never selects as a listening port if you enable EnableRandomListeningPort. For example, to prevent port competition conflicts, you might specify ports that other applications use. If you specify multiple exclusions, use a comma to separate each port. By default, the client does not exclude any ports that are within the range that the RandomListeningPortMin and RandomListeningPortMax settings define. As necessary
RandomListeningPortMax REG_DWORD TaaS does not support this setting. Specifies the high end of the range of ports from which the client randomly selects a listening port if you enabled EnableRandomListeningPort. The default is port 64000. As necessary
RandomListeningPortMin REG_DWORD TaaS does not support this setting. Specifies the low end of the range of ports from which the client randomly selects a listening port if you enabled EnableRandomListeningPort. The default is port 32000. As necessary
RandomListeningPortTTLInHours REG_DWORD TaaS does not support this setting. Specifies the interval in hours at which the client selects a new listening port if you enabled EnableRandomListeningPort. The default is 24 hours. Do not set the value lower than the client reset interval, which by default is a random interval in the range of 2 to 6 hours. As necessary
RegistrationCount REG_DWORD Count of completed registrations. This value, in conjunction with the ComputerID, enables TaaS the Tanium Server to detect duplicate Computer IDs. If the RegistrationCount value that TaaS the Tanium Server maintains does not match the value that the client reports, TaaS the server assigns a new, unique ComputerID to the endpoint to resolve the apparent ComputerID duplication. For details, see Registration and ComputerID. No
ReportingTLSMode, OptionalTLSMinAttemptCount, OptionalTLSBackoffIntervalSeconds, OptionalTLSMaxBackoffSeconds, Server_ReportingTLSMode, Server_OptionalTLSMinAttemptCount, Server_OptionalTLSBackoffIntervalSeconds, Server_OptionalTLSMaxBackoffSeconds REG_DWORD TaaS automatically manages all TLS settings for the Tanium Client. Tanium Core Platform 7.2 or later supports TLS communication for connections from Tanium Clients to the Tanium Server or Zone Server. Tanium Core Platform 7.4 or later also supports TLS communication between Tanium Client 7.4 peers. For details, see the Tanium Core Platform Deployment Reference Guide: Setting up TLS communication. As necessary
Resolver N/A - non-Windows only Program to invoke for resolving the IP address of TaaS the Tanium Server. The default is getent. For AIX and OS X, set this to nslookup. The options are: getent, getenta, host, nslookup, dig, res_search, gethostbyname (OS X only), and getaddrinfo (OS X only). As necessary
ServerName REG_SZ FQDN or IP address of the TaaS instance the Tanium Server or Zone Server with which the client tries to connect. For details, see ServerName. As necessary
ServerNameList REG_SZ A comma-separated list of Tanium Server and Zone Server FQDNs or IP addresses for the TaaS instances with which the client can try to connect. For details, see ServerNameList. As necessary
ServerPort REG_DWORD The port to use for client-server and client-client communication. The default is 17472. For details, see ServerPort.

If you configure the ListenPort or EnableRandomListeningPort setting, it overrides ServerPort for client-client communication.

As necessary
Version REG_SZ Tanium Client version number. No

When Tanium Clients register with TaaS the Tanium Server, they also receive values for settings that relate to peering and sensor data. Clients write these settings to the Status registry subkey on Windows endpoints and to the SQLite database (client.db) on non-Windows endpoints. You do not edit these settings, but their values might help you understand expected behavior when troubleshooting peering. You can issue questions to see the values of some of these settings: see Use questions to review peering settings. Contact Tanium Support for more assistance.

 Table 3: Tanium Client peer settings
Setting Name Description
BackPeerAddress Address details for the current backward peer. Use the Tanium Back Peer Address sensor (Client Management content set) to see the value for this setting.
BackPreviousPeerAddress Address details for the previous backward peer.
BufferCount Number of buffered messages that are currently queued for the Tanium Client to process. Use the Tanium Buffer Count sensor (Client Management content set) to see the value for this setting.
ClientAddress Address details for the client host endpoint. Use the Tanium Client IP Address sensor (Base content set) to see the value for this setting.
NeighborhoodList Connection details that TaaS the Tanium Server provides for up to ten forward and ten backward peers. Use the Tanium Client Neighborhood sensor (Client Management content set) to see neighborhood information.
PeerAddress Address details for the current forward peer. Use the Tanium Peer Address sensor (Client Management content set) to see the value for this setting.
PreviousPeerAddress Address details for the previous forward peer.
StaleCount Count of sensors with stale data.
StaleList List of sensors with stale data.

Tanium Client Management service logs

If you used the Tanium Client Management service to deploy Tanium Clients, see details about the service logs and troubleshooting steps under Tanium Client Management User Guide: Troubleshooting.

Tanium Client installation log

On Windows endpoints, the Tanium Client installer generates an installation log file, Install.log, to record a chronology of the actions that the installer performed. Each time the installer runs (that is, for each installation and upgrade), it appends the actions for that execution to the end of the file instead of rotating the file. If you encounter issues with your installation, examine Install.log to see which actions succeeded or failed. Install.log is in the Tanium Client installation directory.

Tanium Client logs

Tanium Client logs can help you troubleshoot client issues. For example, a client might not answer questions or appear in the Tanium Console (Administration > Management > Client Status) because that client cannot connect to a TaaS instance the Tanium Server or Zone Server. In this case, you can review the client logs to determine whether the connection failed due to an invalid instanceserver IP address, DNS resolution failure, missing Tanium public key file, or firewall rule.

The Tanium Client writes new client logs to the file log0.txt. The default maximum log file size is 10 MB. When log0.txt reaches the maximum size, the client renames it log1.txt and then creates a new log0.txt. When log0.txt again reaches the maximum, the client renames log1.txt as log2.txt, again renames log0.txt as log1.txt, and again creates a new log0.txt. The process of rolling logs whenever log0.txt reaches the maximum size continues until 10 logs exist: log0.txt to log9.txt.

When log0.txt reaches the maximum size again after that, the client compresses log9.txt as a file named log10.zip. When log0.txt again reaches 10 MB, the client renames log10.zip as log11.zip and again compresses log9.txt as a file named log10.zip. The ZIP file rollover process continues until 10 ZIP files exist, log10.zip to log19.zip. When log0.txt reaches 10 MB again after that, the client creates a new log10.zip without renaming log19.zip as a new file, effectively dropping the old log19.zip information upon renaming log18.zip as the new log19.zip.

The location for log files is configurable (see LogPath). The default is <Tanium Client installation directory>/Logs.

Action logs

When a package does not seem to work after you deploy it through an action, examining action logs can help you troubleshoot. Each time the Tanium Client receives an action message with an instruction set to execute, the client creates an action log file named Action_<ID>.log, where <ID> is the action identifier. The action log contains the CLI output associated with the action command.

The Tanium Client stores action logs and Action_<ID> directories, which contain related files, in the <Tanium Client installation directory>/Downloads directory. The Tanium Client removes action logs from its host after a configurable interval (see Action log and package cleanup).

The Tanium Console displays the Action ID in the Action > Action History and Action Summary pages (see Tanium Console User Guide: Deploying actions). The Action Summary page provides options for accessing action log information from multiple endpoints: see Tanium Console User Guide: View action summary and status.

Action history logs provide a longer history of which actions a managed endpoint has run, but without the CLI output and other details.

Action_<ID> directories

Each Action_<ID> directory contains all the files required to deploy an action package. For example, if you deploy a package that has five files, the Tanium Client places each file in the Action_<ID> directory after it finishes downloading. After all five files download, the action status changes from Preparing Files to Running on the Action Summary page. Even if a deployed package has no associated package files, the Tanium Client creates an empty Action_<ID> directory for it. The Tanium Client removes Action_<ID> directories from its host after a configurable interval (see Action log and package cleanup).

Action log contents

Action logs record each phase of an action:

  1. Downloading Files

    During this phase, the action log entry indicates the files are downloading:

    2016-11-28 14:12:30 +0000|Downloading Files.
    2016-11-28 14:12:30 +0000|Files Failed Verification

    Although it appears to be an error condition, the message "Files Failed Verification" indicates simply that the client does not have the necessary files in its local cache, so it asks for the necessary files from its peers. This indicates normal behavior.

  2. Running

    During this phase, the action log notes that the action is currently running. Following this entry, the log displays anything echoed from the package:

    2016-11-28 14:12:37 +0000|Files Verified, running action.

  3. Completed

    When the action finishes running, the log records a completion entry under the standard output capture of the action.

    2016-11-28 14:12:37 +0000|Command Completed

Completion does not indicate success. For example, an action to execute a command might complete even if the command itself fails. For example, the command line for the package might not match the name of the distributed file or the command might fail to distribute a file. Managed endpoints show that the action completed, even though nothing occurred. Optionally, consider adding a validation query to the package to have the action status indicate success or failure.

Action log and package cleanup

The Tanium Client checks hourly, or immediately upon resetting (every two to six hours), whether any Action_<ID>.log files are over one day old and deletes them if they are. The Tanium Client also checks hourly, or immediately upon resetting, whether any corresponding Action_<ID> directories have expired, and deletes them if they have. This process ensures that the endpoint does not consume more disk space than necessary for Tanium actions. Contact Tanium Support if you want to preserve action logs or action directories for a longer time.

Action history logs

When you troubleshoot or audit actions on managed endpoints, use the action history logs to see which actions ran, their start and run times, and associated commands. Although the Action logs record more details, the Tanium Client preserves action history logs for a longer period (their individual log files are smaller) and therefore they provide a longer chronology of actions. The Tanium Client archives the first 10 MB of action history logs as plain-text files. After reaching the 10 MB threshold, the client archives the oldest logs as ZIP files before adding new logs as plain-text files. The log rollover process is as follows:

Plain text logs files

The Tanium Client creates a new action-history0.txt file whenever an action runs. When that file reaches 1 MB in size, the client renames action-history0.txt as action-history1.txt and creates a new action-history0.txt. When action-history0.txt again reaches 1 MB, the client renames action-history1.txt as action-history2.txt, again renames action-history0.txt as action-history1.txt, and again creates a new action-history0.txt. The process of rolling logs whenever action-history0.txt reaches 1 MB continues until 10 logs exist: action-history0.txt to action-history9.txt.

ZIP log files

After recording 10 MB of plain-text action history logs, the Tanium Client compresses action-history9.txt as a file named action-history10.zip. When action-history0.txt again reaches 1 MB, the client renames action-history10.zip as action-history11.zip and again compresses action-history9.txt as a file named action-history10.zip. The ZIP file rollover process continues until 10 ZIP files exist, action-history10.zip to action-history19.zip. When action-history10.zip reaches 1 MB again after that, the client creates a new action-history10.zip without renaming action-history19.zip as a new file, effectively dropping the old action-history19.zip information upon renaming action-history18.zip as the new action-history19.zip.

The Tanium Client stores action history logs in the <Tanium Client installation directory>/Logs directory.

Sensor history logs

When you troubleshoot or audit sensor activity on managed endpoints, use the sensor history logs to see the following information about each sensor that ran:

  • Sensor identity, by name and hash value
  • Start and run times
  • Size in bytes
  • Parameter values (the logs identify parameterized sensors as temp sensors)
  • Number of answer strings and associated hash value

The Tanium Client archives the first 10 MB of sensor history logs as plain-text files. After reaching the 10 MB threshold, the client archives the oldest logs as ZIP files before adding new logs as plain-text files. The log rollover process is as follows:

Plain text logs files

The Tanium Client creates a new sensor-history0.txt file each time a sensor runs. When that file reaches 1 MB in size, the client renames sensor-history0.txt as sensor-history1.txt, and creates a new sensor-history0.txt. When sensor-history0.txt again reaches 1 MB, the client renames sensor-history1.txt as sensor-history2.txt, again renames sensor-history0.txt as sensor-history1.txt, and again creates a new sensor-history0.txt. The process to roll the logs whenever sensor-history0.txt reaches 1 MB continues until 10 logs exist: sensor-history0.txt to sensor-history9.txt.

ZIP log files

After recording 10 MB of plain-text sensor history logs, the Tanium Client compresses sensor-history9.txt as a file named sensor-history10.zip. When sensor-history0.txt again reaches 1 MB, the client renames sensor-history10.zip as sensor-history11.zip and again compresses sensor-history9.txt as a file named sensor-history10.zip. The ZIP file rollover process continues until 10 ZIP files exist, sensor-history10.zip to sensor-history19.zip. When sensor-history10.zip reaches 1 MB again after that, the client creates a new sensor-history10.zip without renaming sensor-history19.zip as a new file, effectively dropping the old sensor-history19.zip information upon renaming sensor-history18.zip as the new sensor-history19.zip.

The Tanium Client stores sensor history logs in the <Tanium Client installation directory>/Logs directory.

Review or reset the public key (Tanium Client 7.4 only)

You can review or reset the public key to help resolve connection issues that are related to an invalid key.

  1. Access the operating system CLI on the endpoint and change directory (cd) to the Tanium Client installation directory.
  2. Enter the following command:

    TaniumClient pki show

    The output displays information about the current public key.

  3. (Optional) Reset the key with a new tanium-init.dat file.

    1. From the Main menu in the Tanium console, go to Administration > Shared Services > Client Management.
    2. From the Client Management Overview page, download the installation package for the OS of the endpoint.
    3. Extract the tanium‑init.dat file from the downloaded bundle, and copy it into the Tanium Client installation directory.
    4. From the Main menu in the Tanium console, go to Administration > Configuration > Tanium Server > Infrastructure Configuration Files.
    5. In the Clients v7.4+ and Zone Server section, click Download.
    6. Copy the downloaded file into the Tanium Client installation directory.
    7. From the CLI on the endpoint, enter the following command:

      TaniumClient pki reset tanium-init.dat

Manage sensor quarantines

Enforcing sensor quarantines prevents sensors from running on an endpoint for the current question or action if those sensors exceeded the runtime timeout during a previous question or action. Quarantines are useful for limiting the impact on endpoint resources, such as CPU utilization, when questions and actions use excessively long-running sensors. The non-configurable timeout is set to one minute.

By default, quarantines are not enforced: after a sensor exceeds the timeout and stops running, the sensor has quarantined status but stills run for future questions or actions until it completes or times out. In this case, the Tanium Client uses the quarantined status just to record that the sensor timed out.

Regardless of whether you enable enforcement, the Tanium Client stops any sensor at the moment it exceeds the timeout. Each client quarantines sensors and enforces the quarantines independently. Consequently, a sensor might be quarantined on some endpoints and not on others.

When a Tanium Client quarantines a sensor, the Tanium Console displays the following message in the Question Results grid: TSE-Error: Sensor evaluation timed out. When you issue a question that uses a sensor that is already quarantined and enforcement is enabled, the Question Results grid displays TSE-Error: The sensor is quarantined. The Tanium Client adds entries to the client logs and sensor history logs when it quarantines a sensor or prevents an already quarantined sensor from running.

If temporary sensors exceed the one-minute timeout, the Tanium Client quarantines the original sensor as well as all current and future temporary sensors that are based on the original sensor.

When enforcement is enabled, quarantined sensors do not run when you use them for targeting endpoints, even if the sensors are members of computer groups. However, quarantined sensors might skew the targeting of a question that has a vague from clause, such as from all machines with Is Windows not equals true. In this case, Windows endpoints on which the Is Windows sensor is quarantined would match the condition not equals true because their response would be TSE-Error: The sensor is quarantined rather than true. To avoid such outcomes, make the target clause as specific as possible and do not use negative matching conditions such as not equals true.

View quarantined sensors

If the Tanium Client does not answer a question, you can determine whether the associated sensors are quarantined. To see a list of all the quarantined sensors on all endpoints, see Tanium Console User Guide: Manage sensor quarantines. To list all the quarantined sensors on a specific endpoint, perform the following steps:

  1. Access the operating system CLI on the endpoint and change directory (cd) to the Tanium Client installation directory.
  2. Enter the following command.

    TaniumClient quarantine list

    The output lists the quarantined sensors by name and associated hash value.

Remove all sensors from quarantine

In some cases, enabling the Tanium Client to answer questions that use quarantined sensors might be more important than limiting the impact that long sensor run times have on the resources of an endpoint. Note that even after you remove the sensors from quarantine, if they exceed the timeout in a future question, the Tanium Client will then stop the sensors and quarantine them again without answering the question. To remove sensors from quarantine through the Tanium Console, see Tanium Console User Guide: Manage sensor quarantines. To remove sensors from quarantine through the operating system CLI on the endpoint, perform the following steps:

  1. Access the operating system CLI on the endpoint and change directory (cd) to the Tanium Client installation directory.
  2. Enter the following command:

    TaniumClient quarantine clear

    The output displays the number of sensors removed from quarantine.

Remove a single sensor from quarantine

To remove a sensor from quarantine through the Tanium Console, see Tanium Console User Guide: Manage sensor quarantines. To remove a sensor from quarantine through the operating system CLI on the endpoint, perform the following steps:

  1. Access the operating system CLI on the endpoint and change directory (cd) to the Tanium Client installation directory.
  2. Enter the following command to see the hash values associated with quarantined sensors.

    TaniumClient quarantine list

  3. Enter the following command, where <sensor_hash> is the hash associated with the sensor that you want to unquarantine:

    TaniumClient quarantine remove <sensor_hash>

If you modify a sensor, Tanium Clients that receive its new definition automatically remove that sensor from quarantine.

Add a sensor to quarantine

You can manually quarantine a sensor on an endpoint if you anticipate that running the sensor will negatively affect the endpoint.

Quarantining a sensor does not automatically enable quarantine enforcement.

  1. In the URL field of the browser that you use to access the Tanium Console, enter https://<TaaS instanceTanium Server>/hash/<sensor>. For the <TaaS instanceTanium Server>, enter the TaaS Tanium Server FQDN or IP address. The <sensor> must match the sensor name that the Tanium Console displays with respect to capitalization and spaces.

    The browser displays the hash value associated with the sensor.

  2. Access the operating system CLI on the endpoint and change directory (cd) to the Tanium Client installation directory.
  3. Enter the following command.

    TaniumClient quarantine add <sensor_hash>

Enable or disable enforcement of quarantined sensors

After you enable quarantine enforcement, Tanium Clients do not answer questions that use quarantined sensors and those sensors do not run for actions. After you disable enforcement, clients still quarantine sensors and log quarantine events, but do not prevent those sensors from running.

Your user account must have a role with the Write Global Settings (micro admin) permission to enable or disable quarantine enforcement. Users with the Administrator reserved role have this permission.

The first time you enable enforcement, you must add the EnableSensorQuarantine setting to the global settings on the Tanium Server as follows. By default, enforcement is disabled and the setting does not appear in the Tanium Console. After you add the setting, the Tanium Server applies it to all Tanium Clients.

  1. Access the Tanium Console.
  2. From the Main menu, go to Administration > Management > Global Settings, and click New Setting.
  3. Enter the following values and click Save.
    • Setting Name = EnableSensorQuarantine
    • Setting Value = 1
    • Affects = Client
    • Value Type = Numeric

Perform the following steps if you want to change the enforcement setting after adding it to the global settings:

  1. From the Main menu, go to Administration > Management > Global Settings.
  2. Select EnableSensorQuarantine, click Edit, set the value to 1 to enable enforcement or 0 to disable enforcement, and click Save.

If you want to change the enforcement setting in specific clients instead of all clients, add or edit the EnableSensorQuarantine setting in the local configuration of those clients.

Add or edit the EnableSensorQuarantine setting on the Tanium Clients for which you want to enable or disable quarantine enforcement.

Contact Tanium Support

Tanium Support is your first contact for help when troubleshooting the initial deployment and for optimizing the speed and scale of your deployment as the number of managed endpoints grows. As necessary, Tanium Support can help adjust Tanium Client-related settings, including:

  • Tanium Client registration frequency
  • Connections between Tanium Clients and TaaSTanium Core Platform servers
  • Client-to-client connections
  • Bandwidth
  • File caching

If you require further assistance from Tanium Support, include Tanium Client version information for Tanium Core Platform components and specific details on dependencies, such as the host system hardware and OS details.

To contact Tanium Support for help, sign into https://support.tanium.com.