Does anyone know why our BigFix shows an Action either completed or not relevant in one screen but in the screen where Relevant Fixlets are displayed, it still shows the computer needing that fixlet(s)? This is driving me crazy, as soon as an Action completes it would be nice if the fixlets dropped out of relevancy for any machine that successfully ran the fixlet. What cause this? Is there a troubleshooting tool for this? I really need completed Actions to sync up immediately and show the correct data because I run reports all day and when fixlets show as relevant when they actually are not, my reports are screwed up. I need someone to explain what I can do in plain English. I appreciate any help.
Do the computers that still report as relevant eventually figure out they’re not relevant and drop off the list, or do they remain relevant? If they remain relevant, my guess would be that either 1) the fixlet didn’t actually complete successfully or 2) the success criteria and/or relevance for the fixlet is incorrect.
If it’s the case that the issue is just that computers take longer than you’d like to drop off the list of relevant computers, you might want to check on their communication health. Can they receive UDP pings? If not, is persistent connection enabled? What is their average evaluation loop time?
Computers cannot drop off “as soon” as the action completes, because they need some time to communicate back up through the relay infrastructure to the server that they are no longer relevant for that piece of content. It should be pretty quick though.
One other thought – maybe clear your console’s cache? Are there other operators also seeing this issue?
Sorry for the million questions, but I think we probably have to narrow down exactly which moving piece is the issue before we can solve your problem.
Fixlets the client has already evaluated are “old content” and are re-evaluated as part of the normal client loop.
New fixlets (including new actions) are “new content” and get moved to the front of the client’s evaluation loop. So the client will report action status with a higher priority, but doesn’t go back to evaluate the original source fixlet until that fixlet’s turn comes back through the loop.
One way to make the client move through its evaluation loop more quickly is to increase the cpu utilization on the client. By default the client is throttled to only use 2% of one processor core, so it runs in the background without interfering with anything else running on the computer. You could increase that throttle to let the client evaluate content faster, at the cost of using more CPU on the client.
Another thing you could do is to force the client to refresh. This checks that the client has the latest version of every site, re-evaluates every fixlet and analysis property, and sends up a full report. You shouldn’t do this frequently as it puts more workload on the relay and root server, but if (for example) you need a full re-evaluation after a monthly patch baseline, you could include a task at the end to force a full evaluation. You can do that with the actionscript command notify client forcerefresh