I need to push a baseline to 10s of thousands of clients. I will have the action execute across them randomly over 48hours, but what’s the most efficient way to target them? I could set a bes client setting on them and then target them by Retrieved Property > setting, but then I have to push an action to all of them to set the client setting, which I think is costly.
Would it be more efficient to try and add them all to a manual group and then target them by Retrieved Property > Manual Group?
This is the entire point of the Relevance Language.
You use it to create a statement that will return “TRUE” for any computer that meets the conditions that you are attempting to “correct” with the components of the Baseline.
They way it works is as follows …
(Relevance of the Baseline) AND ((Relevance from Component #1) OR (Relevance from Component #2) OR ...)
If the Component is a Fixlet, it’s Relevance is automatically added. If a Component is a Task, you need to tell the Baseline to include the Relevance from the Task. This is done by clicking the “twisty” next to the Task Component and selecting the appropriate option.
Then, any computer that is Relevant to the Baseline Relevance clause AND at least ONE of the Component Relevance clauses will execute the baseline.
Hi, yup, got that. I’m just asking what is the most efficient method to target 10k+ endpoints.
Targeting by Retrieved Property is more efficient then by specific computer name, but specific computer name uses Mailboxing so that makes that option better I think.
As with many things in life, there is no simple answer here. Sorry if my answer rambles a little.
There are a lot of factors that go into determining the most efficient way way to deploy a baseline to 10k+ clients. I manage a system with 47k+ endpoints. We routinely deploy content to 10+ clients using the Dynamically target by property option. All the clients are then notified (via UDP messages from their Relays) about the new action and will all start to request it and evaluate it.
Some things to consider …
Consider how your Relay architecture is setup. Do you have enough of them? Can they cache all the files in the Baseline?
I assume you have already tested all the components in the Baseline, so their downloadable content is already cached on the BigFix Server, waiting for the Relays to request it as needed. I recommend you use the “File Pre-Cache Wizard” to pre-stage the files on your Relays so the endpoints don’t waste any time waiting for the Relays to download the files. You have to select the Fixlets/Tasks individually in the Wizard.
Are your endpoints centralized or distributed at WAN connected sites? (This gets back into Relay architecture)
What is in the Baseline?
How many components in the Baseline?
How many files might need to be downloaded to a given endpoint?
I would recommend considering the use of the following options in the Action …
Start client downloads before constraints are satisfied (presumes you schedule a Start on time that is sufficiently in the future to allow most clients to pre-download their needed files, and that the clients have enough cache space available).
to accommodate the pre-caching from a Baseline, you may need to consider adjusting local client cache settings. _BESClient_Download_PreCacheStageEnabled, _BESClient_Download_PreCacheStageDiskLimitMB, _BESClient_Download_RetryLimit, _BESClient_Download_ChannelThreshold, _BESClient_Download_DownloadsCacheLimitMB
You may also want to consider the _BESGather_Download_CacheLimitMB, _BESGather_Download_ChannelThreshold settings on your Relays before you deploy the action.
When deploying the Action, use the Stagger action start times over … minutes to reduce network load option. This can also reduce congestion on your Relays.
I believe BigFix complains if you try to select more than 1000 endpoints per action if you target by selecting Computer Names.
Also, you won’t be able to cover any computers that are not currently in the system (freshly built/rebuilt computers) if you attempt to use mailboxing (selecting specific computers). I don’t know if that is important to you or now.
I think the best way will be to add the endpoints to a manual group and then target then by Retrieved Property > Manual Group (plus some of your suggestions above).
First suggestion is to not deploy your patch baselines as a Master Operator. Actions taken by a Master Operator can have serious performance and reliability impacts across the deployment.
I’m assuming that you are not targeting all of your endpoints, otherwise you would just target all computers and let the baseline or fixlet relevance deal with what to apply where, and you action constraints deal with when.
So, if you have X thousand endpoints, what are you trying to achieve by splitting the target into groups? Reduced network or endpoint load? Something else?
That will pretty much dictate your targeting requirements.
We use client lock states to dictate when patches are installed, for example. We have an action that reads local client details to determine when the machine can be unlocked and actions are then applied, and then we have a separate action that locks the system again after the maintenance window closes. This way, each endpoint can be configured individually to meet specific business needs.
Is this similar to what you are trying to achieve? I definitely agree that manual groups are not a good approach.
EDIT
To echo @TimRice, we also routinely deploy actions to 10s of thousands of endpoints.
We are deploying a baseline that runs BFI scans and targeting endpoint based on deployment status (dev, qa, prod1, prod2, etc), but the scope of each group is a specific list of endpoints. So each specific list needs to be tagged to allow for Retreived Property targeting to work, but that means still having to push a client setting to all endpoints. That’s why I thought just adding each group to their own manual group would allow me to target each group when I want to but not need pushing 2 things 1) a tag 2) the baseline.
I would create automatic groups for that, personally.
That also seems like it would be near impossible to maintain, by the way. Are there no other criteria that can be used, such as subnets or AD Sites or anything like that?
Relevance example for hostnames:
exists computer name whose (it as lowercase is contained by set of ((“hostname_X”;“hostname_Y”;“hostname_Z”) as lowercase))
I do these for both SCCM and BigFix, and usually use the Transpose feature in Excel to covert a list of hostnames into the required “A”;“B”;“C” format.
EDIT
I do want to point out that we do not do this for tens of thousands of endpoints…
Most I’ve done is 1200 or so; you might be surprised at the relevance evaluation time…
And these groups never change? Manual groups just seem exceedingly difficult to maintain, there has to be a better way. Could you manage the exclusions instead? I.e. deploy unless X. Might be a smaller audience.
yeah, i’ll have to think about it. For now it’s just a one time deployment but it could happen more often, at which point the group members would change and it would be a nightmare to manage, to your point.
Manual Groups aren’t nearly as bad as they used to be. Once upon a time you had to redeploy the action when you updated the group because it was completely static. Manual groups now do exactly what you’re otherwise prescribing. They add a tag in the registry that identifies them as belonging to that group. If you’re forced to do something off of a static list that can’t be defined with automation, manual groups aren’t terrible. You could do the same thing with AD groups if you would rather compile the manual groups there and reference the group membership via relevance. That said, you still have the same maintenance point. You’ve just moved it. Hope that helps.