I was always told that once a baseline starts, it has to finish. however, I currently have a dozen baselines that can only be applicable between 00:00 - 02:00. Yesterday I noticed that 6 of the baselines became applicable in that timeframe,which I expected. But when I looked at the BES Client log file of the endpoint that started to run those baselines, i noticed that baseline components from different baselines were running in order, not “1,2,3” for baseline#1, then “1,2,3” from baseline #2, but more like "baseline1compoent1, baseline2compoent3,baseline1compoent2, etc.
Is this normal behavior? My goal was to have the baselines run when they were applicable, but not run when they weren’t, and since I assumed that they ran in order, that they will be able to see that they were no longer applicable when time ran out. however, if what I am seeing is correct, they all start running at the saem time and will have to finish, regardless if they go past 02:00.
baselines are guaranteed to run their actions in order.
any single action can only run one at a time (you won’t see simultaneous actions from different baselines)
in between baseline actions, other actions can run… this will likely happen if there are downloads required because it gives more time for another action to launch.
So the interleaving that you see in the baselines is expected. Each baseline will run in order, but they can take turns running their actions.
So you’re saying the components of baseline1 and baseline2 will run in order, and baseline1 and baselin2 can actully be running their compoents an the same time (baseline 2 doesn’t need to wait for baseline1 to complete). Correct?
If that’s true, then it complicates my patching process, because as soon as all the baselines evaluate and determine that they are applicable, then they will all start running, regardless of if they become non-relevant in 5 minutes or not.
So you’re saying the components of baseline1 and baseline2 will run in order, and baseline1 and baselin2 can actully be running their compoents an the same time (baseline 2 doesn’t need to wait for baseline1 to complete). Correct?
If that’s true, then it complicates my patching process, because as soon as all the baselines evaluate and determine that they are applicable, then they will all start running, regardless of if they become non-relevant in 5 minutes or not.
Yep.
To deal with this behavior, we use “control files” to stage the baselines in order. At the end of baseline 1, file “baseline1-completed.bf” is written to a particular folder. The relevance in baseline 2 restricts it from being applicable until baseline 1 has run.
Sometimes I wish there was a setting that would prevent multiple baselines (and perhaps even individual actions) from running simultaneously, or an action setting that would prevent any other actions from running while that particular action is running. It’s not a deal breaker though.
I was going to do that too boyd, but then realized that all off the baselines would need to be applicable, else the baseline would not run, not update the .txt file, and baselin2 would never run.
So any suggestions how I can have by baselines only run between 00:00 - 02:00 ? Once they become applicable because it is 00:00, they will all start running, and even if it become 02:01, they will continue to run until they are finished, even if they are no longer applicable.
We use an approach similar to what Boyd does. All the baselines and all the “flag” tasks within them are applicable to all the target machines. BL2 runs only when BL1 is complete. BL3 when BL2 is complete, etc. So all machines run all baselines, but in some baselines that only relevant item may be the “flag” task. We also usually make the relevance of the baseline and flag task the same, then only check the “Baseline will be relevant …” checkbox on that “flag” task. This works consistently and well, but has the extra overhead of the “flag” tasks.
I was going to do that too boyd, but then realized that all off the baselines would need to be applicable, else the baseline would not run, not update the .txt file, and baselin2 would never run.
If you configure your control file tasks correctly, each baseline should run sequentially. Each control file task should have relevance like this so that it will run once and once only: not exists file “C:\control\baseline1.ctl”
When you put the control file tasks into your baseline, be sure to check the box “baseline will be applicable when this task is applicable” so that the baseline will be run if the control file has not been written yet. But keep in mind that, even if this task is applicable, the baseline will not run if the applicability relevance of the baseline itself returns true.
JonL, that’s exactly what we’re doing.
So any suggestions how I can have by baselines only run between 00:00 - 02:00 ? Once they become applicable because it is 00:00, they will all start running, and even if it become 02:01, they will continue to run until they are finished, even if they are no longer applicable.
Maybe set them to only run between 00:00 and 01:00 so that they have an hour to finish up?
yeah, that’s what i’m doing. they are applicable from 00:00 - 02:00, but have a “cool down” period from 02:00-02:30. But i’m seeing that when some clients have 100+ relevant fixlets, it could take over 2hours to patch them and that’s no good. Maybe it’s not possible…
A few more thoughts in this vein that have helped us …
In some cases we have opted for a custom registry hive and values instead of files to use as control or flag values.
If the baseline preceding a given baseline requires a reboot, it can be helpful to have include a line at the end of the last task in the first baseline “action requires restart”. Then in the actionscript of the first task of the follow-up baseline begin with “pause while {pending restart}”. The prevents the reboot from the first baseline to randomly happen mid-stream during the second baseline.
Since it is potentially easy for someone to mistaken delete a control/flag file, thereby making a baseline relevant that shouldn’t, we typically take it a step further and use a combination of one or more both positive and negative relevance items. Here is a simple conceptual example:
BL1 relevance: exists target naming convention regex; not exists BL1 complete flag; not exists “Updates in process” flag
BL1 task1 actionscript: create “Updates in process” flag
BL2 relevance: exists BL1complete flag; not exists BL2 complete flag; exists “Updates in process” flag
BL3 relevance: exists BL2complete flag; not exists BL3 complete flag; exists “Updates in process” flag
.
.
.
BLx relevance: exists BL(x-1) complete flag; not exists BLx complete flag; exists “Updates in process” flag
BLx task actionscript: delete “Updates in process” flag
While it may be easy to accidentally delete a flag/control file, it is difficult to impossible to “accidentally” both create and delete various control files/registry values.
We use may variations on this basic theme for dozens of baselines targeting thousands of machine successfully. Using that approach, we don’t have false positive problems or unintentional application of baseline actions.
JonL, i was going to do the same thing, where as a baseline will only be applicable with BLx-1 runs, however i decided to not use that way because that would require all my baseline to be applicable, and that wasn’t true all the time.