I’m having an issue where sometimes a new RHEL client will ignore the relay set in its besclient.config file and attempt to register directly with the BigFix server itself. The besclient.config works the majority of the time on the majority of servers.
Due to firewall rules – this doesn’t work. If we try to reinstall the bigfix client it still ignores the RelayServer1 setting.
We have found uninstalling BigFix client completely, rebooting the server, and then installing the BigFix Client resolves this issue. We’d prefer not to have to reboot every server this occurs on to install the client.
I’ve experienced something similar and haven’t been able to track it down. My local workaround has usually been to add an entry to the /etc/hosts file, assigning the IP address of the nearest relay to the name of our BES root server. The client still thinks it’s registering to the root server, but it’s actually communicating with a relay.
@JasonWalker 's solution is a bit ugly, but it does work. It is basically the same concept as “Fake Root” or “Hidden Root”.
Basically from the client’s perspective, it doesn’t care if it is talking to a relay or the root.
This is a reasonable way to get things going, and then you can set any missing client settings through an open action instead of through a config file.
I would be curious if this happened, and then you did the hosts file hack that @JasonWalker recommended above, and then use an analysis property to see what the effective client settings are to see if it is missing when checked that way as well.
On the Windows client, I find that if I stop the BESClient and update the client settings in the Registry, the updated values are ignored and eventually overwritten back to the original values, unless I also increment the “effective time” stored in the registry to more recent value than what was previously stored.
Settings in the Registry from a previous installation, and settings added through a clientsettings.cfg file applied during the setup.exe installer, also are stored with no effective time. I read somewhere (maybe in the technote on sysprepping?) that the settings with no effective time are valid, but will be overwritten by any action with any effective time at all.
I believe that intuition is correct. In this specific case however, the client has never communicated successfully with the bigfix server so there has not been any chance for a more recent action to overwrite the relay settings.
In addition, we include the relay in our msi without an effective date and have never had this issue.
In fact, just recently I tested including every relay in the tertiary relay list and sure enough the client found the one it could register to. This, for whatever reason, seems to be limited to the rhel client specifically.