Delay BigFix site subscription to speed up client provisioning

Tips
1

Many of the BigFix external sites and potentially many custom sites do not need to be subscribed to and evaluated by a newly installed BigFix client right away.

Adding a delay to the site subscription criteria will greatly improve the initial client provisioning speed by having it skip over the sites with the delay and subscribe to them at a later time. In most cases I think a delay between 1 and 6 hours makes the most sense.

Doing this will allow non master operators to see the client appear in the console much faster and for the client to process more important policy actions faster before running less important actions.

In most cases this will have no negative impact on the client what so ever, but in rare cases there could be unintended consequences when there are applicability dependencies between sites and groups where by adding a delay on one might cause a delay on others. In most cases this will not be a problem, and actually be desired, but it is something to be aware of.

This is the relevance to add a 6 hour delay:

exists absolute values whose(it > 6*hour) of (now - it) of minima of subscribe times of sites

The following sites should most definitely have the 6 hour or so delay added:

  • All sites containing “Checklist”
  • Vulnerabilities to Windows Systems
  • SUA / Inventory
  • Any others not being actively used

Other sites should be considered with a shorter delay (1 hour or so)

  • all of the patching sites
  • any custom site not needed for early provisioning

As a more long term goal, it may make sense to copy content identified as being critical to run very early on in the client provisioning process to a particular custom site with no delay so that a delay can be more easily added to other sites.

A hybrid approach:

You could have some sites have a delay based upon a time delay or something to indicate that initial provisioning and important actions have completed. For example, subscription to many sites could happen after 6 hours or if a specific file is created signaling the end of provisioning, then the site subscriptions could happen earlier.

Related:

6 Likes
2

I must say, I like the idea of this!

I will have to see if I can get approval to try this on a few sites!

1 Like
3

Let me know how it goes.

You could always start with a 1 hour delay or something like that on a few and then expand from there if that goes well.

You could also add a delay into certain content and baselines directly, but that is of less value than being able to do it to entire sites.

4

We now have this in production for many sites.

It is especially useful for sites that we have activated, but are not actively using currently.

I wish I had some numbers for comparison to the speed of initial provisioning before and after, but it seems like it is now under 2 minutes from start to site subscriptions and starting master operator actions.

5

The other approach I’ve used is keying off a setting or property that is set at the end of a provisioning baseline, and tying the other site subscriptions to the existence of that setting. That should give you a bit more flexibility since you could change how/when that setting is set and wouldn’t have to change the site subscription relevance.

1 Like
6

You could/should combine the two and do it based upon (the setting or a timeout) so that way if a system never gets the proper setting, it would still end up subscribed to everything it should.

I could see doing it this way for the OS Patch sites / Application patch sites… they are important, but not in the very beginning.

1 Like
7

It just occurred to me that there are many sites that the client on my root server & dedicated relays don’t need to evaluate, so there are probably many custom & IBM sites in which the root server itself and relays could be excluded from entirely. The primary advantage would be to shorten the client eval loop on those systems.

8

An inverse of this approach is to have a custom site that only new systems subscribe to that has content that is specific to provisioning, like a baseline with lots of old patches.