We are trying to build automatic computer groups for things like Windows Computers, Windows Servers, Windows Workstations, Windows Laptops, Windows Desktops and similarly groups for all OS types - Servers, Workstations, Laptops and Desktops. We can build the logic into each group or we can build the main group and the base the sub groups off of the main group.
From a performance perspective, is it better to nest Automatic Computer Groups or keep them self contained?
We are trying to build automatic computer groups for things like Windows Computers, Windows Servers, Windows Workstations, Windows Laptops, Windows Desktops and similarly groups for all OS types - Servers, Workstations, Laptops and Desktops. We can build the logic into each group or we can build the main group and the base the sub groups off of the main group.
From a performance perspective, is it better to nest Automatic Computer Groups or keep them self contained?
How do you nest groups? I thought it wasn’t possible?
We build a base dynamic computer group (ex: Windows Systems) and then we build another dynamic group (ex: Windows Servers) that has one property set to “Group Membership” “is member of” “Windows Systems” along with another property “Relevance Expression” “is true” “product type of operating system = nt server product type”.
The goal is to somewhat duplicate what we had in Systems Center Configuration Manager.
RANT: Honestly, What I’m trying to do is build a set a basic groupings for targeting and reporting. I REALLY wish BigFix would include these out of the box. There’s no value in what I would guess is 90% of their customers recreating the same basic groups.
I want to be able to create a groups called “US”, “Latin America”, “Asia Pacific”, and then be able to put groups INSIDE of those. That way, I can let me administrators in those areas, create groups inside and NOT clutter up the group list.
I second TommyG’s suggestion about being able to set up groups in a hierarchal structure. We’re really just getting started with scratching the surface of what BigFix can do and we’re already piling on the groups.
Nesting. Yes, that would be even more appealing. Then I wouldn’t have to worry about building in parent group logic or duplicating the parent group logic. Assuming the nested groups were completely based off the parent group - not just a visual nesting. Someone add this to the feature list!
Properties have the ability to allow flexible selection from the tree view… can you use properties for these examples that you mention?
Another way to put it is that I am not sure I understand why you would ask for groups based on OS, server type, etc. when those are out-of-the-box properties that allow simple selection, targeting, filtering.
When we patch clients, we create a group. I have over a few hundred different lines of business, who send me lists of clients to patch and reboot at a particular time. I create groups for every patching excersize. You can imagine how many groups are created it’s ugly.
There are not enough properties available for groups. For fixlets and tasks, there ARE good properties, but not groups.
If people send you different lists for different patching cycles, why would you create a group for them rather than just pasting the computer names into the action when you apply the patches?
We use the groups for targeting well and would like to have systems assigned to them dynamically. Instead of creating the logic in every single task or fixlet, we’d rather have it on the automatic group.
It’s much simpler in our minds to do things based off a group versus having logic buried into every fixlet, task, report, etc.
We also use them to assign BigFix operators the ability to manage only those computers.