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.