We have all seen these types of errors in our BES client logs:
BES Clients error FAILED to Synchronize - General transport failure. - SOCKET CONNECT (winsock error 4294967288
What I wanted to ask is does anyone have a ROCK SOLID list of things to check in any particular order that a person could give the endpoint support team to walk through and get to the bottom of?
We all know what is the cause or causes of this, mainly firewalls and of course we can’t leave out blaming DNS in the way of comms. I would think any such list would include telnet cmds, ping cmds, nslookup cmds etc.
This can be a normal issue if the relay the client is currently talking to is no longer accessible due to it moving networks, but it has not yet found a new relay to talk to.
Sometimes this will just settle out once a new relay is selected. If that isn’t happening, that might be the bigger issue.
If the client is able to connect to the relay but only one side is working, then that is different. One side would be that the client can send reports but not sync sites, or it can sync sites but not send reports.
The main thing to check for is that 52311 TCP traffic can go from client to relay. The client should not block TCP 52311 outgoing and the relay should not block TCP 52311 incoming.
Moving back up to 10,000 feet, I think what we are really talking about is either a flow or step by step recipe on client to relay, relay to client comms and how to determine step by step that the comms are flowing nicely or if they are not, how to zero in on where the issue is.
While the error itself, and even confirming/validating it outside of the BigFix Client is relatively straightforward, identifying root cause of the issue comes down to troubleshooting network connectivity, for which there are many potential factors (most of which are not related to BigFix itself).
We do need to fix the numbers associated with the error codes described in this article, but it does provide high-level guidance on the issue:
err_SOCKET_CONNECT - The IP address of the BigFix Server/Relay is found, but the connection could not be established
We can likely come up with a potential flow on things to check, but it’s difficult to account for all the potential environmental factors.
We can almost certainly expand on this, but these are some of the questions I would typically ask/review in such scenarios:
is the device connected to the network?
does it have an IP address?
is it able to communicate with its gateway?
is it able to resolve DNS? (this particular step shouldn’t be a factor in this case since the error returned would have been err_BAD_SERVERNAME if DNS was the issue)
consider a traceroute to identify where the break in communication may be occurring (this may require some knowledge of the network in question)
other considerations here:
is the device communicating through a proxy?
is there a firewall (hardware OR software) between the device and the relay?
there are a lot of potential software products running on the endpoint that might interfere with network connectivity
are other devices able to register with the relay in question and/or exhibiting the same behavior? are they on the same network, or different networks than the Client failing to communicate?
I don’t think I’d try to rewrite a “general” network troubleshooting guide, there are plenty of them out there. Just to hit the bullet points though
DNS
Ping
Traceroute
Probably the most useful BigFix-specific thing I could think of is a connectivity test to the relay. A client should be able to connect to http://relay.domainname:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=Version and retrieve a version number from the deployment. This should be possible from a browser or ‘curl’. I usually recommend ‘curl’ because it tends to bypass proxies configured in the browser, behaving more like BESClient itself.
That wiki link references an old version…the newest version of the wiki page in question points to the following link which has been updated: