TCO common mistakes
TCO · Understand the traps and how to avoid them.
Answers connectivity scenarios by assuming the Tanium Server must reach each endpoint and that inbound ports must be opened to every managed machine.
Candidates carry over habits from server-push management tools and never internalize that the Tanium Client is the one that initiates and maintains the connection outward to the server/zone server.
What to do instead
Rehearse the direction of traffic: clients connect outbound to the server on TCP 443 and poll for work, so no inbound rule to the endpoint is required; only the server side needs to be reachable by clients.
When a sensor, package, or set of endpoints is missing from the console, concludes the content is broken instead of checking the operator's role, persona, and content set assignments.
Most hands-on practice is done with a full administrator account, where every sensor and every endpoint is visible, so the effect of role-based access control is never observed.
What to do instead
Learn that roles and content sets scope which sensors, saved questions, packages, and endpoints an operator can see and target; verify assignments first before troubleshooting content.
Selects the top-level question result row (the aggregate count) and deploys an action from it when the intent was only the endpoints inside one drilled-down row.
The results grid presents per-row counts, and it is easy to act on the visible aggregate rather than the specific row that identifies the target population.
What to do instead
Drill into the specific result row that defines the target set, confirm the endpoint count shown for the action target, and only then deploy.
Types question text freehand and trusts whatever the parser resolves it to, or issues the question against all machines when only a filtered subset was intended.
Tanium questions are parsed against the sensor library, so loosely worded text can resolve to a different sensor than the candidate had in mind, and the parser's interpretation is rarely read back.
What to do instead
Build the question by selecting the sensor explicitly from the library, read the parsed question text before issuing, and attach filters to narrow scope rather than asking broadly and interpreting afterwards.
Deploys a package without opening the package definition to confirm the command line and required parameters, then treats a green deployment as proof the change happened.
The action form pre-populates parameters and a package can run successfully while doing nothing useful, so a Completed status is mistaken for the intended outcome.
What to do instead
Review the package command line and every parameter before deploying, and after the action finishes confirm both the per-endpoint status and the actual endpoint change.
Concludes a deployment failed because not every endpoint shows as completed, when the remainder are pending approval, not run, or expired.
Only the headline action status is checked; the individual endpoint statuses and any approval requirement on the action are never inspected.
What to do instead
Read the per-endpoint action status breakdown and distinguish Pending, Active, Completed, Failed, and Expired; check whether the action is waiting on approval before calling it a failure.
Writes a custom sensor that returns multiple rows, an entire directory listing, or a large block of text, then wonders why the question errors out or the results are unusable.
Sensors look like scripts, so candidates write them as if they were general-purpose reporting tools, ignoring that a sensor returns one row per endpoint to the question engine.
What to do instead
Design every sensor to return a single row of data per endpoint, aggregating or filtering inside the sensor itself, and use other mechanisms for bulk output.
Saves a newly authored sensor and immediately wires it into a broad saved question or dashboard without ever running it against a small test group.
Authoring and validating feel like separate steps, and the console makes saving content easy enough that testing is skipped; the difference between a sensor error and a legitimate no-result is then invisible.
What to do instead
Ask the sensor against a handful of known endpoints first, confirm expected values and clean error output, then save it and widen its use.
Treats a dashboard tile or report as live endpoint state and draws conclusions from it without checking when the underlying saved question last ran.
Dashboards present data visually and current-looking, so the fact that each tile is the result of a past execution of a saved question is forgotten.
What to do instead
Check the last-run time for the saved question behind each tile, and confirm the question is scheduled at the cadence the report requires.
Quotes a compliance percentage from a question without confirming how many managed endpoints actually returned results.
The results grid naturally emphasizes the endpoints that answered, while endpoints that did not respond simply are not in the numerator or denominator, so the reported rate looks better than reality.
What to do instead
Compare the number of endpoints that answered against the expected managed endpoint count, and report non-responding endpoints as unknown rather than compliant.