Troubleshooting Client Registration

One single client among many similar computers cannot register with the server. In the client log file I’m getting:

RegisterOnce: Attempting secure registration with 'https://<besserver>:52311/...'
RegisterOnce: GetURL failed - General transport failure. - 'http://<besserver>:52311/...' http failure code 0

It doesn’t appear to be any sort of winsock error, almost like the BigFix server is refusing this ID?

Normally a client will succeed with a log line line this:

Registered with url 'https://<besserver>:52311/...'

So the hop from HTTPS to HTTP is possibly the issue here.

How else can I troubleshoot this? Is there a way to debug the TLS connection? I’ve tried:

  • Removing the client with the latest BES Remove Utility, and reinstalling.
  • Running the BES Client Diagnostics, which report that network connectivity is OK (over HTTP), and the that the client is not registered.

Hello sryn,

Could you please try to use an IP address instead of a hostname for a Server/Relay the Client is trying to register with?

Also a similar issue was resolved by reducing the MTU size on a Server/Relay (when the VPN encapsulation added overhead to the packets, causing them to exceed the Path MTU and get fragmented)

Regards,
Vitaliy

OK, I’ll try - is the best way to edit the registry and change the __Relay_Control_RootServer to use an IP instead of a hostname?

I have confirmed it’s not a name resolution issue.

There's no way it's DNS

__RelayServer1 and __RelayServer2

Are there registration logs on the server?

IP adresses don’t seem to make any difference. I can retreive files off the server from the unregistered client over HTTP, for example,

$url = 'http://<besserver>:52311/cgi-bin/bfgather.exe/actionsite'
Invoke-WebRequest -UseBasicParsing -Uri $url

StatusCode        : 200
...

I can retrieve other secure websites from the same client, so HTTPS is not blocked by the network.

The fallback HTTP registration attempt fails at the server with http failure code 0, so it looks to me like the server is refusing to register just this particular client, possibly based on the parameters passed in the registration URL (MAC address, IPv4 subnet & address, client version).

http://besserver.example.com:52311/cgi-bin/bfenterprise/clientregister.exe?
  RequestType=RegisterMe
  &ClientVersion=9.5.10.79
  &Body=0
  &SequenceNumber=1
  &MinRelayVersion=7.1.1.0
  &CanHandleMVPings=1
  &Root=http://besserver.example.com%3a52311
  &AdapterInfo=b8-ae-ed-73-fe-b4_10.46.104.0%2f26_10.46.104.55_0
  &AdapterIpv6=b8-ae-ed-73-fe-b4%5efe80%3a%3a96c%3aa2d8%3a13b3%3a1c72%2f64_0

Can I debug this without packet capture?

The only reliable way (per devs) to verify DNS resolution would be adding a Relay’s IP/hostname into the Client’s OS hosts file. Also you may need to make sure that a DNS resolution is working both ways (a parent Relay should be able to communicate with a Client as well).

If that won’t get an answer, Wireshark could tell if there’s any communication between Client and Relay.

Is there Proxy/Firewall/VPN between Client and Relay?
Which OS is Client and Relay?