Business Units best practices
Best practices for Business Units
When creating or moving Business Units, use these best practices to prevent devices from inadvertently inheriting unwanted settings.
Devices assigned to multiple Business Units will use the settings from the highest-priority Business Unit - which is always the lowest Business Unit that the device is a member of, as listed in the configuration panel.
Because of this, creating or moving a Business Unit can cause member devices to inherit different settings than you might expect, potentially triggering immediate patch/reboot cycles.
These best practices will help prevent situations like this.
Create a restrictive Schedule and Maintenance Window
Create a restrictive schedule and maintenance window that will not be triggered in the near future. These are used for the next best practice, Give the All Clients Business Unit extremely restrictive settings.
For the purposes of this document we will call these objects Safety Window, but you can choose any name.
1. Create a Safety Window Schedule
In OneSite Patch, under Platform Features, select Schedules.
Click + New.
Enter Safety Window for the schedule name, and optionally add a description.
In the Schedule Repeat field, select Not Recurring.
In the Start Time field, click the calendar icon and select a date in the far future, such as Dec 1st, 2075.
Click Save and Deploy to save the new schedule.
2. Create a Safety Window Maintenance Window
In OneSite Patch, select Advanced Settings > Maintenance Windows
Click + New.
Enable the Apply to All Urgencies toggle.
Click + Create Maintenance Window.
Next to Start Time Schedule, click Browse (this opens the Select Schedule dialog).
Find and select the Safety Window Schedule that you created in the previous step.
Click OK to return to the Create Maintenance Window dialog.
Set the Duration field to 2 minutes.
Click Create Maintenance Window.
Under Start Time Schedule, select Safety Window.
Enter Safety Window as the Maintenance Window name and optionally add a description.
Click Save and Deploy.
This will create a new Maintenance Window called Safety Window that will not be reached in the next 50 years.
Give the All Clients Business Unit extremely restrictive settings
When you click + New to create a new Business Unit, it is created at the bottom of the list, giving it the highest priority. It also inherits settings from the root All Clients Business Unit by default.
The All Clients Business Unit does not define any Maintenance Windows by default, and has the User Interaction Settings set to Reboot Only - 24 Hour Warning (Anytime), which does not respect Maintenance Windows.
This means that if you create a new Business Unit and add devices to it without changing any other settings, the device will not have any Maintenance Windows defined. If any strategy deploys patches to any Business Unit that the devices are members of, those devices will immediately attempt to apply the patches and potentially reboot.
To prevent this, edit the All Clients Business Unit and make the following changes:
Set the Deployment Window and Reboot Window to the Safety Window Maintenance Window that you created in the previous best practice.
Set the User Interaction Settings to Deployment and Reboot - 24 Hour Warning (In Maintenance)
Click Save.
This will make it so that any direct children Business Units will not apply any patches or reboots unless the Maintenance Windows and User Interaction Settings are specifically set.
Create two root Business Units for utility and deployment
To help enforce settings priority, you should create the following root level Business Units at the bottom of the list of Business Units, in the following order:
Utility- a parent for Business Units for any utility functions, such as reporting, filtering, exceptions, and rollbacks. These Business Units are typically not part of a strategy.Deployment- a parent for any Business Units related to deploying patches. Each Business Unit in this group should be included in at least one strategy.
Set the maintenance windows and user interaction settings for these new Business Units with settings that are applicable to the majority of your devices, especially for the Deployment Business Unit.
With these new base Business Units, you can create children Business Units under each category by clicking the action menu (...) and selecting Add Child Business Unit.
This way, device settings in Deployment will have priority over device settings in Utility, which in turn have priority over device settings in any Business Unit listed above it.
Using these two categories to contain most of your Business Units helps to explicitly define the priority and settings of your devices, reducing the risk of unexpected device patching and reboots.
Note that you can only add devices to a child Business Unit if those devices are also present in the parent Business Unit, so make sure to add devices appropriately to these new Business Units.
Best practices when moving Business Units
When changing the position of a Business Unit in the list, follow these best practices to avoid unintended deployment behavior:
Validate settings
Before moving the Business Unit, review the Business Unit’s settings, including Rollout Processes, approval behavior, maintenance windows, notifications, and interaction settings, and understand which settings are being inherited and what the new settings will be after the change.
After the change, validate that the Business Unit's settings match your expectations. If the Business Unit had children, ensure that the children Business Units' settings also meet your expectations.
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 hierarchy.
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.
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.
Test changes before broad rollout
Where possible, validate hierarchy changes using a lab or test Business Unit before applying them to production environments.
Last updated
Was this helpful?