why is it so difficult to get a list of computer groups in client relevance?
Trying: (settings of client) whose (it as string as lowercase contains “group” and it as string contains “=True”)
Seems to return everything from the settings/client hive of the registry… But it’s missing group memberships. For instance, I can see group X under “Computer Group Memberships” in the computer details (console)… But that group “setting” does not exist in the registry and of course is not returned using the query above. The registry seems to have a mix of manual and automatic groups, but is missing some. Why???
IS there a reliable way to get a list of groups by name? I want to check for group membership using regex to match as in:
exists ((settings of client) whose (it as string as lowercase = (regex “_group.*mw_win\d(st|nd|rd|th)(sat|sun|mon|tue|wed|thu|fri)\d\d\d\d.*=true”)))
… but that all hinges on “settings of client”, which isn’t giving me some groups…
seems this should just be a simple client inspector…
It’s my understanding that membership in a manual group is governed by a specific client setting that happens to share the name of the manual group. For instance, creating a manual group called “New Manual Group” with specific members actually creates actions in the background that push out a setting called __Group_0_New Manual Group to the clients in the group. This is why you see manual groups in the registry.
I do not believe automatic group membership is actually stored in the registry.
Here is some relevance that will get you the names of all the computer groups the computer is a part of:
values of headers "subject" of relevant fixlets whose (value of header "X-Fixlet-Type" of it = "ComputerGroup") of sites
You can modify sites to be more specific with site <string> (the name of the site).
This breaks down into pulling the sites in memory on the client:
sites
Get the relevant fixlets in the site:
relevant fixlets of <site>
Filter out everything except for computer groups:
relevant fixlets whose (value of header "X-Fixlet-Type" of it = "ComputerGroup") of sites
We now have all of the groups the computer is a member of (relevant groups).
Get the title of the computer groups:
values of headers "subject" of <fixlet>
Some caveats…
You should be careful doing this – normally a reason people try to do this is to put computer groups in fixlet/baseline relevance instead of targeting the group.
In addition, by using the name of the group instead of the ID you run into a particularly volatile situation that folks may not be use to where changing the name of something in the console can actually break something on a client.
That is all session relevance, correct? I’m referring to client relevance… I need to be able to figure out in client relevance MY group memberships.
We have a very specific naming convention for maintenance window groups and I need to see when a computer is no longer a member of ANY of those groups… or IS a member… by name pattern (regex). I don’t want to use group numbers and have to maintain that. Assuming a strict naming convention is in place and adhered to, using the name is MUCH simpler.
There has to be a way in client relevance (and hence in action script) to query membership…
Yep! That seems to work… But it’s only getting automatic groups… So to get ALL groups, I’ll try combining the values with ; and reference the combined values using it / whose and see what I come up with…
(unique values of it) of ((values of headers "subject" of relevant fixlets whose (value of header "X-Fixlet-Type" of it = "ComputerGroup") of sites); (if exists ((settings of client) whose (it as string contains "__Group_0_" and it as string contains "=True")) then (following texts of substrings "__Group_0_" of preceding texts of substrings "=True" of (((settings of client) whose (it as string contains "__Group_0_" and it as string contains "True")) as string)) else "")
// Checks for a group matching regex:
exists ((unique values of it) of ((values of headers "subject" of relevant fixlets whose (value of header "X-Fixlet-Type" of it = "ComputerGroup") of sites); (if exists ((settings of client) whose (it as string contains "__Group_0_" and it as string contains "=True")) then (following texts of substrings "__Group_0_" of preceding texts of substrings "=True" of (((settings of client) whose (it as string contains "__Group_0_" and it as string contains "True")) as string)) else "")) whose (it as string as lowercase = (regex "win.*")))
You can slim down the relevance a fair bit by taking advantage of the, name of <setting> and value of <setting> properties as well as taking advantage of the fact that plurals provide error handling without if/then/else statements.
For instance this:
(if exists ((settings of client) whose (it as string contains "__Group_0_" and it as string contains "=True")) then (following texts of substrings "__Group_0_" of preceding texts of substrings "=True" of (((settings of client) whose (it as string contains "__Group_0_" and it as string contains "True")) as string)) else "")
Can be simplified to just this:
following texts of firsts "__Group_0_" of names of settings whose (value of it = "True") of client
Which would bring our final relevance for both automatic and manual group membership to:
(values of headers "subject" of relevant fixlets whose (value of header "X-Fixlet-Type" of it = "ComputerGroup") of sites);(following texts of firsts "__Group_0_" of names of settings whose (value of it = "True") of client)
Next we can get the unique values and perform a regex match to determine which match our criteria:
unique values whose (it as lowercase = (regex "win.*")) of (values of headers "subject" of relevant fixlets whose (value of header "X-Fixlet-Type" of it = "ComputerGroup") of sites);(following texts of firsts "__Group_0_" of names of settings whose (value of it = "True") of client)
Strawgate, Is there a method to deploy a baseline to all computers that are relevant for it EXCEPT those that appear in a Manual group, utilizing this method?
In our 9.5.14 environment, actions using this relevance based on @strawgate’s are NOT relevant for respective computers:
(exists (values of headers "subject" of relevant fixlets whose (value of header "X-Fixlet-Type" of it = "ComputerGroup") of sites) whose (it as string starts with "Special Group"))
Actions using the following are relevant (“relevant fixlets” changed to just “fixlets”) for respective computers:
(exists (values of headers "subject" of fixlets whose (value of header "X-Fixlet-Type" of it = "ComputerGroup") of sites) whose (it as string starts with "Special Group"))
What’s really weird about this is that the first string of relevance should evaluate True on the computers in question, and it does using the Fixlet Debugger:
Q: (exists (values of headers "subject" of relevant fixlets whose (value of header "X-Fixlet-Type" of it = "ComputerGroup") of sites) whose (it as string starts with "Special Group"))
A: True
T: 0.033 ms
I wonder what we’re missing here.
EDIT: After a 9.5.15 upgrade, we are getting the same strange result.
Client’s background evaluation shouldn’t allow inspecting ‘relevant fixlets’ to contribute to the relevance of fixlets/actions as this may lead to unstable relevance expressions (e.g. “number of relevant fixlets < X”).
Inspecting ‘relevant fixlets’ for property evaluation should be possible instead, and that’s why it’s working with the Fixlet Debugger.
The inspectors can provide important information about the fixlets at any site. These inspectors only work in the context of property evaluation, not Fixlet evaluation.
This tripped me up years ago when trying to automate site unsubscription based on “no more relevant fixlets in site A”. Had to use a policy action to get around it. Pain has a great learning curve.
I’ve accidentally set up site subscription such that membership of the site excluded you from it. This meant computers would add and remove themselves from the site continually FOREVER. So… don’t do that.
There are some clever possibilities, but you have to be careful about it. Surprisingly, not all of the worlds problems can be solved with a single overly clever Relevance statement, but I try anyway.
Hi, apologies for jumping this far back but I was curious as how to write the relevance for only manual groups?
I know Manual Groups are not the best, but my company requires machines to be separated by them and I am fairly new to BigFix. Hoping to have this property added for reports to customer with what manual groups they are in.
