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.

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

RingTarget GroupGoal
Ring 1Unit TestValidate the client package on a very small set of endpoints.
Ring 2Pilot TestValidate the package on a larger sample close to production.
Ring 3DeploymentRoll out to the rest of production after validation.

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.

Configure Upgrade Rings

  1. Open Endpoint Management -> Change Management in the Tanium Console.
Change Management page in the Tanium Console
  1. Edit Ring 1, enable Tanium Clients Upgrades, and assign the Unit Test Computer Group.
Ring 1 configured for the Unit Test computer group
  1. Edit Ring 2 and assign the Pilot Test Computer Group.
Ring 2 configured for the Pilot Test computer group
  1. Edit Ring 3 and assign the broad production group, typically All Computers or your production scope equivalent.
Ring 3 configured for the broad deployment scope
  1. Save the configuration and verify ring membership before launching the client upgrade.
Ring configuration summary after save

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.

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

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
Question showing endpoints where Action Lock is currently off
  • Deploy the package Tanium Client – Set Action Lock On (Windows).
Deploy Action package used to set Action Lock on

CLI alternative on the endpoint:

TaniumClient.exe config set ActionLockFlag On

Disable Action Lock

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

Get Is Windows and Action Lock Status from all machines with Action Lock Status contains Action Lock On
Question showing endpoints where Action Lock is currently on
  • Deploy package: Tanium Client – Set Action Lock Off.
Deploy Action package used to 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.

Patch

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

Patch configuration for Action Lock behavior
  • Disable Applicability Scanning and Deployments
  • Applicability Scanning Only (default)
  • Ignore Action Lock
Patch options showing the three Action Lock behaviors

Deploy

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

Deploy configuration for Action Lock behavior
  • 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.

Core package option to bypass Action Lock
Cloned or custom package configured to ignore Action Lock

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.

  • 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.

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

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.