Today we currently apply Microsoft OS security patches to almost 500 servers a month, on varying days of the month. Each server has a field called “UpdateCycleDay” where we identify what day of the month we want that server patched. Then we have dynamic groups that contain the servers to be patched each day of the month based on that field entry. Then when we apply our patching baseline, our action is based on that dynamic group and is set to run at 9pm each day. So when that day is relevant, those servers get patched that evening at 9pm.
Now here’s my dilemma. We are starting to get requests to patch during the day because certain servers cannot be rebooted at 9pm. I want to keep the process simple from our team’s perspective, where we can continue to create just one task that’ll run all month and apply to those servers via dynamic group. But I don’t know how to identify the servers that should start at 9pm and the servers that should patch at 8am. . . . and keep it all in one action.
If anyone has any thoughts on this, it’d be greatly appreciated. I will preface this with I’m not saavy in BigFix land, I inherited support of it when a coworker left. . . . learning by the seat of my pants.
From your description, it sounds like the requirement is to have a relatively simple “maintenance window”. Please see if the following link/approach helps for your use case:
Very similarly, we issue our Actions with a Custom Constraint, which we define with a custom setting. In the Take Action dialog, we use “Run only when…PatchWindowState does not equal False”
We issue a single action for each Patch Baseline against all computers of an OS (i.e. one action targeting a group “All Windows Computers”, another against “All Linux Computers”, etc.), all using this Action Constraint.
When the patch baseline actions arrive at the clients, they show Action Status of “Constrained” until we set a value for the PatchWindowState client setting and make it anything other than “False”. (If the Client Setting does not exist at all, the Action still remains “Constrained”).
We send a separate action out to clients to change their PatchWindowState settings to a value (we use several different ones). For example, we might have an Offer out to clients to set “PatchWindowState” to “Opt-In”, so the users can start a Patch Window at their discretion. We also schedule a separate action to set “PatchWindowState” to “Required” at a deadline time - and anyone who hasn’t Opted-In gets hit at the Deadline time.
We have another action that schedules the reboots, also constrained based on the values of PatchWindowState. If PatchWindowState is “Opt-In”, we give a “nice” reboot message with 24-hours to reboot. Once PatchWindowState changes to “Required”, they pick up a different Reboot action, which is “less-nice” and only gives 2-hours notice for reboots.
This is very similar to the Maintenance Window dashboard, except that we don’t lock the entire client. These settings only affect our Patch Baselines that are configured with the action constraints, so the clients do continue executing any other actions that are sent to them.