5.2 Operations Modules: Deploy, Patch, Asset, Performance and Provision
Key Takeaways
- Tanium Deploy installs, updates or removes software on a flexible set of targets, and is the right tool when what you manage is software with a lifecycle rather than a one-off command.
- Tanium Patch automates patch delivery and models supersedence, so a raw question for a specific superseded KB can wrongly suggest an endpoint is unpatched.
- Tanium Asset aggregates live asset data with recent data from offline assets, which is what makes it usable for licence reconciliation and audit rather than a live Interact question.
- Tanium Performance monitors, investigates and remediates endpoint performance issues and carries history, so it can distinguish a new slowdown from a longstanding one.
- Tanium Provision handles bare-metal and operating-system refreshes, and a provisioned endpoint loses local state such as custom tags, which breaks hand-maintained manual computer groups.
5.2 Operations Modules: Deploy, Patch, Asset, Performance and Provision
Quick overview: Blueprint objective NAV-1 asks you to navigate to a module to perform a basic module-specific task. That means knowing, for each module, what problem it owns and what the first thing you do in it is. This section covers the operations-side modules an operator uses most; section 5.3 covers the security and risk side.
1. Why the module boundary matters
Interact can answer almost anything and deploy almost anything, so a reasonable question is: why use a module at all?
Because modules add three things Interact does not have:
- Domain state. Patch knows what a patch is, which ones supersede which, and what "installed" means on each platform. Interact only knows sensor strings.
- Workflow. Deploy knows about software packages, maintenance windows and reboot behaviour, so you configure a deployment rather than assemble one.
- History. Modules retain their own results over time, which is what objective NAV-2 — interpret module-specific historical results — is about.
The exam-relevant instinct: if a module owns the problem, go to the module. Rebuilding patch compliance out of raw sensors in Interact is possible and is the wrong answer.
2. Tanium Deploy
What it owns: installing, updating or removing software on a flexible set of targets.
| You want to… | Basic task in Deploy |
|---|---|
| Get an application onto a set of endpoints | Create a software deployment targeting a computer group |
| Remove unwanted or unlicensed software | Create a removal deployment |
| Keep an application at a required version | Configure a deployment that re-evaluates over time |
| Know what is deployable | Review the software packages catalogue in the module |
Deploy also feeds Reporting: the Endpoint Details page's Endpoint Management tab shows Software Package Applicability and Maintenance Windows panels populated by Deploy.
[!TIP] Deploy versus a plain package action: use a package action for a one-off command or script; use Deploy when the thing you are managing is software with a lifecycle — versions, applicability, maintenance windows, removal.
3. Tanium Patch
What it owns: automating patch delivery to minimise security vulnerabilities.
| You want to… | Basic task in Patch |
|---|---|
| See what is missing across the fleet | Open the module's overview and read patch applicability |
| Push this month's updates | Build a deployment from a patch list against a target group |
| Standardise a recurring monthly process | Create a deployment template and reuse it |
| Control when endpoints may be disrupted | Configure maintenance windows |
Patch also populates the OS Patch Applicability and Maintenance Windows panels on the Reporting Endpoint Details page.
The patch trap worth knowing
Cumulative updates supersede earlier ones. A question such as Get Installed Patches from all machines on a fully patched Windows endpoint returns the current cumulative update — not the twelve monthly updates it replaced. Searching for a specific superseded KB and finding nothing does not mean the endpoint is unpatched. This is exactly the kind of domain knowledge that makes the module the right tool: Patch models supersedence, a raw sensor question does not.
4. Tanium Asset
What it owns: viewing enterprise inventory by aggregating live asset data with recent data from offline assets.
That phrase is the whole point of the module. Interact tells you about endpoints that are online now. Asset gives you the inventory including the machines that are switched off — which is what makes it usable for licence reconciliation, hardware refresh planning and audit responses.
| You want to… | Basic task in Asset |
|---|---|
| Answer "how many of X do we own?" | Open the inventory views in the module |
| Reconcile software licence counts | Report on installed software across the full inventory |
| Plan a hardware refresh | Report on hardware attributes and age |
| Feed a CMDB | Combine Asset with Connect (chapter 6) |
5. Tanium Performance
What it owns: monitoring, investigating and remediating endpoint performance issues.
Performance is the module to reach for when the complaint is subjective — "my laptop is slow" — and you need it to become measurable. It carries history, so it can answer "was it slow yesterday, or only since the change?", which a live Interact question fundamentally cannot.
| You want to… | Basic task in Performance |
|---|---|
| Investigate a slow endpoint | Open the endpoint's performance view and review its history |
| Find fleet-wide degradation | Review performance across a computer group |
| Correlate a change with a slowdown | Compare the period before and after a deployment |
6. Tanium Provision
What it owns: modernising bare-metal and operating-system refreshes.
Provision is where OS deployment lives. For an operator the relevant fact is usually a consequence rather than a task: a provisioned endpoint is a new endpoint. Custom tags are gone (section 3.5), local state is gone, and any manual computer group listing the old machine is now wrong. Dynamic groups and tagging built into the build process survive; hand-maintained lists do not.
7. A routing table for operations scenarios
| Scenario | Module |
|---|---|
| "Install this application on the finance workstations" | Deploy |
| "Which endpoints are missing this month's updates?" | Patch |
| "How many Windows Server licences do we actually need?" | Asset |
| "This group of laptops has been slow since Tuesday" | Performance |
| "Rebuild these machines to the standard image" | Provision |
| "Is this specific process running right now?" | Interact — no module needed |
| "Run this one-off script on twelve endpoints" | Interact — deploy a package action |
8. Fleet hygiene as a worked routine
Continuous hygiene is where these modules earn their place, and the routine is the same each cycle:
| Step | Where | What you are establishing |
|---|---|---|
| 1. Inventory | Asset | What we have, including offline assets |
| 2. Exposure | Patch and Comply (5.3) | What is missing or misconfigured |
| 3. Remediation | Patch, Deploy | Close the gap on a controlled schedule |
| 4. Verification | Interact, module history | Did the gap actually close? |
| 5. Trend | Reporting (chapter 6) | Is the gap closing faster than it opens? |
Step 5 is the one that distinguishes an operator from a ticket-closer. A single patch cycle is an event; the burn-down across cycles is the thing leadership asks about, and chapter 6 is how you produce it.
An operator queries a fully patched Windows endpoint for a specific security update from six months ago and gets no result. What is the correct interpretation?
A licensing audit needs an accurate count of installed copies of an application across the enterprise, including machines that are currently powered off. Which module is designed for this?
When should an operator use Tanium Deploy rather than deploying a package action from Interact?
Why does provisioning an endpoint break a manual computer group that listed it, while a tag-based dynamic group behaves differently?