We have a patch policy with a schedule using group targeting. In the console, the group shows 59 devices. 12 of the devices have not been seen in greater than 5 days.
When the multi-action group is generated, 36 devices are shown as targeted. What could be the reasons why not all of the 59 are targeted?
I think I did read somewhere on this that the relevance for the group is re-evaluated on each device. But, I’d expect each device to consistently maintain that relevance.
The target group relevance:
(version of client >= “6.0.0.0”) AND ((exists true whose (if true then ((Exist settings “CLO_STAGE” whose (value of it as string as lowercase = “Prod” as lowercase) of client) AND (Exists true whose (If true then (exists (operating system) whose (it as string as lowercase contains “Win” as lowercase)) else false))) else false)) AND (not (exists true whose (if true then (member of group 127975 of site “CustomSite_SEC_-2d_General”) else false))))
group 127975 is an exclusion group that is currently empty (relevance for this group is set to false) right now.
I would think that even devices not seen in 5+ days would be targeted. They just might miss the action since they were powered on. Are devices excluded from the target due to relevance of the individual components (not relevant for the any of the patches in the policy).
Do any of the WebUI logs show this detail? I did look in …\BigFix Enterprise\BES WebUI\WebUI\logs but it didn’t seem to explain how the targeting logic was done. I didn’t try verbose… wanted to check here first. Thank you!
Firstly, you need to understand why there are some group members that have not reported recently. If the client is active but no longer meets a of the requirements it will remove itself from the group, so you do need to know whether the clients in question are somehow broken, no longer live or temporarily off your network.
Secondly, the action relevance had to be evaluated on each client. Those clients that have not connected to your Bigfix infrastructure will not know about the action and will not have reported relevant.
Thirdly, clients that are active and members of the group, but not applicable to any of the component actions will also not report themselves relevant to the action.
The server does not work out which clients ought to take the action, it merely makes the action available to any interested client and the client evaluates the relevance on the action and each component to decide whether the action is applicable.
I have a more specific case as a follow-up. And a more specific question: Is there a defined “last report time” threshold for a device in a target group to be excluded from a patch policy action?
Sample scenario:
Patch Policy and schedule includes a target group of 20 devices. All of these devices are cloud VMs (AWS/Azure). Because they are non-production, they have some automated power-on/power-off schedules managed through cloud tools.
New patch content arrives on root server on Wednesday after patch tuesday.
Patch policy is auto-refreshed Wednesday evening (7pm).
Device A is the target group and but it powered off all of Wednesday and comes online at 3am Thursday. Device B is powered on during Wednesday, but is powered off at 1am on Thursday and comes back online at 11am Thursday.
Patch policy action is started at 2am Thursday and lasts until 9am Thursday.
Expected outcomes (please confirm my understanding or ask additional questions to clarify):
Device A will NOT be included in the patch policy action since it did not have a chance to report back to the server that it is relevant to the new patch content on Wednesday that was now included in the refreshed policy.
Device B WILL BE included in the patch policy action since it did report back as relevant to the new patch content. It had been offline for 1 hour before the patch policy action was issued at 2am.
What if device B was offline for 2 hours before the patch policy action was issued? Again, does the time offline matter for the device to be included in the policy action? If it does, what is the threshold?
Patch Policy actions issued to a group are using dynamic targeting, which means the action is issued to all devices that an operator administers, and not individually to computers.
Any devices that meets both the following criteria:
is part of the targeted group(s)
is relevant to any patch fixlet in the action
will gather the operator site (opsite), look at the dynamically targeted action from Patch Policy, and the device itself will check the criteria and run the action if it meets the criteria. Of course, the device would need to be turned on at some point during the active time of the action. Both Device A and Device B will be included in the patch action in your scenario.
Caveat: there is an optimization in Patch Policy where the action only includes fixlets that are at least relevant for one device for that operator, at action issue time.
Assuming that Device A and B are the only devices that the operator administers, Device A has never evaluated any of the new content, since it has never been powered on Wednesday and before the action issue time. Device B was turned on Wednesday and has reported back its applicability to the new content, even if it is technically offline during the action issue time. The Patch Policy action will only contain fixlets that are applicable to Device B, but both Device A and Device B will run the action (assuming there is at least one fixlet applicable to Device A).
EDIT: Device B will not run the action at all, since it is not on during the entire patch window. I got the times mixed up in my head. But Device A will run the action since it is on for at least some part of the patch window.
In addition, since the Device B is offline the whole patch policy scheduled window, it cannot receive the action and evaluate it; as soon as the action expires, the clients never evaluate and report back. So, Device B won’t be included in the action result, due the dynamic targeting.