BigFix Clientsettings OS Applicability

We are starting to extend BigFix to more operating systems and looking to set some client settings during install time.
However it would nice to confirm which OS the client settings will actually have an affect on each OS.

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Configuration%20Settings

Client settings are usually only applicable to the client itself. The OS of the endpoint shouldn’t matter unless there is specific pathing involved such as logging or configuration paths between Windows and Linux. Is there a specific setting you see as problematic between different operating systems?

We have not typically set client settings during install time, but are looking to start to lay some basic configs on win/mac/linux and wanted to know if any of the client settings did or did not apply or have any affect on the different operating systems.

1 Like

The settings should be global across all the platforms unless a “Platform” section is there limiting the item. There should also be a section indicating where a setting was added or retired but this document doesn’t have it.

@BigFixNinja do you know of a better version of this document for the public that more closely matches the DEV version?

1 Like


@steve

I believe the OP is asking about the ClientSettings.cfg feature available with Windows and Mac client installers.

I have not used all of them, but from my understanding they are client settings that affect the client regardless of Operating system it is installed on. That being said, I do pick out a few such as

  1. _BESClient_Inspector_ActiveDirectory_Refresh_Seconds
  2. _BESClient_Inspector_DisableWMI

Are about the only two that won’t have much effect on non-windows endpoints. Other then that I believe all settings do the same thing regardless of OS.

Hope I understood your question correctly -

Tim is correct about what I am looking for and also a nudge to IBM documentation that it would be helpful to specify if there are any clientsettings.cfg (as dpowers1 pointed out) that does not apply to a specfic OS.

We ran into an issues where the clientsettings.cfg are not being applied on our MAC installs. We put the file in the same folder as the installer.

Does anyone have any tips of how to apply clientsettings.cfg on non windows machines?

*sbl -

I think you are looking for OVERALL what are best things to set as far as these settings?
and along with that, what it the BEST way to enforce them?

I agree that setting this at INSTALL time is optimal… but you can always have something fall thru the cracks (someone uses the WRONG clientsettings.cfg… they don’t use any clientsettings.cfg … etc). So if those are your goals, then first is to understand what each setting does. Then determine what people consider BEST practice, good example ( Patching practices ) by @jgstew and others if you read the post.

After this, you do want to put them clientsettings.cfg during your roll out. I have NOT seen the on the Mac where it does not pick these up, but could happen. So for various reasons you might want to ENFORCE your settings by creating a Fixlet that runs as a policy (not ending) to CHECK the settings on each endpoint, and adjust if not what you want.

Below is a simple example to start with (you can of course check ALL your settings, and update the missing ones)

Note that was just checking for a single thing, but we could add checks for all the settings we wish to enforce. My point here is that you WILL have one-offs during the install process, so why not enforce your BEST practices with a policy.

Mac definitely uses the clientsettings.cfg but will only populate a plist for the client if none exists yet.

Additionally the cfg file must be created with a true text editor (the exact same file that works on Windows is the best one to use and transfer the file in binary format to the Mac)

For UNIX the best solution is to write out your own besclient.config file prior to the client starting (after install) and it will just use the file in question. The besclient.configdefault is used if besclient.config is not present

1 Like

Thanks for the feedback and links. In general we are setting and enforcing many things through policy actions or GPO.

To provide a little more context to my situation:
The client settings being set at install time is due to ease concerns from a new set of *nix admins we are laying the BigFix agent down on. They are not used to being managed and they manage their systems with puppet but BigFix is being enforced due to company policy. To help ease the transition we are planning on setting command polling, cpu throttling and the agent being locked (and stay locked) for these admins so they don’t worry about the BigFix Admins making changes to their systems. (also to keeping our hands clean if there was an accidental targeting of all computers)

We maybe looking at other settings as we tune things for them. We had a pilot group of linux machines run up to 50% CPU utilization with the BES agent upon install. It was having problems evaluating one of our custom sites set to be relevant on all computers. I had to edit the relevance to not have linux machines evaluate that site which had primarily windows content in it. After a client restart, the clients unsubscribed to the site and things settled down.

1 Like

Take a look at this page.

How to assign relay at installation time

Unfortunately you can NOT use the same file on *nix as you do on Mac / Windows. The structure is a bit different, so you’ll want to be sure to keep 'em separated. I think you’ll also want to create the file on the OS you are going to deploy on, as the line endings may get a bit funky.

1 Like

For any settings that you want to be on all machines no matter what, you can have a policy action that sets them that way so if they are not set with the clientsettings.cfg or similar, then they will be by that policy action. Example: https://bigfix.me/fixlet/details/6117

Another option I like is to set certain settings once and only once so that others can change it later to something different if they wish. This can be achieved by setting it if only not set. Example: https://bigfix.me/fixlet/details/5024

The *nix admins that want things locked could have a policy action that locks all clients in their scope which would achieve part of what they are looking to do.

My general point is, don’t rely on the clientsettings.cfg and similar mechanisms alone for certain settings.

We’re also looking into configuration options that tailor to certain usecases.

In particular, I’m looking into doing something similar to @jgstew’s examples: Have a “high performance” configuration that is set via a resident action, relevant to the IP space of the deployment workbench. Then have another “normal performance” resident action that is relevant elsewhere.

Similarly, I’m looking at twiddling the ClientUI’s history display according to IP space, and possibly whether the logged in user has an administrator privilege. However, I haven’t found the relevance will help me determine if the logged in user also happens to be one of my support staff.

"admin privilege of user " seems to only work for local users, not Active Directory users. I was thinking I can look for membership via the “builtin Administrators group” inspector, but I haven’t found how to look for membership in AD groups.

1 Like

Our support staff admin accounts have a particular pre-fix and post-fix we look for.

You could also populate an automatic group with relevance created automatically with an LDAP query and REST API. Have it refresh overnight.

See here: https://bigfix.me/analysis/details/2998380

I like the idea of all clients being high performance at install time, then once BigFix is installed for X hours, then an action/task becomes relevant that automatically lowers the performance.

So only at the package injection point can you use this? Thank stinks…I’m trying to get it to load the clientsettings.cfg for the mac…by using “xar” to unpackage then put the clientsettings.cfg in the Resources directory then “xar” it to a new pkg name…the file format looks correct but bombs out on the install after I create a new pkg file.

If you manipulate the pkg file its signature isn’t valid anymore and most of the new OS’s will not work. The pkg looks for a clientsettings.cfg (and the actionsite.afxm) next to the .pkg file during installation