I have a situation where all workstations on a subnet have had their selection set to Automatic. All systems, but 3 or 4, can find the proper relay and populate the distance accordingly. The 3 or 4 end up showing the distance as <N/A>. I’ve looked at their systems and nothing strange hits me. Each are running BES client 6.0.20.9 or 6.0.21.5. The DNS on each can resolve each of our relays and main BES server. Each can run a traceroute and ping, effectively hitting the relays and main server.
I was able to take these system, set them to Manual, point them to some other relays in the company. This allowed them to have the correct relay distance. I then changed them to be Automatic and they recalculated correctly to their nearest relay.
The BES Client uses the ICMP protocol in a manner very similar to tracert to calculate distance. It seems like ICMP is not blocked (which is the most common reason to see “<n/a>” for the “Distance to Relay”), but it is possible that at the moment that the distance to relay was being calculated, the BES Client was unable to send or receive ICMP (like perhaps the network was unavailable for less than a second or two).
Thanks Ben. Unfortunately none resolve on their own. Some of these clients have been installed for many, many months. I have to manually change them, then put them back to Auto for things to work out. So far, doing that clears up the issue.
Just to chime in here after coming across this thread…
So far I haven’t had much success at all getting the clients to pickup on relays (on the same subnet) that I deployed through my account. Right now I had to manually set those PCs to use the specific relay.
I believe Daryl had better success deploying the relays via the master account and having the clients pickup on them.
Not sure what to look at on this one. These are also PCs that I don’t have easy access to (non-domain PCs).
When a relay is installed, clients will not know about it until a) the relay is installed, b) the client reports back that it is a relay, and c) a master operator propagates an action (any action).
Step C is necessary because clients learn about relays via a file called relays.dat. Relays.dat is part of the master action site. If a relay has been added or removed, when the action site is propagated a new relays.dat will be created and gathered by clients as part of the new action site. Relays.dat lives in the action site rather than operator sites so that all clients are guaranteed to get a copy.
To sum up: Once a relay has been installed, a master operator must take an action before clients know about the new relay.
Though when the master operator takes an action, does only the clients contained in the action’s target only get the updated relays.dat – or do all clients get the new relays.dat as some propagation outside of the action?
This seems a bit odd in either case. You’d think this would be a little more automated that the clients would get the updated relays.dat the next time they check into the BES server. Much like virus definitions automatically get distributed when the client checks in. Adding/removing relays should be as simple as deploying the relay task and waiting for the clients to realize it.
So as an operator I can install a relay and manually assign it. But I need the master operator to really fix it for me. At that point your better off having 1 person deploy all of the relays via the master operator.
All agents get the updated relays.dat whenever any action is taken as a master operator. The reason you need to take an action as a master operator is because the relays.dat list needs to be digitally signed and it needs to go out to all the computers. Operators control only subsets of the computers and it would be inefficient to include the full relays.dat in every operator site (some of our customers have 5000+ relays in their deployments and relays.dat can be sizeable). So the best solution we came up with was to include the relays.dat in the actionsite.
If we re-architect it, we probably would include an ability for the agents to separately get the relays.dat instead of including it in the actionsite, which solves some of the issues you mentioned… we have discussed this and potentially will include this in a future version of BES.
Now I understand what’s going on. Right now its more of a sneaky way to get the relays.dat generated and signed by the master account via an irrelevant action.