I know I’m fundamentally misunderstanding something, so hoping someone can take pity on me and give me a gentle slap to the head and explain what I’ve got wrong using words of few syllables.
Scenario:
Bigfix 9.5.9
Machines are members of various automatic groups (let’s call them group1, group2, group3 etc). A machine will only be in 1 of these groups.
A multi-action fixlet is targeted against Group1 (tab Target->Dynamically target by property->Group1). The applicability tab is “Run this action group on computers for whom…the relevance clause from the original Fixlet or Task Message evaluates to true.”
Result: all machines (in groups2, 3, 4, etc) appear to be evaluating the full sub-contents of the action even though the targeting is aimed only at group1.
Is this correct behaviour? Why does the applicability relevance of the sub-action get evaluated even though machine fails the targeting relevance check?
My thought is that by narrowing to Group1 through targeting, the group targeting should evaluate to False on all the other machines who are not members of the group. They would then skip the rest of the multi-action fixlet. I’ve tested the group targeting through the debugger and that is functioning normally.
The top of the relevant FXF looks like this:
X-Action-Component-Type: Group Header
X-Classify-Subsequent-Relevance: Targeting
X-Relevant-When: exists true whose (if true then (member of group <group1_number> of site “CustomSite_My_Patches_site”) else false)
X-Fixlet-ID: my_fixlet_number
X-BigFix-Minimum-Required-Client-Version: 8.0.0.0
X-Report-Criteria: IsOrWasRelevant
— and later:
Subject: MS19-JUN: Servicing Stack Update for Windows 10 Version 1809 - Windows 10 Version 1809 - KB4504369 (x64)
X-Action-Component-Type: Group SubAction
X-Classify-Subsequent-Relevance: Targeting
X-Relevant-When: true
X-Classify-Subsequent-Relevance: Applicability
X-Relevant-When:
X-Success-Criteria: OriginalRelevance
x-group-error-policy: ContinueOnError
Note, this has become apparent due to the lovely MS Windows 10 Servicing Stack patches which seem to take a large amount of evaluation. Looking at the Profiler logs, I can see multiple actions all pointing back to this patch even though the machines are not members of the various groups so the effect of the patch is magnified throughout the evaluation cycle. I’m not looking for help with Servicing Stack patch – that’s a separate issue. Just trying to figure out where I’ve misunderstood how the evaluator is functioning.
I believe this is expected operation. The relevance for the automatic group membership is added as a relevance statement into the action group, which is what you are seeing as the “X-Relevant-When” header at the action group creation time. This allows the action group to apply to any endpoint that was automatically added to the group at a point after the action group was deployed. Likewise, if the endpoint stops being a member of the automatic group, this also means the action group will no longer be relevant and the endpoint will stop evaluating/running the group components.
Doesn’t that mean we’re seeing the reverse of the expected operation?
Machines that are not in the groups are continuing to evaluate the sub-action applicability. I thought the idea was that as soon as you evaluate a FALSE then all other sub-actions should stop evaluation for performance reasons.
I agree with the adding/deleting machines and then things becoming relevant or stopping being relevant. I’m still struggling with machines not being in the group evaluating the subsequent irrelevant actions.
Each of the sub-action IDs match back to sub-actions from actions where the targeting group for that the machine is definitely not a member of (tested on actual machines where the Group Header targeting evaluates to false). In this case all of those high value sub-actions are the applicability for the Windows 10 Servicing Stack updates.
If it evaluated the group level to false (as I expected) it would perform this in milliseconds and I would be happy.
It’s not just 1 affected machine, I’m seeing this on a significant amount of machines in the environment. Obviously the servicing stack update applicability check is slow - but the root issue is applicability targeting for the group seems to work differently to the way I believed it should work.
Why would it continue to evaluate the applicability of the sub-actions after realising it’s not a member of the group? (Apologies if I am misunderstanding your answer).
The group targetting making the baseline not-relevant should indeed stop further evaluation on the sub-action components, but that does not seem to match your findings. I believe you should open a PMR for this as it is not the expected behavior.
I don’t recall seeing anything about this in release notes but it might be worth upgrading one client to 9.5.13 to see whether it’s already been fixed, otherwise it could be a bug.
Phew, I’m not going entirely mad with my observations then
I’m glad that it should work the way you suggest.
I’ve talked to our infrastructure team who are prepping the complete 9.5.13 upgrade so that will definitely be happening however I may just push for a few of these machines to become 9.5.13 clients and see what happens.
If it persists with 9.5.13, I’ll definitely get a PMR raised.
Upgraded a client to 9.5.13 and rebooted - no change
Created a new single instance action (to eliminate it being an issue with multi-actions) - no change
Changed the success criteria - no change
So we have confirmed that machines that are not part of the groups are continuing to evaluate the complete “applicability” and not halting after the first FALSE statement is encountered. This has a significant impact on processing.
I pulled out a web report for all machines reporting within the last 5 days and expanded the Top 10 from Agent Performance Counters. I split the strings into 2 parts (name of the evaluator, time spent) and then pivoted them. The results are enlightening and clearly shows how these action evaluations are having significant impact across the total environment.
I’ve asked for a PMR to be raised and will obviously report back here
Targeting relevance (which is what you have there and show correctly) should be evaluated and block out the entire group if not relevant.
You say its still checking the sub actions? How are you inferring this? It may show up in logs but it would not perform a full relevance evaluation. I presume no action becomes relevant even though the sub action might be relevant to the group that isn’t targeted?
By examining the usage profiler, I can see high usage for machines that are not members of the group. I’ve put examples in the post on 8th July which shows the output from the profiler. In addition the action ID’s are matching the sub-actions (that should never be evaluated). Hope that helps.
Turns out that this is actually by design. We raised a PMR. It’s been investigated and it has now been closed with the statement:
“regarding this case, I would like to confirm you that the observed behavior is a design choice in BESClient: sub actions in MAGs maintain their applicability when a group’s outer level relevance (or targeting) changes the MAG is handled correctly. For this reason, even if the targeting relevance condition is not satisfied, BESClient evaluates the applicability relevance conditions as well. Hope this would clarify.”
