Business Units are the primary organizational structure in TPM. They logically group devices based on shared attributes such as:

• Location

• Purpose

• Users

• Organizational structure

These groupings determine how patches, settings, and policies are applied to devices. Business Units can also be used to directly target customized products.

Rollout Processes operate at the Business Unit level and define how patches are approved and deployed. This includes managing approvals, targeting a specific Business Unit, and initiating patch rollouts once approval is received.

Business Units

Business Units group devices with shared characteristics and provide a scalable way to manage patching behavior. Each Business Unit can define its own rollout process, approvals, maintenance windows, notifications, and other patching settings.

Business Units are hierarchical, with child units inheriting settings from their parent unless explicitly overridden. TPM includes a default parent Business Unit for all clients, along with child and lab Business Units to further refine deployment scope and customize patching behavior.

Note: When using Business Units with an Advanced Patching Strategy, ensure the Patch Deployment Bot for that strategy targets the same Business Units.

Parent and Child Business Units

Business Unit objects use a parent-child hierarchy. This structure gives you the freedom to create patching hierarchies that match any endpoint landscape.

Note: Child Business Units may only contain devices that the Parent Business Unit also manages.

There is no functional difference between parent and child Business Units. The parent/child hierarchy exists solely to support settings inheritance. An inherited setting or process is indicated by a blue up-arrow, and inheritance is enabled by default. When overriding inheritance, deselect the blue up-arrow and this will enable the previously greyed out field.

Organizing the Business Unit Hierarchy

You can arrange the Business Unit view in hierarchies that meet the needs of your environment. Parent Business units pass attributes to child Business Units, so it is important to maintain those relationships where they exist.

When a device belongs to multiple Business Units, deployment behavior is always governed by the highest-priority Business Unit.

For example, if a device belongs to both the Seattle HQ parent Business Unit and the Seattle Windows Only child Business Unit, the device follows the settings defined in Seattle Windows Only, assuming it has the higher priority. Even if a patch strategy targets the Seattle HQ Business Unit in a deployment ring, the device still uses the settings from the higher-priority Seattle Windows Only Business Unit.

Best Practices

Business Units at the bottom of the hierarchy have a higher priority than at the top.

When changing the priority of a Business Unit in the TPM hierarchy, follow these best practices to avoid unintended deployment behavior:

1. Validate settings

   • After changing priority, review the Business Unit’s settings, including Rollout Processes, approval behavior, maintenance windows, notifications, and interaction settings.

2. Review device scope and membership

   • Ensure that all devices in the Business Unit are intended to receive the policies and deployments associated with the new priority level.

3. Verify inheritance configuration

   • Check inheritance toggles after the move to confirm that settings are either correctly inherited from the new parent or explicitly overridden where required.

4. Assess impact on deployment rings

   • Identify whether the Business Unit or any of its ancestors are included in deployment rings that target descendant Business Units.

     • Remove the Business Unit from rings that no longer apply.

     • Confirm that any inherited ring participation is intentional.

5. Test changes before broad rollout

   • Where possible, validate priority changes using a lab or test Business Unit before applying them to production environments.

Create a Business Unit

Tenable provides default Business Unit templates. Except for the Root template, these templates can be copied and customized, or you can create new Business Units as needed. Child and Lab Business Units allow administrators to further refine and customize the patching environment.

In version 10.970 and later of TPM, there are several business unit templates that effectively target smaller subsets of devices in order to deploy patches more granularly.

Note: When creating a new Business Unit, and it is immediately scoped for membership (by default), it becomes the highest priority Business Unit. If you have not defined the Maintenance Window settings or the User Input Settings, this may override other settings in the hierarchy and cause unexpected software deployments or reboots.

1. Select Asset Management > Business Units in the left side navigation.

2. Select the right arrow to the left of any folder to expand the list of available templates.

3. Select the ellipses (...) then select Save As.

4. Save the template with a new title:

   1. In the upper-left of the dialog, select More, and then select Save As.

   2. Enter a new name for the template, and then select Save as. This returns you to a copy of the template with the new name.

General Settings

1. (Optional) Enter a Description.

