Using the built-in Patching Strategies

In this article:

Introduction - Introduction and purpose of this article

List of built-in Patching Strategies - Basic list showing all of the Patching Strategies that are included with the Autonomous Patch product

Strategy Distinction - Distinguishing between the various built-in Patching Strategies

Strategy Considerations - What to consider when selecting an appropriate Patching Strategy

Patching Strategies Breakdown - Full list of properties available for patch filter conditions

Further Information - Where to go for further information

 

Introduction

The effective management and deployment of software patches are crucial for maintaining the security and stability of an organization's IT infrastructure. To simplify this process, the Autonomous Patch product provides a range of built-in Patching Strategies designed to address various deployment scenarios and considerations. This article serves as a comprehensive guide, detailing each built-in Patching Strategy, their intended usage, and the factors administrators should consider when selecting the most suitable strategy for their environment.

 

List of built-in Patching Strategies

The following Patching Strategies come included out of the box in the Autonomous Patch product:

• No Approval - Immediate Mandatory Deployment
• No Approval - Immediate Mandatory Phased Deployment
• No Approval - Immediate Optional Deployment
• No Approval - Risk-Based Mandatory Deployment
• Initial Approval - Immediate Mandatory Deployment
• Initial Approval - Immediate Mandatory Phased Deployment
• Initial Approval - Immediate Optional Deployment
• Initial Approval - Risk-Based Mandatory Deployment
• Phase Approval - Immediate Mandatory Phased Deployment
• Phase Approval - Risk-Based Mandatory Deployment

Strategy Distinction

The preconfigured built-in Patching Strategies are designed to cater to four specific use cases, each characterized by different approval types, rollout speeds, rollout gating, and end-user experiences. By offering various combinations of these parameters, the built-in Strategies provide a versatile framework that can accommodate a wide range of scenarios without the need to create new Strategies.

The four distinct use cases covered by the built-in Patching Strategies are:

1. Approval Type: This determines the level of approval required for deploying patches. The options include no approval, initial approval, or phased approval.

2. Rollout Speed: This defines the speed at which patches are deployed. The choices include immediate deployment or a risk-based approach that considers factors such as impact and urgency.

3. Rollout Phasing: This determines the deployment strategy, whether patches are deployed all at once or in phased stages.

4. End-User Experience: This defines the nature of patch deployment for end-users. Patches can be mandatory, meaning they must be installed, or optional, allowing users to choose whether to install them.

By adding software products to the appropriate built-in Patching Strategy, organizations can leverage the preconfigured settings to automatically manage the deployment of patches according to their specific requirements. This flexibility allows for efficient patch management without the need for extensive customization or the creation of new Strategies.

 

Strategy Considerations

When deciding which Patching Strategy to choose, consider the following attributes:

 

Approval Type

Considering the approval type attribute helps align the Patching Strategy with your organization's requirements for reviewing and approving patches before deployment.

• No Approval: If you do not require approval before deploying new releases for certain products, consider selecting one of the Patching Strategies categorized as "No Approval." This allows for immediate deployment without the need for approval.

• Initial Approval: If you prefer to have updates undergo an initial approval process before deployment, consider selecting one of the Patching Strategies labelled as "Initial Approval." This ensures that patches receive approval before they are deployed.

• Phase Approval: If you prefer to have an approval step between each wave in the Deployment Waves object, consider choosing one of the Patching Strategies labelled as "Phase Approval." This allows for incremental approval at each phase of the deployment process.

Rollout Speed

Considering the rollout speed attribute helps determine how quickly updates should be deployed and whether they should be treated uniformly or based on their risk levels.

• Immediate: If you want all updates for the selected products to be treated equally and deployed immediately, choose one of the Patching Strategies categorized as "Immediate." This means that the Patching Process within the Patching Strategy itself will handle the deployment without any delay.

• Risk-Based: If you prefer to handle updates differently based on their risk levels, consider selecting one of the Patching Strategies labelled as "Risk-Based." In this approach, updates are deployed using Deployment Channels. Higher risk updates are added to high-frequency Channels, while lower risk updates are added to less frequent Channels. This allows for a more targeted and controlled deployment based on the risk assessment of the updates.

