Roll Out and Deploy Updates
After reviewing pending updates, you can push them to multiple endpoints at once directly from the Update Approval page. Select the patches you want to deploy and click Install Now.
In addition to on-demand patch delivery, Action1 enables you to automate the patch management process and tailor it to your organization’s patch management policy.
Automated patch deployment strengthens overall infrastructure security and helps you ensure that your endpoints are up-to-date and compliant with the security requirements.
How Does It Work?
The automated patch management process goes as follows:
- The stable updates for Windows and Mac systems typically become available in the Action1 cloud within two days after release. Linux updates are retrieved from the corresponding online repositories.
Important! Action1 does not support major macOS upgrades.
- If your workflow requires patch review and manual approval before distribution, the authorized administrator reviews and approves patches on the Update Approval page.
- Action1 automatically distributes approved updates to the target endpoints according to the configured schedule.
TIP: To roll out updates in stages, you can use a new Update Ring automation. See Update Rings for details.
- Endpoints that are offline or disconnected at the time of deployment receive updates automatically when they come back online, provided it occurs within the configured retry window.
- To examine the update deployment results, you can use:
- Automations view – see Managing Automations.
- Built-in Reports | Patch Management reports – see Installed Updates and Reports.
Application Restart Behavior During Updates
Some applications must be closed before a new software app version can be deployed on target endpoints. To control how Action1 handles these situations, use the Application restart behavior during updates advanced setting in the Action1 console.
NOTE: This functionality is supported for Windows applications only. Currently, this setting is available for a limited number of built-in applications.
This setting determines what happens when Action1 detects that a running application must be closed before an update can proceed. The following options are available:
- None — do not close the running apps, cancel the update deployment
- Force Close — close the application automatically, without prompting the user; the update then proceeds.
- Prompt & Force Close — ask the user to close the detected apps within 1 hour, then close them automatically and proceed with the update.
- Reboot (default) — reboot the target endpoint to close the detected apps; the update then proceeds.
By default, this setting is applied to the Action1 Enterprise. To configure it, a role with the Manage Advanced Settings permission is required.
How It Works
When configuring application version deployment settings, the pre-deployment scripts are provided on the Additional Actions tab. They are executed by the agent on the target endpoint and detect the running app processes that may conflict with the selected application update. These additional actions will handle the potential conflicts depending on the Application restart behavior during updates option selected:
- Reboot (default) — If a conflicting application is detected, Action1 resolves the issue by rebooting the endpoint. (When a conflicting application is found, the script returns a reboot exit code.) This closes the conflicting applications and allows the update to proceed. The reboot is handled as described in this section:
- The endpoint user receives a reboot prompt.
- The reboot occurs according to the user’s response to the prompt.
- After the reboot operation successfully closes the applications, the update deployment is completed.
- None — If a conflicting application is detected:
- No applications are closed.
- The update deployment is canceled.
- A corresponding error message is recorded in the automation History.
- Force Close — If a conflicting application is detected:
- Its process is closed automatically, without notifying the user.
- The update deployment proceeds immediately.
NOTE: Applications closed using this option are not restarted automatically afterward.
- Prompt & Force Close — If a conflicting application is detected:
- The endpoint user is shown a message listing the applications that must be closed and is given 1 hour to close them manually. For example:
“Installation of Adobe Acrobat Pro requires closing the following applications: Microsoft Outlook, Word, and Excel. Please close them within 1 hour. Action1 will then attempt to close any remaining processes automatically.” - Once the applications are closed, Action1 deploys the update and notifies the user upon completion.
- If the applications are not closed within 1 hour, Action1 attempts to force-close them.
- If the force-close attempt fails, the update deployment is canceled.
- The endpoint user is shown a message listing the applications that must be closed and is given 1 hour to close them manually. For example:
How to Create an Automation?
Follow the Deploy Update automation wizard, as explained in the Automate Patch Management section.
Service-Level Agreements (SLAs) for Updates
In the Update Approval view, you can see update status and SLA Compliance deadlines, such as Overdue or Due later. These deployment deadlines are calculated based on the industry best practices and service-level agreements (SLAs) that prescribe different timeframes for updates with different severities.
For example, when you establish the SLA for deploying Critical severity updates to X days, you aim to deploy the update within X days of its release (i.e., availability in Action1). Overdue updates will be prominently displayed on the dashboard.
Default SLAs are as follows:
- for Critical updates – 7 days
- for High impact updates – 15 days
- for Medium impact updates – 30 days
- for Low impact updates – 60 days
Adjusting Update Deployment SLAs
To modify SLAs using the dashboard:
- Open the Dashboard page and go to the Update Deployment Compliance widget.
- Click a gear icon in the top-right corner.
- In the Service Level Agreement dialog displayed, set remediation timeframes for each severity.
To modify SLAs using Action1 configuration settings:
- Open the Advanced page, select SLA settings category.
- Select the Vulnerability Remediation SLA you want to update and provide a new value.
