Tanium Client Upgrade Strategy with Rings and Action Lock

This guide explains how to run a safe Tanium Client upgrade using rollout rings, validation gates, Action Lock, module configuration, approved package exceptions, and client extension controls for troubleshooting.

Useful external reference: Tanium documentation.

Tanium Client Upgrade Strategy: Rings, Action Lock, and Safe Rollout

Use rings, validation gates, and Action Lock together for a Tanium Client upgrade. This keeps the blast radius small and makes rollback decisions easier.

Useful external reference: Tanium documentation.

Rings and Action Lock

• Rings reduce blast radius by validating the upgrade in small, controlled groups before broad rollout.
• Action Lock protects sensitive endpoints where no console-initiated action should run unless it is explicitly allowed.
• Module configuration defines whether Patch, Deploy, or custom packages should respect or bypass Action Lock during the rollout.

Prerequisites

• Computer Groups are ready for the rollout: Unit Test, Pilot Test, and Deployment.
• The target Tanium Client package has already been validated in a lab or non-production environment.
• Rollback owners and validation criteria are defined before the first production ring starts.
• You know which endpoints must remain protected by Action Lock during the rollout.

Ring Strategy

Do not move to the next ring only because the deployment finished. Move only after you check client health, extension loading, endpoint reachability, and rollback readiness.

Useful external reference: Tanium documentation.

Configure Upgrade Rings

1. Open Endpoint Management -> Change Management in the Tanium Console.

1. Edit Ring 1, enable Tanium Clients Upgrades, and assign the Unit Test Computer Group.

1. Edit Ring 2 and assign the Pilot Test Computer Group.

1. Edit Ring 3 and assign the broad production group, typically All Computers or your production scope equivalent.

1. Save the configuration and verify ring membership before launching the client upgrade.

Action Lock

Action Lock blocks console actions on an endpoint, including deployments, patches, scans, and scripts. Use it to protect critical systems or keep exception devices outside the rollout.

Useful external reference: Tanium documentation.

Locked endpoints ignore actions unless the action uses Ignore Action Lock. This protects devices that must not join the rollout automatically.

Useful external reference: Tanium documentation.

Enable Action Lock

• Check the current status before enabling the lock.

Get Is Windows and Action Lock Status from all machines with Action Lock Status contains Action Lock Off

• Deploy the package Tanium Client – Set Action Lock On (Windows).

CLI alternative on the endpoint:

Useful external reference: Tanium documentation.

TaniumClient.exe config set ActionLockFlag On

Disable Action Lock

Use the saved question below to find locked endpoints before removing the control:

Useful external reference: Tanium documentation.

Get Is Windows and Action Lock Status from all machines with Action Lock Status contains Action Lock On

• Deploy package: Tanium Client – Set Action Lock Off.

Module Configuration on Locked Endpoints

Action Lock is useful only if module behavior is intentional. Review how Patch, Deploy, and custom packages behave on locked systems before starting the rollout.

Useful external reference: Tanium documentation.

Patch

Patch can be configured to either fully respect Action Lock, scan only, or ignore the lock entirely.

Useful external reference: Tanium documentation.

• Disable Applicability Scanning and Deployments
• Applicability Scanning Only (default)
• Ignore Action Lock

Deploy

Deploy uses the same logic. Here you decide if standard deployments are blocked, partly allowed, or forced through on locked endpoints.

Useful external reference: Tanium documentation.

• Disable Applicability Scanning and Deployments
• Applicability Scanning Only (default)
• Ignore Action Lock

Core Packages and Cloned Packages

If one package must run on locked endpoints, enable Ignore Action Lock in the package definition. Use this only for controlled exceptions.

Useful external reference: Tanium documentation.

Rollout Flow

• Start with Ring 1 on non-critical endpoints and validate client health, extension loading, and endpoint communication.
• Move to Ring 2 only after Ring 1 behavior is stable and your rollback decision path is still clear.
• Use Action Lock on systems that must be protected from the rollout by default.
• Use Ignore Action Lock only for approved exceptions where the upgrade must proceed despite the lock.
• Promote to Ring 3 only after validation, not merely after package completion.

Temporarily Disable a Client Extension

If the client upgrade succeeds but a specific extension causes issues, you can temporarily stop that extension from loading for troubleshooting.

Useful external reference: Tanium documentation.

• Deploy Action: Modify Tanium Client Setting
• RegType: REG_DWORD
• ValueName: DisableExtension_<ToolName>
• ValueData: 1
• Then run: Endpoint Configuration – Restart Client Extensions [Windows]

The targeted extension will no longer load. To resume normal behavior, set ValueData = 0 and restart client extensions again.

Useful external reference: Tanium documentation.

Valid tool names: client, comply, config, core, dec, discover, enforce, extras, index, performance, recorder, reveal, risk, software_manager, stream, support, threatresponse, tsdb, integrity_monitor

Useful external reference: Tanium documentation.