Unfortunately it does appear to be evaluating the sub-action and thus the cause of my confusion. What I see in the usage profiler logs is:
Start:Mon, 08 Jul 2019 13:20:31 +1000
Elapsed Time:01:01:14
Tracking: Top 100
Samples:2992
Elapsed Evaluation Time:00:41:45
- 216.635: opsitexyz.2682139:Background Evaluation
- 215.875: opsitexyz.2655537:Background Evaluation
- 215.127: opsitexyz.2682215:Background Evaluation
- 211.305: opsitexyz.2655461:Background Evaluation
- 209.763: opsitexyz.2682063:Background Evaluation
- 208.233: opsitexyz.2655614:Background Evaluation
- 208.205: opsitexyz.2653886:Background Evaluation
- 204.412: opsitexyz.2682520:Background Evaluation
- 203.632: opsitexyz.2682368:Background Evaluation
- 203.626: opsitexyz.2681987:Background Evaluation
- 202.888: opsitexyz.2682291:Background Evaluation
- 181.441: opsitexyz.2682063:Background Evaluation
- 2.290: opsitexyz.1876533:Background Evaluation
- 0.771: opsitexyz.2653709:Background Evaluation
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).
