I am curious if anyone else has some thoughts to contribute to this. Please comment on this post.
The high level summary is that all custom sites with unique scope should have an automatic group with a matching set of computers as the site’s computer subscription. ( though you will likely have many more automatic groups than sites )
I’m trying to document what I have come to think of as a good way to use Custom Sites & Automatic Groups in BigFix. This applies mostly to Master Operators and how they should consider creating and managing Custom Sites and related Automatic Groups. This may also be useful for normal console operators, but they have less influence over how these things are created. Also, not all of these Custom Sites are required until a sufficiently significant amount of content exists to go in them, which may not apply in all environments.
First of all, it is generally a bad idea to have content in the “master action site”. There are a few reasons why content should exist there, but in general, content should be organized into Custom Sites instead.
It is also generally a bad idea to have content in “operator sites”, particularly because if the operator account gets deleted, the content goes with it. Content in operator sites also can’t be collaborated on by other operators in the same part of the organization. In most cases, I’d like to just be able to turn off the ability to create content in operator sites.
There are a few types of Custom Sites that don’t have much to do with “Automatic Groups” like I am going to talk about in this post.
- You may have a Custom Site that no computers subscribe to called something like “Archive” where you put content that you are no longer using, but are not yet ready to delete.
- You might also have a Custom Site that no computers subscribe to, but all operators have write access to called something like “Shared” where any operator could copy something to make available to others.
- This has some security and related concerns, but is an interesting option.
- You may have a few Custom Sites that all computers subscribe to for a variety of reasons.
- As an example, you may have one called something like “Global” that all operators have read access to, but may not have write access to in most cases, which is where content created centrally is shared with other operators. If you have enough content, you might even create a “Global/Windows” site for windows content and “Global/Mac” for mac content, etc…
Now for the real reason I’m writing this post.
You should have custom sites that only certain computers subscribe to. Either only those for a particular department, or a particular OU, or based upon a function.
- Some examples of “functional” custom sites are if only certain computers are patched centrally, then there should be a custom site for the patching baselines and related content that only the computers that get this patching subscribe to.
- Another example is SUA/Inventory. If only certain computers get inventory scans and you create enough custom content to help manage this, then it should belong in a custom site that only the relevant computers subscribe to.
For any of these or similar custom sites, I strongly recommend having an automatic group with a matching set of computers as the custom site’s subscription. There are many reasons for this:
- The automatic group helps you visualize which computers are in scope for the custom site.
- This makes it easier to target only these computers with content from other sites.
- It is also important to understand that content from a site deployed to an Automatic Group takes affect on only the computers in both. There are reasons to take action on content in a site targeting an Automatic Group that does not have the exact same set of computers, but I think it makes more sense when there are both matching and non-matching computer groups to choose from to better understand the intent and outcome.
This begs the question, what is the best way to have an automatic group and site have matching computers? There are a few options, each with their own advantages.
- Have the relevance that dictates the Custom Site’s computer subscriptions duplicated in the matching automatic group.
- this doubles the effort requires by the client, which usually isn’t an issue, but is important to keep in mind.
- this also doubles the effort requires to make changes to site subscriptions and could cause problems if they are out of sync with each other.
- Have the site only contain computers in the matching automatic group by referencing the automatic group directly.
- this slows down the client subscribing to the site, which could have negative implications for initial provisioning.
- Have the automatic group only contain computers that are subscribed to the site by having it reference the site directly.
- this wouldn’t slow down the provisioning of the site, but would slow down the computers joining the group a bit, which would slow down actions being deployed to this group a bit. This is a more minimal impact since most of these actions wouldn’t do anything until site subscriptions are completed anyway.
- Have the automatic group actually inside the custom site itself so that it inherits the scope of the Custom Site’s subscription criteria. The automatic group would contain “All Computers”, but in this case it would be “all computers within this site”
- I think this option makes the most sense, but doesn’t help in cases where an Automatic Group may need to be in the master action site to show up in certain places within the console / web reports / etc…