Tanium 6.x: Action Groups


Action Groups are a way to push scheduled actions out to the same targets and bundle them into collapsible lists. There are many potential uses for Action Groups, but one very common one is Windows OS Updates. Action Groups for updates can be created for each new Microsoft patch cycle. You must create Action Groups before you can use them in a scheduled action.


To create an action group:

  1. Log in to the Tanium Console
  2. Navigate to ActionsScheduled Actions
  3. Click the Add New Action Group... link in the upper right corner of the Actions tab.
  4. Enter an "Action Group Name"
  5. Select one or more Computer Groups to include in the Action Group as targets.
  6. The Action Group can be used for Scheduled Action deployments.


As an example, visiting the Windows OS Patch Management Dashboard, we can first sort by Date and then by Severity. Use Ctrl-Alt-Click on columns to sort by secondary and tertiary columns.

Select a group of updates like below:


Next, press the Deploy Action button and fill in the details, choosing the Action Group.


In almost all cases, an operator would be wise to choose All rows selected in the source question. This keeps actions from being fired off from the server if no machines respond that they would be targeted for them.

Also note the Reissue Every: option. Reissuing the Action is important so that machines that are offline would eventually get the update files. Without a reissue, the action would only trigger on machines that are online one time. It is best when testing packages to not use reissue and deploy against a single specific machine using either a single machine action group or selecting the target machine to deploy the action against.

As soon as the operator proceeds through the Finish window, the Scheduled Action is created. What makes patch deployments such a fitting candidate for Action Groups is the ability to multi-select Computer Groups in the action group. In this example, when the Patch Pilots group has tested the updates and they are ready for wider deployment, there is nothing to do other than visit the Action Group and redefine its target to now include a wider audience, perhaps something like All Workstations.

Best Practice

Action groups are one of the primary ways to control the scope of an action, with the other being scope of the source question. Because of this it is important to define a specific process for actions and the use of action groups to deploy across an environment.

When Tanium is first installed the Default action group contains all machines. This is setup to allow many core Tanium packages to get pushed to the first end-points. As the number of end-points increases for the installation it is best to follow a few best practices in defining and using action groups:

Move Tanium Actions to Their Own Group

Tanium's initial content as well as many other solution packs and workbenches come with scheduled actions to ensure the end-points have the tools needed to perform the functions in the sensors and packages deployed. These scheduled actions need to persist and re-issue to all machines to catch any new machines that don't have Tanium installed, machines that were rebuilt or had Tanium uninstalled, or VDI type machines that refresh on a regular basis.

All solution packs put these new scheduled actions into Default that originally contains all machines, but as the number of end-points and scheduled actions grows, Default can become unwieldy if used in this way. Actions may accidentally be disabled or deleted that are critical to Tanium functions or the scope may be reduced, as is recommended, even though these actions should continue to hit all machines.

A new action group should be created with a scope of All Computers and these actions moved to this new group. New solutions imported should have their scheduled actions moved once they are proven out using the Default action groups scope.


Reduce the Scope of the Default Action Group

All new actions will be set to run against the Default action group unless specifically set otherwise and solution pack imports, excluding Tanium Trace, will place their actions in the default group automatically. This is ideal when first installing Tanium, but can introduce risk if the question the action is based off of is scoped incorrectly with thousands of machines in the environment. Once a number of action groups are created, including the Tanium Core Actions group, it is recommended to reduce the scope of the default action group to machines owned or controlled by the Tanium Admin team. This group can be used to test deployments to machines where log verbosity is turned up and admins have easy access to logs to review any issue.


Define Specific Use for Each Action Group

There are two methods to define action groups in an environment. The above usage example shows a single action group used for deploying February patches. This action group would typically start with test machines and the action group definition would change over time to include more machines until the maximum scope, such as All Computers or All Windows Computers, was hit. In this scenario, no new actions would be deployed against this group as, depending on when the new actions were deployed, the new action could be hitting all machines.

The other method is to define action groups with a predefined scope of machines. A "Patching Test" action group could be defined and new patches run against those machines. This would require the scheduled action be moved by dragging and dropping the action into a different group such as "Patching UAT" and eventually hitting "Patching Prod" that would contain the same end scope as the above scenario, "All Computers" or "All Windows Computers". Actions could be defined and added to these groups at any time as their definition would not change and there would be less need for new action groups.

Limit Access to Edit Action Groups

No matter which method of managing action groups is chosen, managing how and when the action group definition changes is very important. When deploying an action users are given the number of machines currently online that will be effected by the action, but it is difficult to know if the action group definition has changed from this screen and the user may create a scheduled action to reissue to a larger scope than intended. Changing of action groups in either deployment scenario should be a controlled process and within Tanium only Content Administrators and Administrators can change the scope of an action group.

Enabling action approval will require a second user to ensure the scope and action are correct. This approval is performed from the scheduled action tab which gives this user good visibility into the action group definition along with the package scope. See Action Approval for additional details.

Have more questions? Submit a request