Custom Site & Automatic Group "best practices"

Tips
1

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…
7 Likes
2

This is how I typically setup single tenant environments:

ss (2016-04-14 at 12.11.06).png1019×486 31.7 KB

  • BF_Relays site
    • All Relay Servers
    • Top Level Relays
    • DMZ Relays
  • BF_Server site
    • All BigFix Infrastructure Servers
  • Content site
  • Endpoints site
    • All Endpoints
    • Department Group 1
    • Department Group 2
  • Servers site
    • All Servers
    • Server Function Group 1
    • Server Function Group 2

The Custom Sites have corresponding site level relevance
The “All #### Something” groups have relevance of just “true” so they are constrained by their site.

Without a group that matches the site level relevance you lose the ability to target all the computers in a site by group (Notice you can’t target all computers subscribed to the Content Site because there are no computer groups in the content site):

6 Likes
3

In my case I have created a custom property for custom sites, and I use that to target the clients by site

1 Like
4

Thanks for sharing these best practices.

Are there any limits to the number of custom sites that can be created?
Does a large number of custom sites impede server & agent performance over time?

1 Like
5

Not technically.

It could depending on the number and how difficult the relevance is to evaluate. Less is better than more, but ~400 is not unusual for large companies.

1 Like
6

Currently our setup (used purely for patching servers) is quite simple in comparison and we have Windows, Red Hat, Oracle Linux and AIX servers. I have the relevant OS content inside the respective sites, but all internal and DMZ servers are together, along with their content.

This is an interesting concept, but I am not clear what the advantage of keeping servers in an “empty site” and content in another site is. What about multiple OS would a content for each OS be pertinent?

I’ve organized the application in a way that “works” for our patching processes but should we grow from our current “single focus” organization with 2 DCs within 2 hours of each other into a cross-national or international presence, what can/should be done to ensure the application is configured to support a much more varied and distributed set of endpoints/servers across multiple time zones?

Are there other forum posts I haven’t found or whitepapers available that could help avoid painting myself into a corner or burying myself in unnecessary complexity?

7

Hi.
We know having content in Master Action Site impact the performance of the BigFix components. But, does the existence of Automatic Groups, from several to lots of them, impact the performance of the BigFix components?

1 Like
8

The smaller the action site the better, but you MUST put automatic groups in the master action site in order for it to show up as a selectable target in WebReports and elsewhere, so they are necessary in those cases. You can and should put automatic groups in other sites when it makes sense, but you might find yourself needing to move it up to the action site in some cases. That said, if you are going to use an automatic group membership in other relevance, it really should also be in the action site and not elsewhere otherwise you can run into major problems.

Automatic groups are usually very small and should ideally be quick to eval, so they are less of a concern than other forms of content in the actionsite.

I’m not really sure. There would be an impact to the eval loop of the clients depending on the complexity of the relevance. I just know hundreds of automatic groups is common, but I’m not certain about the impact on other components.

2 Likes
9

Thanks @jgstew
I like the approach of Automatic Groups inside Custom Sites, it is the one I try to always use. For web reports I’m kind of a basic user, would you be so kind to share 1 or 2 examples of situation when Automatic Groups are mandatory in Master Action, SIte? Whether it is for Web Reports or another different situation…

10

We have more in the master action site than I would like but we really don’t have much of a choice. We are an MSP and we have “system wide” policies in place. We need them to apply to all systems.

Each customer has a custom site with relevance to a unique ID each customer has.

if (exist values of settings "Client-EMSEID" of client | False) AND (value of setting "Client-EMSEID" of client = "12345") Then True else False

We use the client setting so it is cross platform.

Policies include setting client settings and then locking systems we do not patch, such as Citrix PVS and non-persistent VDI

We use BigFix to install other tools. We have a policy that includes the installer and the commands to install it. It is only applicable to systems with a specific reg key. We then use a task in each site to set that reg key. Sometimes the setting is a UID or “key” to authorize the tool. We set the key at the site, the policy becomes applicable, installs the tool and then is no longer applicable because the tools is already installed. We think of it as a GPO replacement for tool installs.

