What do you wish you knew when you first started using BigFix?
What are some “Best Practices” for using BigFix?
I’m doing a “Meet the Experts” session in the Expo at the Interconnect 2016 conference coming up. I expect there to be a mix of people with many different levels of experience with BigFix, and even those with no experience. I hope for the presentation to be a bit dynamic and discussion based, but it would be good to have some specifics to go over as well.
Long term I hope for this post to be a place where others and myself can compile some “Best Practices” as well as links to other posts that represent “Best Practices”.
I think one of the confusing things that comes up when I’m teaching people BigFix (or working with existing BigFix users) is the fact that fixlets/baselines/actions are just copies of the content from when that baseline/action was made and that just because you update the baseline doesn’t mean the action is up to date.
Also, the difference between a task and a fixlet is one of the harder things to grasp because for most people it doesn’t matter until it does
Yes, this definitely comes up. It makes sense it is the way it is for auditing purposes and so that one person doesn’t take an action while another changes what it does, both affecting each other in a non-obvious way.
This one is a bit odd too. There really isn’t a difference, except that there is, and it is really about default behavior.
We often create something as a fixlet or task based upon organization within the console, and not normally about the desired behavior since most of our custom content is designed to be considered successful when the applicability relevance evaluates to false.
Generally I tell people that a fixlet should be something that is expected to be remediated, while a task is optional or repetitive, but ideally all content would have good relevance that goes to false after it completes if possible.
I wish I had remembered to keep my license.pvk and license.crt files as well as the password for it in a secure place (apart from the BigFix server). And that admin who left the company, I wish I could have trusted him not to have changed the password on it or left in a disgruntled manner without sharing it. Or at least causally verified the password before firing him.
I wish I would have backed up my BFEnterprise database on a nightly basis, had confirmed it was being backed up, and verified I could restore from the backup if necessary.
I wish I had known about Send Refresh abuse and the steps to take to prevent it so that I didn’t have to go through these mysteries times of computers graying out and the filldb bufferdir getting backed up: http://www-01.ibm.com/support/docview.wss?uid=swg21688336
I wish I had set all of my relay’s (and the main server’s) download caches to something greater than the 1GB default so that my downloads would not take forever or cause my corporate network’s bandwidth to suffer because of multiple downloads of the same file. Knowing that I could pre-cache the files ahead of the action executing would have been good to know as well.
I wish I had planned out my deployment of relays and select method smarter than I did. I didn’t realize auto relay selection depends on ICMP messages and parts of my deployment do not allow ICMP traffic
I wish I had setup a test environment and tested things before executing them in production. And when I had gone to production, I wish I had deployed the new stuff in a narrow and incremental stepped approach.
I wish I had known never to re-import actions that had been exported from the console (even through BigFix allows this). Even actions that were in a Stopped or Expired state when re-imported would re-activate and re-execute. It would have saved me from having to explain lots of things to management. And saved me the time to clean/re-deploy/reset relays and clients to purge the undesired actions from them.
Task:Successful/Completed when all lines of the action script complete successfully
Fixlet:Successful/Completed when the relevance evaluates from true to false after the executing of the action script (or restart of the endpoint machine as is the case with Windows patches)
Yep, it is about the default, but you can change one to be like the other, which makes it even more confusing.
The other thing that trips people up is that when a fixlet is added to a baseline, it makes the whole baseline relevant by default, while a task does not, regardless of what the success criteria is of the task or fixlet itself.
I think a huge number of infrequent operators don’t realize that with the BigFix architecture almost every change you make in the console actually causes a change on an endpoint. I think it’s a well kept secret from auditors, etc that you don’t need to deploy an action to freeze an endpoint with sha1 of descendants of folder "C:\" hidden in an analysis or a well intentioned master operator doing sum of sizes of folders of folder "C:\Windows\Temp"
Or my other favorite:
From a production environment – grabs the last two hundred lines of SWD_DeploymentResults.log. When you have 3000 lines this takes 20ms but when you have 30,000 lines this takes >30 minutes. It opens and reads the entire file once for every line in the file.
Right actions taken from baselines do not update when you update the baseline, which is good in a way because if someone is fiddling about with a baseline you would not want the change to the baseline to propagate to the endpoints until the baseline editor was sure the change is something they want.
It would be nice however to have a button that would allow the editor to propagate the changes to the baseline to all the actions based off of the baseline. But even then what if one baseline action was targeted to one group of computers to execute at one time and another action was targeted to execute at another time. So this new update-propagation functionality would need to allow the baseline editor to choose which actions to propagate the changes to.
Keeping it simple, we basically say, if you make a change to a baseline and you need to re-deploy this new baseline on, take a new action.
ouch! yeah that would hurt. Every change in the console updates a piece of information in a site whose differential is gathered by the clients on their next gather.
Normally we see excessive SWD logs because an application has verbose output on the command line during installation – all it takes is the analysis to hit before the task does (if you even remember to use that task) and your client is locked for 30+ minutes – that was just a fun example of: good intentions == hung clients
Mike’s advice is correct. For something like the Trend CPM policy actions, or for that matter any policy actions that are critical to the functionality of a BigFix product it is best to have a master console operator take action on them and thus keep them in the master action site.
Things like large baseline actions and software distribution jobs though are best to be done by non-master console operators, keeping them on opsites.
With mailboxing starting in version 9.0 the tipping point of an inefficiently large actionsite is slowed. I notice a difference in the amount of cases we are getting in support. I haven’t pinned a large actionsite as the root of evaluation problem on the endpoint since before 9.0 was released.
Also recommend operators perform their Windows patches in a 4 hour patching windows rather than trying to squeeze them into a 2 hour window, even with a very tuned deployment 4 hours gives plenty of time for the patches to complete. Opinions may very on this.
The only thing is, if MS has a surprise reboot required in one of the patches it could disrupt the end user’s work. It would require having a “patching culture” in place in the company. “Every such and such a day of the month between such and such a time is when we apply patches to the endpoint”. In that way everyone knows it is coming.
Not to mentioned if an operator fat fingers something or deploys something they should not in a manner they should not…
That would be a bit of a problem, but it generally isn’t.
This is a little complicated since a machine may not be awake at the time, so it isn’t going to get the patches at a predictable time, but generally it is a good idea to have a consistent time when patches are deployed that everyone is aware of even if it doesn’t end up all happening at that time.
It is in some ways more important for the helpdesk staff to know when patches are expected to happen rather than users so that if users report problems, then they have a better idea of that it may be due to patching. Ideally users wouldn’t need to know about things at all.
This is a great question. I’m sure I’ll have more but I’ll start with this …
I wish there was a (youtube) video that would walk me through the basics of the relevance language. When I have to debug why the ILMT “Initiate Software Scan” task isn’t relevant, for example, knowing relevance language would be very helpful.
