Making a setting only after a baseline has been fully applied

Hi, perhaps someone can help me out with this:

For patching Windows clients we are going to use baselines on a monthly basis. The first one is out now and next month’s is in the making. Until the image is overhauled several of these baselines will be out as a policy action at the same time. For reporting purposes and relevance-checking we are thinking about making a new client setting (e.g. called “PatchLevel”). The challenge here is that a value for “PatchLevel” must only be set after the complete baseline has run and permanently lost its relevance. Most of the time a baseline contains patches/fixlets that get relevant only after another one in the same baseline has run and the client has been rebooted. In the meantime a baseline is “not relevant” for a short amount of time until the client sees applicability for a new component and the baseline as a whole becomes relevant again. After a few reboots the baseline is then -finally- applied fully. So how to get that value in there only when the baseline has been applied entirely?

The whole point being, of course, that the baseline for next month’s patches only gets relevant after the previous one(s) have been applied and that reports show the correct applied patch level.

Perhaps my whole way of thinking here is a bit off. In that case it would be great to hear your thoughts as well.

What are you trying to achieve?

It may make much more sense to have a log file that gets an entry every time a patch baseline is run, when it was run, and potentially what components ran or the number of components that ran.

I’m not sure how easily it can be determined which components or the number of components that ran, but it is definitely possible to record which baseline ran and when.

You can just add a component to the very end of the baseline that has a relevance of TRUE, is set to not make the baseline itself relevant, and the actionscript just appends to the log file the name & time of action execution of the currently running baseline. This component would be the same and added to all of your patch baselines. It would use relevance substitution to grab the name of the currently running action/baseline so you wouldn’t have to change it by hand.

I have a related project that generates patch baselines automatically:

https://bigfix.me/fixlet/details/6132

In this concept, you would stop all previous running patch baselines and auto-generate a new one that contains all relevant patches for Windows in this example. You would similarly generate patch baselines for other categories separately, so you would have multiple patch baselines that would run concurrently.

This hasn’t been done yet, but the baselines could register the need for a reboot at the end of each baseline, and a separate task would actually do the reboot automatically if no user is logged in after a delay, or another would tell the user they need to reboot after a delay. ( In other words, only require a user to reboot their machine if their uptime is greater than X days and only if a reboot is needed )

