I’ve seem to have hit a wall. We have clients that are within subnets that cannot communicate back with the root bes server. We have been trying to use clientsettings.cfg file to set the primary and secondary relays without success. I’ve pasted an edited copy of our file below.
I have tried varying versions of the clientsettings.cfg file using quotes and then not using quotes. What is really frustrating is that it takes other parameters such as __LockState and __RelaySelect_Automatic just fine but it won’t set the primary, secondary, or failover relays.
Each time I uninstall the BES client I blow away the registry entries so the install starts fresh and I’m using the setup installer and not the MSI installer.
Any thoughts would be helpful, any way to increase debugging to see if its choking on something in the clientsettings.cfg file?
We used to have a similar situation where we had clients blocked from communicating directly with the main server. We used this copied directly from our clientsettings.cfg file:
We set both relay settings to the same relay computer. Maybe try the relayselect line before the relay server lines. We used the setup.exe installer with this file and it worked fine for years.
Are the clients showing up in the console at all? One common thing to consider, is that deployments may have a Policy Action configured that changes the clients to Automatic Relay Select mode. When we engaged IBM for our first deployment, they configured such a policy action while they were here, so I think that is a common approach.
If that’s the case, you’d see the client appear in the console, then shortly after it will stop updating. If the client is trying to use Auto Relay Select, it will need to be able to talk ICMP with the relays.
Just tried putting RelaySelect first but still no dice, I guess it’s time to open up a support ticket. We don’t have any open actions that are reconfiguring the end points. I’ve tried the client settings with and without quotes but have the same results.
Alan,
The endpoint is a Windows 7 machine.
Jason,
Client shows up in the console but without a primary of secondary relay.
Wanted to provide an update, we figured out that deleting the registry entry was not enough, we had to uninstall the bes client, delete the registry keys, and manually delete the client folder to get the client settings to take. After we did this it would accept any configuration including IP, Relay IP, and RelayServer1, etc. Thanks for all of the help.
If it’s showing up in the console, then it was able to contact a relay.
Was this an initial install, or did the client move to a new network?
One hack we’ve used when our clients get into a bad state relay-wise, has been to put an entry in the hosts file that maps the bigfix server’s hostname, to the address of a relay the client can reach. Once the client is checking in, we can use the console to fix whatever else is wrong. Beats a reinstall.
I just had occasion to show one of our groups how to install the Client on machines that were “outside” our firewall.
@jgstew lists the correct format to use in the clientsettings.cfg file. We used it on several Macs and several Windows systems to register clients via our DMZ Relays. You do have to use the EXE client installer for the clientsettings.cfg file to have an effect.
…but when clients are on our wireless network, they bootstrap to relay1.domain.com.
For the life of me, I can’t figure out how it goes to relay1 instead of relay2, as specified. It’s maddening.
If I add
__RelaySelect_Automatic=1
It runs a relay selection and winds up at the core server! (Yeah, I know, protect the root… I’m working on that.) Both relays can be reached via ICMP and http:52311.
You may want to run the client diagnostics with the -r to run a relay selection test to see how the computer is selecting relays. You can also use the relay parser to see what list of relays it has received from the core server.
If you turn on automatic selection in the CFG file then your settings for the selected relay don’t “match” the available set for the deployment (as you have a chicken and egg problem as you haven’t gathered the available set yet) so it will try to go to root.
The settings should be for a manual configuration and then you can change it after it gathers.
The “Relay IP” or “IP” will set __RelayServer1, __RelayServer2 to the given value and set __RelaySelect_Automatic to 0
Your command worked for me while the documented command of just having the IP:http://relay.domain.com:52311/bfmirror/downloads/ configuration line went to the root server instead of the relay for me. Thanks for the input. The instructions on IBM’s support site were a bit confusing and didn’t really indicate that you needed the second line to make it work.