We want to stop users to using Manual Group as its not efficient as Automatic Groups, also in ref. to Manual Groups vs Automatic
Since have 150K endpoints we really dont want Manual groups.
Is there any way we can disable Manual Group Creation functionality for all operators.
And if there is way we can disable manual group, Is there any better option for users we can give them other than automatic groups.
In other words What could be the alternatives of manual groups.
Filters could be an alternative to manual groups though admittedly not as powerful.
To my knowledge there is no way to prevent users from creating manual groups however you could perhaps automate the deletion of them at a set frequency using the API.
It might require some scripting to work however Iām sure that there would be a way to do it via the API.
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.
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.
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.
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.
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 -
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.
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!
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.
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.
@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.
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.
