Filters yes but for most of users it will be not as simple as manual group.
any further thoughts & suggestions please.
I’d suggest looking here
Specifically
> disableNmoManualGroups
If set to "1", NMOs cannot add or remove computers from manual groups, and see manual groups that none of their computers are members of.
3 Likes
Thanks but still question remain what would be the alternative if we take away manual groups
There is no alternative really.
You have filters, auto computer groups or doing something in web reports 
There is one other BigFix Console group functionality: “Ad-Hoc Groups”.
A simple grouping technique is to manually select members of a group from the listing in the Computers List Panel. For a quick look at a manual selection, click View as Group from the right-click context menu. This opens an Ad-Hoc Computer Group document in the Work Area where you can quickly analyze various properties of the group. Ad-hoc groups are temporary, and only exist while the Ad-Hoc Computer Group document is open.
2 Likes
Or the practice I hate the most (and see most often): a spreadsheet of hostnames that get copy & pasted into the manual target list of an action.
4 Likes
I already aware about thats and its really good to use add hoc but when we are talking about grouping part user love to have manual group so that they can use it for multiple times, thus looking for similar process but not using manual groups, and still want group to be created on client.
Describe what you want the operators to be able to do, because I’m not understanding your requirement, other than that Manual Groups are forbidden.
1 Like
I usually add a several custom client settings (like Location, Datacenter, Owner Group, System Role), create Tasks to set values on them, and use ‘Target By Property’ to select the right values amongst those properties. One could also create dynamic groups based on those client setting values.
Yes I am focused on taking manual group functionality from operators but also giving them some best options to ease their task.
As of now what I have got is -
- Custom filter - it will be more complicated for operators
- Ad hoc - we have restricted operators to use custom actions but given blank task to create ad hoc group but thats not help them for permanent groups.
- Custom properties - as of now we have many custom properties if we enabled this for their day to day activities there will be thousands of properties can be created by users, thats we cant handle
And counting…
Not sure what you’re looking for…you’ve ruled out both manual groups and automatic groups; external references to computer lists, and dynamic properties stored on the client. I’m not sure I understand the issue.
1 Like
The requirement is to facilitate the grouping of seemingly random machines - they’re not completely to the operator, but appear that way property-wise - without allowing it through the creation of manual groups, which are apparently the devil. For example, an operator may want to test the deployment of some new software to only the machines of the 15 local IT staff in his region. This may be a recurring requirement. A manual computer group makes sense for this, as it is easy to create; easy to target; and can be reused.
An idea would be to create a “Custom_Group” client setting, for example, that they could set on any target group of machines to make each machine part of that “custom” group. Problem is, that limits the operator to one group per machine (when normally, the machine has the option to be part of many Computer Groups). Similarly, one could permit the creation of a defined number of groups via client settings (e.g. Custom_Group1 - Custom_Group5, but it’s still not as easy manual computer group creation and would be more difficult to coordinate from the operators point of view (i.e. documenting which group settings are already used; and which setting/number corresponds to which group).
So that is the explanation of what it is that we’re looking for 
All ideas are welcome!
1 Like
It seems to be a matter of cost vs benefit: @jgstew provided an in depth answer on the question of Manual Groups vs Automatic . It may be worth it to you to allow manual groups to meet your requirements, but put some process controls around their creation. You’re going to have to manage something, regardless of your final decision.
1 Like
Totally makes sense @itsmpro92. The problem is; if you allow manual Computer Group creation, you open the door for people to essentially do it whatever way they want. I’ve been deleting groups that don’t meet current requirements, but it is a never-ending task! Unless you meant some specific around “process control”?
How about a client setting, with an associated Retrieved Property, that can have multiple values? Then the operator targets actions “By Property”.
Client setting: "My Almost-Manual Groups List"
Property:
(substrings separated by ";" of setting "My Almost-Manual Groups List" of client) as trimmed string
Task: Add a Fake-Group:
action query parameter "NewGroup" with description "Enter group to add to client:"
setting "My Almost-Manual Groups List"="{concatenation ";" of ((substrings separated by ";" of values of settings "My Almost-Manual Groups LIst" of client);parameter "NewGroup" of action)}"`
Task: Remove a Fake-Group
action query parameter "RemoveGroup" with description "Enter group to remove from client:"
setting "My Almost-Manual Groups List"="{concatenation ";" of (substrings separated by ";" of values of settings "My Almost-Manual Groups List" of client) whose ( it != parameter "RemoveGroup" of action)}"`
I’m not sure this is any more efficient than just using manual groups though, you still have a potential to get all sorts of unmanaged setting values on the clients.
Manual Groups should only be visible in that specific users Operator Site. If you have a bunch of Master Operators doing this, then the manual groups end up in the Master Action Site; but it’s really a symptom - Master Operators really shouldn’t be sending actions to clients, outside of perhaps a small number of deployment-wide Policy Actions, such as Inventory scans, Unmanaged Asset Scans, or BigFix infrastructure upgrade/deployment.
2 Likes
@it_cat - Since manual Computer Groups are useful entities, but come with costs to the BigFix infrastructure, I was suggesting that you formalize their management, and put them under Change control. You could use the Comments feature, and record any approvals.
It might also prove helpful to educate the operators on the impacts their decisions have on the larger BigFix infrastructure.
2 Likes
This does seem to be more a process issue though I’m lucky not to be in an environment where I have to manage/housekeep the content of numerous ops. Just thinking out loud, in a very similar approach to @JasonWalker, how about a custom setting that is set by a task then then allows an endpoint to evaulate into an automatic group? Say you have automatic groups using relevance, eg exists setting "_MyCustomGroups" whose (value of it contains "Group_Custom1") of client and your ops use a fixlet that has HTML drop down that the ops selects the group from. This way may be a bit more overkill and does require the task/fixlet to be updated at the XML level to add/remove items from the dropdown list but if control was one of the requirements, this means ops can only set client setting for the groups you include in the task permit.
3 Likes
This is the fixlet I created to provide the HTML combo box if anyone was interested.
5 Likes
Guys, all of this feedback is brilliant - thank you! 
@JasonWalker - I’m basing it on a client setting as you have outlined (as I do think this will be a lot more efficient than manual groups). I’ve named the new setting “__Group_1_Manual” so it sits under the manual computer groups ( “__Group_0…” in the Windows registry), for convenience.
I’ve updated your tasks very slightly. To add a group:
action parameter query “NewGroup” with description “Enter group to add to client:”
setting “__Group_1_Manual”=“{concatenation “;” of unique values of ((substrings separated by “;” of values of settings “__Group_1_Manual” of client);parameter “NewGroup” of action)}” on “{now}” for client
I just add the unique value bit so it won’t add any duplicate groups.
Remove task, pretty much the same:
action parameter query “RemoveGroup” with description “Enter group to remove from client:”
setting “__Group_1_Manual”=“{concatenation “;” of (substrings separated by “;” of values of settings “__Group_1_Manual” of client) whose ( it != parameter “RemoveGroup” of action)}” on “{now}” for client
I really like how this is setup using the “RemoveGroup” parameter; don’t think I ever would have thought of it.
I changed the RP slightly - to not concatenate the results - as this prevents an action from targeting any individual group in the string:
unique values of substrings separated by ";" of values of settings "__Group_1_Manual" of client
I’ve also created a task to populate the new client setting with the existing manual computer groups, so that when I make this new process available - and disable the creation of manual computer groups for non-master operators - they will have the values already set and available for use:
setting “__Group_1_Manual”=“{concatenation “;” of (following texts of substrings “_Group_0” of preceding texts of substrings “=True” of (((settings of client) whose (it as string contains “__Group” and it as string contains “True”)) as string))}” on “{now}” for client
@SLB - I love this fixlet format (and have used similar myself) but we have too many groups (250+) to maintain a manual list like this. I think I already know the answer, but I don’t suppose there is any way to have the drop-down list select from a list a existing RP results/values? This would be particularly useful for the removal of a group; making sure that it is one that is actually existing.
@itsmpro92 - in an ideal world, we would adhere to a more formalised approach. But unfortunately I just don’t have the time and/or resources to manage this. I try to keep operators educated, but with so many operators (and few BigFix staff), it’s difficult. I have some plans in mind, but not around moving forward with manual computer groups specifically.
If anyone sees any flaws above - or any suggestions for improvement - I am all ears.
2 Likes