4.3 Verifying Endpoint State and Automating with Scheduled Recurring Actions

4.3 Verifying Endpoint State and Automating with Scheduled Recurring Actions

Quick overview: Two blueprint objectives live here. TA-2 asks you to verify the state of an endpoint before and after making changes, and TA-3 asks you to automate remediation using scheduled recurring actions. They are the same idea at two speeds: ask, change, ask again — done once by hand, or done forever by the platform.

---

1. The verification loop

        +-----------------------------------------------------+
        |  1. ASK          establish the BEFORE state          |
        |     "which endpoints have the service stopped?"      |
        +-----------------------------------------------------+
                              |
                              v
        +-----------------------------------------------------+
        |  2. ACT          deploy the package as an action     |
        +-----------------------------------------------------+
                              |
                              v
        +-----------------------------------------------------+
        |  3. CHECK        exit codes and action status        |
        |     "did the command run without erroring?"          |
        +-----------------------------------------------------+
                              |
                              v
        +-----------------------------------------------------+
        |  4. ASK AGAIN    establish the AFTER state           |
        |     "is the service running now?"                    |
        +-----------------------------------------------------+

Steps 3 and 4 are not the same check, and conflating them is the most common verification mistake in real operations.

Verification sensors automate step 4

A package can name a verification sensor. After the action runs, Tanium evaluates that sensor to determine whether the intended outcome was achieved. This turns the manual re-ask into part of the deployment, and it is why associating the right verification sensor when a package is authored pays off on every subsequent deployment.

Why the "before" matters as much as the "after"

Capturing the before state gives you three things you cannot reconstruct afterwards:

1. A denominator. "47 endpoints were affected" is the number you compare against.
2. Change evidence. For audited environments, the before-and-after pair is the record.
3. A rollback trigger. If the after count is worse than the before count, you know immediately.

[!TIP] Save the "before" question as a saved question. It becomes the "after" question for free, the standing monitor afterwards, and the targeting criteria for the recurring action in section 3 below.

---

2. One-time actions versus scheduled recurring actions

The Tanium Server creates a scheduled action when you deploy an action from the Question Results page and either specify a Start At date instead of deploying immediately, or set the Schedule Type to Recurring Deployment.

If you select multiple recurring actions and act on them together, Tanium creates copies of the actions with their Schedule Type set to One Time Deployment — a detail worth knowing before you bulk-edit a set of recurring actions and wonder why they stopped recurring.

Finding a scheduled action's ID

On the Scheduled Actions page the ID column is hidden by default. Since the action ID is what ties the console record to the client-side log entries, enabling that column is one of the first things worth doing when you start troubleshooting deployments.

---

3. Policy actions and the question expiration rule

A recurring action that targets a question rather than a fixed list is often described as a policy action: the question defines "endpoints not in the desired state", and the action keeps putting them back.

At each scheduled interval the Tanium Server does this:

1. Evaluate whether the question results exceed the question expiration period, which is 10 minutes.
2. If they do not, use the results cached the last time the question was issued.
3. If they do, reissue the question to collect new results, then act on those.

Two things follow from that, and both are exam-relevant:

• A policy action does not re-query the fleet on every cycle regardless of cost. It reuses fresh-enough results, which is why a short interval does not necessarily mean constant fleet-wide querying.
• Targeting quality is entirely a function of the question. A policy action built on a sloppy question enforces a sloppy policy, forever, without anyone watching.

Desired-state configuration in practice

   SAVED QUESTION  "endpoints where the required agent service is not running"
          |
          |  defines the non-compliant population
          v
   SCHEDULED RECURRING ACTION  deploys the start-service package
          |
          |  runs on its interval
          v
   VERIFICATION  the same saved question should trend toward zero

The loop is self-correcting: as the action succeeds, the question returns fewer endpoints, and the action naturally does less work. If the count does not trend to zero, that is a signal — something is undoing the change, or the package is failing on a subset. Which is exactly what Action History is for.

