Patching Strategies

In this article:

Introduction - Overview of Patching Strategies

General Settings - General Patching Strategy settings

Products - Define the product(s) that will be managed by the Strategy

Deployment Settings - Set the Patching Process, target Deployment Wave, Channels, and Bots

Approval Chains - Control how Approvals are handled

Notifications - Define who should be notified and how

Content Prestaging Settings - Whether content gets predownloaded on devices

Business Unit Addition Settings - What to happen if new Business Units are added to the Strategy

Further Information - Where to go for further information

 

Introduction

A Patching Strategy is an integral object within the Autonomous Patch product, designed to oversee the deployment of patches to software products. It establishes a set of rules and procedures that determine which patches are applied to which software products, the order in which they are installed, and the specific time at which they are to be deployed.

One or more Patching Processes are included in the Patching Strategy, which are responsible for deploying the patches directly to target Business Units or adding them to a Deployment Channel. The Patching Process is a crucial component that can perform vital functions such as patch approvals, notifications, and other critical tasks, and it can be customized to perform specific use cases.

The Patching Strategy also features a Deployment Wave object that defines the Business Units that will receive patches and the order in which they will be deployed.

Additionally, Patching Strategies includes Patch Deployment Bots that filter patches based on configurable criteria before submitting them to the Patching Process cycle.

Overall, a Patching Strategy provides an efficient and centralized approach to manage patch deployments across an organization's software products.

 

General Settings

The general settings section is for basic identifiable information, Name and Description, and to Enable or Disable the Strategy.

Name: The name used to identify this Patching Strategy

Description: (Optional) A description used to describe the purpose or functionality of the Strategy.

Strategy Enabled: When enabled, the Strategy will process patches and execute Patching Process cycles. When disabled, it will not.

 

 

Products

In the Products section, you can specify which products the Patching Strategy should manage. Products that are not included in a Patching Strategy will not receive updates. The purpose of the Patching Strategy is to group together products that require similar processing. Deployment Bots can be used to filter patches for the same product and execute different processes. If different products require different processes, approvals, notifications, etc., they should be included in separate Patching Strategies.

If you want to manage all products using a single Patching Strategy, you can enable the Include All Products option.

However, if you want to manage specific products using this Strategy, you can click on the Add Software Products button and select the desired products.

 

 

Deployment Settings

Deployment Wave

The Deployment Wave is a critical component of a Patching Strategy as it specifies the Business Units that are allowed to receive Patches. The sequence of Business Units contained in the Deployment Wave determines how the Patches are deployed to each Business Unit, which is controlled by the Patching Process and/or Deployment Channel Process (if used).

For immediate deployments, the waves are ignored, and the Patches are deployed to all Business Units in the Deployment Wave object. However, for phased deployments, the order and membership of the individual waves are honoured, and Patches are deployed to each wave in turn.

It's important to note that the Deployment Wave restricts the Business Units that can receive Patches from a particular Patching Strategy.

To select an existing Deployment Wave object, or to create a new one, click the Browse button.

 

Patching Process Settings

The Patching Process is a crucial feature in the Autonomous Patch product, serving as the primary method for deploying Patches to Business Units or adding Patches to a Deployment Channel. In addition to these functions, it also performs Patch Approvals, Notifications, and other core tasks. The Patching Process can be customized to accommodate specific use cases, such as performing additional tasks when new metadata is received. Overall, the Patching Process is a critical component in ensuring the smooth deployment of Patches across an organization's network.

To create a Process Setting for the Patching Process, you can click on the Create Process Setting button. This will allow you to specify additional properties associated with the Patching Process.

 

In the overlay that is shown, select an existing Patching Process, or create a new one by clicking the Browse button.

The Patching Process is an Adaptiva Workflow that executes on the Adaptiva Server.

By default, a standard process is included that should meet the needs of most users. However, in cases where the default process is inadequate, users can create custom Patching Processes that address specific needs by either authoring a new process or extending the existing one.

