Is it still best practice to do general deployments with a non-master operator account in version 9.1? Does it still cause more overhead on Bigfix if all of your actions are taken with a master operator account even though the content is in a custom site?
Yes. Master operator actions go to every computer everwhere. Very few actions should be processed by every computer in the deployment
NMO actions only go to the computers that are subscribed to that operator.
1 Like
In my case, my non master operator account will be subscribed to as many sites as my master operator account. Is there still an advantage to having a non master operator account in this case. Are master operator accounts given a higher priority than a non master operator account within a given site for actions and analysis?
Management of the user is one, you can disable that account.
Master operators have a lot of power so restricting it is always good. Master operator sites and mailbox sites are the first gathered yes but all operator sites (including those 2) are processed together.
And I don’t mean sites, it is the endpoints that matter. The master actionsite always goes to every endpoint. But is the non master operator also going to each and every endpoint? Its quite often not the case, unless you are a very small deployment, that an NMO manages every endpoint as there is usually some logical breakdown by department or functional area.
1 Like
Hello
Can you please tell what’s the line(s) in the BES Client log that tell us a MO sent an action in the environment. I mean to identify a MO sent and action that does not apply to me as BES Client but either way I’m ingesting that action?
All actions sent by any master operator are recorded in the Master Action Site and are visible in the Console. The record includes the ID of the Action (00-xxx), the date and time and the name of the operator that sent the action.
This unique ID also is recorded in the BES Client Log. Look for lines that start with:
ActionLogMessage: (action:xxx) starting action,
Where xxx is the ID of the action.
Hi @itsmpro92 Thanks. My question is more like this: It is know and mentioned here in the forum that, an action sent by a MO is sent to all clients even if they are not target of the action, I think I recall there a line in the besclient log that can prove that, something with the actionsite or the gather of the actionsite. In your example is an action at is intented for the client in question. Please let me know if my rephrase is now better.
I don’t think it will be visible in the logs because that happens only if agent cycle gets interrupted which only happens for the targeted devices BUT you can easily prove it - open the Actionsite folder within __BESData and check the .fxf file for that action is there (i.e. will be evaluated by the client on each client cycle).
2 Likes
Thanks! @ageorgiev I will check but I think this is what my mind forgot.
I think it could be GatherHashMV or GatherAction commands what you are looking for.
Fer
The idea is to identify that an action sent by a MO is sent to all clients even to those that are not intended targets, hence causing them to necessarily evaluate content. As per my understanding GatherHashMV or GatherAction couldn’t spot that idea, or maybe I’m missing something? If yes, could you explain? Thanks
When an action is Dynamically Targeted (By Property or By Group), the client has to download the action and check the Targeting Relevance to determine whether the client is among those targeted. It only has to evaluate the Targeting Relevance at first, which ideally should be less impactful.
On the client you may observe that “Action ####.fxf” is present. If it was issued by a Master Operator, the file will be in the actionsite folder; otherwise it will be in the opsite### folder of the non-mo operator who issued it.
If an action is Statically Targeted, by selecting computers or entering their names, the action will instead be found in the client’s mailboxsite.
If a dynamically-target action is not relevant to the client, the action does not appear in the client log, though a “gather” message for the actionsite, opposite, or mailboxsite may be present.
Edit - I may need to double-check that statically-targeted actions go into the mailboxsite
1 Like
Your safest way will be checking on the Action xxxx.fxf Files then, as others already mentioned here.
1 Like
You are correct, the statically-targeted actions go into the mailbox 
2 Likes
Thanks for the wonderful explanation Jason.
This actually is something I brought up a while ago with the thoughts that there may be some improvement in the area but never got anywhere, so maybe since we are talking on the subject it is something worth revisiting and if more people have inclination to vote for it we can submit it as an idea and change things long-term. My specific problem is not with the overall design - it makes perfect sense but the rigidness of it doesn’t. For example, if you have a baseline with 200 windows patching fixlets and you submit it as an action targeting one computer group with 5 machines dynamically, that actions is sent to ALL computers that include Unix, Linux, MacOS, etc + Windows, and it makes absolutely no difference what you put in the relevance of the computer group OR even what you put as top-level relevance of the baseline, this action will reach all machines and will be evaluated by all clients (even as deep as all the fixlets in it one by one). So imagine if you are thinking from “client cycle times” prospective how much time is wasted there both per each client and overall combined across all machines…
IMHO, there just needs to be some key/higher-level performance optimizing logic where certain criterias that system realizes won’t change and avoids even sending those actions to them - one such example would be “operating system” - i.e. same exact example BUT since I have “windows of operating system” as top-level relevance for the baseline, when I submit the dynamic action the system should realize that there is no point of sending this actions to any non-Windows machines! It’s not like I can change the OS of Linux or Unix machine “as is” to Windows and have it all of a sudden become relevant to this action, so if it is missing from its Actionsite it’s a problem. In certain situation, the same exact logic can be said for “version of operating system” as well - if for example I have relevance of the baseline that it’s for Windows 21H2 and above, why send it to Windows 2016 for example? It’s not like you can drop your OS level as is with agent installed and retaining its agent ID, so when it happen and it’s missing this action it will be a problem; And so on, I am sure others can think of other such relevances that would not change and can be considered “key”/“top-level”…
Curious - if the action was a baseline from a site with only say Windows systems subscribed, would the dynamic targeting still cause the other non windows systems to download - if so would it be a simple check to know it has nothing to download as the baseline is not subscribed to the computer to evaluate?
No, it doesn’t matter - IF you run it as MO account, will place it in Actionsite and send it to all machines (hence, me saying it’s a bit rigid and wasteful).
1 Like
I like this in concept, but in implementation it adds significant complexity at the security level - especially around which computers are subscribed to which operators.
If we considered these new action-sites as “channels”, then there is a mix of “which operator can send an action on a channel” and “which computers subscribe to a channel”. Taking just the OS selection described, we could have something like “all Windows Servers subscribe to channel X”, and “Operator Y can send actions to channel X” but … at that level it becomes much more difficult to assign operator rights for “some” computers in a channel.
The changes I could envision might be to leverage Roles. As both Operators and Computers can be assigned to Roles, perhaps we could create distinct action sites for each Role. When taking an action, and Operator could assign which Role the action targets. This should preserve the security assignments between computers and operators, but would probably also lead to some confusion if the user is assigned to multiple roles with different computer sets, and some computers don’t respond to the user’s actions because the action is targeted through a different role.
There certainly are improvements that could be made, I’m just pointing out that this would all have to be carefully considered because there are impacts to the security model, and I’m not sure the performance improvements would be large enough to justify the added complexity.
That could be an option. The improvement also can be done on the client evaluation side too. The overhead of MO actions really becomes a big issue with baselnes/action groups because the agent automatically blindly goes through all the fixlets in it and continues to do it on every single agent cycle or in fact agent cycle interruption it recieves. If the agent evaluation engine scans for those “key relevance clauses” first, evaluates only them and then halt from further processing of anything else as soon as it realises it is never going to be relevant to this action… and has the way to record that, so even though the .fxf file is still there but it just skips it through that also solves the problem without having to touch anything on action submission/site structure/distribution/etc…