This section identifies resources you can use when troubleshooting issues with the Tanium Client deployment.
- Check with your Technical Account Manager (TAM) to ensure the Tanium Client version is a recommended version.
- Ensure your environment meets the host system and network requirements: see Requirements.
- If you encounter failed access messages when running a Tanium Client installer, examine the permissions for the logged in user.
- If you encounter Tanium Client installation issues, review the Tanium Client Management logs if you used that service to deploy the clients (see Tanium Client Management User Guide: Troubleshooting) and examine the Tanium Client installation log on the endpoints.
- If the Tanium Client fails to connect or register with the Tanium Server or Zone Server, or it fails to respond to questions, check Tanium Client logs.
- If you encounter issues when deploying actions, see Action logs and Action history logs.
- If issues related to sensors occur, see Sensor history logs and Manage sensor quarantines.
- Check the status of the Tanium Client service and, if necessary, restart it. The steps to restart the service vary by operating system:
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.
Tanium Client settings are initially set when the client is installed and updated during registration with the Tanium Server. The location of the settings varies by operating system.
On Windows endpoints, the settings are Windows Registry settings. The path to Tanium Client registry keys is HKEY_LOCAL_MACHINE\Software\Wow6432Node\Tanium\Tanium Client.
The Tanium Client Registry Key includes subkeys: Sensor Data, Status, ValueSystem. Typically, subkey values are set during client installation and are not subsequently modified unless 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.
On non-Windows endpoints, the location of the Tanium Client settings varies by version:
- Tanium Client 6.0: The settings are entries in the TaniumClient.ini file, which is located in the installation directory.
- Tanium Client 7.2 or later: 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.
Tanium Client settings are initialized upon registration or service restart.
|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|
|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 directed|
|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.
|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.
|LastInstall||REG_SZ||Date and time of latest Tanium Client installation.||No|
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.
|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 <Tanium Client>/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 About Us).
The following decimal values are best practices for specific use cases:
(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).
|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 or later supports TLS communication for connections from Tanium Client 7.2 or later to the Tanium Server or Tanium 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. For Tanium Client 6.0, the TLS settings are ignored.||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, set this to nslookup. The available options are: getent, getenta, host, nslookup, dig, or res_search. On OS X, additional options are: 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 or 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 or 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 or later). Do not edit these entries. The information might help you and your TAM understand expected behavior when troubleshooting peering.
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.
On Windows endpoints, the Tanium Client installer generates an installation log file, Install.log, as a chronological log of the actions that the installer performed. Each time you run the installer (that is, for each installation and upgrade), it appends the actions for that execution to the end of the file instead of rolling over the file. 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 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:
- Tanium Client 6.0 and earlier: installation folder (see Tanium Client installation paths)
- Tanium Client 7.2 and later: <Tanium Client>/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> folders, which contain related files, in the <Tanium Client>/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).
The Tanium Console displays the Action ID in the Action > Action History and Action Summary pages (see Tanium Core Platform User Guide: Deploying actions). The Action Summary page provides options for accessing action log information from multiple endpoints: see Tanium Core Platform User Guide: View action summary and status.
Tanium Client 7.2 or 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
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 Summary 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:
- 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.
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.
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
The Tanium Client checks once every hour, or immediately upon resetting (every four hours), whether any Action_<ID>.log files are over one day old and deletes them if they are. The Tanium Client also checks once every hour, or immediately upon resetting, whether any corresponding Action_<ID> folders are expired, and deletes them if they are. This process ensures that the endpoint does not consume more disk space than necessary for Tanium actions. If you want to preserve action logs or action folders for a longer time, contact your Technical Account Manager (TAM).
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 <Tanium Client>/Logs folder (see Tanium Client installation paths).
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 <Tanium Client>/Logs folder (see Tanium Client installation paths).
Tanium Client 7.2 or later supports sensor quarantines which, when enforced, prevent a sensor from running for the current question or action if that sensor exceeded the runtime timeout during a previous question or action. Enforcing quarantines is 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 will have quarantined status but will still 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.
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. As a best practice 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:
- Access the operating system CLI on the endpoint and change directory (cd) to the Tanium Client installation folder (see Tanium Client installation paths).
- 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:
- Access the operating system CLI on the endpoint and change directory (cd) to the Tanium Client installation folder (see Tanium Client installation paths
- 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:
- Access the operating system CLI on the endpoint and change directory (cd) to the Tanium Client installation folder (see Tanium Client installation paths
- Enter the following command to see the hash values associated with quarantined sensors.
TaniumClient quarantine list
- 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 will 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; only the EnableSensorQuarantine global setting controls enforcement.
- In the URL field of the browser that you use to access the Tanium Console, enter https://<Tanium_Server>/hash/<sensor>. For the <Tanium_Server>, enter the FQDN or IP address of the Tanium Server. 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.
- Access the operating system CLI on the endpoint and change directory (cd) to the Tanium Client installation folder.
- Enter the following command.
TaniumClient quarantine add <sensor_hash>
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.
- Access the Tanium Console.
- From the Main menu, select Administration > Management > Global Settings, and click New Setting.
- 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:
- From the Main menu, select Administration > Management > Global Settings.
- 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).
Your TAM 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, your TAM can adjust Tanium Client-related settings, including:
- Tanium Client registration frequency
- Connections between Tanium Clients and Tanium Core Platform servers
- Client-to-client connections
- File caching
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: 7/16/2020 12:00 PM | Feedback