Remediation plans are created either automatically or manually.
We strongly recommend you follow the patching checklist as part of your remediation plan process.
| Important: JetPatch patches at a group level. It is not possible to deploy a patch to one individual endpoint unless the group contains only that one machine. |
Creating a Remediation Plan
For a manual Remediation Plan, follow the instructions below.
- Click on Patches → Patches Catalog in the main menu.
- Select the patches you would like to install. To easily create the Remediation Plan, you can filter by specific patch name, patch severity, category, etc. Don’t forget More Filters for additional options such as date ranges, severity, category, vulnerability, and product.
- Select all desired patches by checking the top-left checkbox, or select them individually.
- Click Create Remediation Plan.
Configure Plan
The first part of the Remediation Plan is to define the Remediation Plan information:
- Remediation Plan Name
- Description
- SLA dates
- Email a Report on Completion
- Is the Emergency Remediation Plan - Check this box if this is a zero-day/emergency patch. This allows you to create a one-time maintenance schedule without changing your entire environment. For more information, see the
- Email a Report on Completion
Fill in the needed values and click Save & Continue
SLA Dates
Every Remediation Plan has an SLA to follow the required execution timeline in your organization.
-
SLA Start Date
- The date from which you want to measure the SLA for this specific Remediation Plan.
- The default value is the creation date of the plan.
-
SLA End Date
- The date to which you want to measure the SLA for this specific Remediation Plan.
- The default value is the creation date + the configured days in the following configured attribute in intigua.properties:
# Will determine the SLA End Date pg.sla.planned-end-period.days = 30Note:
- A Remediation Plan will automatically cancel if the current time exceeds the SLA End Date.
- The status will be set to “Cancelled by policy.” By default the SLA End Date is 30 days after activation.
- This is configurable (see above). You can manually override the default end date during Remediation Plan creation.
To download the SLA Report, check the Generate SLA Report
Email Reports
1. Completion
When an active Remediation Plan is moved to the ‘Done’ or ‘Cancelled by policy’ status under the “Completed” column, JetPatch can send a notification email with an executive summary.
To enable this, select the checkbox under the Notifications section of the Configure Plan tab, and enter the recipient email address.
2. Activation
When an active Remediation Plan is activated by policy, JetPatch can send a notification email.
To enable this, select the checkbox under the Notifications section of the Configure Plan tab, and enter the recipient email address.
3. Cancellation
When an active Remediation Plan is cancelled by policy, JetPatch can send a notification email.
To enable this, select the checkbox under the Notifications section of the Configure Plan tab, and enter the recipient email address.
| Note: Cancelling a plan after activation does not revert approval status. A new plan would need to be created to set the new status. |
Approve Patches
You can specify several actions you would like to perform on the patches:
| Action | Description |
| No Action | Nothing has been specified for the specific patch. |
| Install | This indicates that the patch has been put into a remediation plan, and the plan has been activated. However, the patches have yet to be installed. Note: once a patch is approved, it will stay approved across all RPs unless a new plan is created changing the approval back to not approved. |
| Remove | JetPatch will roll back the selected patch(es). Rollback is not yet available for AIX or Ubuntu. |
| Not Approved | This indicates that a patch is available for an endpoint(s), however is not in an active remediation plan. JetPatch will reset the approval of the patch to ‘Not Approved’ when discovered. |
| Decline | JetPatch will decline the patch from JetPatch and WSUS (for Windows). |
You can also add and edit your patch selection by clicking on Edit Patches.
| Note: After a patch is created, you can also access and edit it via the Remediation Plans dashboard. |
When finished assigning the requested actions, click Save & Continue.
Bulk actions
You can use Bulk Actions to assign the same action to multiple selected patches at once:
- Select the required patches. You can select all patches by clicking the checkbox to the left of the table headers.
- Click on the Select Bulk Action list and choose the required bulk action to perform on all selected patches (e.g., Bulk Install or Bulk Remove for rollback). patches.
Create Cycle
Select the Smart Groups you want the Remediation Plan to run on, and the Workflows (for each Operating System) you would like to run.
- Smart Groups – Select the groups to run the plan on.
- Workflows – Select the relevant workflow for each Operating System (e.g., a Linux Reboot workflow).
- Priority – When selecting different Maintenance Windows for different groups, you must prioritize them.
|
Note:
|
Choose your save option:
- Save Cycle – Saves the plan as New on the Remediation Plan board without activating it.
- Save & Activate – Saves and activates the plan, starting the patch cycle process.
| Tip: It is highly recommended to run Predictive Patching directly from the Remediation Plan in the New column before activating, to ensure there are no existing technical issues for the endpoints within your plan. |
Reviewing the Remediation Plan
After saving, head to the Remediation Plans board to view where your plan ended up:
- If you chose Save Cycle, the plan appears at the top of the New column.
- If you chose Save & Activate, the plan moves to the Pending column, where it waits for ITSM approval (if configured) and for the maintenance window to begin.
What’s Next?
- After activating a Remediation Plan, it will be moved to the Pending column in the Remediation Plan Board and will wait for ITSM approval, if configured.
- When a plan is approved, it goes to In Progress status (in the RP dashboard) and is activated according to the maintenance windows set for the endpoints.
- If the plan was rejected, it will return to the New status (in the RP dashboard), awaiting further action.
| Note: A remediation plan will be executed on each endpoint based on the next maintenance schedule configured for that endpoint. |
How Remediation Plan Policies Work
Approval Status Is Persistent
Once patches (for example, KB123 or KB456) are set to install in any remediation plan, that approval remains in force for the targeted Smart Group even if the plan fails or is cancelled.
Canceling a remediation plan never rolls the approval back.
Undoing Approval Status
To reverse an unwanted Install approval, you must create a new remediation plan and set those patches to Decline.
Selecting Not Approved does not remove an existing approval.
Example Scenario (Two Plans)
- RP 1 – Sets KB123 and KB456 to install for Smart Group A (machine B). RP 1 activates, but is cancelled before installation is attempted.
- RP 2 – For the same Smart Group: sets KB123 and KB456 to Decline (clearing their approval) and sets KB789 to Install. RP 2 activates and succeeds, installing KB789 only while ensuring KB123 and KB456 will no longer deploy.
Rollback
Rolling back endpoints is straightforward with JetPatch.
There are two rollback scenarios: one where you know the exact patch that needs to be rolled back, and one where you do not know which specific patch is causing the issue, but you know the Remediation Plan it is in.
Linux/Unix Notes
- JetPatch can only roll back Linux/Unix patches it installs.
- When reverting a patch installation process, JetPatch uses OS-level undo functionality to remove all related packages. In order for that procedure to succeed, the previous package version must exist in the repository.
- More information can be found here.
- JetPatch does not support rollback for Ubuntu, Debian, and AIX.
Windows Notes
- For Windows, JetPatch can uninstall any patch, regardless of how it was installed, as long as Microsoft allows it (e.g., SSU updates are not allowed to be rolled back by Microsoft).
Scenario 1: Rollback a Specific Patch
Use this approach when you know the exact patch that needs to be rolled back.
- Navigate to Patches → Patches Catalog and filter down to the specific patch or patches that need to be rolled back.
- Select the patches and click Create Remediation Plan.
- Give the plan a Name and Description. If the rollback is urgent, consider using an Emergency Remediation Plan (see Emergency Remediation Plan).
- Click Save & Continue.
- On the Approve Patches page, select Bulk Remove to set the action to rollback for all selected patches.
- Click Save & Continue.
- Select the relevant Workflow (e.g., Linux Reboot).
- Click Save & Activate. The plan moves to Pending on the Remediation Plans dashboard and will execute during the next maintenance window.
Scenario 2: Rollback an Entire Remediation Plan
Use this approach when you cannot determine which specific patch is causing an issue and want to roll back all patches in a plan. This is common when a team needs to be safe and roll back everything.
- Navigate to Patches → Remediation Plans.
- Find the plan that is causing the issue. Click the three dots (…) menu and select Duplicate. The copy appears at the top of the New column.
- Click Edit on the duplicated plan.
- Update the plan name to clearly indicate it is a rollback (e.g., “[Original Plan Name] – ROLLBACK”). Click Save & Continue.
- On the Approve Patches page, select Bulk Remove for all endpoints to ensure the entire plan will be rolled back.
- Click Save & Continue.
- Select the relevant Workflows.
- Click Save & Activate. The plan moves to Pending and will be executed during the next maintenance window.
| Note: Both rollback scenarios result in the plan sitting in Pending until the maintenance window arrives, at which point the rollback process begins automatically. |
Comments
0 comments
Please sign in to leave a comment.