A little complicated but we have tasks to harden systems at different levels. We have tasks to perform the remediations/mitigations, at different levels. For example, level one hardening are the least likely to cause issues in the environment, safe to set. Level two is more likely than level 1 to cause issues once deployed.

We then have a baseline with all levels of hardening fixlets/tasks. It is applicable to all current levels of hardening and “Test” systems.

We then have a task to set the level we want a system to be at. If we set it to test, it will be applicable to all level of fixlets/tasks but if it is set to level 1, 2, 3 and so on, it will be applicable to the baseline and the level of fixlets in it. And, Level 2 includes level 1 and level 3 include level 1 and 2.

Back to the topic, the hardening fixlets/tasks must be in the master action site to be applicable to any systems, from any customer as well as the task to set the level. If we put them in a site, the site would have to have all systems.

11

If you want to be able to select the group to filter on in Web Reports or select it as a target for deployment in the Console, I think those are both cases where it is required if you are wanting that functionality.

1 Like
12

There are actually cases where it makes sense to have content that applies to all systems in a custom site that all systems subscribe to and it NOT be the actionsite. Part of the reason is that any changes to the actionsite have to be synced to all computers and processed by all computers. It is actually better for that to be split up so it isn’t all a single site so that changes can be propagated in smaller portions with smaller and less frequent diff sites. If the actionsite has a maximum of 10 diffsites and a computer is asleep when 10 changes are made to the actionsite, then they have to process a full site instead of a diffsite. Splitting things up makes this less like to happen for less total content.

That said, it is better to have content in the actionsite rather than have the same content duplicated in every site and deploy that duplicated content to all computers… that doesn’t really net you anything.

The way I do this is I have the following Custom Sites:

Private
Shared
Shared/Windows
Shared/Windows/Desktop
Shared/Windows/Server
Shared/Mac
Shared/Linux

All of these sites are subscribed to by all computers (except for the OS specific sites which all computers of that OS subscribe to)

The Private site is only accessible by Main Operators, not regular operators. It contains things that are not meant to be shared with other operators or externally. (Warning: other operators will still be able to see actions crated from this site targeted to computers they manage)

The Shared sites all operators have read access to at least. They are where most of the content goes. When applicable it goes to the OS specific site so that only computers with that OS type will see it and have to process it. If it is applicable to more than one type, it can go into the top level Shared site. The hierarchy is entirely fictional and only in name and site subscription.

I should point out, that part of why I do this is that I have like 11,000+ items of custom content… so… yeah.

I would not recommend making all of these sites right away, but as soon as you have like 100 items that would belong in a specific site that makes sense to break away as a group, then it might make sense to start doing this.

Also, in each of these sites, you can make an automatic group with the relevance of TRUE and then that automatic group will contain all computers that subscribe to that site, but not any computer that does not subscribe to that site.

These sites are in ADDITION to sites that are specific per department or org. Those sites are where the operators from those locations have write access and can do their thing in a scope that is specific to their computers.

13

Question,

When you take action for content under a specific site, can you have the action be under that site as well? I see no way to have the action run under a site. What is the point of having an “actions” under a custom site if you can’t take action and have it run there?

image

14

It appears to be a presentation flaw - if you navigate Actions | All Actions | By Site you will see a populated tree

15

It’s an artifact of using the same view template in the Console to view any Site, but only the ActionSite or Operator Sites actually have ‘actions’ in them.

The Actions view organizes based on the site of the source fixlet of the action, but the action itself is either in the actionsite or an opsite.

This is why computers only respond to an action issued by an operator who has management rights - the computer may be subscribed to the custom site from which the action was taken, but the action itself is in an opsite the computer may not have subscribed.

1 Like
16

I’m trying to reduce the size of our actionsite and the largest components to it are our patching baseline actions. Our patching baselines are in a site of their own so I was hoping that the actions taken on them would be in the site they are in.

17

You must be using a master operator to kick off your baselines since, the resulting actions are stored in the actionsite (aka the master action site). If you change your approach and use a non-master operator to deliver the patching baseline, then the resulting actions will be stored in their opsite.

1 Like
18

I was thinking that yesterday. It may be something we do. I will test it out.

1 Like
19

it can also be in a computer’s mailbox site. One of those 3 options.

1 Like