For help creating or extending Patching Processes, please log a support ticket and a member of the Adaptiva Support Team will be happy to provide assistance.

 

When configuring a Patching Process, you need to select one or more Execution Schedules that determine when the Patching Process will run. The frequency of the schedule determines how often updates will be processed. For example, if the schedule is set to run daily at 11am, any updates released after 11am will not be processed until the following day. It's important to note that this includes any actions in the Patching Process workflow, such as approvals and deployment to Deployment Channels.

Adding a Time Limit to the Patching Process can help prevent the cycle from running for an excessive amount of time and potentially causing issues in the system. This setting will set a maximum time that the Patching Process cycle can run before timing out and being terminated. If the cycle exceeds the time limit, any changes made during the process may not be completed, and the process may need to be run again. Set all values to 0 for no time limit.

 

 

Deployment Channels

Deployment Channels serve as a virtual queuing system for updates, which can prevent constant disruptions to end-users. Rather than immediately deploying updates upon release, updates are added to Deployment Channels, where they will be queued until a more suitable time for installation. This approach combines process terminations, notifications, and device reboots into a single cycle, reducing the impact and disruption to users.

The Deployment Channels option within the Patching Strategy restricts which Deployment Channels within Deployment Bots are allowed to be used. Deployment Bots that use Deployment Channels not added here will not be permitted to be used in this Strategy.

 

Patch Deployment Bots

Note: A Patching Process must be selected before Patch Deployment Bots can be added.

A Patch Deployment Bot's primary function is to generate Patch Approvals for new patches, while filtering them in or out based on metadata properties. They also specify the patching process that will be executed to handle the Patch Approvals, the Deployment Channel to be used (if any), and can limit approvals to specific Business Units.

The Patch Deployment Bots option in a Patching Strategy refers to the bots responsible for submitting new patches to a deployment cycle for that Strategy. These bots are used to filter which patches should be included or excluded based on the target products. However, it is important to note that Deployment Bots can only be selected after configuring Patching Process Settings and must include a Patching Process that matches a Patching Process Setting in the Strategy. Additionally, if the Strategy includes Deployment Channels, the selected Deployment Bots may not have a Deployment Channel that is not present in the Strategy.

 

Approval Chains

Approval Chains can be assigned to a Patching Strategy as needed. These Chains are used during the Patching Process execution to seek approval from one or more designated Chains. The provided Approval Chain personas, such as Product Owner, Patch Management, Security, Test Lab, and Change Management, are mere suggestions. The Approval Chains and Roles added to these fields can be customized to meet specific requirements. It is essential to note that the Patching Process workflow will reference these Approval Chains. Therefore, they should correspond to the Process defined in the workflow.

To assign an Approval Chain, click the Browse button next to the relevant Approval Chain, and either select an existing chain or create a new one.

 

To create a custom Approval Chain, select Create Custom Approval Chain and give the chain an appropriate purpose. The Custom Approval Chain can also be referenced in the Patching Process. If the Custom Approval Chain is not referenced, any value entered in this field will be ignored.

 

 

Notifications

Notifications can be utilized to notify different parties about the deployment or release of Patches, including System Administrators, Group Administrators, end-users, or any other roles. Notification Bots can be set up to filter patches based on customizable criteria, and Notification settings can be adjusted to specify a Workflow that will process the Notifications and send the appropriate message to the intended roles.

Notification configuration options are available in this section to manage which notifications are sent and how they are sent.

 

Notification Chain

The Notification Chain is the set of roles containing the administrators that should be notified about the patch.

Select the Browse button to either add an existing Notification Chain, or create a new one.

 

Patch Notification Bots

The Patch Notification Bot's primary function is to generate Patch Notifications for new patches, while filtering them in or out based on metadata properties. If the Patch matches the specified filter expression(s), a Patch Notification will be generated and sent to the Patch Notification Cycle that has been executed via this Patching Strategy.

