> For the complete documentation index, see [llms.txt](https://docs.adaptiva.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adaptiva.com/patch/overview/patch-planning-guide.md).

# Guide to planning a patch solution

High level overview of how to plan and implement a patching solution.

This guide outlines the recommended phased approach for planning and deploying updates using Adaptiva OneSite Patch. A structured plan minimizes disruption, validates fixes safely, and ensures critical systems remain operational.

This guide is largely conceptual and provides strategic guidance, rather than providing step-by-step implementation instructions.

## 1. Determine patch timing and cadence

The initial step is to determine the overall patching cadence.

We recommend that you open up a calendar to get a comprehensive view. Determine your desired patch deployment schedule based on your business needs. For example, you may want to collect all non-critical patches during the week and deploy them on your devices at the end of each week, while deploying critical patches on devices at the end of each day after business operation hours.

Next, determine the appropriate maintenance windows when the various devices in your organization can be patched or rebooted without disrupting business operations. Devices can have different patching and reboot windows. Some devices may have vastly different maintenance windows from other devices, so start grouping devices based on shared maintenance windows.

For example, you may have server clusters where you want to minimize downtime with tightly constrained maintenance and reboot windows, while workstations can be allowed to patch anytime during the day with reboots limited to non-business hours to avoid work disruptions.

## 2. Install the Adaptiva Client on all devices

Each device must install the Adaptiva Client. The client scans the applications on the device and identifies when a new patch is available that applies to the device, and communicates this to the server. The OneSite Patch server coordinates the devices and patch cycles, but the client actually handles the work of installing patch updates.

## 3. Model your environment into Business Units

Next, you should organize your devices into logical groupings that share similar patching requirements and restrictions. In OneSite Patch, these groupings can be represented by objects known as Business Units.

Business Units are the virtual structures that Adaptiva uses to represent a group of devices that share the same patching requirements. These should reflect operational groupings, not just physical locations.

Business Units define settings such as:

* Maintenance windows - when devices can apply patches.
* Reboot windows - when devices are allowed to reboot.
* Approval chains - The process of requesting approvals from specific people or groups before proceeding with patch deployments.
* Notification chains - The process of notifying specific people or groups about the patches being deployed.
* Additional settings. For more information, see [Business Units](/patch/patching-fundamentals/business-units.md).

Group your devices based on shared configurations and risk profiles, such as:

* Identical maintenance/reboot windows.
* Identical operating system.
* Similar installed applications.
* Similar patch frequency and immediacy requirements (e.g., "Critical" vs. "Low Priority").
* Shared operational impact profiles.
* Shared device administrators for patch approvals and notifications.
* Shared networks and subnets. Devices on the same network can benefit from peer-to-peer patch sharing, meaning individual devices do not need to download a separate copy.

## 4. Create pilot/test groups

Identify a subset of your devices in each grouping to work as a Pilot Group, to test and validate patches before rolling them out to the larger production group. The Pilot Group should contain users willing to provide immediate, detailed feedback on stability issues.

## 5. Organize Business Units in a hierarchy

You can create hierarchies of Business Units in a parent-child relationship, with children Business Units able to selectively inherit settings from their parent. This allows for the fine-tuning of smaller groups of devices that have more specific requirements or restrictions.

Review the [Business Unit Best Practices](/patch/patching-fundamentals/business-units/business-units-best-practices.md) for additional recommendations when creating Business Units.

## 6. Add devices to Business Units

Once you have identified and created your Business Units in OneSite Patch, the next step is to add devices to the Business Units. Every device must have the Adaptiva client installed on and be detected by the server before you can add it to a Business Unit.

You add devices by defining the Business Unit Scopes, which can be a list of device IDs, one or more SQL queries, sensors, or a list of locations.

The recommended way to add devices to business units is to set up an SQL query that filters devices based on predictable identifiers like the client name, rather than relying solely on IDs.

You can also use [sensors](https://docs.adaptiva.com/platform-guide/platform-features/sensors), objects that are deployed to devices to retrieve specific device data, to dynamically add or remove devices from a Business Unit. For example, you can use a sensor to map Business Units to Active Directory organizational units.

Set the evaluation schedule for a Business Unit so that it will periodically check for changes to device membership.

If you have created a Hierarchy of Business Units, you must add devices to the parent Business Unit before you can add devices to the child Business Unit.

Devices can belong to multiple Business Units; in such cases, the device applies the settings from the Business Unit listed lowest.

## 7. Use dashboards to view the state of your devices

OneSite Patch includes a number of helpful [dashboards](/patch/get-started/dashboards.md) that provide real-time information about your system. Before you set up your patch strategies, it's a good idea to thoroughly examine the dashboards to identify the following:

* Known vulnerabilities.
* Critical risks.
* Products or patches that must explicitly be excluded from any deployment due to business impact concerns.
* Any specific customizations required for patching any of the products on your devices.

In OneSite Patch, you can select **Asset Management > Devices** to get a high level view of your device states. You can drill down into specific devices to see detailed information such as patch history, lists of products on the device and their patch states, etc.

## 8. Create a test strategy

Next, select a product requiring patches across multiple devices. Make sure some of the devices that need patching are in a pilot group, and others are in the production group.

[Strategies](/patch/get-started/strategies-v2.md) are the central management objects in Adaptiva that define how, when, and where to update patches.

Create a simple strategy to rollout that patch to the pilot group of devices, then run the strategy to test that everything works correctly.

If the patch succeeds on the pilot machines without issue, then you can rollout the patch to the production machines.

You can either create a second strategy to rollout the patches to the production machines, or use the deployment rings feature of strategies to deploy to devices in waves.

## 9. Define your minimum set of strategies

Once you've confirmed that your test strategy is working and deploying patches properly to your devices, you can start building out your minimum set of strategies for your business.

At a minimum, create separate strategies for:

* 3rd party patches - these tend to be smaller, require less time to install, and typically don't require a reboot.
* OS Patches - these tend to be larger and usually require one or more reboots.
* Each OEM (Dell, HP, Lenovo) hardware interface updates - this includes BIOS, firmware, and driver updates provided by Dell, HP, and Lenovo. These can often interrupt device functionality, and usually require reboots.

{% hint style="info" %}
When creating these strategies in OneSite Patch, document why the separation exists (e.g., "OS patches require a reboot; this group runs only during nightly maintenance") in the description of the strategy. As your collection of strategies grows more complex, this will help you keep track of them.
{% endhint %}

To maintain test integrity and ensure reliable results, refrain from utilizing the **Include all products** toggle within any strategy definition. Instead, manually select specific target products for each defined strategy. This approach enables you to test against a controlled set of known products and vulnerabilities. Using an overly broad scope risks deploying unknown variables (i.e., applications installed on production machines but outside the pilot group), significantly increasing the likelihood that critical issues will reach live environments undetected.

View the [Common patch configurations](/patch/get-started/common-patch-configs.md) topic for guidance on how to implement commonly used strategies, such as:

* Pilot Monday/patch Friday
* Accelerated browser patching
* Clustered server patching

## 10. Define special case patching scenarios and strategies

Next, you'll want to identify any special patching scenarios as defined by your business needs, which are not covered in your more general strategies. These may be strategies specific to a group of devices, clusters of server nodes that need to be patched in a specific order to avoid downtime, groups of devices that have different approval chains, etc.

Identify any products that require customized command lines or special actions (like suspending BitLocker) in order to install patches. For example, the Zoom desktop app installation has multiple customizations available. For these products, you can create [Customized Products](/patch/advanced-settings/customized-products.md).

For each scenario, make sure that you have pilot devices available to test the patches before rolling them out to your live production environment.

## 11. Regularly use the dashboards to ensure that the system is running smoothly

OneSite Patch includes a number of helpful dashboards so you can validate if everything is patching smoothly, or if there are issues you need to address. In OneSite Patch, you can select **Dashboards > Dashboards** to see a list of preconfigured dashboards as well as any custom dashboards.

For example, you can use the preconfigured dashboard **Deployment Status History Per Device** to see a list of all patches that were installed on a specific device.

In addition, you can create or import custom dashboards as needed. For more information, see [Common Dashboards](https://docs.adaptiva.com/platform-guide/platform-features/dashboards/dashboards-common).

You should also become familiar with [Flex Controls](/patch/patching-fundamentals/flex-controls.md), which allow you to perform manual operations such as adding patches to a blocklist, rolling back patches, pausing patch operations, etc.

## Ask for help

If you have any questions during the process and would like additional guidance or assistance, please reach out to the Adaptiva Customer Success team:

* You can enter a support ticket via the Web portal: <http://support.adaptiva.com>. Both full-site and mobile versions are supported.
* Alternatively, you can send an email to <ticket@adaptiva.com>. Registering in the Adaptiva Support Portal first will help ensure that your email is delivered promptly to the team.