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.
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 not relevant 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.
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.
Note:
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.
The Execution:
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.
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.