Baseline Redeployment after Sync?

Usage and Config Patch
1

Hello,

I’m a new BigFix admin and was told to always sync baselines prior to deployment, which makes sense. However, since IBM updates the fixlet very often, it inadvertently happens within our patch cycle (30 days) at least 2-3 times, maybe more.

Do I have to redeploy the baseline every time I sync it? What will happen if I don’t redeploy it?

I would want to avoid redeploying it as it could reboot users’ machines more than once (if the updated fixlet from IBM requires another reboot - our baseline “post action” is a message and a forced reboot after some hours) within our patch cycle and that’s really frowned upon where I work, unless there are very good reasons to do so.

Thank you!

2

If you do not redeploy the baseline, then any open baselines continue using the “old” version of the baseline. You may have false positives or false negatives that were corrected by the fixlet updates.

If your systems had a false positive, they’ll appear Relevant for a patch they don’t need, and the Action Status will show “failed”.

If you had a false negative, then a system would skip installing a patch that it needed. That will show up as machines becoming Relevant to a fixlet/baseline after the fixlet is updated or the baseline is resynced.

I can’t claim best-practice here, but what I do is to create a new baseline every month, resync the old baselines, remove Superseded fixlets from the old ones, and then re-action all of my baselines. I usually don’t interrupt or restart a baseline action in the middle of my deployment cycle unless I’ve personally encountered a problem with one of the fixlets.

3

Jason,

Thank you for the response.

So you only redeploy baselines once a month (up to a certain amount of months in the past, I’m assuming) and remove superseded patches from the old ones before redeploying. Also, you do not replace those superseded patches in the old baselines, so you just delete them (because the newer version exist in your current baseline)?

What you describe works, however wouldn’t that cause multiple reboots in certain cases? Say some of the updated fixlets of the current baseline require a reboot.

I suppose if upper management is not sensitive to reboots, this would work fine. However, where I am, I can’t go to management and say: hey look because IBM is updating their fixlets often, some of the users will get more than 1 reboot in a given month. Uptime is very important.

Perhaps just syncing right before the first deployment is best and leave it at that?

4

I don’t send the post-action reboot as part of each baseline. I’ll start with a simplification of how I’d do it, which I think is pretty common here:

I’ll send all of the baselines out, targetting all machines, every month, with no post-action. Some machines install more patches than others, depending on the relevances, how long it’s been since the machine last patched, whether it’s a laptop coming back from an extended offline state, etc.

In addition to the patching actions, I send a separate set of reboot actions to occur at the end of the patching window. The relevance on that reboot action is just “pending restart”, with one or two retries waiting an hour between. So whether a machine installed one patch or two hundred, there’s only one reboot (ideally). If some patches failed and need to be retried after a restart, the “reapply” behavior of the reboot action gives enough time for a patch retry to happen and then triggers a second restart.

So that’s the simple version. The more complex version (and what I actually use), is that I send all of the Patch actions out with a Custom Constraint - “Run only when … setting PatchWindowState … is not ‘closed’”. I send out all the patch actions, and they start out Constrained. I have a separate action (an Offer) to allow clients to “Opt-In” for patching, it changes the value of a client custom setting “PatchWindowState”. So I can send out one action for each Patch Baseline, targetting “All Windows Computers” (not breaking it up by target platform). I let the local system owners decide when they kick off the Opt-In for patching. I send another action (not Offer) to force their patch window setting at a certain deadline time each month. So I have a deadline set, but the local system owners/operators can “Opt In” to have their patching start early.

I work in a 24x7 Critical system, so in many cases the local system owners have multiple sets of redundant equipment. The Opt-In allows them to schedule their patch times around complex ops or service failovers, so I don’t have to be as involved in their scheduling. The Patchwindow Deadline action only forces them to patch if they have not already Opted-In (based on effective date of setting "PatchWindowState" of client)

The action that handles rebooting the client also increments a client setting tracking how many times we triggered the client reboot during this cycle; when the client no longer needs to reboot (all the patches finished) or the client reaches a certain reboot count (patches have retried too many times), an action resets the client PatchWindowState setting back to “closed”, ending the patch cycle for that period.

1 Like
5

So you deploy multiple baselines/tasks/actions/fixlets within e.g. 30 days, and at the end of the 30 days, you reboot all hosts. That, however leaves you vulnerable to exploits within those 30 days, since a lot of fixes require a reboot to be effective, do you agree? Is this something you just accept as a risk?

6

I can re-trigger the patch window as frequently as needed. With Microsoft releasing on a regular schedule, every 30 days is usually sufficient, providing that cycle comes pretty quickly after the patches are released.

We are always at risk, even the day after deploying patches. Security is built on layers, and while patching provides one layer, it’s certainly not the only one (and in my environment, a pretty isolated government deployment, probably not even the most important layer).

Edit: if it wasn’t clear, I usually re-issue my patch baselines every month, but I don’t wait a month before rebooting. A given machine reboots after the patches run, usually with a window of about 3 hours.

7

Jason,

Thank you. My main concern was to see whether a synced baseline (after it was initially deployed) will get stuck. It doesn’t seem like that’s the case. Also thank you for sharing your patch strategy.

John

8

I see.

When you create a baseline, it makes a duplicate of the fixlets as they exist at that time. When the original source fixlet is updated, the baseline is not changed, and deploying the baseline would use the original version of the fixlet.

Likewise, an Action contains a copy of the baseline as it existed when you took the action. Actions do not get updated when you modify the source baseline.

So your Actions will not get stuck if the source baseline or source fixlets are modified. What you really need to watch for is that if the source fixlets were modified to correct a false positive or false negative, that false result is still in effect for your Actions.