Troubleshooting

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

Tanium Client installation paths

The following table lists the default paths. If you are troubleshooting an issue on a installation that uses a non-default path, be sure to note this when contacting Tanium support.

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

Tanium Client settings

Tanium Client settings are initially set when the client is installed and updated during registration with the Tanium Server.

Windows

On Windows, the settings are Windows Registry settings. The path to Tanium Client registry keys varies by OS architecture.

Table 2:   Tanium Client registry key paths
OS Registry Key Path
32-bit HKEY_LOCAL_MACHINE\Software\Tanium\Tanium Client
64-bit HKEY_LOCAL_MACHINE\Software\Wow6432Node\Tanium\Tanium Client

The Tanium Client Registry Key includes subkeys: Sensor Data, Status, ValueSystem. Typically, subkey values are set at client installation and not modified, or they are modified when Tanium actions or sensors are updated.

The Status subkey holds the information the client receives from the Tanium Server during registration. Do not edit these entries. The information might help you and your TAM understand expected behavior when troubleshooting peering.

Non-Windows

For Tanium Client 6.0, the settings are entries in the TaniumClient.ini file, which is located in the installation directory.

For Tanium Client 7.2, the settings are stored in an SQLite database. You can use the Tanium Client CLI to set them. For details, see Reference: Tanium Client CLI.

Settings reference

Tanium Client settings are initialized upon registration or service restart.

Table 3:   Tanium Client settings
Setting Name Type (Windows) Description Modify
ComputerID REG_DWORD Value assigned to the client by the Tanium Server to uniquely identify and track each Tanium managed device. No
DatabaseEpoch REG_SZ Typically the date on which the Tanium Server was installed. Used for content freshness comparisons. No
FirstInstall REG_SZ Date and time of first Tanium Client installation. No
HostDomainName N/A - non-Windows only Required only when the domain name is not being populated correctly in Tanium results. The value specified for this setting overrides the data that would otherwise be returned by the client OS.

Specify just the domain portion of the FQDN. For example, if the FQDN is host.example.com, specify example.com.

As directed
HostFQDN N/A - non-Windows only Another option when the hostname and domain name are not being populated correctly in Tanium results. The value specified for this setting overrides the data that would otherwise be returned by the client OS.

Specify the complete FQDN, including hostname. For example, specify host.example.com.

As directed
LastInstall REG_SZ Date and time of latest Tanium Client installation. No
LastGoodServerName REG_SZ The name of the Tanium Server or Tanium Zone Server with which the Tanium Client last connected successfully. If the client cannot reach the server specified in ServerName, it attempts to connect to the server specified in LastGoodServerName.

If you want to avoid this fallback behavior during testing, troubleshooting, or migration scenarios, delete the LastGoodServerName value.

No
LogFileSize REG_DWORD The size in bytes at which the log file is rotated. As directed
LogPath REG_SZ By default, Tanium Client 6.0 and earlier writes client log files (see Tanium Client logs) to its installation folder (see Tanium Client installation paths). Tanium Client 7.2 and later writes the logs to the <installation_folder>/Logs subfolder. You can use the LogPath setting to define an alternative absolute path to write the logs. For example: LogPath=/tmp. As directed
LogVerbosityLevel REG_DWORD

