This section identifies resources you can use when troubleshooting issues with the Tanium™ Client deployment.
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.
On Windows, the settings are Windows Registry settings. The path to Tanium Client registry keys varies by OS architecture.
|OS||Registry Key Path|
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.
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.
Tanium Client settings are initialized upon registration or service restart.
|Setting Name||Windows Registry Type||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.
|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 server for the last successful client-server connection. If the client is unable to reach the server specified in ServerName, it attempts to connect to the value contained in LastGoodServerName.
During testing, troubleshooting, or migration scenarios, you might want to delete this value when you want to avoid this fallback behavior.
|LogFileSize||REG_DWORD||The size in bytes at which the log file is rotated.||As directed|
By default, Tanium Client log files are written to the Tanium Client installation directory. The default for macOS is /Library/Tanium/TaniumClient. The default for Linux, Solaris, and AIX is /opt/Tanium/TaniumClient.
You can use the LogPath setting to define an alternative absolute path to write the logs. For example: LogPath=/tmp.
By default, if this setting was not specified during installation, it is not present.
Path to Tanium Client installation folder.
If none is specified, the Tanium Client assumes the default path for the OS.
If you specify a different path, the TaniumClient.ini file (6.0) or client.db (7.2) is still expected in the default location. This entry in the Tanium Client settings in the default location points to a "root" installation directory to be used for the files and directories associated with the Tanium Client installation, such as Downloads, Sensors, Strings, Tools, and so on. You can get similar results using symlinks. Before modifying this setting, contact your TAM to discuss your objectives and evaluate whether symlinks are preferred.
|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 should attempt to connect.||As directed|
|ServerNameList||REG_SZ||In HA deployments, a comma-separated list of Tanium Server FQDNs or IP addresses.||As directed|
|ServerPort||REG_DWORD||The port to use both for client-server and client-client communication. The default is 17472||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 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.
Total log space does not exceed 10 MB. Logs are written to the file log0.txt. When that file reaches 1 MB in size, log0.txt is renamed to log1.txt. When log0.txt reaches 1 MB in size again, log1.txt is renamed to log2.txt, and log0.txt again renamed to log1.txt. The process to roll the logs whenever log0.txt reaches the 1 MB size limit continues until 10 logs exist in total. In effect, once the Tanium component reaches the 10 log limit, the log details in log9.txt are overwritten each time a new log0.txt is started.
Log files are written to the Tanium Client installation directory.
|Windows 32-bit||\Program Files\Tanium\Tanium Client|
|Windows 64-bit||\Program Files (x86)\Tanium\Tanium Client|
|AIX, Linux, Solaris||/opt/Tanium/TaniumClient/|
When the Tanium Client receives an action message with an instruction set to execute, the agent creates an action log file. Note that these files are temporary and that the client removes them from the system after a configurable amount of time. If a package does not seem to work when deployed through an action, it may be useful to examine the action log files on clients.
The action log files reside in the Tanium Client Downloads folder on the file system.
The Downloads folder contains Action_XXX.log files and, temporarily, the Action_XXX folders, where XXX is the Action ID. You can find the Action ID in the Tanium Console Action Status and Action History pages.
The Action_XXX folder contains all of the files that are necessary for the package to be deployed. If you deploy a package that has 5 files, each file is placed here once it is completely downloaded. Once all 5 files are completely downloaded, the action status changes from "Preparing Files" to "Running" on the Action Status page.
Even if there are no package files associated with a deployed package, this folder is created, but contains no files.
An Action_XXX.log file logs 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, anything echoed from the package will be shown:
2016-11-28 14:12:37 +0000|Files Verified, running action.
When the action is finished running, an entry to indicate completion will be made. This appears underneath the standard output capture of the action.
2016-11-28 14:12:37 +0000|Command Completed
To indicate success or failure, consider adding a validation query to the package to have the action status inform on success or failure. This is optional.
Action log cleanup
The Tanium - Clean Stale Tanium Client Data scheduled action runs every 4 hours by default. This action purges old Action_XXX folders and Action_XXX.log files:
- Action_XXX folders that are 2 days old are deleted
- Action_XXX.log files that are 4 days old are deleted
Tanium strongly recommends that the Tanium - Clean Stale Tanium Client Data scheduled action remains enabled and at the default frequency. If you want to extend the amount of time that the above logging files and folders are on the endpoint, please contact your technical account manager (TAM).
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: 5/22/2018 1:29 PM | Feedback