4. Action History: the fleet-wide audit trail

Once an action has been deployed, the Action History workspace (Administration > Actions > Action History) serves as the central operational hub for auditing, monitoring, and forensic analysis.

+---------------------------------------------------------------------------------------------------+
|                                   ACTION HISTORY WORKSPACE                                        |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  High-Level Metrics & Summary Columns:                                                            |
|  * Action ID        : Unique numerical identifier (e.g., Action #10482)                            |
|  * Package Name     : Name of the executed package (e.g., "Restart Spooler Service")             |
|  * Target Group     : Scoped Action Group or Computer Group                                       |
|  * Deploying User   : Username of the submitting operator                                         |
|  * Approving User   : Username of the authorizing approver (if approved)                          |
|  * Start / Expiry   : Start timestamp and Expiration cutoff                                       |
|  * Status Summary   : Aggregate counts (e.g., 4,850 Completed, 12 Failed, 138 Expired)           |
|                                                                                                   |
+---------------------------------------------------------------------------------------------------+

Per-Endpoint Execution Drill-Down

Clicking into any action record in Action History opens the Action Details modal, enabling operators to inspect individual endpoint execution metrics:

+---------------------------------------------------------------------------------------------------+
|                                ENDPOINT EXECUTION DETAIL MODAL                                    |
+---------------------------------------------------------------------------------------------------+
|  Computer Name      : PROD-APP-04.corp.internal                                                   |
|  IP Address         : 10.14.20.88                                                                 |
|  Tanium Client ID   : 928374102948                                                                |
|  Execution Status   : Completed (Verified)                                                        |
|  Start Time         : 2026-08-27 14:22:10 UTC                                                     |
|  End Time           : 2026-08-27 14:22:18 UTC                                                     |
|  Duration           : 8 seconds                                                                   |
|  Process Exit Code  : 0 (SUCCESS)                                                                 |
|  Standard Output    : Service 'Spooler' successfully stopped. Startup set to 'Disabled'.          |
|  Standard Error     : (None)                                                                      |
+---------------------------------------------------------------------------------------------------+

---

5. Reading exit codes

When a package command executes on an operating system, the child process returns an integer Exit Code (also called return code or error level) to the Tanium Client. Understanding common exit codes is critical for operational troubleshooting:

Remote Log & Standard Error (stderr) Inspection

Instead of opening remote desktop or SSH sessions to failed endpoints, operators can read the captured stdout and stderr streams directly within the Tanium Console. If a script fails, the exact line number, syntax error, or missing dependency reported by the local shell interpreter is displayed in the Action History execution log.

---

6. Stopping an in-flight action

If an operator discovers that an action was deployed with incorrect parameters or targeted at unintended systems, the action can be stopped (canceled) immediately from the Console.

+---------------------------------------------------------------------------------------------------+
|                                 ACTION CANCELLATION MECHANICS                                     |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  1. Operator Action                                                                               |
|     Operator navigates to `Action History` (or `Scheduled Actions`), selects the in-flight        |
|     action, and clicks `Stop Action`.                                                             |
|                                                                                                   |
|  2. Server Instruction Broadcast                                                                  |
|     The Tanium Server immediately broadcasts a cancellation token across all linear chains.       |
|                                                                                                   |
|  3. Endpoint Response by Execution Phase:                                                         |
|     ├── Pending / Downloading: Endpoint halts payload download and discards the action.           |
|     ├── Currently Running   : Client attempts to kill the active process tree.                    |
|     └── Already Completed   : Action state is marked as Completed prior to stop; rollback         |
|                               requires deploying a reverse remediation package.                   |
|                                                                                                   |
+---------------------------------------------------------------------------------------------------+

[!CAUTION] Stopping Actions vs. Rollback: Stopping an action prevents future or pending executions across remaining endpoints. It does not automatically roll back or undo state changes on endpoints that have already finished executing the package. To reverse changes on completed endpoints, an operator must deploy a separate remediation package.