Rollout Phasing

Considering the rollout phasing attribute helps determine the deployment approach, whether it should be done in a phased manner for better control and issue detection or in a non-phased manner for quicker deployment without early issue detection opportunities.

• Phased Deployment: If you want to roll out updates in a phased manner, consider selecting one of the Patching Strategies categorized as "Phased Deployment." This approach deploys updates to each wave within the target Deployment Waves object sequentially. Phased deployments provide a level of control, allowing for early detection of issues in smaller phases and the opportunity to rectify them before the update reaches subsequent waves. However, it should be noted that phased deployments are slower compared to non-phased deployments.

• Non-Phased Deployment: If you prefer to deploy updates to all devices in all business units within the targeted Deployment Waves object simultaneously, choose one of the Patching Strategies not labelled as "Phased Deployment." This approach is faster than phased deployments but does not offer the same level of early issue detection during the deployment process.

End-User Experience

Considering the end-user experience attribute helps determine whether the deployment should be mandatory, providing no control to end-users, or optional, allowing end-users to initiate the installation at their discretion.

• Mandatory: If you want to enforce the deployment of updates without giving end-users control over the process, consider selecting one of the Patching Strategies categorized as "Mandatory." With a Mandatory Strategy, end-users will still receive alerts and have the option to postpone updates according to the user interaction settings defined in the respective Business Units. However, they will not be able to initiate the installation of updates from within the client-side user portal.

• Optional: If you prefer to allow end-users to have control over the installation of upgrades through the user portal, choose one of the Patching Strategies labelled as "Optional." This gives end-users the ability to decide when they want to install the updates. However, it's important to note that the overall deployment time may be slower as some users may delay the installation.

 

Patching Strategies Breakdown

 

No Approval - Immediate Mandatory Deployment

This Patching Strategy does not require any approval before deploying updates. The updates are deployed immediately to all devices in the targeted business units. The deployment is mandatory, meaning end-users cannot control the installation.

The deployment process within the Patching Strategy is exclusively managed by the assigned Patching Process and does not use Deployment Channels.

The Deployment Bot does not apply any filtering mechanism, meaning that all updates related to the Products included in this Strategy will be processed by the Patching Process.

 

No Approval - Immediate Mandatory Phased Deployment

Similar to the previous strategy, this one also does not require approval. However, the updates are deployed immediately in a phased manner, rolling out to each wave of business units sequentially. The deployment is mandatory, and end-users cannot control the installation.

The deployment process within the Patching Strategy is exclusively managed by the assigned Patching Process and does not use Deployment Channels.

The Deployment Bot does not apply any filtering mechanism, meaning that all updates related to the Products included in this Strategy will be processed by the Patching Process.

 

No Approval - Immediate Optional Deployment

In this Patching Strategy, updates are deployed immediately to all devices in the targeted business units. However, the deployment is optional, allowing end-users to choose when to install the updates from the user portal.

The deployment process within the Patching Strategy is exclusively managed by the assigned Patching Process and does not use Deployment Channels.

The Deployment Bot does not apply any filtering mechanism, meaning that all updates related to the Products included in this Strategy will be processed by the Patching Process.

 

No Approval - Risk-Based Mandatory Deployment

This strategy deploys updates immediately to all devices in the targeted business units, but the deployment is based on risk levels. Higher-risk updates are given priority and added to high-frequency Deployment Channels, while lower-risk updates are added to lesser frequency Channels. The deployment is mandatory, and end-users cannot control the installation.

The deployment process within the Patching Strategy involves a combination of the Patching Process and Deployment Channels. The initial waves specified in the Deployment Waves object are managed by the Patching Process, which handles the deployment of patches to the corresponding Business Units. However, the final wave follows a different approach. Instead of being directly deployed by the Patching Process, it is sent for deployment via the Deployment Channels. The Deployment Bot filters Patches based on their risk level. The selection of the appropriate Deployment Channel is determined based on the risk level associated with the patches. This ensures that the final wave is processed and deployed through the most suitable Deployment Channel, adding an additional layer of control and customization to the deployment process.

 

Initial Approval - Immediate Mandatory Deployment

