Create a Patch Policy

In this page, steps for creating a patch policy, selecting patches to include, setting deployment options, and designating targets are provided in detail.

About this task

To open the application, select Patch Policies from the WebUI Apps menu. For a summary of Patch Policy tasks, see Patch Policy Operations.

Procedure

  1. On the Policies page, click Add Policy.
    The Add Policy page is displayed.
    Note: A non-master operator (NMO) needs Create/Edit Policy and Delete Policy permissions to add, edit or delete policy. For more information on permissions, see The WebUI Permissions Service. NMOs cannot edit definition of the policy stored in the Master Action Site despite having the permission to Create/Edit Policy. Currently, NMOs are not allowed to access the Master Action Site and they can access only their custom site.


  2. Provide the following information under Policy Criteria page:
    Policy Name
    Enter the new policy name.
    Site
    Select the Master Action Site or Custom Site from the drop-down to store the policy and its schedules.
    Description
    Enter the description.
  3. You can include two types of content: Custom Content and/or External Content.
    Custom Content:

    1. Check this option to include Fixlets from a custom site.
    2. Under Custom Content Criteria, select the Category, Sites, Start/End Date, and Sources dates from the drop-down that the new policy must include.
      Note: Custom Fixlets must include the above fields in order to be included in the policy.
    External Content:

    1. Check this option to include Fixlets from an external site.
    2. Under External Content Criteria, select the Operating System, Category, Severity, and Content type.
    • Operating System (choose one): Amazon Linux, CentOS, Mac OS X, Oracle Linux, Red Hat Enterprise Linux, SUSE Linux Enterprise, Ubuntu, Windows.
    • Category: Bug Fix, Enhancement, Security.
    • Severity: Critical, Important, Moderate, Low, Unspecified.
    • Content Type: OS Updates, OS Application Updates, 3rd Party Updates.
    Note: While creating the patch policy, ensure the following:
    • Fixlets must have a default action. If not, the Fixlets will not be included in the patch policy.
    • Patch policies will only detect Fixlets that has a default action.
    • Tasks will not be detected.
  4. If required, specify any patch exclusions or inclusions under Keyword Criteria. Type a keyword or phrase from the patch title and press Enter to add more. These fields are not case-sensitive, so capitalization can be ignored. Use and icons to remove/add a keyword or phrase.
    Note: Including a large number of items, ex. 100,000 or more fixlets in a policy, can slow down Patch Policy performance significantly. To keep things running smoothly, it is recommended to create smaller policies.
  5. Click Next to configure the Pre-Patch and Post-Patch behaviour of the new policy. For more details on when using Pre/Post content and when not using Pre/Post content, see Execution behavior.
    Note: It is not mandatory to configure Pre-patch and Post-patch contents, you can either have Pre-patch content or Post-patch content or both. You can skip this step by clicking Next if you do not want Pre-patch and Post-patch content in your new patch policy.


    1. Click the toggle switch to enable Pre-patch or Post-patch.
      Note: By default, the Pre-patch and Post-patch is disabled.
    2. Select the Site from the drop-down.
      Note: You can only select a Custom Site.
    3. Enter the Content ID. The name of the Fixlet or Task is displayed below Content ID.
      Note: The Content ID field only accepts a single Fixlet or Task.
    Note:

    If Pre-Patch or Post-Patch is selected, the following behaviors apply:

    • If the resultant policy action contains 200 or fewer Fixlets, the policy action will be executed on targeted devices if the devices are applicable to the pre-task, post-task, or any of the patch Fixlets within the policy.
    • If the resultant policy action contains more than 200 Fixlets, the policy action will be executed on all targeted devices, not just the devices that are applicable to the patch Fixlets within the policy. In addition, settings like Offers and Force Restart will be executed on all the targeted devices, if enabled.
  6. Click Next to configure the Auto-refresh behaviour of the new policy.
  7. Use the optional Auto-refresh feature to automatically include new patch content in your policy. To control update timing and frequency, set a refresh interval. Auto-refresh is disabled by default.
    • Refresh cycle (daily, weekly, monthly), on a specific day (of week/month) at (hour).
    • Day Offset: Use the optional Day After controls to schedule Auto-refresh updates relative to a monthly event, such as patch Tuesday. The second Tuesday of the month often falls in the second week—but not always. (For example, in August of 2018, Patch Tuesday fell on the 14th.) Use the Day After options to coordinate refreshes with events whose dates change month to month.
    • Time Zone: Select the desired time zone (WebUI Server Time or UTC).
  8. Click Save to save policy settings and display the policy document.

    The Schedules and Content (External/Custom) tabs, appear at the upper left, beneath the policy name. A policy summary appears on the right. Once established, policy schedules will display on the left. The Edit Policy control appear at the lower right. The Added by column represents the operators who had added targets to the schedule and in the case of Target By Property, it's the operator who had set the condition.
    Note: You can delete a policy using the Delete Policy action. To delete a policy, click Edit Policy and in the Edit Policy page, click Delete Policy.
  9. Click the Add Schedule button to set policy deployment timing, behavior, and targets. A policy can have multiple schedules, each with its own deployment options and targets. A policy without a schedule does not deploy.
    Scheduling adds predictability to patching and can help minimize errors. It also ensures that your environment meets company security policies in time for compliance audits. Some vendors follow a regular patch release schedule, which can tailor your policy schedule to meet. You may want to roll out a policy in a test environment prior to deploying to production. Consider defining separate patch rollouts for Test, QA, and production stages, each with their own timing and duration.
    Note: NMOs need Create/Edit Schedule and Delete Schedule permissions to add, edit, or delete a schedule. For more information on permissions, see The WebUI Permissions Service. NMOs also need write access to the site where the policy is stored to add, edit, or delete a schedule.
    1. Enter a name for the schedule and set the deployment interval.
      Image of the Add Schedule page.
      1. This event repeats (daily, weekly, monthly), on (day of week/month).
      2. Day after: Use the optional Day after controls to schedule patching relative to a monthly event, such as Patch Tuesday. The second Tuesday of the month often falls in the second week—but not always. (For example, in August of 2018, Patch Tuesday fell on the 14th.) Use the Day after options to coordinate patching with events whose dates change month to month.
      3. At (Start time).
      4. Time Zone: Use Client time to initiate a process relative to its time zone, for example, to initiate patching in the overnight maintenance window where each endpoint resides. Use UTC time when you want all endpoints to act simultaneously across all time zones.
        • Client Time - the local time on each endpoint; the time on the device where the BigFix agent is installed.
        • Universal Time - Coordinated Universal Time (UTC) is the global standard used to regulate clocks and time worldwide.
        Note: If you specify Client Time, the policy Start time will begin at the specified time in UTC+14 time zone. For more information. See Deployment Time
      5. Patching Duration (minutes, hours, or days, up to 30 days). The amount of time the policy will attempt to install patches on a target device that is not responding.
      6. Run within the Maintenance Window - This option allows you to run patch policies during maintenance activities. You can use the Maintenance Windows Dashboard to schedule maintenance activities run by BigFix.
        Note: To use this feature, a global In Maintenance Window property must exist.
        To create the global In Maintenance Window property:
        1. From the BigFix console, go to Tools > Manage Properties.
        2. Select In Maintenance Window property from the BES support site, click Make Custom Copy, and then click OK.
  10. Set deployment and post-deployment behavior.


    • Pre-caching: To download required files before patching starts, set the in minutes, hours, or days up to 5 days.
    • Stagger patching start time, for example, to reduce network load. Set an unlimited number of minutes or hours.
    • Bypass patch errors and continue patching. Patch policies are Multiple Action Groups (MAGs). MAGs run sequentially and stop on the first action that fails. Use the Bypass patch errors option to ignore failures and proceed to the next action. Use this option when the actions in a MAG do not depend on the actions that precede them. For more information about policies and Multiple Action Group (MAG) processing, see Monitoring Deployed Policies.
    • Retry up to n times (unlimited). If a patch fails to install on a device, for example, due to lack of space on the hard drive, set a retry value and the wait period between attempts.
      • Wait n (minutes, hours, up to 30 days) between attempts to install.
      • Wait until device has rebooted to install.
    • Force a Restart - Force a restart on completion. Notify device owners when a restart is required and provide options for restarting at a convenient time. (1, 7, 15 days). Use the default message or type in your own.
  11. Use Offer feature to send the schedule as an offer which gives the operator an option to accept the schedule if they are interested.


    1. Check Send this as an offer.
    2. If required, check Notify users of offer.
    3. Enter the Offer Description.
  12. Click Save to save the schedule and return to the policy document.
  13. The new schedule appears at the top of the list. Click Add Targets.
    Target by Device
    Skip locked constraints during patching: Use this feature to deploy patches to locked devices without having to unlock the device. This option is only available to an operator with console lock or unlock permissions, and only applies to targets added by that operator. For information on lock permission, see Can Lock - Adding Local Operators.
    Note: NMOs need Add/Remove Your Own Targets permission to add or remove the self created targets. NMOs need Remove Other Operator's Targets permission to delete the targets that are created by other operators. NMOs can target only the permitted number of devices and cannot exceed the limit. In case of violation, WebUI app will display an error message and the NMOs cannot proceed further. For more information on permissions, see The WebUI Permissions Service. NMOs need read access to the site where the policy is stored to add/remove the targets.
  14. Select devices or computer groups from the Target by device or Target by groups tabs. Alternatively, you can define a set of property conditions with Target by properties and the policy will be issued to the devices that match those conditions. Note that you cannot mix targeting methods in a single schedule. A schedule without targets does not deploy. Check the device to select or deselect it. The numbers in Applicable Patches and Deployments column refers to the number of patches associated with that device and the deployments information. Use your browser’s Back button to return to the Patch Policy app.

    Target by property
    With Target by properties, you can define the required condition of the endpoints you intend to target. Target by properties is limited to one operator per schedule. For that schedule, the policy will only be issued to the endpoints owned by that operator.
    With Target by client relevance, you can write your custom relevance that determines the Policy's targets. For example, you can check the versions of specific files. The policy actions will be dynamically targeted. Note that you cannot choose multiple targeting methods at the same time. Target by client relevance is limited to one operator per schedule. For that schedule, the policy will only be issued to the endpoints owned by that operator.
    Target by client relevance
    If a NMO sets the Target by properties or Target by client relevance for a given schedule, then only the following operators can edit or change the targeting methods to Target by device or Target by groups:
    • The original NMO who had set Target by properties or Target by client relevance.
    • Master operator (MO).
      Note: The Target by properties or Target by client relevance tab will only appear for NMOs whose Device Target Limit permission is set to Unlimited. NMOs must click the Use plain client relevance for targeting to see the Target by client relevance tab. For more information on permissions, see The WebUI Permissions Service.


  15. Click Save to save targets and return to the Policy document.
  16. Click Content (External/Custom) tab to Include, Exclude and add New patches in the policy.

    Image of List of Patches page.
    1. Select the patches that you want to exclude.
    2. Click Exclude.
  17. When you are ready, click the Activate toggle button to activate the policy and commence patching. Activating a policy activates each of its schedules. Suspend an active policy at any time to halt patch deployment. Click Refresh Policy icon to refresh the policy.
    To monitor policy-based patching activity, use the WebUI’s Deployment views
    Note:

    If you have specified Client Time in your policy schedule, the policy start time will be the specified client time in UTC+14 time zone after activating the policy. This is to ensure that clients in all time zones will be receiving the policy at the specified time.

    In WebUI, the start time will be displayed in browser time, after the policy is activated.

    • Client time = The time on the endpoint receiving the policy.
    • Browser time = The time on the machine on which the browser resides.
    The following calculation can be used to convert from UTC+14 time to your browser’s time:
    • Start_time (in browser time) = <specified_client_time> - 14 hrs + <utc_hour_offset_for_browser_timezone> hrs
    Example

    You have specified a Client Time of 5 A.M., because you want the policy to be executed at 5 A.M. in each endpoint’s timezone, that is 5 A.M. PST, 5 A.M. EST, 5 A.M. IST, etc. This means the policy action will be issued at 5 A.M. in the UTC+14 time zone but the policy will not execute on a client endpoint until it is 5 A.M. in the client’s local time.

    Consider your browser is in Pacific Daylight Time (PDT). PDT is UTC-7, therefore the UTC offset here is -7.

    Start time in PDT = 5 A.M. – 14 hours + (-7 hours) = 5 A.M. – 21 hours = 8 A.M. PDT.

    Now let us consider that your browser is in Indian Standard Time (IST). IST is UTC+5:30 so the UTC offset here is +5:30.

    Start time in IST = 5 A.M. – 14 hours + (5:30 hours) = 5 A.M. – 8:30 hours = 20:30 IST or 8:30 P.M. IST.

    Note: If pre-caching is selected, the policy issue time is offset by the amount of time specified in the pre-cache section.

    For example, if you opted to set pre-caching to 1 hour before patching begins, the action will be issued at 7:30 P.M. IST rather than 8:30 P.M. IST.