Create a Custom Package in Tanium Deploy

This example shows how to create a custom package in Tanium Deploy. Here the package is a ZIP archive with files and scripts.

Prepare the Package Content

Start outside Tanium. Put the installer, scripts, transforms, config files, and other content in a clear folder structure before you create the package.

• Gather the installer files, scripts, and configuration assets required for the deployment.
• Package everything into a single ZIP archive.
• Test the install command outside Tanium first so Deploy is not your first validation point.

If the package has multiple files, use one ZIP archive. This is often simpler than trying to force everything into one executable.

Create the Custom Package

1. Open Deploy -> Software and click Create Software Package.

2. Upload the prepared ZIP in Package Files.

3. Define a clear package name in Package Details.

Use a clear package name. It should identify the application and, if needed, the runtime or version family.

Set Requirements Carefully

Requirements decide which endpoints are eligible before the install starts. A bad requirement can create false Not Applicable results or target systems that should be excluded.

• Use requirements for OS, architecture, prerequisites, disk space, or existing software state.
• Keep the requirement logic readable. Complex filters become hard to troubleshoot later.
• If a package already exists on many systems, make sure the requirement and verification logic clearly distinguish installed from not installed.

Define Installation Actions

For ZIP-based packages, a common pattern is to extract the archive first, then run the installation command from the extracted working directory.

Important: check the extract path and the path used by the next command. Many failures come from a simple path mismatch.

Example install command:

cmd.exe /c "powershell.exe -NoProfile -ExecutionPolicy Bypass -File c:\ProgramFiles\YourApp\install.ps1"

Replace the path with the real script location after extraction. If you use a working directory, test it on one endpoint before broad deployment.

Add Verification

Verification tells Tanium Deploy whether the install succeeded. Use a check that is clear and stable.

• File existence works well for predictable binaries or markers.
• Registry checks are useful for Windows installers that publish a stable key or version value.
• Version-based logic is better than process checks when the application does not stay running.

4. Save the configuration and create the package.

Launch the Deployment

After the package is ready, target the right endpoints and launch in the right time window.

• Select the target group carefully. Broad groups hide mistakes until too late.
• Use pilots or rings before rolling out to the full production scope.
• Confirm the schedule matches your maintenance policy and rollout window.

Always review the deployment preview before launch. It is the last easy check for a wrong target group or a wrong endpoint count.

Monitor and Troubleshoot

Deploy troubleshooting usually comes down to a few recurring questions:

• Is the endpoint eligible?
• Is the endpoint allowed to run the deployment now?
• Did the package download?
• Did the command execute successfully?
• Did verification confirm success?

Coverage Status Details

Start with Coverage Status Details. It shows how endpoints are split across waiting, downloading, installing, completed, failed, or not applicable.

Action Lock

If endpoints use Action Lock, Deploy can be blocked before the install starts. Check this early.

Useful Interact query:

Get Action Lock Status from all machines

Maintenance Windows

Endpoints outside an active maintenance window can stay in Waiting even when the package is correct. Check the maintenance window before treating this as a failure.

Scan Interval

The scan interval controls how often the client checks for deployments. If it is too long, endpoints may start late.

Tools Status Details

For a single problematic endpoint, query the tool status directly.

Get Endpoint Configuration - Tools Status Details from all machines with Computer Name contains LABLTSC2019.monlab.lan

This helps you separate package issues from client or tool issues on the endpoint.

Deployment Phases

The deployment activity view becomes much easier to read when each state is interpreted correctly:

• Waiting: the deployment has not started yet, often because of schedule, maintenance window, or readiness conditions.
• Downloading: content transfer is in progress.
• Installing: the install command is running.
• Completed: the install and verification steps succeeded.
• Not Applicable: the endpoint does not satisfy package applicability or already matches the target state.
• Failed: execution or verification did not succeed.

Check Applicability Explicitly

If many endpoints show Not Applicable, check applicability directly with Interact.

Example query using package ID 6220:

Get Deploy - Software Packages Applicability Details[6220] from all machines

This helps you separate eligible endpoints from endpoints that are already compliant, on the wrong architecture, or outside the requirement scope.

To drill into one endpoint, add a computer filter:

Get Deploy - Software Packages Applicability Details[6220] from all machines with Computer Name contains LABLTSC2019.monlab.lan

Read the Client Logs

When the console view is not enough, read the endpoint logs directly:

C:\Program Files (x86)\Tanium\Tanium Client\Tools\SoftwareManagement\logs

• software-management.log shows the main deployment workflow.
• subprocess.log shows command output and execution failures from the installer layer.

Good Practices

• Start with a pilot deployment before pushing to broad production scope.
• Keep the install command simple and predictable, and test it outside Tanium first.
• Use verification that reflects the final installed state, not only command completion.
• Investigate Not Applicable and Waiting with the same seriousness as Failed, because they often point to logic errors in targeting or scheduling.

Track with Custom Tags

Custom tags can help mark endpoints after a successful deployment and make post-rollout checks easier through Interact.

Example Interact query:

Get Custom Tags from all machines

Keep the package, applicability, execution path, and verification aligned. If one of these parts is weak, troubleshooting gets harder very quickly.