Most Clients Shown As 'Disconnected' in SEC 5.5.0

Hello John P, Ian, and other interested parties,

(I thought I've done so but) I've not yet explicitly said that verbose logging showed that

• the adapter is considered already active (otherwise a check-loop is entered)
• the first call to IPAddressSet::InitialiseWithHost() correctly adds both localhost and the actual IP4 address
• either Resolving the root object adapter... or Creating MessageRouter CORBA object... take localhost as resolved IP

Unless there some additional debugging option (which Support would have to reveal) further attempts from our (your) side to find or help in finding the prime reason are purportless (but perhaps educating). Inspecting other logs, network traces, registry and other comparisons will just show the (expected) consequences of the incorrectly set IOR - not why it has been incorrectly set in the first place. Development should know what happens at this point (and if necessary how to obtain actually helpful information).
Even if you are able to find the cause on your own you'd likely have only the option to work around until RMS is updated: Delayed start, service restart, adapter disable/enable. IMO the first has the least side-effects.

You can check the status of your case at Sophserv. 

Christian

Hi John,

Our last correspondence with Sophos was on Thursday evening when they advised that this issue had been escalated to one of the Level 2 Escalation Engineers.  This morning we emailed Sophos for an update and, to be honest, complain on the basis they only ever appear to respond when prompted. The outcome of this is that an engineer is now reviewing the escalation note and that this may include speaking to the Sophos GES/DEV team on our behalf.  Once again we referred them to this thread. 

Ian.

Hi Christian,

Thank you for your input, as usual it has proven quite helpful.

Forgive me if I have been 'over-posting' in relation to this issue. I was hoping to gain some better understanding of what the underlying issue is and if anyone else had encountered something similar in their SEC instance.

I have to say, however, that the response from Sophos Support (via Sophserv) has been less than stellar. I have updated the submitted support case a few times with my findings and have not received an update of any sort.

Looks like we will go with the delayed start for the Sophos Message Router service as an interim.

Many thanks and best regards,

John P

Cheers Ian,

Thanks for the update. If I hear anything back on my end, I'll keep you posted.

Best regards,

John P

Hi John,

Following your post I have reviewed the registry keys here on two devices that are working and two devices that are unable to connect to the SEC.  One of the devices that is unable to connect to the SEC is a laptop with a clean install of Windows 10, the other three have been deployed for many months.  The registry key HostIPToParent entry on the two 'disconnected' devices is shown as a REG_DWORD with a value of 0x00000000 (0).  On working devices the registry keys differ between devices and follow a similar pattern to those you identified i.e. ac1e0515 (2887648533)

One other observation is that on all four devices the Router registry entries were located under HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Messaging System\Router i.e. not under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\Messaging System\Router.  This is perplexing, especially in the case of the clean install.

Ian.

Hello Ian,

just the IP address (172.30.5.21), containing the IP of the adapter used to communicate with the parent.

Is there even a \Wow6432Node\ subtree, could these be 32bit systems?

Christian

Hi Christian,

Kudos for working out the IP address from the registry value.

All computers and laptops are 64-bit systems.  The WOW6432Node subtree exists.

Ian.

Hello Ian,

64-bit systems
strange, RMS is a 32bit application, but apparently it works (when it works) regardless.

Christian

Hi John,

We have been using the netstat -ano | findstr :8194 command you provided.  The Level 2 Escalation engineer contacted us this morning after waiting for the GES\DEV team to put a mentoring note on the case and advises the issue seems to be with the IOR string not finding the IP address of the server, it is finding the loop back address. 127.0.0.1.  This would suggest they haven't been following this thread.  The engineer provided a link to http://sophos.com/kb/17268 and requested we add an entry to the hosts file on the server for 127.0.0.1  This we have done to no avail.  The article referenced the Sophos Network Communications Report.  The report which can be accessed via Start > All Programs > Sophos > Sophos Endpoint Security and Control > View Sophos Network Communications Report lists the current state of communications with Enterprise Console and attempts to identify any problems. 

Ian.

Hello all,

I wonder if I'm the idiot here ...
This is IMO a ridiculous answer. I can only imagine that this came about because only partial information has been passed on with an extra big amount of self assurance.

add an entry to the hosts file
yeah, for thousands of endpoints, and yes, assigning static addresses for all hosts and adapters in DHCP? And maybe I'm misinterpreting the logs but there's clearly a Local IP addresses: 10.63.14.118 entry before it spits out 127.0.0.1. You can't achieve more than that with etc\hosts.

Whatever Level 2 is these days, I'd like to know what information was passed to GES/DEV and what they have put into the note.   

Christian