Thank you for the replies jgstew! Multiple baselines set as policy actions are needed for newly deployed machines to catch up until a new image is created (I guess once every 6 months orso, still pondering 'bout that). At the moment a second action group in each baseline is in place containing one task mostly for the purpose of preventing a premature reboot. From what I understood a best-practice… This particular task sets a date stamp of when the baseline was run and forces a refresh of the client. Note: even though not all patches in the baseline are applied in the first run, this sets a date stamp nevertheless and therefore can not be used as a “final” marker. It only tells me the most recent date of when the baseline was (partially) applied. The Post-Action settings of the task that uses the baseline is set in a way that a restart is scheduled. At one point the baseline is not applicable anymore, but when next month’s baseline gets introduced it will have the same task in the 2nd action group and whenever that gets relevant it is relevant in the previous baseline as well. Result: a bunny-hopping reboot frenzy. By having a “PatchLevel” property I think some relevance can be built-in to prevent this.

I would recommend not using the PostAction reboot at all in baselines, unless you make it so the baseline can only ever run once using relevance, which doesn’t sound like you want to do.

Have the task that sets the time stamp use the action script:

action may require restart

http://www-01.ibm.com/support/knowledgecenter/SS63NW_8.2.0/com.ibm.tem.doc_8.2/Platform/Action/c_action_may_require_restart.html

Then have a different action that checks that uptime is greater than 1 day and that a restart is required, and have that action schedule the reboot using the PostAction mechanism. This different action should work for all reboots and will not need to be stopped or restarted.


###Related:

Hello jgstew,

Your proposed answer has one problem; and that is that íf the machine already has an uptime of >1 day, and it runs it’s very first patch (which has a ‘action might require restart’… , it’ll suddenly get relevant for the restart-action, and gets a restart pending scheduled; even though the baseline which contains the patches is still running…

Is this a correct assumption?

It’s however not a giant problem, since after the first patch the next reboot will be in at least a day… I’m just wondering if there’s some kind of safety build in that only after a baseline is completed (completely) - a restart is scheduled; and the baseline will never be relevant again…

That would be the correct assumption if you don’t add further relevance to delay the scheduling of the reboot from when it first becomes relevant.

I think there is a way to address this.

Right, now I remember:

Uptime should be > than 1day, but also, if each baseline sets a time stamp at the end of each execution, then the maximum of all baseline time stamps should be > than 3hour or something similar to prevent a reboot happening before all execution is finished.

With your feedback we made some changes by creating a separate task that determines a reboot pending by a BES action AND looks if a machine has an uptime for more then 24 hours. This task can then be used together with the correct post-actions for rebooting the client. The last task in the patches baseline will be a client resfreh together with a datestamp. Not sure what the “action may require restart” thing does but perhaps we make some changes later on. Let’s see where this gets us. Thanks!

1 Like

This actionscript will check some places in the registry to try to determine if a pending restart is needed. If it doesn’t find any signs of it, then it just won’t require a restart.

True, but it may perhaps also identify flags set by actions or software other then Endpoint (or not?). Just need to be sure the restart was triggered by the patching and that is why we use “…by a BES action”.

So if you want to ensure why the restart was needed, you can tag it.

ActionScript something like:

action requires restart "FromPatchBaseline"

Relevance:

pending restart "FromPatchBaseline"

You use the actionscript in a task at the very end of the baseline. You use the relevance in whatever is doing the restart. This would have the task that manages the reboots only apply if it sees a pending restart with that specific tag. This would mean it wouldn’t be a generic restart, instead it would be more specific.

You can use it without the tagging and just use a generic reboot task for everything, but you may need more relevance.

It took some puzzling but finally it looks like we have something that works. Put all bits and pieces together but now we have multiple patching baselines active simultaneously without one “jumping over the other”. For it to work we had to do the following:

The baselines all have a special last Action Group with 1 task in it that sets values for patchlevel and patchdate. It also forces the client to do a refresh and uses the action requires restart “FromPatching” (using a tag, thx. James!). Relevance for this last task is determined by being true for the lack of existence of a setting PatchLevel OR a specific value already being there (same or smaller then the current running baseline). That way, when the baseline is applied during a catch-up, it will run the patches in it but will skip the settings part at the end and that way will not set the reboot-flag (because another baseline will take care of this already).

Finally, a settings fixlet has been created that forces the client to refresh when it gets relevant for the "pending restart “FromPatching” and an uptime of more then 24 hours. The Post-Action on the policy using this fixlet takes care of the restart.

As a consequence, with each new monthly baseline also a “companion task” has to be created with the specifics for the PatchLevel setting (no problem). Furthermore, baselines will always run simultaneously during catch-up. So it will be possible that a newer baseline will finish before an older one although I do not see a problem with that just yet.

1 Like

I’m curious what these look like to see if they could be automated using relevance substitution, perhaps based upon the name of the baseline.


It used to be the case in BigFix that if you had multiple open actions for baselines in the same custom site that the first baseline to start running would run all the way through until completion before the next one would start. I think that stopped being the case at some point.


This should not be a problem as long as the relevance for the baseline components is correct, which it should be for IBM provided patches. You could have a situation in which a patch is not relevant because another patch has not yet installed. In this case the first patch would be skipped until the second was run, at which point the first would become relevant. If the baseline is set to reapply, it would then run again but only install the patches that were missed the first time.

The specifics of the companion task:

ActionScript

setting "PatchLevel"="201508" on "{now}" for client
setting "Last_Patch_Date"="{now}" on "{now}" for client
action requires restart "FromPatching"
notify client forcerefresh   

Relevance 1

A customer specific ID (a custom BES Client setting)

Relevance 2

if (not exist setting "PatchLevel" of client) or ((exist setting "PatchLevel" of client) and (value of setting "PatchLevel" of client <= "201508")) then true else false

Relevance 3

if(name of operating system starts with "Win") then((exists key "HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\BESPendingRestart" of it AND exists value "BESPendingRestart" of key "HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\BESPendingRestart" of it) of registry OR (exists key "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce" of it AND exists value "BESPendingRestart" of key "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce" of it) of registry) else (true)

That last one is a really nice copy-paste action from some other task :wink:

What does Relevance 3 do? I think there might be an easier option for this.

This should be equivalent for Relevance 2:

not exists values whose(it as trimmed string as integer >= 201508) of settings "PatchLevel" of client

I haven’t found a way to do this yet, but I would like to be able to determine the name of the running baseline from within the companion task itself and then pull the 201508 info from that name. This would hopefully mean that the companion task would never need to be changed.

I can pull the name of the running task from an action by itself, but I haven’t found a way to do it for a baseline as a whole.

1 Like

As indicated I got relevance 3 from some copy-pasting and it should be a check for a restart pending from a BES action on a Windows system, not? It could perhaps be optimised but it works as-is. Relevance 2 also works but I see you found some room for tweaking that (thx.!).

This will be TRUE if a restart is pending for any reason:

pending restart

If you use the following actionscript:

action requires restart "PatchingBaseline"

Then the following relevance will be TRUE if the above actionscript was used previously and the system has not rebooted:

pending restart "PatchingBaseline"

Which would replace relevance 3, as long as you use the actionscript first.

1 Like

Will have to try that next patchround but simplicity is always preferred. Thx for the addition!