Deploying a BigFix Baseline in Sequence without using Server Automation

Baselines can be a great tool in BigFix. You can simultaneously send dozens of Fixlets (or more) to hundreds or thousands of endpoints and patch every one. When trying to execute tasks on specific endpoints in sequence, however, baselines present various problems—Though each Fixlet executes sequentially on an individual endpoint, the entire baseline executes in parallel on all the endpoints targeted.

That’s why on their own, baselines are dumb. For instance, you can’t tell a baseline to send Fixlets to a specific endpoint and then only send Fixlets to another endpoint when the first set finishes—It’s all or nothing. Sure, you could delay sending Fixlets to another endpoint by “staggering” the deployment, but I would argue that this is also dumb because the process occurs on a schedule regardless of what the previous endpoint is doing.

The methodology

As I mentioned earlier, baselines are dumb because they execute on all “relevant” endpoints at the same time. The key word here, though, is “relevant.” As long as an endpoint is irrelevant or not applicable to the baseline, it is ignored. Fortunately, this is simple enough to accomplish: add a relevance clause to the baseline that will only make a certain endpoint applicable to it.

The trick is to make other endpoints relevant to the baseline in both sequence and in real-time after the action has been taken. The easiest way to do this is to create a “token” that can be passed from one endpoint to the next, thereby ensuring that only the endpoint with the token becomes applicable at any given time.

The Setup

  1. Create a text file with a list of endpoint names in the desired patching order. Add an EOF marker as the last line. It can be anything. In this case I just made it End.

  2. Place this file in a folder within the 'Uploads' directory of the BigFix Root Server (..\BigFix Enterprise\BES Server\wwwrootbes\Uploads\SequencingTasks)

  3. Create a file that will act as the token to be passed (token.txt). This file can contain any text or no text. Just make sure to always use the same copy of the file when executing your sequence.

  4. Use the Fixlet Debugger to find the 'sha1' hash of this file

  5. Copy this exact file to the "c:\temp" folder of the first server in your group. In this case that would be “server1.”

  6. Login to the BigFix Console and create a computer group (manual or automatic) that contains every server in your ServerList.txt file. This limits the servers the action will be sent to at run-time. It is an optional step if you choose to select “All Computers” at time of deployment.

  7. Using the BigFix Console, import the following Fixlet:


Sure, this makes the Systems Lifecycle module all the more enticing. That’s why I like to think of SA as delicious frosting—you rarely eat it alone, but you certainly enjoy it when it is part of something like a cake. However, not everyone wants the figurative cake that is the Lifecycle Management upgrade. What if all you need is “Patch Management?”

Normally I don't like to “re-invent the wheel” when there's already an off-the-shelf solution, but over the past two years I've been asked on more than one engagement how to sequence tasks without upgrading to Lifecycle Management.

When you create your baseline you will either give it a specific relevance clause or leave it as default relevance for all computers”.

In the SA module the sequencing logic is performed at the Root Server level. The process described here, however, leaves the clients themselves to work out the logic of who should be running the baseline and at what time. The process will be slower than using SA because it has to wait until clients evaluate which endpoint has the token before it receives the baseline and the components needed to execute.

As I said earlier—Ugly! but it will work to sequence a baseline deployment to one endpoint at a time.