Something I’ve been curious about for a while, but have not had issues with until recently. If I create analysis, I can set the time frame for it to be evaluated, but there is no such setting for fixlet relevance. I have a set of fixlets, one which uninstalls older versions of sysmon and another which installs the newest version of sysmon based on relevance which tests to see if the sysmon service exists. I have also created some analysis to query the existance and versions of sysmon on all endpoints. Once the uninstall fixlet runs, analysis confirms that the sysmon service no longer exists on the endpoints, but the installer never becomes relevant. If I start a new installer (take action) it will be relevant and run the installer on the same systems. Not sure what I am missing here?
The relevance for the analysis and the fixlet are identical:
not exists service whose (it as string as lowercase contains “sysmon”)
Possibly this needs the “reapply this action -> when it becomes relevant again” setting? Does not really make sense.
When you say “never becomes relevant” how long have you waited? What is the avg agent cycle time on the endpoints?
Generally speaking for the relevance of the fixlets to change it requires the agent to go through the reevaluation of ALL fixlets which depending on the number of content; CPU cap on agent side; avg agent cycle times; etc may take a while. Properties on the other hand, once first propagated are just evaluated at the required intervals and they would pause the cycle to do it if required (which in itself can delay the cycles),
What are you after here? The fact of the matter is if you just want to see it relevant to the 2nd task it may take a while BUT if your intention is to deploy asap you don’t have to actually wait at all… You can add the two tasks in a baseline and as soon as the first task is completed it will force the agent to check if the 2nd has become relevant and continue with the execution; if you want to “force it” to show as relevant you can use “send refresh” and that will also reset the entire agent cycle; so on. Question is what do you want to achieve from the reevaluation, so best steps can be advised.
Are both fixlets part of the same site(s)? Are the systems applicable to that same site(s)? How about site location for the analysis?
Not sure about average cycle time, but when I initially set this up there was 36+ hours between the time some of the systems showed the uninstall to have been successful and the time I ended the current install action and stated a new one. The same systems became relevant to the newly created action within minutes. The idea here, I guess was that I could create a fixlet which would install sysmon on any endpoint where it did not exist and target “all computers.” Then I could run an the uninstaller fixlet and target various groups. Once the uninstall happened, the installer fixlet would install the newer version on these machines. I have done this sort of thing before without issue. This is not something that is causing serious issue, as I can always creat another install action each time I creat an uninstall action, but honestly, this is such a simple thing that i’m surprised I am having issues. Maybe I am missing something obvious?
Yes all endpoints and actions are in the same site.
Evaluation time does not care if it is 36 hours or not. If the polling time is set to 20 min and the eval time takes 30 min, your eval will never finish because it is being interrupted every time the system polls, and it starts over.
Check the poll time
Then run these on the machines.
((maximum of it /1000* second)/minute) of evaluationcycle of client
((average of it /1000* second)/minute) of evaluationcycle of client
track fixlets of evaluationcycle of client
value of setting "_BESClient_Comm_CommandPollEnable" of client
If that returns a value of 1, it is turned on
value of setting "_BESClient_Comm_CommandPollIntervalSeconds" of client
I often see some of my staff create a fixlet that takes a long time to run, and it runs longer than the eval time, causing it to never, or rarely finish it’s eval.
For a lit of settings, you can see those here…
https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Config/r_client_set.html
Checking this now. My question would be why creating a new action for the same fixlet would give a different result.
Yeah, I am at a loss for that
I think we’re are mixing terms. Usually we still about a Fixlet/Task being Relevant, which is just based on the relevance statements of the task/Fixlet.
I think you’re mostly describing the Action applicability though - which is based on both the original Fixlet/task applicability, as well as whether the action was targeted against the machine, whether the action has already executed, etc.
If sending a new action from the same source Fixlet is working, then what you likely need to set are the Retry or Reapply options in the ‘Take Action’ dialog.
You probably need either “Reapply whenever it becomes relevant again”, or “Reapply while relevant, waiting X minutes between reapplications”.
You can use the first case of the original Fixlet toggles to Not Relevant when you run the action, and then switches back to Relevant later. Like, if you wanted to repeatedly remove Chrome every time the user reinstalls it. This task is Relevant when Chrome is installed, executing the action removes Chrome and toggles the Fixlet to Not Relevant, and if the user reinstalls Chrome it becomes Relevant again and the action re-executes.
You’d use the second option if the original Fixlet does not switch to Not Relevant when you run the action. Like if you wanted to execute an Inventory scan once a day. The Relevance for the task is just “I have Inventory Scanner installed”, and that does not change to ‘Not Relevant’ after executing a scan…you need this task to "Reapply while relevant, waiting 1 day between reapplications’
If you don’t specify any reapply at all, the action runs exactly one time and never tries again.
Going to do some experimenting.