How to handle patching of powered off servers?

Usage and Config Patch
1

These days many of the servers my team is responsible for patching are cloud based. And many of those are turned off to save money - they’re only powered up when they’re needed.

We patch monthly. Our non-production servers are patched the weekend following “Patch Tuesday” and then production the weekend after that. We have servers grouped by function or location (“Finance” or “San Diego” for example). This allows us flexibility in patching different groups of servers at different times while keeping those that are related together.

I have written a script that looks at each group, sees which patches are applicable to the group and builds a baseline for it and then schedules the baseline for deployment. However, if servers are powered off they will not evaluate any new patches that are released, and the baseline may not include patches that would actually be required.

I’m sure I’m not the only one who has run into something like this and am wondering how others are handling it?

2

You could use WOL or sometimes you are allowed to configure a scheduled power on in the BIOS.

Technically, you wouldn’t need these servers to pre-evaluate the baseline relevance, you could just send them the baseline action and they will install/ignore baseline components as needed.

3

Our baselines include all relevant and not relevant patches because we are an MSP that has new systems being added every day. I can’t predict that NewSystemA is going to need Patch124 when I push our baselines so we include all current, relevant or not content.

1 Like
4

Our baselines include all relevant and not relevant patches

How do you determine what is relevant if the target system hasn’t been able to evaluate it?

5

Endpoints evaluate relevance at time of execution, so you send out ALL patches for the month

6

Add all new patches to the baselines.

For example, we deploy all patches that have a category “like” security and a source severity that is not equal to “Unspecified”

We build our baselines from Filters and our SQL baseline has 47 fixlets. Notice the hightlighted ones have no relevant systems.

image
image880×319 27 KB

image

7

Add all new patches to the baselines.

Do you create new baselines each month or just add new patches to existing baselines?

8

For what is worth one of the suggestions for future enhancements for MultiCloud feature is to create ability to manage power states of public cloud devices - power on, power off, etc using the Cloud APIs that the Plugin Server uses. It will not be entirely unlike the functionality to deploy BigFix agent to cloud machines that Plugin server does but instead give you the ability to manage the instances status (PM/DEVs were quite receptive at the time, so I never bothered to submit it as an idea but maybe it should be). If ever delivered it will open the door to manage deployments on such machines quite easily (pre-deployment power on machines, post-deployment shut them back down). It can solve a problem with running BFI scans on such machines and so on too which is problematic now as well!

3 Likes
9

You would create a baseline per month. You also shouldn’t exceed 100 ~ 120 components. If this happens you should split the baseline into two.

10

What about using the Patch Policy feature? You can define which patches will be available, when the content refresh will be - the content will also contain non-relevant patches - and on the Schedule itself it will patch only the relevant content

1 Like