By default, this setting is not present if you did not set the logging level when deploying the Tanium Client (see Deploy 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 directed
Path REG_SZ (Windows only) Path to the Tanium Client installation folder (see Tanium Client installation paths). If none is specified, the Tanium Client assumes the default path for the OS.

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

As directed
RegistrationCount REG_DWORD Count of completed registrations. This value, in conjunction with the ComputerID, enables the Tanium Server to perform duplicate Computer ID detection. If the RegistrationCount value maintained by the Tanium Server is not consistent with the value being reported by the client, the Server will assign a new, unique ComputerID to the device to resolve the apparent duplicate ComputerID situation identified. No
ReportingTLSMode, OptionalTLSMinAttemptCount, OptionalTLSBackoffIntervalSeconds, OptionalTLSMaxBackoffSeconds, Server_ReportingTLSMode, Server_OptionalTLSMinAttemptCount, Server_OptionalTLSBackoffIntervalSeconds, Server_OptionalTLSMaxBackoffSeconds REG_DWORD Tanium core platform 7.2 supports native TLS 1.2 for the Tanium Client to Tanium Server and Tanium Client to Tanium Zone Server connections. Both client and server must be 7.2. See the Tanium Core Platform Installation Guide. As directed
Resolver N/A - non-Windows only Program to invoke to resolve the IP address of the Tanium Server. getent is the default. For AIX and OS X this should be set to nslookup. The available options are: getent, getenta, host, nslookup, dig, or res_search. On OS X there are two additional options: gethostbyname and getaddrinfo. As directed
ServerName REG_SZ FQDN or IP address of the Tanium Server to which the client attempts to connect. In Tanium Core Platform 7.2.314.3263 and later, the setting can include an optional port value. As directed
ServerNameList REG_SZ In HA deployments, a comma-separated list of Tanium Server FQDNs or IP addresses. In Tanium Core Platform 7.2.314.3263 and later, the setting can include an optional port value for each Tanium Server. As directed
ServerPort REG_DWORD The port to use both for client-server and client-client communication. The default is 17472. If the ServerName or ServerNameList specifies a port, it overrides the ServerPort value. As directed
Version REG_SZ Tanium Client version number. No

In addition, there are Tanium Client peer settings that hold status information and peer settings that the Tanium Client receives from the Tanium Server during registration. On Windows, these are written to the Status subkey. On non-Windows, they are written to the TaniumClient.ini file (6.0) or the client.db (7.2). Do not edit these entries. The information might help you and your TAM understand expected behavior when troubleshooting peering.

Table 4:   Tanium Client peer settings
Setting Name Description
BackPeerAdddress Address details for current backward peer.
BackPreviousPeerAddress Address details for previous backward peer.
BufferCount Number of buffered messages currently queued to be processed by the Tanium Client.
ClientAddress Address details for the client host computer.
NeighborhoodList Connection details provided by Tanium Server for up to ten forward and ten backward peers.
PeerAddress Address details for the current forward peer.
PreviousPeerAddress Address details for the previous forward peer.
StaleCount Count of sensors with stale data.
StaleList List of sensors with stale data.

Client Deployment Tool logs

The Tanium Client Deployment Tool (CDT) writes debug logs, including logs for connection attempts and client installation success and failure, to the the <CDT_installation_folder>/Tanium Client Deployment Tool folder. The CDT writes the most recent logs to TaniumClientDeploy.log. When that file reaches the maximum size, the CDT rolls over the older messages into TaniumClientDeploy.log[.integer].

Tanium Client installation log

The Tanium Client installation log file, Install.log, is a chronological log of the actions that the Tanium Client installer performed. If you encounter issues with your installation, examine Install.log to see which actions completed successfully and which failed. You can find Install.log in the Tanium Client installation folder (see Tanium Client installation paths).

Tanium Client logs

Tanium Client logs can help you troubleshoot client issues. For example, say a client does not answer questions or appear in the Tanium Console (Administration > System Status) because that client cannot connect to the Tanium Server or Tanium Zone Server. In this case, you can review the client logs to determine whether the connection failed due to an invalid server 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 1 MB in Tanium Client 6.0 or earlier and 10 MB in 7.2 or later. 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 rollover process depends on the Tanium Client version:

  • Tanium Client 6.0 or earlier creates a new log0.txt without renaming log9.txt as a new file, effectively dropping the old log9.txt information upon renaming log8.txt as the new log9.txt.
  • Tanium Client 7.2 or later 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 log files location is configurable (see LogPath) but the default is:

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 Console displays the Action ID in the Action > Action History and Action Status pages (see Tanium Core Platform User Guide: Deploying actions).

Tanium Client 7.2 and later records action history logs that provide a longer history of which actions a managed endpoint has run, but without the CLI output and other details. For details, see Action history logs

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

Action_<ID> folders

Each Action_<ID> folder 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> folder after it finishes downloading. After all five files download, the action status changes from Preparing Files to Running on the Action Status page. Even if a deployed package has no associated package files, the Tanium Client creates an empty Action_<ID> folder for it. The Tanium Client removes Action_<ID> folders 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 did not match the name of the distributed file or no file was distributed). 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 inform on success or failure.

Action log and package cleanup

If you enable the Tanium - Clean Stale Tanium Client Data scheduled action, it runs every four hours by default. This action deletes:

  • Action_<ID> folders that are at least two days old
  • Action_<ID>.log files that are at least four days old

