The dynamic group membership is determined by the client on the endpoint itself.
So you need to get the data that’s used by the client to determine group membership onto the endpoints.
If you have that done then you can define the dynamic group - which is the rule the client uses to determine if it’s in the group or not.
Any reason you need to use the REST API to define the group ?
Thanks for your answer.
We use our CMDB to define the maintenance groups (for OS updates). The idea was to use the CMDB (or an export of the data contained in the CMDB) to build the dynamic maintenance groups in BigFix.
If I understand correctly, I should create a script that generates a file or registry key somewhere on the endpoints based on the CMDB data. Then I will create a rule in BigFix that uses this file or registry value to add the computer/server to the right dynamic group.
In our multi-OS environment, I believe the script that will distribute this file/registry can be complex.
I was hoping we could use the REST API to directly add/remove the computer/server to the right dynamic groups and reduce the complexity.
If your CMDB is tracking your systems by hostname, you could build the XML for each of your Dynamic Groups, and have the XML include <Relevance>exists ( host1";"host2") whose (it=hostname as lowercase)</Relevance>
Each client would have to evaluate the group relevance and report it back before the computer appears in the group. The Relevance for this directly proportional to the number of hosts; I don’t know if there’s a limit to the length of a relevance statement.
You might also use the API to attach a file to a Custom Site; the file could be a simple format like
host1, group1
host2, group1
host3, group2
The Site File would be downloaded to every client, and you could base the group membership relevance on parsing the file. ‘group1’ Relevance: exists lines whose (it starts with hostname as lowercase and tuple string item 1 of it = "group1") of file "myfile.txt" of client folder of current site
Actually, with regards to the second option of attaching a Site File, you could improve performance by avoiding rereads of the file until it changes. Have a Task that sets a property “MaintenanceGroup”, and base the Group Relevance on its value.
Task: Update MaintenanceGroup Setting
Relevance: if not exists setting "MaintenanceGroup" whose (exists effective date of it) of client then true else exists file "myfile.txt" whose (modification time of it > effective date of setting "MaintenanceGroup") of client folder of current site
Action:
if {exists lines whose (it starts with hostname as lowercase) of file "myfile.txt" of client folder of current site}
setting "MaintenanceGroup"="{tuple string items 1 of lines whose (it starts with hostname as lowercase) of file "myfile.txt" of client folder of current site}" on "{now}" for client
else
setting "MaintenanceGroup"="" on "{now}" for client
endif
Then each Computer Group’s relevance would be something like
Group1: exists setting "MaintenanceGroup" whose (value of it = "group1") of client
Normally, configuring a setting with an effective date of {now} is bad practice, but in this case you need the setting updated when the file changes - not when the action was issued, because you could keep a single open action this way and have the client validate its groups when the file is updated.
I’m doing a similar thing to download a CSV file to the clients defining a lot of settings that are site-specific (name of Splunk server, name of Symantec server, members of Administrators group, etc.) so that I don’t have to update Fixlets/ Resend Actions when site configurations change.
You’ll want to keep the file as small as possible, as there can be a performance hit in that every client has to download the file every time it changes. But I think the XML for the automatic groups you’re trying to create would actually be larger.
I’d suggest staying away from XML and going for csv or JSON - these are much easier to handle in relevance especially in a multi-OS environment.
The JSON inspectors are cross platform as are the line and string ones you’d use for a CSV file.
I query BigFix through the API (query?relevance=(ids of it, names of it) of (bes computers)).
I cast the XML file returned to extract the relevant computer IDs
I build a new XML file that calls a BigFix Action for those computers (the action defines a specific setting/file on the server) then I use the API (method POST) to call the action
Once the action is executed for the list of computers, the dynamic group is populated based on this setting