Configuration Behavior

This tab enables you to configure a number of different options related to the deployment of patches.

Watch a related video (6:56)

Select Show summary to see a summary of your custom patch configuration options, with a tab for each operating system. This summary is updated in real time as you add, delete or modify your patch configuration options.

Deployment behavior

Deployment behavior enables you to configure when patches will be deployed (the schedule), which patches will be deployed (the deployment options), and if and when requests to reboot your target devices will be sent during the deployment process (the reboot behavior).

You can configure different deployment behaviors for different operating systems in the same patch configuration. The deployment behavior for each operating system comprises one or more deployment tasks that you can toggle on or off:

  • Routine maintenance: typically used for the standard monthly patching of operating systems and applications, and often requires a reboot of the endpoint.
  • Priority updates (Windows only): for applications that release updates more frequently, such as browsers and telecoms applications. As these rarely require a reboot, scheduling these deployments more frequently can reduce your vulnerability with little impact on users.
  • Zero-day response (Windows only): for urgent responses, such as for exploited vulnerabilities.

You can use these tasks to implement a risk-based strategy to patching by configuring different types of patches to be deployed at different schedules.

To create a scan-only patch configuration, switch off the deployment toggle for all tasks for all operating systems. The patch engine scans the endpoint as soon as it is installed, and then daily between midnight and 2 am at the local endpoint time.

To enable a patch task, enable its toggle, then click Configure this task to display the configuration panel for the task.

Schedule

This area enables you to configure deployments that are performed on a recurring schedule.

The Choose a schedule section enables you to regularly schedule deployment operations at a specific time and using a specified recurrence pattern. For example, a deployment can be run every night at midnight, or every Saturday at 9 PM, every weekday at 11 PM, or at any other user selected time and interval.

  • Run on reboot if schedule missed: If a scheduled deployment is missed because a device is powered off, it will run within an hour of the device being powered back on.
  • Deploy patches: You can schedule the patch deployment using the following options:
    • Daily: The deployments will run every day of the week at the time of your choosing.
    • Weekly: The deployments will run on the specified day of the week at the time of your choosing.
    • Monthly: The deployments will run on the specified date or occurrence of a day every month at the time of your choosing. You can also use this option to schedule a deployment in conjunction with Microsoft's Patch Tuesday. For example, you might schedule a monthly patch deployment to occur the day after Patch Tuesday by enabling the Also deploy after Patch Tuesday check box and then specifying 1 as the number of days after Patch Tuesday to delay the deployment.
      The Add delay option adds further flexibility to the scheduling by enabling you add a delay of a number of days to a monthly schedule. For example, if your Change Advisory Board meets on the first Wednesday of each month to agree which patches to deploy on the following Saturday, you could select to deploy on the first Wednesday with a delay of 3 days. This handles the case where the Saturday following the first Wednesday could be either the first or the second Saturday of the month.
    • Patch Tuesday: Schedule the deployments to run on the same day as Microsoft's regular monthly patching event, known as Patch Tuesday.
  • Stage content before deployment (Windows and Mac): Instructs the patch engine on the endpoint to download patches ahead of the deployment task. This is particularly useful for endpoints with maintenance windows, so that none of the duration of the maintenance window is wasted on the download. You can stage the content anywhere from 1 - 23 hours before the deployment is performed. A patch scan is automatically performed by the agent at the start of the staging process in order to reassess the device's patch status before the deployment.

    There is an exception for patch deployments that will occur on the first day of the month. To avoid issues with leap years and other similar quirks in the calendar, the interface prevents you from staging content on the day prior to the first day of the month. For example, if you schedule a deployment for 8:00 am on the first day of the month, you will be allowed to stage content only 1 - 8 hours before the deployment.

Deployment By

The available deployment options depend on the operating system:

  • Windows: Deploy by risk score, Deploy by severity, Deploy/Exclude by Patch Group, Include enablement packages, and Selected Vendors/Products
  • Mac: Deploy by severity, Deploy by Patch Group
  • Linux: Deploy all missing patches, Deploy by severity, Deploy by Patch Group

By default, only critical security patches for Windows are deployed. If you:

  • enable and configure Deploy by severity and set some patch groups to Include in Deploy/Exclude by Patch Group, the effect is additive, with all of the patches for each configured option being deployed
  • enable and configure Selected Vendors/Products, that option filters out patches from the other two options
  • set a patch group to Exclude in Deploy/Exclude by Patch Group, then patches that are in a patch group set to Exclude are always excluded even if they are set to be included elsewhere

Example 1: If you want to deploy only those patches that are contained within a patch group:

  • Disable the Deploy by severity and Selected Vendors/Products options
  • Enable the Deploy/Exclude by Patch Group option and set the desired patch group to Include

Example 2: Say you configure the following:

  • Deploy by severity: Security Critical and Security Important are selected
  • Deploy/Exclude by Patch Group: You set one patch group to Include that contains one Security Critical patch, one Security Important patch, and two Security Moderate patches
  • Selected Vendors/Products: This option is disabled

In this case:

  • Security Critical and Security Important patches will be deployed for all vendors and products
  • all four patches contained in the patch group will be deployed, including the two Security Moderate patches

Example 3: Same as Example 2, but you also:

  • use the Selected Vendors/Products option to specify that only Adobe patches should be deployed

In this case, the only patches that will be deployed are:

  • Adobe Security Critical patches, Adobe Security Important patches, and any Adobe patches contained in the patch group

Example 4: Same as Example 3, but you also:

  • use the Deploy/Exclude by Patch Group option to exclude a patch group that contains a specific Adobe Security Critical patch

In this case, the only patches that will be deployed are:

  • Adobe Security Critical patches (except for the one in the excluded patch group)
  • Adobe Security Important patches
  • any Adobe patches contained in the patch group

If a patch is added to a patch group that is set to Exclude, then the patch will not be deployed, even if other settings specifically suggest it should be deployed.

Example 5 (Windows edge case): Say you configure Deploy by severity with only Security Critical and also configure Deploy by Patch Group to include Vantosi V3.

If Vantosi V4 is then released as Security Critical and, before another patch deployment, Vantosi V5 is released as Security Important then for Windows neither Vantosi V4 nor Vantosi V5 are deployed. This is because the latest version (Vantosi V5) does not meet the Severity requirement for deployment and neither Vantosi V4 nor Vantosi V5 are included in the patch group. Note that if you configured the same patch configuration for Mac, Vantosi V4 would be deployed.

We recommend that you regularly use the Compliance Reporting component to check the compliance status of your devices, and add any new Security Critical patches to a patch group. For more information, see Compliance Reporting and Patch Groups.

