Cumulative patching

Usage and Config Patch
1

(imported topic written by cstoneba)

In our old SMS days, we were able to deploy all relevant patches that a system needed and then push a reboot at the end of patching. I’m trying to do something similar with BigFix, because cumulative patching is a requirment in our environment, but am having some difficulties.

Idealley, i would duplicate that SMS logic by having a single baseline with a reboot at the end. however, as we all know, large baselines are not suggested. So as soon as my “cumulative patching baselines” grow to more than one baseline, a single reboot post patching becomes difficult. Is there anyway to force a single reboot when all my relevant baselines have finished patching?

2

(imported comment written by BenKus)

Maybe just add a restart to the end of one of the baseline actions and add a fairly long countdown and all baselines should complete in the meantime?

Ben

3

(imported comment written by cstoneba)

that’s an option, but I really dislike using static times because there is no guarantee that they will always be enough time. I’m suprised that there is no built in way to do this automatically.

4

(imported comment written by SystemAdmin)

cstoneba,

I’ve just recently implemented a process to handle this and it’s fairly simple. One task handles triggering a flag to set the patching window to True when it should be ‘Active’ (as a Bigfix setting, to keep it simple and easy to re-configure via console, if necessary) and later to False when inactive.

A second task handles the reboots, set to reapply every 30 mins. In order to keep me informed of which machines are doing what, I set a setting called ‘Patching-Status’. The patching active/inactive task above also updates the status, as do all the baselines. That way I know which task is working/has just done work on the client.

In the reboot task, the initial setting is to ‘Reboot triggered - not required’ and then an if statement handles three tests - within the first half-hour, within the last half-hour, or (in any of the ‘midde’ half hours, if its ‘Pending Restart’. Each of these if’s only contain a restart command and an update to the Status setting (as appropriate to let me know which was triggered).

Thus during the patching window, the status may go from ‘Active’, ‘Reboot - 1st cycle’, ‘Baseline being applied’, ‘Baseline complete’, ‘Reboot - not required’, ‘Baseline being applied’, ‘Baseline complete’, ‘Reboot - last cycle’, ‘Deactivated’. The baselines might get applied before the last reboot…and even possibly after the last reboot occurs, but as there are essentially 9 other half-hour windows (between possibly reboots, including the first) for the patching to occur, I am not that bothered about the rather low possibility of a few patches being applied after that last one.

Now, this is not quite as ‘tight’ as I could make it. To do exactly what you’re talking about, I would want the Active setting to probably go through the sequence “False, Start, True, End, False”. The baselines would only be running when it’s True, but the Start, True and End would all be relevant possibilities for the reboot cycle. And the reboot cycle is 30 minutes mostly because I got bored waiting for an hour between reboots and having to wait for the final patching status to come back as completed. :wink:

Let me know if you have any questions.

-Jim

P.S. I know some of the long-winded suggestions I’ve posted here before have only been theoretical (such as controlling the timing of rebooting/patching paired machines), but this process has been running currently for almost two months (jinxing myself as I write this) and has worked very well.

5

(imported comment written by cstoneba)

thanks Jim, i’m trying to get as many inspirations as I can right now.

Since our maintenance windows are only for 3 hours once a month, I think it is pretty important to have all patching completed prior to the reboot. And that’s what i’m trying to figure out but I just can’t. How is it possible for that reboot task to know when all patching is completed. Reboot flags set in the patching baselines would work, but the Restart baseline has no idea when all the patching baselines are completed. As soon as one finished, it could see the flag and reboot. Then i could have 5 more patching baselines queued up that would start patching post reboot. I dunno, maybe it’s just not possible.

6

(imported comment written by SystemAdmin)

If you have a patching window, in my mind it doesn’t matter how much work there is to do on a machine, once the patching window closes we shouldn’t be applying patches nor rebooting the machine. If all the patches didn’t get applied, then the window wasn’t long enough this week/month and we’ll have to wait for next time.

Therefore, you have to make some allowance for the ‘flexibility’ of how BF processes the relevance for baselines, actions, etc. If you must stop at a certain time, then I would suggest you create a process that marks the ’ last orders’ time for any patching baselines (as per my suggestion for changing Active setting to ‘End’ prior to becoming ‘False’). The time after ‘last orders’ and ‘closing time’ is whatever time you think is reasonable for a reboot task to become relevant on a machine, get placed in the action queue, get executed and having the machine come back up. 15-30 minutes seems like a reasonable time for that to happen.

As an additional measure, you could even have the same process that moves the active trigger from ‘True’ to ‘End’ also alter the workidle and sleepidle settings to increase the likelihood of the reboot process triggering and getting the machine restarted. (Remembering to have the final change to ‘False’ also reduce the settings back to normal.)

And after having discussions with a couple of people where I’m working now (and posting this), I’m very tempted to modify the process as I’ve described (with the extra ‘Start’ and ‘End’ intervals), just to ensure we are rebooting first (before any baselines are applied) and as the very last piece of the process, prior to the end of the patching window. This just seems cleaner to me and even easier to explain (compared with currently having to explain that there is a small chance that a baseline could be applied prior to the first reboot or after the last one).

-Jim

7

(imported comment written by cstoneba)

i’m as little confused. So your reboot task runs every 30 minutes. Doen’t you feel that you are spending too much time rebooting? The process i’m working on is for Servers. Some servers can take 10+ minutes to reboot, and if I do that multiple times in a window, i could be waisting valueable time rebooting the servers. That’s why I’m trying to get to a point where it reboots only once, post all patching baselines.

8

(imported comment written by SystemAdmin)

Sure, but rebooting as necessary seems better than not, for both workstations and servers.

Potentially, in a worst-case scenario, it ‘might’ reboot every 30 minutes…but if it requires it (due to patches being applied that require a reboot and not wanting to queue up too many unapplied pre-boot changes), then I would much rather have that occur than just reboot once or twice but leave a number of patches unapplied. If you are quite cautious about rebooting, then that just means the machine is possibly sitting around doing nothing after a baseline has run and waiting for a reboot.

Typically, a machine will only reboot twice, or even three times. Once, for the initial reboot (possibly/hopefully) that occurs as the first part of the process. A second will be the very last time for the machine in the patching window (and hopefully, no more baselines/patches running after this). The middle reboots only occur in the case where ‘Pending restart’ has been set on the machine…so for that situation, please tell me what you’d rather have happen?

Yes, you can always reduce the reboots to once an hour, but for your case, that only gives you 2 ‘windows’, separated by a single reboot for doing all the work.

  • If there aren’t many patches, thats fine…but almost any proces would work in that case.

  • If there are a number of patches to be applied (therefore increasing the possibility of requiring a reboot), then I would rather have the reboots occuring fairly quickly in that case.

The two significant parts of the reboot task are linked to a) measuring the time interval and determining if we’re in the first, last or middle parts of the window and b) deciding if a reboot should occur somewhere in the middle due to ‘Pending Restart’ being True.

When I first put this process in place, machines were being restarted anywhere from 2-5 times. During the last few weekends of patching, the majority (of those same machines) just rebooted twice (as the required minimum), with most of the rest just restarting a third time (in the second half-hour cycle), so it really becomes a fairly moot point once a machine has been slapped with the BF patching stick at least once (and quite hard). :wink:

-Jim

9

(imported comment written by NoahSalzman)

/me waits patiently for someone to post a pic of a “BF patching stick”.

10

(imported comment written by SystemAdmin)

A picture would be difficult, because as soon as you realise, it’s too…WHACK!

{thud}