2. Select Browse next to Evaluation Schedules.

   For Business Units with dynamic membership that may change over time, evaluation schedules determine when to check the membership of a Business Unit. Dynamic membership can occur based on Location or Sensor scopes, where a device moves between locations or Sensor results change over time.

   The Evaluation Schedules added here trigger Group Membership evaluations for this Business Unit to regularly check for group membership changes.

   

Business Unit Scopes

Business Unit Scopes define the rules used to find and include devices in a named Business Unit. Tenable supports using one or more scopes to create a Business Unit.

Select a Rollout Process

Customizing Rollout Processes is an advanced feature of Tenable. For more information, contact your Tenable Representative or Tenable Customer Support.

Maintenance Windows in Business Units

Business Unit maintenance settings allow you to define separate windows for deployments and reboots. Deployment Windows and Reboot Windows operate independently.

If you configure a Deployment Window but do not define a Reboot Window, installations occur during the Deployment Window, but any required reboot may occur at any time.

To restrict reboots, you must configure a Reboot Window. Reboot Windows must occur within the Deployment Window.

1. Select Browse next to Deployment Window or Reboot Window and select the desired option or create a new window.

2. Click OK.

Add User Interaction Settings

Choose a User Interaction Setting for the devices in this Business Unit. These settings control how end users are notified about upcoming installations and reboots. For more information about User Interaction Settings, see User Interaction Settings.

1. Select Browse next to User Interaction Setting and select the desired option.

2. Click OK.

Add Approval Chains to a Business Unit

Approval Chains settings enable administrators to specify users who will receive patch approval requests for Business Units. You have the option of defining an approval chain for each type.

1. Select Add... next to the type of Approval chain you want to add.

2. Select an Approval Chain from the Approval Chains table.

Customer Extension Data

Customer Extension Data is an advanced feature of Tenable. The Customer Extension Data fields allow you to specify different key/value pairs for use in customized Patching Strategies, Deployment Chains, or Business Units when necessary to achieve different results.

Customer Extension Data fields relate directly to fields in a customized template. If you do not have customized templates with key/value pairs you can modify, you do not need to configure or use this feature. If you want to create customized templates that use key/value pairs for some settings, contact Tenable Support.

Add a Notification Chain

Notification Chain settings exist in the object templates for Patching Strategies, Deployment Channels, and Business Units.

1. Select Browse next to the Notifications Chain. This opens the Notifications Chain dialog.

2. Select a Notification Chain from the table.

   To edit or create Notification Chains, refer to Chains.

Content Prestaging Settings

The Content Prestaging feature deploys content to devices ahead of the scheduled deployment, either pushing content to a location or allowing a client to pull content. Prestaging content makes the content available on the device locally when the deployment time arrives. This reduces the deployment time and minimizes the chances of missing service windows or having devices going offline before a content download finishes.

To configure these settings, refer to Content Prestaging Settings.

Related Business Units

In this section, you can select associated Business Units to relate to your new Business unit. This lets you define Parent and Child business units and use a lab business unit for testing.

If inherited from a parent Business Unit, values merge with the custom lab values of the parent and supersede the parent values when they conflict.

Verify Business Unit Members

After saving the Business Unit, select Show Members to display the members of the Business Unit and verify that you have populated the Business Unit as you intend.

Note: Selecting Evaluate Now causes evaluation of the group membership rules to occur off schedule.

Rollout Processes

Business Unit rollout processes determine which clients receive patches and control the final step before patches are delivered. For example, a rollout can deploy patches in batches of 100 clients, allowing administrators to monitor progress and address issues before continuing.

After the Patching and Deployment Channel processes define the required activity, they delegate rollout execution to each Business Unit. Each Business Unit then manages its deployment using its customized All Clients Rollout Process workflow. Before creating a custom Rollout Process, enter a support ticket and request help from Tenable Customer Support.

Including Rollouts in Business Units

The Rollout Process uses information from a Business Unit template, such as Approval Chains, Notification Chains, and Related Business Units, to control patch approval and deployment. It also performs the actual client deployment for the Business Unit.

New child Business Units automatically inherit the parent’s Rollout Process, which is typically the All Clients Rollout Process. If a Rollout Process is inherited, you must disable inheritance before making changes.