Selecting deployment options

  • Deploy all missing patches / Deploy selected patches (Linux only): For Linux, you can choose to Deploy all missing patches. Alternatively, selecting Deploy selected patches enables further controls so that you can select which patches are deployed.
  • Deploy by risk score (Windows only): If enabled, allows you to specify the risk scores associated with patches that you want to include in a deployment.
    • VRR Score: Deploys patches with a VRR Score greater than or equal to the configured value. The Vulnerability Risk Rating (VRR) represents the risk posed by a given vulnerability, provided as a numerical score between 0 and 10.
    • CVSS Score: Deploys patches where the latest version of the CVSS (Common Vulnerability Scoring System) score taken from all CVEs associated with the patch is greater than or equal to the configured value. The score range is from 0.1 to 10.
    • For more information about VRR and CVSS, see Threat & Risk.

    • Deploy patches for exploited vulnerabilities: If enabled, deploys patches for vulnerabilities that have been reported as exploited.
  • Deploy by severity: If enabled, allows you to specify the types of patches and the severity levels that you want to include in a deployment. By default, only critical security patches is selected. There are different levels available for each operating system and Linux distribution. Icons show which Linux distributions support each level.
    • Security: Security bulletin-related patches. You can choose to deploy one or more specific severity levels.
      • Critical: Vulnerabilities that can be exploited by an unauthenticated remote attacker or vulnerabilities that break guest/host operating system isolation. The exploitation results in the compromise of confidentiality, integrity, availability user data, or processing resources without user interaction. Exploitation could be leveraged to propagate an Internet worm or execute arbitrary code between virtual machines and the host.
      • Important: Vulnerabilities whose exploitation results in the compromise of confidentiality, integrity, or availability of user data and processing resources. Such flaws could allow local users to gain privileges, allow authenticated remote users to execute arbitrary code, or allow local or remote users to easily cause a denial of service.
      • Moderate: Flaws where the ability to exploit is mitigated to a significant degree by configuration or difficulty of exploitation, but in certain deployment scenarios could still lead to some compromise of the confidentiality, integrity, or availability of user data and processing resources. These are the types of vulnerabilities that could have had a critical impact or important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.
      • Low: All other issues that have a security impact. Vulnerabilities where exploitation is believed to be extremely difficult, or where successful exploitation would have minimal impact.
      • Unassigned (Windows and Mac): Security patches that have not been assigned a severity level.
    • Non-security (Windows and Mac): Vendor patches that fix known software problems that are not security issues. For Windows, you can choose to deploy for one or more specific vendor severity levels. See Security patches for a description of the available severity levels.
    • Bug fix (Linux only): Vendor patches that fix bugs.
    • Enhancement (Linux only): Vendor patches that provide feature enhancements.
    • Enhancement is not available for Oracle v7 and Red Hat v7.

  • Deploy/Exclude by Patch Group (Windows) or Deploy by Patch Group (Mac and Linux): If enabled, allows you to specify one or more patch groups that contain the patches that you want to include in a deployment or (Windows only) that you want to exclude from deployment. This is a good way to make sure that only approved patches are deployed. Missing patches not contained in patch groups set to Include will not be deployed unless they meet the requirement specified in the Deploy by severity option. Patches in patch groups set to Exclude will not be deployed even if other settings specifically suggest it should be. Details about the available patch groups can be viewed using the Patch Groups tab within the Patch settings page. Patch groups are managed from within Patch Intelligence.

    Linux devices are always updated to the latest package available in the repository, even if an earlier version is added to a patch group. Also, not only are packages associated with the advisories in the patch groups installed, but also packages associated with dependent advisories.

    When you enable Deploy/Exclude by Patch Group, a grid of all patch groups appears that shows the number of patches for each operating system, plus the total number of patches in each patch group. Select the check box alongside a patch group then click Include or Exclude as appropriate. Click Clear to deselect a patch group.

    A check mark or x icon next to the count of patches for the operating system not being configured indicates that the configuration already includes or excludes those patches respectively.

    You may want to quickly remind yourself which patches are contained in a group before you select it. To do that, click a numeric link in the grid to display the corresponding patches beneath the Patch Groups grid. Use the Platform column to determine the operating system, and the Status column to determine the status of each individual patch.

    The status shown is actually an approximated status based on the use of this patch group with the current patch configuration. A number of factors can affect the patch status. For example, if you use Selected Vendors/Products in conjunction with a patch group, that may filter out one or more patches from the group.

    • Active: This patch group has been used by this configuration to make the patch available to the end-user devices. The devices are part of the policies that are associated with this patch configuration.
    • Not active: There are two possible reasons for this patch status. (1) This patch group has not been used to make the patch available to any devices. (2) The patch configuration to which this patch group is assigned has not been made active to devices.
      There is a scenario where a patch that is listed as Not active may actually be active. If the patch resides in more than one patch group, one of those other patch groups may have been used to make this patch active to devices.
  • Include enablement packages (Windows only, Routine maintenance only): If enabled, deploys the selected enablement packages. Enablement packages are a limited set of cumulative updates that enable you to upgrade from one version of Windows to another. Use Show superseded packages to show or hide items that have been superseded.
  • Selected Vendors/Products (Windows only): If disabled, patches for all available vendors and products will be included in the deployment defined by the Deploy by severity and Deploy by Patch Group options. As new products and patches become available, they will be added to the deployment.
  • If enabled, it allows you to specify the vendors, product families and product versions that can be deployed to endpoints. Vendors and products that are not selected will be excluded from the deployment. The items are presented in a hierarchical list. If you enable a check box at one level, all check boxes at lower levels are also enabled.

    • Select All: Enabling this check box selects all currently available patches for all vendors and products in the list. New vendor and product patches that become available at a later date will be added to the deployment.
    • If you want to exclude a small number of items, you can enable Select All and then clear the check boxes of the items you want to exclude.

    • Selecting individual vendors and products: Only patches for the selected vendors, product families and/or product versions will be deployed. Unselected vendors and products are filtered out from the deployment.

