That is the reason why.
The short answer: Use manual groups sparingly, especially as a master operator. Do everything sparingly as a master operator.
My long and rambling answer:
In general, you should not do anything as a master operator unless it is something that only a master operator can do and you should not put things in the master action site and should instead use custom sites as much as possible.
There are a few reasons for this. One of the main ones is that master operators have infinite privileges in BigFix, so if you use that account for everything, and the password gets compromised, then you are in more trouble than if it was a non master operator. This is the concept of least privilege.
The other reason not to do things as a master operator, including creating manual groups, is that the things go into the master action site causing it to grow in size. Things in the master action site go to all computers no matter what, so any changes there go everywhere even if they don’t need to. The master action site is also the first thing clients process when they install the client for the first time, so the more stuff in there, then the slower initial provisioning may be. There are ways to speed up initial provisioning, but generally it is a good idea to keep the master action site lean.
The need for custom sites and the structure of them really depends on your organization and how your bigfix operators and their permissions are organized, but in general it isn’t a bad idea to have sites for “Windows”, “Mac”, “Linux”, “Servers”, etc… that everyone in the organization has access to and have only the correct computers subscribe to those sites. It really depends on how much content you have and what makes sense to divide it up.
My understanding of another reason manual groups are a bad idea is that what actually happens when you create a manual group and add a computer to it is that the console sends out hidden actions that tell that computer that it should belong to that manual group. These actions basically live forever until that manual group is deleted. If you remove a computer from a manual group, then the action that adds it to the manual group stops, but another one that tells the client to remove itself from the manual group starts and then lives forever until that manual group is deleted. More Info: Stopped and Expired hidden actions - #11 by flecciso
Another issue with manual groups is that if you reimage a computer but it has the same name, same IP, same almost everything, it will not rejoin that manual group. You must readd it to the manual group. The same is true if you use the BES Removal tool as a troubleshooting step to completely remove the BES Client and reinstall it. This is because computers are added to manual groups by bigfix computer id which changes if the client is reinstalled from scratch.
You can have an automatic group that acts the same way as a manual group by having relevance that tells it to include the individual computers by ID, this would provide the same kind of functionality. The better option would be to have an automatic group that includes computers by some mix of criteria like AD OUs or computer names or subnet or mac address or serial number or any other thing that makes sense to achieve what you are going for. The reason this is nice is that this will survive reimaging, at which point the computer will join the same group and then it will start processing anything targeted at that group.
Another useful thing you can do with an automatic group is that you can have relevance that causes a computer to join the group using many different criteria, but you can also have the automatic group look for a setting on the computer that excludes it from the group even if it meets that criteria or have a similar setting that causes a computer to join that group even if it doesn’t meet that criteria. You can then have bigfix actions that you use to specifically include or specifically exclude computers, but you could also send those out as offers and allow users of the computers themselves to also determine the membership if you want to allow them to do that. You can also use other tools that may run on the computer itself to set those settings in which case you could have Active Directory or MDT or a custom GUI application or anything you want able to control if a computer belongs to a particular automatic group.
The main benefit of manual groups is that they are a bit easier to manage to add specific computers to them and the console actually does some trickery to make it look like the computers you added to the manual group appear within the manual group right away, even though that is not the reality. The important part is that if a computer meets the relevance of an automatic group or has been added to a manual group and you target an action at that group, then the computer will run it, it will just run/check what is needed for it to know it is a part of the group first in either case.
The other drawback of doing things as a master operator is that you are basically forcing the existence of the manual group or property or content on every operator, not just every computer. You might make something as a master operator that a regular operator somewhere will never have use for and never need, but by doing it as a master operator, you are forcing it on them. There are times where this is what you want, like having a property show up in some of the drop downs in web reports and the console, but even that you should use sparingly.
If you have a very small number of bigfix operators and not a ton of clients and you don’t expect that to change over time, then you can ignore everything I just said and do whatever you want.
I would probably still be careful with Master Operator credentials. I recommend only allowing console connections from a terminal server and having 2 factor authentication on that terminal server.
Related: