Manual Groups vs Automatic

I’m currently creating groups to work with in an upcoming purge of Microsoft Office for end-clients. I was going to create a Manual Group and add the users which are cleared to have Microsoft Office and have an automatic group targeting all computer that have Office on their computers using a relevance such as:

exists regapp “excel.exe” or exists regapp “Microsoft Excel.app” or exists folder “/Applications/Microsoft Office 2008”

and have this automatic group exclude those end-clients in the Manual Group created.

I was just curious about Manual Groups because during my research in doing this I ran across several posts about how it’s best to stay away from creating/using manual groups. However I never saw any explanation as to why. Are there issues with the way bigfix relays information from manual groups?

In my experience, the major drawback of Manual Groups is that you cannot share them between Console Operators.

I prefer to use Automatic Groups with Relevance to pickup computers based on their Computer Name so that a computer that matches ANY of the Relevance elements joins the group.

You can still use the same concept of excluding the members of an Automatic Group based on their membership in another Automatic Group.

That’s strange, both myself and my coworker can see each others Manual Groups that we create as different Console Operators. Of course we’re both Master Operators, would that be the reason why?

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:

3 Likes

This is great information! Thank you so much for your response @jgstew!
I’m the main operator of Bigfix for my company, however there are two other users that have access in case I’m not available. I can see why creation of Manual Groups could be so frowned upon for larger corporations which have multitudes of bigfix operators. For us I don’t see it as a big deal as long as we don’t abuse/overuse Manual Groups.

I do have a question in regards to creating an automatic group using criteria from AD; I had noticed that it is possible to target computers using AD OUs, however is it possible to target using AD Groups instead?

1 Like

If you only have 3 operators, then it is probably fine. If you have 300+ console operators, then much less so, especially if those operators all end up creating their own versions of the same manual groups, then things really get messy, particularly when they are never exactly the same but being used as if they are.

There are a lot of “best practices” for BigFix that don’t entirely apply if you have less than 10 operators and/or less than 10000 clients.

If there is a way to get that with relevance or on the command line, then yes, but I’m not certain if that is the case without looking into it.

Try this: unique values of (it as trimmed string) of names of groups of local computers of active directories

Related: