So we create a unique baseline each month for OS Patches. In this case lets deal with just MS patches as they are the most common. Let’s say that after 6 months we deploy a new round of computers. When each one comes on line, it evaluates the baselines an applies them. The same problem arises with our sales team - they may not get patched for a few months. Each out of compliance computer goes through multiple reboots and the process is slow. Then there is the sheer number of open actions.
The question is this: If we create a Generic OS Patch Baseline and add the monthy baselines to it, do we gain or lose? Do we gain a single baseline, single reboot, report against a single baseline. Do we loose because all the the items from all the baselines exceed the recommended number, we have to report against multiple baselines? The deployment health check dashboard flags it as an issue.
Is there a better way? What approach have you taken?
As you put more components in a baseline, there is definitely a cost as they get too big, which can cause agents to report and respond slower than usual.
For new computers, you might consider increasing the agent’s resource usage so it will apply the patches faster and minimize the time for the “top-off”.
Don’t forget to consider building off the latest service packs for each OS rather than applying all the patches.
If you do have big baselines, make a new operator account that specifically manages new computers (perhaps with a flag in the registry that indicates it is a new computer). This will help keep the other agents in your deployment from seeing the big baselines that might slow them down.
Thanks for the tips. I’ve seen the notes on “efficient mime” before - however the Health Check Dashboard still screams “too many” if you go over 100. It causes fear in the average BES Admin.
What is considered too large even for “efficient mime”? Can we safely put all MS OS patches since Service Pack 3 for Windows XP into a single baseline? Is there a negative to nesting a baseline in a baseline to create a large all inclusive baseline?
I think these days we see about 250 components is the max you want without sacrificing much performance… You don’t really get a win by putting baselines in baselines since the underlying Fixlets are just copied over… Maybe make a baseline per year by OS to keep the number of baselines relatively small but keep each baseline from getting too big?
Is there any way to make a baselie run after other baselines have completed? for example, if I have 3 patching baselines and a reboot baseline, is it possible to have the reboot baseline run only after the applicable patching baselines have completed?
Sure. Add a task to the end first baseline that writes a file or registry key and then have the relevance of the second baseline be that the file or key you just created exists. Deploy all 3 baselines and then they’ll execute in order in which you want them to.
Thanks Brian, but I thought of that. The problem is, if the 2nd baseline isn’t applicable, the task to set the flag won’t ever run, so the 3rd baseline will never become applicable.
The workaround would be to force baseline #2 to always be applicable, but then my reporting for the number of endpoints the baseline is applicable on would be inaccurate.
If the task’s relevance is the non-existence of the file or key it’s would be making, that single task in the baseline would be applicable causing the baseline to run even if it’s just to run the task that enabled the next baseline. As long as all the tasks in the baseline have relevance that stop them from running if they’re not needed, then it’ll run the baseline a single time to complete that single task enabling the next baseline. If you need to produce metrics based on how many machines ran the baseline because they needed one of the fixlets, then yes they’ll be inaccurate because the baseline will run on every machine at least once.
I think you could create the ability to have progressive baselines that can also be skipped if not needed but that would mean creating some seriously messy relevance in the second and third baselines. The relevance would need to be the combined relevance of all of the earlier baseline’s tasks/fixlets. So the baseline would only become relevance after all of the items in the prior baselines relevance to false.
if 4 baselines are queued up, constrained to run when a property = True, would the action that was queued up first be the first to run on the endpoint, or could any one of the 4 be the first to run?