Is anyone using Patch Policies for all of their Windows Updates?

Hey Guys,

I am new to BigFix and I debated about using Patch Policies vs. Baselines to automate our patching. The goal being wanting the simplest solution that will be completely automated and continues working when an admin goes on vacation, etc. For those reasons, I went with Patch Policies and after testing about 60 servers this seems like the correct choice. If there is anyone out there that is using Patch Policies and has any feedback on the following questions, I would appreciate it.

  1. Is anyone using manual groups to align your computers with different patch policy schedules? I know you can manually add servers to the different patch policy schedules, and that is what I am currently doing. The issue there is I am not seeing a way to reverse engineer and quickly look up what policy schedule a server object is a member of when browsing devices, etc. I do not want to have to browse through 40 different patch policy schedules to see which one contains a server named bravo1.redacted.com, etc. Creating Groups with the same names as the Patch Policy Schedule, and targeting those groups with the Patch Policy Schedules, would normally seem like a no-brainer and should solve the problem, but I still have problems seeing those group memberships as well when I click on a server object. So I am not sure if they really help or not because you must manage patch policies through WebUI, and the WebUI also does not seem friendly for either figuring out what groups a specific server is a member of, or adding/removing group memberships through WebUI. I am probably missing something extremely simple, but still looking for a way to quickly tell which patch policy schedule, or manual group memberships, a server has when clicking on it in devices inside WebUI.

  2. Does anyone know a way I can create a dynamic group to look for computers with a specific Patch Policy Schedule applied to them, in order to basically assist with reporting? I am patching servers all around the world and have about (40)different Patch Policy schedules, and it would be nice to browse to different dynamic groups, that assigned to each Patch Policy Schedule, and quickly see what servers are a member of what dynamic groups(patch policies schedules) - I am looking through the following regkey and not seeing anything that I can target with dynamic groups to help them match up with servers that have specific Patch Policy schedules assigned to them - hklm\software\wow6432Node\BigFix\EnterpriseClient\Settings\CustomSites\CustomSite_Windows_Patching

If your Organization patch policy cycle is 1 month - Patch Policy should be your go to.

“40 different patch policy schedules” - seems to be over the top. Please see what I think is your issue

If I understood you correctly, you have scenario with LOTS of Maintenance Window for different machines - and you want to run the Patch Policy one time and let it apply for each machine on its own Maintenance Window - Look into the following:

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 Tools > Manage Properties.
Select In Maintenance Window property from the BES support site, click Make Custom Copy, and then click OK.

At the moment, you cannot change group membership directly from the WebUI (you have to login into the Console), but you can have the group membership information in the device list by customizing the columns shown: The Device List

1 Like

Thanks - I was thinking that and appreciation the confirmation. Trying to customize the columns in the device list now. Thank-you

It’s generally frowned upon to use manual groups. It’s not a huge issue, but not ideal.

Preferably you want to use a Dynamic Group and then have an attribute on the computer add itself to that group. One of the more common is to have a property added such as a day, a group number, etc. Then relevance on the Dynamic group would match that property.

Yes - I really wanted to use maintenance windows, but they only have the option of Client Local Time and no UTC. Our servers are all around the world and it is easier to translate all maintenance windows into 3 regions and then use UTC for the windows of that entire region, etc… What we are doing is working 100%, but just has issues with trying to reverse engineer and see either what Patch Policy Schedule a client is attached to, or use Groups that are named/align with the PatchPolicy Schedule.

Customizing the columns of the on the Devices View is helpful, but the Servers are members of multiple groups and it truncates. I am playing around with this and might try an naming the Patch Policy Schedule groups with an underscore, etc to put them first and assist with that view. I just did not know if there was another way to click on a Device in WebUI, etc and see what group memberships it has

Yes - I agree in using dynamic groups is better, and that is why I was browsing through the BigFix keys in the registry to see if there is something there natively that shows patch schedule settings, etc. That way we do not have to always manually “tag” each individual server with a specific regkey when setting them up, etc. Thanks for all of the responses as I am just trying to figure out the best options

it is our understanding that you cannot use tasks in patch policies. Not sure why development decided on this large restriction but oh well.

@DanNashville So The Information you are looking for is:

Computer Name, Associated Patch Policy and Next Schedule?

Do you want to see it on Web Report or WebUI?

Well, basically Fixlets are objects meant to “fix” something broken in the client (you cannot reapply a successfull fixlet as it won’t be anymore relevant - at least unless system configuration changes again), while Tasks are a set of operations to be performed on a client (it can be easy reapplied on success, as the success criteria is not linked to its applicability relevance).

A patch policy is a set of criteria that defines a patch list; that is, a collection of Fixlets that meet the patching criteria of a specific set of endpoints. It was designed to patch (or fix) your clients.

It’s pretty common with things like ‘configuraton workaround’ tasks to publish one Task to enable a workaround and another to Disable the workaround. This leads to to a kind of a ‘trap’ scenario where it would be very easy as an operator to configure your Patch Policy to apply both, resulting in the configuration toggling back-and-forth and the Policy always failing (usually repeatedly, with repeated reboots).

We needed the support for tasks for things like putting a computer in maintenance mode, rebooting, housekeeping etc.

This is an area where HCL could improve.

Have you checked into Pre-patch and Post-patch in the Policy definition? That was added a few revisions back, and I believe that can specify Task IDs. I’m not certain whether it could specify Baseline IDs, I haven’t tried that out but suppose it’s possible.