This strategy requires an initial approval step before deploying updates. Once approved, the updates are immediately deployed to all devices in the targeted business units. The deployment is mandatory, and end-users cannot control the installation.

The deployment process within the Patching Strategy is exclusively managed by the assigned Patching Process and does not use Deployment Channels.

The Deployment Bot does not apply any filtering mechanism, meaning that all updates related to the Products included in this Strategy will be processed by the Patching Process.

 

Initial Approval - Immediate Mandatory Phased Deployment

Similar to the previous strategy, this one also requires initial approval. However, the updates are deployed immediately in a phased manner, rolling out to each wave of business units sequentially. The deployment is mandatory, and end-users cannot control the installation.

The deployment process within the Patching Strategy is exclusively managed by the assigned Patching Process and does not use Deployment Channels.

The Deployment Bot does not apply any filtering mechanism, meaning that all updates related to the Products included in this Strategy will be processed by the Patching Process.

 

Initial Approval - Immediate Optional Deployment

In this strategy, updates require initial approval before deployment. Once approved, they are immediately deployed to all devices in the targeted business units. The deployment is optional, allowing end-users to choose when to install the updates from the user portal.

The deployment process within the Patching Strategy is exclusively managed by the assigned Patching Process and does not use Deployment Channels.

The Deployment Bot does not apply any filtering mechanism, meaning that all updates related to the Products included in this Strategy will be processed by the Patching Process.

 

Initial Approval - Risk-Based Mandatory Deployment

This strategy involves an initial approval step before deploying updates. Once approved, the updates are deployed immediately to all devices in the targeted business units based on their risk levels. Higher-risk updates are given priority in high-frequency Deployment Channels, while lower-risk updates are added to lesser frequency Channels. The deployment is mandatory, and end-users cannot control the installation.

The deployment process within the Patching Strategy involves a combination of the Patching Process and Deployment Channels. The initial waves specified in the Deployment Waves object are managed by the Patching Process, which handles the deployment of patches to the corresponding Business Units. However, the final wave follows a different approach. Instead of being directly deployed by the Patching Process, it is sent for deployment via the Deployment Channels. The Deployment Bot filters Patches based on their risk level. The selection of the appropriate Deployment Channel is determined based on the risk level associated with the patches. This ensures that the final wave is processed and deployed through the most suitable Deployment Channel, adding an additional layer of control and customization to the deployment process.

 

Phase Approval - Immediate Mandatory Phased Deployment

In this Patching Strategy, approval is required between each wave of the deployment. Updates are deployed immediately in a phased manner, rolling out to each wave of business units sequentially. The deployment is mandatory, and end-users cannot control the installation.

The deployment process within the Patching Strategy is exclusively managed by the assigned Patching Process and does not use Deployment Channels.

The Deployment Bot does not apply any filtering mechanism, meaning that all updates related to the Products included in this Strategy will be processed by the Patching Process.

 

Phase Approval - Risk-Based Mandatory Deployment

This strategy involves approval between each wave of the deployment. Updates are deployed immediately to all devices in the targeted business units based on their risk levels. The deployment follows a phased approach, and higher-risk updates are given priority in high-frequency Deployment Channels. The deployment is mandatory, and end-users cannot control the installation.

The deployment process within the Patching Strategy involves a combination of the Patching Process and Deployment Channels. The initial waves specified in the Deployment Waves object are managed by the Patching Process, which handles the deployment of patches to the corresponding Business Units. However, the final wave follows a different approach. Instead of being directly deployed by the Patching Process, it is sent for deployment via the Deployment Channels. The Deployment Bot filters Patches based on their risk level. The selection of the appropriate Deployment Channel is determined based on the risk level associated with the patches. This ensures that the final wave is processed and deployed through the most suitable Deployment Channel, adding an additional layer of control and customization to the deployment process.

 

These Patching Strategies provide different combinations of approval types, rollout speeds, rollout phasing, and end-user experiences, allowing organizations to tailor their patch management approach according to their specific requirements and preferences.

 

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 any of the built-in Patching Strategies, please log a support ticket and a member of the Adaptiva support team will be touch as soon as possible.