One other suggestion is to delete the folder C:\Users<userid>\AppData\Local\BigFix\Enterprise Console<server name> then start up the console. I have seen in rare occasions that the local cache gets corrupted and the Clear Cache does not fix it.
Next I would look at the bes client log file when you deploy the fixlet and see what it says.
I guess the other question is, does it need to be applied or not when you manually try it?
Depending on the relevance for the action it may become non relevant when another install is going on. This would be something like detecting the msiexec is running or another item.
The bigger question would be if the actions you had shown as relevant when you took it didn’t run. Is that the case?
Could you upload a log file so that we could review what is happening on the agent side? It is often helpful to review the information within the agent log file.
-Jgo
I’ve seen this before as well. In the cases where I’ve seen it, the system is truly Not Relevant for the content (which is easily checked by running the relevance through the Fixlet Debugger on the affected clients.
I’ve also seen cases where the client is Not Relevant to a fixlet, but shows Relevant to that same fixlet as a baseline component. Maybe it has to do with busy clients, large baselines, and long site evaluation cycles.
In the cases I’ve seen, this is usually resolved by right-clicking the nodes in the console, and performing a “force refresh now”.
Baselines underwent a bit of a fix in 9.1 to make them more “correct” with their targeting so perhaps the baseline issue you are referring to isn’t still around.
Remember though, Force Refresh causes the client to re-evaluate ALL content and produces a full report. This can significantly tax the infrastructure if you do it to too many machines, such that if you did it to a large deployment it may take a significant time for the infrastructure to recover from it.