For Tanium Client 6.0 and earlier, Tanium strongly recommends that you leave the Tanium - Clean Stale Tanium Client Data scheduled action enabled and at the default frequency. If you want to preserve action logs and folders for a longer time, please contact your technical account manager (TAM).

Action history logs

When troubleshooting or auditing actions on endpoints that run Tanium Client 7.2 or later, you can use the action history logs to see which actions ran, their start and run times, and associated commands. Although the Action_<ID>.log files record more details (see Action logs), 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 <client_installation_path>/Logs folder (see Tanium Client installation paths).

Sensor history logs

When troubleshooting or auditing sensor activity on endpoints that run Tanium Client 7.2 or later, you can 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 <client_installation_path>/Logs folder (see Tanium Client installation paths).

Manage sensor quarantines

If certain sensors do not run when expected on endpoints running Tanium Client 7.2 or later, this might indicate that sensor quarantines are enforced. Tanium Clients stop and quarantine a sensor if its runtime exceeds the non-configurable one-minute timeout. If enforcement is enabled, the quarantined sensors cannot run again for subsequent questions. Enforcing quarantines is useful for limiting the impact of questions on endpoint resources, such as CPU utilization, in cases where some sensors predictably exceed the timeout. By default, enforcement is disabled and quarantined sensors can run whenever a question calls them, until they complete or time out. You can enable or disable quarantine enforcement for all clients through a global setting. However, clients determine and enforce quarantine status independently; a sensor might exceed the one-minute timeout on slower endpoints but not on faster endpoints.

The Tanium Client adds entries to the client logs and sensor history logs when it quarantines a sensor or stops an already quarantined sensor from running. Upon quarantining a sensor, the client sends the following response to the Tanium Console: TSE-Error: Sensor evaluation timed out. When responding to a question that uses a quarantined sensor, the client sends the following response if quarantine enforcement is enabled: TSE-Error: The sensor is quarantined.

If temp sensors exceed the timeout, the Tanium Client quarantines the original sensors and all current and future temp sensors that are based on the originals.

View quarantined sensors

If the Tanium Client does not answer a question, you can determine whether the associated sensors are quarantined by listing all the quarantined sensors on the endpoint.

  1. Access the endpoint CLI and change directory (cd) to the Tanium Client installation folder (see Tanium Client installation paths).
  2. Enter the following command.

    TaniumClient quarantine list

Remove sensors from quarantine

In some cases, enabling the Tanium Client to run quarantined sensors might be more important than limiting the impact that long sensor runtimes have on the resources of an endpoint.

  1. Access the endpoint CLI and change directory (cd) to the Tanium Client installation folder (see Tanium Client installation paths).
  2. To remove all sensors from quarantine, enter:

    TaniumClient quarantine clear

    To remove a single sensor from quarantine, enter the following, where <id> is the sensor identifier. (To see a list of sensor IDs, access the Tanium Console, go to Content > Sensors, and display the ID column.)

    TaniumClient quarantine remove <id>

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

Add sensors to quarantine

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

  1. Access the endpoint CLI and change directory (cd) to the Tanium Client installation folder (see Tanium Client installation paths).
  2. Enter the following command, where <id> is the sensor identifier. (To see a list of sensor IDs, access the Tanium Console, go to Content > Sensors, and display the ID column.)

    TaniumClient quarantine add <id>

Enable or disable enforcement of quarantined sensors

When you enable quarantine enforcement, Tanium Clients do not answer questions that use quarantined sensors. When you disable enforcement, clients still assign quarantine status and log quarantine events, but only to indicate which sensors timed out at least once.

You must be assigned 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, go to Administration > Global Settings, and click New Setting.
  2. Enter the following values and click Save.
    • Setting Name = EnableSensorQuarantine
    • Setting Value = 1
    • Affects = Client
    • Value Type = Numeric

If you want to change the enforcement setting after you have added it to the global settings:

  1. Access the Tanium Console and go to Administration > 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 (see Tanium Client settings).

Contacting Tanium support

Your TAM is your first contact for assistance troubleshooting the initial deployment.

If you require further assistance from Tanium Support, please be sure to include version information for Tanium Core Platform components and specific details on dependencies, such as the host system hardware and OS details. Log into https://support.tanium.com and submit a new ticket or send us an email at [email protected]

Last updated: 12/6/2018 1:07 PM | Feedback