Five Things You May Not Know about BigFix

by | Aug 26, 2019 | News | 0 comments

In the world of Endpoint Management there are countless tools each providing a wide array of features.  Sitting at the top of that list is BigFix, and if you’ve ever used it you know that its basic functions are pretty intuitive and easy to use.  Today, I’m going to take you down the rabbit hole and show you five things you may not know about this powerful platform. So, take the red pill and let’s get to it:

1. The BigFix Client Takes Cat Naps:

Contrary to popular belief, the BigFix client doesn’t continuously evaluate the relevance of content.  It actually takes naps in between work periods.  Granted they’re so fast that to us it just looks like the client is constantly evaluating.  By default, the client only evaluates relevance for 20 milliseconds every second.  You can configure how much time each cycle the client actually spends evaluating and how much time it’s napping by using a pair of client settings:

Determines how much time the client is working

Tells it how long to sleep before starting again.

By default, these values are 10 and 480 milliseconds respectively.  You can make the client evaluate faster by increasing the ‘Workidle’ value and reducing the ‘SleepIdle’ one, but be aware that although a higher ‘Workidle’ setting will make the client evaluate content faster it will also increase the CPU usage accordingly.  There is no Ying without Yang.

2. Clients Can Download Directly from the Internet:

The relationship between a BES Client and its Relay is often described as one of ‘parent’ and ‘child’, so it should come as no surprise that like human children, BigFix clients can also ignore their parents.  In normal BigFix environments when a BES Client requires a file as part of an action, it uses the relay hierarchy to get it.  That is, it asks its parent for the file and waits until it is provided.  However, if you add the client setting:

_BESClient_Download_Direct       (set the value to ‘1’)

The client will download the file directly from the URL defined in the action script without first asking its Relay.  If the network on which the client is connected requires authenticating with a proxy however, it may prohibit this behavior.

3. Some Action Script Behavior Can Be Hidden From the Client Log:

The BES Client log, located in the “<BES Client Installdir>\__BESData\__Global\Logs” usually logs all commands sent to the client along with their parameters.  There are times, however, when you may want those parameters to be hidden so someone with access to the computer won’t know what a value being set or file being created is.  For example, if you are creating or modifying an audit file you may not want to show where that audit file is in the client log.

In such cases you can use the Action Script command:

action log command

right before the action line you want to obscure.  Then when you are done issuing commands with sensitive arguments, you simply use the command:

action log all

This will tell the client that it can resume writing everything to the log file.  In the example below the location and filename of the log file is omitted from the client log.  Once the file is written the command is given so the action logs all other commands normally:

action log command
parameter "auditlogfile" = "{(parent folder of regapp "BESClient.exe"
as string) & "\tk423.log"}"
dos echo %ERRORLEVEL% > "{parameter "auditlogfile"}"
action log all 

4. The BigFix Service has a WatchDog:

Because they are often used to prevent unauthorized behavior, the services that run many endpoint management platforms are targets for deactivation by bad actors.  This means that services can be stopped, disabled or even uninstalled if the operator has the right set of permissions.  With this in mind BigFix has a ‘watchdog’ service that will keep an eye on the BES Client service to make sure it’s running.

The utility is called the ‘BES Client Helper Service’ and can be deployed using the Fixlet: Install BES Client Helper Service (Fixlet ID: 591 [BES Support]).  The helper service’s default behavior is to check the BES Client once per day; however, when deploying it from the BES Console the operator can determine custom parameters.  Monitoring frequency and additional logging can both be set using the second action on this Fixlet.

This still does not prevent an user from uninstalling the BES Client altogether; therefore, another Fixlet is provided: Hide BES Clients from the Add/Remove Programs List – BES Client >=8.0 (Fixlet ID: 713[BES Support]).  Deploying this to computers will remove the BES Client entry from the ‘Add/Remove Programs’ list so it cannot be easily uninstalled.  Not to worry if you need to uninstall it for troubleshooting purposes.  Run Fixlet: Restore BES Clients to the Add/Remove Programs List – BES Client >=8.0 (Fixlet ID: 714[BES Support]).

5. Not All Relays Have to Be in the Auto-Selection Process:

By default, every BES Client knows about every relay in the environment.  This information is stored on every client in a file called ‘relays.dat’.  In theory this is good practice because it allows a client who has lost its relay the ability to find another one.  There are instances, however, where you may have a relay in a location that you do not want clients to connect to while going about their normal operation.  This may be a test relay or one that is purpose-built for the location where it’s in.  Whatever the reason, whenever a relay is deployed all clients are informed and put into the auto relayselection rotation.  The only way to have clients ignore this relay while going through this process is to use the setting:

_BESRelay_Selection_AutoSelectableRelay         (set the value to ‘0’)

Setting this value allows the relay to remain outside the auto-selection rotation.  Clients can still be manually assigned, but none will select it automatically.  A good use case for this is ‘parent relays’ in an n-tier architecture. 

Parent-level relays usually only have other relays as children.  Because they are assigned manually this setting will not interfere with that functionality, but it will keep normal (non-relay) endpoints from accidentally finding and/or registering themselves on these relays.