We are facing some challenges with the existing automation for BigFix client remediation or installation. We need advance solution for the BigFix client installation and registration for WFH and WFO users. We would like to automate the BigFix client remediation as mentioned below.
- Check the IP address of the Client and if it’s connected with Corp network IP starting from 1x.x series so the default package with the config file will be pushed automatically.
- If client is connected to public network and IP address start with 192.X , then Custom Package with Manual key exchange will be pushed.
- After the client installation verify the service of BESClient if it’s not running restart the service.
- At the end automation will verify the registration with the BigFix relay by validating the files existing in “C:\Program Files (x86)\BigFix Enterprise\BES Client\KeyStorage” or some other files to verify the registration.
Please suggest if this is possible.
We implemented a similar setup for our macOS users: a daemon runs on a set frequency to watch BESClient, if it’s missing, we install; if it’s stopped, we start; if it’s misbehaving, we repair; and if none of that works, we re-install.
If you truly have very different requirements for two client packages, only then bother with IP-based branching. Otherwise, ship a single BESClient with a secure key (store it encrypted; the script can fetch/decrypt it at install time). BESClient will auto-handle both cases (tested, initial registration may take a bit): on a private network it uses the secure key for first registration; otherwise, it falls back to normal authentication via other relays (configure a failover list).
- Create a software dump/staging folder with the BESClient installer,
actionsite.afxm, and a config file containing a secure-key placeholder (the real secret is injected just before install).
- Create a script (Task Scheduler / cron / daemon) to run every 6–12 hours and do the following:
a. Existence check: Detect BESClient by install keys/service. If not found, install from the dump.
b. Health check: If the service is running and the latest (24-hour) log contains both lines below, skip and exit:
• “Relay selected successfully”
• “Report posted successfully”
c. Gentle fix: If stopped/not running, restart the BESClient service, wait a few minutes, then re-check for “Report posted successfully.”
d. Connectivity check: If (b) and (c) fail, test relay reachability using the saved relay list (if bundled with the dump) and any relays specified in config. If ports aren’t open, exit and write detailed logs.
e. Last resort: If ports are open, the BESClient KeyStorage has all five files, and the service is running but even after multiple attempts there’s still no “Report posted successfully” remove BESClient cleanly and re-install from the dump.
We’ve also added a few extra health checks (e.g., detecting when the client log showing ‘server is returning old data’ in huge numbers). Start with the basics; once that’s stable in your environment, you can expand the checks as needed.
You can always sync with the HCL team for guidance. That said, per our discussion this isn’t an HCL-recommended approach and there are valid reasons they advise against it. But if it works reliably in your setup and you’ve weighed the trade-offs, go for it, no one’s stopping you 
Note: Initially there will be dups but as I mentioned once its stable you will be in good place.
1 Like