Reboot Behavior

This area enables you to configure if and when reboots of your target devices are requested during the deployment process. The Ivanti Neurons Platform handles reboot requests centrally to prevent conflicts from different Ivanti Neurons features. This means that the reboot may not be instant when requested.

macOS always reboots after operating system patch deployment, after prompting the user to deploy operating system updates. You can also choose Always reboot after an update (even if no operating system patches applied) for Mac configurations.

  • Reboot before deployment (Windows only): If enabled, specifies that the target devices are rebooted before patches are deployed. It is considered a best practice to reboot devices before installing significant new software, especially for large software changes such as operating system product levels. If you elect to reboot the devices, you can then specify the amount of warning that a logged-on user will receive and you can choose the degree of control the user will have over the reboot process. You can:
    • Elect to force a reboot after a number of minutes have passed
    • Alert the user that a reboot will occur when they log off
    • Select the duration to display a countdown message when the shutdown sequence is initiated. To preview the dialog box that the user will see, click Example countdown.
    • Allow the user to extend the time-out countdown up to a specified maximum.
    • Allow the user to cancel the time-out. If a time-out is canceled, the patches will not be deployed until the user logs off or manually reboots the device.
    • Allow the user to cancel the reboot. The patches will not be installed until the device is restarted.
  • Reboot after deployment (Windows) or Reboot after deployment when required (Linux): If enabled, specifies if a reboot of the target devices is requested after patches are deployed. Linux reboots only if required, but for Windows there are two options:
    • Always: Specifies that each device is rebooted after the patches are deployed. This is the safest option when deploying patches as most patches require a reboot in order to complete, but there may be times when devices are rebooted unnecessarily.
    • When required: Specifies that the Ivanti Neurons agent will determine whether or not a reboot of each device is required based on the patches included in the deployment.
    • For Windows you can set the Reboot criticality. This specifies the priority of the reboot request that is sent to the agent, so that the agent can schedule the reboot according to the settings on the reboot experience tab in the agent policy. The reboot request will be honored only if the value set here matches or exceeds the Minimum reboot criticality set in the agent policy. For more information, see Agent Policy Reboot experience.

      For Linux, if you selected the deployment option Deploy selected patches, not only are packages associated with the advisories in the selected patch groups installed, but also packages associated with dependent advisories. If you then enable Reboot after deployment when required, these dependencies may additionally cause a reboot.

  • If you elect to reboot the devices, you can then specify further options such as the amount of warning that a logged-on user will receive and the degree of control the user will have over the reboot process using the associated policies. For more information, see Agent Policy Reboot experience.

Settings - Microsoft preview patches

For testing purposes, Microsoft provides a set of preview patches for Windows ahead of their formal Patch Tuesday release. These patches do not include the security updates, so you will usually not deploy them to all of your devices, and so scanning for these patches is disabled by default. To enable scanning for preview patches, enable Scan for Microsoft preview patches.

If you choose to deploy preview patches, we recommend you deploy them only to a limited test group in your organization.