The Patch Notification Bot will generate Notifications with the specified urgency level. This urgency level will be matched to any Notification Settings present in this Patching Strategy, and the corresponding Notification Cycle workflow will process the Notification and send it via the Communication Channels specified in the Bot.

 

Notification Settings

Notification Settings provide a way of allowing different handling of notifications based on the urgency level defined in the Notification Bot.

Click Create Notification Setting to create a new Notification Setting.

 

The Notification Setting has the following properties:

 

Notification Urgency: If a Notification Bot processes an update that matches it's filter expression, and the urgency level defined in the bot matches the urgency level defined in the Notification Settings, the Notification Cycle Workflow will process that notification.

Execution Schedules: One or more schedules on which the Notification Cycle Workflow should run. This should be set to a schedule that is appropriate to how frequently Notifications should be sent. E.g. this could be set to 'ASAP' and Notifications would be sent immediately, or it could be set to 'Every Week' and Notifications would be queued and only sent out once per week.

Notify Patching Strategy Chains: If this option is selected then Notifications will be sent to the roles contained in the Patching Strategy Notification Chains.

Notify Business Unit Chains: If this option is selected then Notifications will be sent to the roles contain in the target Business Unit Notification Chains.

Notification Cycle Workflow: The workflow that will perform the Notification. This should be set to an Adaptiva Workflow that has the WorkflowPurpose setting set to NotificationCycle. It is the Notification Cycle Workflow that performs the actual sending of the Notification to the appropriate users.

For help creating or modifying existing Notification Cycle Workflows, please raise a support ticket and a member of the Adaptiva Support Team will be happy to provide assistance. 

Time Limit: The maximum length of time that the Notification Cycle Workflow is allowed to run for before timing out. If set to 0s, the workflow can run indefinitely.

 

 

Content Prestaging Settings

Content Prestaging is a feature that enables sending the deployment content to devices ahead of time. By doing so, the content is available on the device locally when the deployment time arrives, eliminating the need to transfer the content over the network at the time of deployment. This reduces the deployment time and minimizes the chances of service windows being missed or devices going offline before the content is downloaded.

There are two independent options available for Content Prestaging:

1. Server Content Push: This option is similar to OneSite's IntelliStage. The Adaptiva Server will send the content to the best-suited sources in all locations where the content is needed. This type of prestaging is recommended when the deployment targets only a subset of devices. High-availability machines will receive the content and act as local sources during discovery and deployment.
2. Client Content Pull: This option enables any client that requires the content to download and cache it before deployment. This option is suitable when the deployment targets all clients that need the updated content. It is recommended that Server Content Push should not be used when Client Content Pull is enabled.

There are three options available for both of these settings:

1. Not enabled
2. Handled by System (Recommended): The Adaptiva Autonomous Patch system will handle the prestaging automatically.
3. Handled by Workflow: Prestaging will only occur if the Patching Process Workflow handles it. The Workflow must perform the prestaging in this case.

 

Business Unit Addition Settings

When a new Business Unit is added to a Patching Strategy that has already processed Patches, the Patches will be inherited from the Template Business Unit. This means that the Patch Approvals for the newly added Business Unit will be the same as the Template Business Unit.

To handle the deployment of these Patches for the new Business Unit, a custom Patching Process can be specified in the Patching Process section. This process can be configured to deploy the Patches or pass them to a Deployment Channel for further processing.

Overall, this approach ensures that new Business Units added to a Patching Strategy can easily inherit Patches and Patch Approvals from an existing Business Unit, while still allowing for customized Patch deployment processes.

 

 

Further Information

For further information, please see the other resources in the Technical Reference Library or speak to a member of Adaptiva Support.

If you experience any issues or suspect there is a bug in Patching Strategies, please log a support ticket and a member of the Adaptiva support team will be touch as soon as possible.