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
Procedure
-
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.
-
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.
-
You can include two types of content: Custom Content and/or External
Content.
Custom Content:
- Check this option to include Fixlets from a custom site.
-
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:- Check this option to include Fixlets from an external site.
- 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.
-
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, for example 100,000 or more fixlets in a policy, can slow down the Patch Policy performance. To keep things running smoothly, it is recommended to create smaller policies.
-
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.
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.
- Click Next to configure the Auto-refresh behaviour of the new policy.
-
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).
-
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. -
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.
- Enter a name for the schedule and set the deployment
interval.
- This event repeats (daily, weekly, monthly), on (day of week/month).
- 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.
- At (Start time).
- 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 - 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.
- 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:
- From the BigFix console, go to .
- Select In Maintenance Window property from the BES support site, click Make Custom Copy, and then click OK.
- Enter a name for the schedule and set the deployment
interval.
-
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.
Note: Retry may not work if multiple MAGs are used in conjunction with Pre- and Post-Patch Actions. - 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.
-
Use Offer feature to send the schedule as an offer which gives the
operator an option to accept the schedule if they are interested.
- Check Send this as an offer.
- If required, check Notify users of offer.
- Enter the Offer Description.
- Click Save to save the schedule and return to the policy document.
-
The new schedule appears at the top of the list. Click Add
Targets.
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.
-
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.
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.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.
- Click Save to save targets and return to the Policy document.
-
Click Content (External/Custom) tab to Include, Exclude
and add New patches in the policy.
- Select the patches that you want to exclude.
- Click Exclude.
-
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 viewsNote:
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
ExampleYou 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.