Advanced Patching Strategies

Beginning with OneSite Patch v10.0, we've created a new more intuitive way to create Strategies. The Patching Strategies outlined in this page are intended for advanced users who want to further customize their Patching Strategies.

For more information regarding the new v2 Strategies, please see our Get Started page.

If you would like to continue with Advanced Patching Strategies, we highly recommend you reach out to our Support Team for assistance.

Patching Strategies are the central management objects in Adaptiva because they group the details that define how, when, and where to update patches. Adaptiva includes prepopulated templates that address most patching scenarios. You can save these templates using your own titles and descriptions, and then customize them to your environment.

Purpose of a Patching Strategy

Each Patching Strategy uses building blocks that can include Schedules, Notifications (Chains), Deployment Channels, and Bots to define a given patching scenario. At minimum, a Patching Strategy must include a Patching Process and a Deployment Bot.

Functionally, a Patch Strategy performs the following:

• Automated handling of new patches

  Automatically discovers new patches and uses the Deployment Bot to match new patches to the Patching Strategy. The Patching Process queues patches for processing and, according to the set schedule, activates patch deployment in groups to minimize the impact on endpoints and end users.

• Customized targeting of patches

  Administrators can target specific products and high-profile patches that trigger a Deployment Bot based on individual products. Targeting is particularly useful when you first install Adaptiva, you have a considerable number of products that require patching, and you prefer to review the progress of patching before fully automating the process.

• Reuse Intent Schema Objects

  All objects in Adaptiva are interoperable and designed for use in any Patching Strategy. Create a patching process, schedule, notification or approval chain, or deployment process once, and then use them in various Patching Strategies depending on your needs.

Built-in Patching Strategies

Built-in strategies are often enough to get an organization started with a patch deployment scenario.

1. Select Strategies from the side bar navigation.

2. Select any folder from the Built-In Patching Strategies to see the available templates associated with that strategy type.

   

Patching Strategy Templates

Effective management and deployment of software patches is crucial for maintaining the security and stability of an IT infrastructure. The Patching Strategies included in OneSite Patch address various deployment scenarios and considerations.

Recommended Use

You can choose a Patching Strategy template, save it under a descriptive local naming convention, and then customize it as needed. OneSite Patching Strategy templates reference objects that include the minimum requirements for a successful patching strategy: Deployment Wave, Deployment Bot, and Patching Process.

Adaptiva recommends creating a folder to hold all new or customized strategies. This separates them from the strategies provided with the product.

Patching Strategy Template Naming Conventions

Adaptiva Patching Strategy templates cater to four specific use cases: Approval Types, Rollout Scheduling, User Interaction Settings, and Rollout Phasing. When deciding which Patching Strategy to choose, consider the following example to understand naming:

By offering various combinations of these parameters, the templates are a versatile framework that can accommodate a wide range of patching scenarios.

Minimal customization includes adding the products to patch and a schedule. This flexibility allows for efficient patch management without the need for extensive customization or the creation of new strategies.

• Approval Type: Level of approval needed prior to deployment:

  • No Approval: Deploys at once.

  • Initial Approval: Requires approval prior to deploying.

  • Phased Approval: Requires approval between each wave in the Deployment Waves object.

• Rollout Scheduling: Defines the schedule and impact of a deployment.

  • Immediate: All product patches deploy at once.

  • RiskBased: Targeted and controlled deployment based on specific risk levels (low, medium, high, critical). Schedule and run patch deployments based on risk levels. Uses Deployment Channels.

• User Interaction: Defines permitted user actions related to the patch installation.

  • Mandatory: Alerts the end user who can postpone depending on User Interaction Settings but cannot decline. All product patches deploy at once.

  • Options: Alerts the end user. Otherwise, functionality not available in this release.

• Rollout Phasing: Deploys in separate phases to allow a review before continuing.

  • Minimal customization includes adding the products to patch and a schedule.

  • This flexibility allows for efficient patch management without the need for extensive customization or the creation of new strategies.

Initial Patch Manager Approval Strategies

Each of these strategies requires an approval step before deploying updates. Except for Risk Based Mandatory Deployment, the Patching Process within these strategies manages the deployment process exclusively and does not use Deployment Channels.

Similarly, the Deployment Bot does not apply any filtering mechanism, so the Patching Process manages all updates related to the products included in the non-risk strategies.

• Initial Approval - Immediate Mandatory Deployment

  • Approval required prior to deployment, then deploys at once with no user interaction.

• Initial Approval - Immediate Mandatory Phased Deployment

  • Approval required prior to deployment, then deploys at once in a phased manner, rolling out to each wave of business units sequentially with no user interaction control.

• Initial Approval - Risk-Based Mandatory Deployment

  • Approval required prior to deployment, and then deploys at once to all devices in the targeted business units based on the patch risk levels.

  Uses both Deployment Waves and Deployment Channels. Higher-risk updates have priority in high-frequency Deployment Channels. Lower-risk updates belong to lower-frequency Channels.

  Also uses Deployment Bot to filter patches based on risk level, and then sends the final wave to the proper Deployment Channels.

  Ensures processing and deployment of the final wave through the most suitable Deployment Channel and adds a layer of control and customization to the deployment process.

No Approval Strategies

Each of these strategies requires no approval before deploying updates. Except for Risk Based Mandatory Deployment, the Patching Process within these strategies manages the deployment process exclusively and they do not use Deployment Channels.

Additionally, the Deployment Bot does not apply any filtering mechanism, so the Patching Process manages all updates related to the products included in the non-risk strategies.

• No Approval - Immediate Mandatory Deployment

  • No approval needed prior to deployment. Deploys at once with no user interaction.

• No Approval - Immediate Mandatory Phased Deployment

  • No approval needed prior to deployment. Deploys at once in a phased manner, rolling out to each wave of Business Units sequentially. No user interaction.

• No Approval - Risk-Based Mandatory Deployment

  • No approval needed prior to deployment. Deploys at once to all devices in the targeted business units based on the patch risk levels. No user interaction.

    Uses both Deployment Waves and Deployment Channels. Higher-risk updates have priority in high-frequency Deployment Channels. Lower-risk updates belong to lower-frequency Channels.

    Also uses Deployment Bot to filter patches based on risk level, and then sends the final wave to the proper Deployment Channels.

    Ensures processing and deployment of the final wave through the most suitable Deployment Channel and adds a layer of control and customization to the deployment process.

Phase Approval Strategies

Each of these strategies requires phased approvals before deploying updates. Except for Risk Based Mandatory Deployment, the Patching Process within these strategies manages the deployment process exclusively without using Deployment Channels.

Similarly, the Deployment Bot does not apply any filtering mechanism, so the Patching Process manages all updates related to the products included in the non-risk strategies.

• Phase Approval - Immediate Mandatory Phased Deployment

  • Approval required between each wave of the deployment, and then deploys the updates in a phased manner, rolling out to each wave of business units sequentially. No user interaction.

• Phase Approval - Risk-Based Mandatory Deployment

  • Approval step required between each wave of the deployment, and then deploys the updates at once to all devices in the targeted business units based on risk levels. No user interaction.