Creating a Custom Patch Configuration

This area enables you to configure what patches will be deployed (deployment options), and if and when requests to reboot your target machines will be sent during the deployment process (reboot behavior). You can configure different deployment behaviors for different operating systems in the same patch configuration.

Enabling deployment for an operating system

You can enable and disable patch deployment for each operating system separately. Under Deployment behavior, select the required operating system, then set Deploy patches as required.

To create a scan-only patch configuration, switch off the deployment toggle for all operating system tabs.

Deployment options

There are up to three configurable deployment options, depending on the operating system:

• Windows: Deploy by severity, Deploy by Patch Group, and Selected Vendors/Products
• Mac: Deploy by severity, Deploy by Patch Group

If you don't modify any of the options, then by default only critical security patches will be deployed just for Windows. If you enable and configure both the Deploy by severity and the Deploy by Patch Group options, the effect is additive, with all of the patches for each configured option being deployed. If you enable and configure Selected Vendors/Products, that option filters out patches from the other two options.

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 by Patch Group option and select the desired patch group

Example 2: Say you configure the following:

• Deploy by severity: Security Critical and Security Important are selected
• Deploy by Patch Group: You select one patch group 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. In addition, 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 will be Adobe Security Critical patches, Adobe Security Important patches and any Adobe patches contained in the patch group.

Example 4 (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 by severity: If enabled, allows you to specify the types of patches and the severity levels that should be included in the deployment. By default, only critical security patches is selected.
  • Security patches: 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: Security patches that have not been assigned a severity level.
  • Non-Security patches: 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.
• Deploy by Patch Group: If enabled, allows you to specify one or more patch groups that contain the patches that you want to deploy. This is a good way to make sure that only approved patches are deployed. Missing patches not contained in the specified patch groups will not be deployed unless they are specified in the Deploy by severity filter. 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.

  When you enable Deploy 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 the patch group you want to deploy. A next to the count of patches for the operating system not being configured indicates that the configuration already includes those patches.

  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 policy groups 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.
• 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.

TIP: 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 machines 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.

The rest of this section applies to Windows configurations only.

• Reboot before deployment: If enabled, specifies that the target machines are rebooted before patches are deployed. It is considered a best practice to reboot machines before installing significant new software, especially for large software changes such as operating system product levels.
  If you elect to reboot the machines, 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 machine.
  • Allow the user to cancel the reboot. The patches will not be installed until the machine is restarted.
• Reboot after deployment: If enabled, specifies if a reboot of the target machines is requested after patches are deployed. There are two options:
  • Always: Specifies that each machine 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 machines are rebooted unnecessarily.
  • When required: Specifies that the Ivanti Neurons agent will determine whether or not a reboot of each machine is required based on the patches included in the deployment.

If you elect to reboot the machines, 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 policy groups. For more information, see Policy Group Detail.

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

The Set recurrence tab 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 the scheduled deployment is missed, it will be performed the next time the machine is reboot. macOS always runs on reboot.
• 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: Specifies if you want to create the deployment package and copy the deployment package to the target machines prior to the actual deployment. 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 machine'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.

• Upcoming task: This table shows a list of upcoming tasks. It enables you to view all of the events that are projected to occur over the next 60 days using the currently selected configuration. Note that the information provided in this table is a projection; many things could occur to prevent one or more of the events from occurring.

• You might create a patch configuration for all vendors and products used by the IT Support teams within your organization. You can then associate this configuration with the agent policy groups that cover your regional teams, such as AMER IT Support, EMEA IT Support, and APAC IT Support.
• You might create a patch configuration for patches that are released on a Patch Tuesday. You can then associate this configuration with a pilot agent policy group that you want to use to test the patch deployments. If the deployments are successful, you can associate the configuration with your primary agent policy group for wider distribution.
• You might create one patch configuration for your laptop and workstation devices and a separate patch configuration for your server devices. You then associate the proper patch configuration with the agent policy group that is governing each device type.
  

To associate the current patch configuration with one or more agent policy groups:

1. Click Select policy groups.
2. Choose the desired agent policy groups.
   To help you choose, the following information is provided about the available policy group(s):
   • Policy group: The name of the agent policy group.
   • Endpoints: Shows the number of endpoints currently using the agent policy group.
   • Current patch configuration: Shows the name of the patch configuration currently associated with the agent policy group.
3. Click Confirm.

The list of all agent policy groups currently associated with the patch configuration is displayed on the Associations page.

The table displays all versions of the configuration. By default, the table contains the following columns and is sorted by the Version column.

• Version: The numerical value of the version. The first save of the configuration will be version 1. Each time the configuration is edited and saved the version value will be incremented by one. Clicking the version value will open the configuration details for that particular version.
• Configuration name: The name of the patch configuration.
• Save date: The date and time the configuration edit was saved.
• Last saved by: The name of the team member who last edited this version of the configuration. If you modify a patch group that is associated with a patch configuration, that qualifies as a revision to the configuration.

• Availability: Shows the current status of the configuration. Possible values are New, Pending, Active, Previously active, Draft, and Failed

• Description: The comment that was provided at the time the configuration edit was saved.

• Revert to selected version: Enables you to revert the patch configuration to an earlier version. Be sure to update the configuration description and to click Save after performing your action. Patch groups are not included in the revert action. Whatever patch groups are included in the current patch configuration will be included in the reverted patch configuration.

Enables you to export the contents of the table to a CSV file. You can choose to export all items in the table or just selected items.

The CSV file is created using ISO standards and is stored in your local Downloads folder. If you use Excel to view the file, the data can be converted to the locale of the machine so that it can be viewed in a more human-readable format.

Any sorting or filtering applied to the configurations will be retained in the exported output. All columns will be included regardless of what has been selected in the Column Chooser.

Select the first column check box for the configurations you want to export. Alternatively, select the check box in the header cell to select all configurations.

Click Export to create the CSV file.