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.
This is where Server Automation (SA) comes into play. Whenever I’m asked to describe SA in a few words, I usually say, “It’s baselines on steroids.” SA’s Automation Plans (the module’s equivalent to baselines) allows you to send specific Fixlets to specific endpoints in a specific order. In the past, if you just wanted “Patch Management,” you could opt to buy SA as a standalone module, but not many people took the option. As a result, it’s now bundled as a part of the “Systems Lifecycle” module.
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.
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.
For the purpose of simplicity, I’ve chosen specific file and folder names that illustrate their purpose, but the files and folders can be named anything as long as they are referenced exactly in the Task.
It’s an ugly process, but please feel free to take what you find useful from here. Additionally, I welcome feedback that will improve this process.
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.
- Place this file in a folder within the 'Uploads' directory of the BigFix Root Server (..\BigFix Enterprise\BES Server\wwwrootbes\Uploads\SequencingTasks)
- 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.
- Use the Fixlet Debugger to find the 'sha1' hash of this file
- Copy this exact file to the "c:\temp" folder of the first server in your group. In this case that would be “server1.”
- 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.
- Using the BigFix Console, import the following Fixlet:
- You must register to be able to download the file in .bes format. However, if you don't register you can still see the contents of the action script and copy it into your own console task.
- After you import the Task make sure you fill in the necessary fields within the action script (SERVICE NAME / BES ROOT SERVER NAME / USERID / PASSWORD)
- Edit or create the baseline containing the Fixlets you will deploy.
- Add this task as the last component in the baseline. If at all possible you should add a generic “reboot endpoint” task just before this one to make sure that the patches in your baseline were completely applied. If you are patching an IIS or SQL cluster, then you will want to make sure that the appropriate service is up before you move on to the next server in the sequence.
Make sure you check the box on the task that makes the baseline relevant when the specific component is relevant:
NOTE: When you create your baseline you will either give it a specific relevance clause or leave it as default relevance for “all” computers. Whatever the case, make sure you add a second relevance clause that will make it applicable to only the computers with the specific “token.”
Two things to remember:
1. The actual sha1 value will differ from the file you select as the token, so make sure to change it in your relevance.
2. Make sure to select the “ALL” operator on the relevance tab so that computers must meet every condition to be considered relevance.
Once these steps have been taken, you are ready to deploy. By now, the first endpoint in your group (the one you copied the token.txt file to) should be showing as applicable to your baseline.
- Select the baseline and “Take Action”
2. Select “Dynamically Target by Property”
3. Select “By Group” and choose the computer group you created earlier.
4. Click OK.
The baseline will then execute on the first endpoint in that group (the one with the token), and the last task in the baseline passes the token to the next server in the “ServerList.txt” file. Within a few minutes, that server becomes applicable to the baseline and executes. This process repeats until the baseline runs on the last server in the list. It will try to find the next server name to pass the token to and will run into the “End” line of the ServerList.txt file. This indicates that it’s reached the end of the list, and it stops the baseline from executing on any other endpoints.
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.