A best practice question regarding software distribution to Windows clients, coming from a background in SCCM.
Is it reasonable to create groups using detailed relevance, and target these with actions where “relevance = true”?
I ask because I am struggling with software deployment tasks where clients show up under applicable computers (so the various relevance statements return true), however after downloading and evaluating the task does not run because “targeted computer reported this action non-relevant” (so the relevance returns false, evaluated on the client).
The tasks do run if I set relevance = true (remove any complex rules), so I’m wondering about using groups like SCCM collections, with relevance filters (SCCM membership rules), and targeting actions to these groups without any further relevance statements in the tasks themselves.
All relevance statements were tested using the fixlet debugger, but tests on VMs don’t seem to mirror results on actual client PCs with their own history.
I can see that storing the relevance in the group rather than the task adds at least one extra round of evaluation befor a client gets a task, so a slight performance issue there.
It is best practice to keep your fixlet/task relevance as representative as possible to the true applicability of that item. So you definitely want to include checks that are appropriate for the software being deployed. At minimum that would include OS and architecture, but should ideally include pre-req checks and a check that the software isn’t already installed.
You can also create computer groups for targeting, but they should not replace fixlet relevance, rather provide additional filtering down to the set of computers you want to try and run the task.
If you’re seeing computers showing applicable for a task, but then report non-relevant when the task is deployed to that computer, it means that the applicability results for that task is out of sync between the server and the endpoint. This should only occur if the BigFix server was restored at some point or if your Console cache is corrupted, such that the client believes it has reported the latest status, but the server/console has an older status.
Moving the task relevance to a group won’t fix that problem, but sending a refresh to that particular endpoint or clearing your console cache will. If you’re seeing this fairly widespread, try the console cache reset because you don’t want to trigger a lot of client refreshes at once (it creates a lot of load on the server).
If you believe the endpoint should actually be relevant for this task with the given relevance, then you’ll need to investigate on that endpoint which part of the relevance is false using fixlet debugger locally, or BigFix Query remotely. There may be some adjustments needed to account for real endpoint variation vs a clean lab system.
Thanks for the input, I hadn’t realised the role played by the console cache.
I understad fixlet relevance to be a kind of “desired state” expression, and that when the client is “fixed” then the task is no longer relevant. It follows then that the relevance statements should stick to the fixlets, and groups are for organising clients around their common attirbutes.
I will look into how the client does verbose logging, and see if I can retrieve log files to the server. I suspect there is no substitute for testing relevance on real machines, my problem here is that I cannot reach these clients to dig deeper.
If you have access to our BigFix Query solution in the WebUI, you can submit relevance to any remote endpoint in your deployment. Alternatively, you can create a custom analysis with properties for each section of relevance from the task, and then get true/false results back from any number of endpoints that you make that analysis relevant to.