message relay changed to endpoint

Hello Tommy Rohner,

is the MR also a SUM?
You say changed - so it has been a relay for how long? If not a SUM, does it update from the correct CID (it should naturally do so even if it is a SUM but a SUM wouldn't reconfigure RMS)?

Christian

Hi QC

thx for your feedback.

Yes the MR is also a SUM. both servers are SUM (SEC and MR).

it has been a relay for about 1 week or even longer.

i guess it changed back because we didn't place the mrinit.conf file in the rms subfolder.

but how can we now change the endpoint to an MR again?

Hello Tommy Rohner,

I assume you did correctly install the SUM (i.e. SUM first, then Endpoint) - in fact the SUM installer should prompt you to uninstall RMS if it's already installed. It used to ignore changes to mrinit.conf (i.e. ClientMRInit refused to run) but it seems the logic has changed somewhat - logs from the 10.6.4 upgrade suggest that ClientMRInit did run on the relays (but not on the SEC server). For whatever reason there are no ClientMRInit logs though.

Is RMS listed in Control Panel → Programs and Features (it shouldn't be there)? Are there any install/uninstall logs with RMS or ClientMRInit in their name in %windir%\Temp?

As the logic seems to have changed, putting the correct mrinit.conf into the (correct) \rms subdirectory (don't forget to run ConfigCID.exe) might indeed resolve the issue.

Christian

Hi again

yes, we installed sum before endpoint.
no, rms is not listed in programs and features, there is only: SAV, SAU, SSP, SUM.
unfortunately there are no rms or clientmrinit uninstall logs..

we already made the changes in the mrinit.conf file again, and copied in the rms subfolder.
after running configcid.exe there is no change.
in reportdata.xml the routertype still shows endpoint instead of message relay.

i could do a complete reinstall but i'm afraid the routertype will change back again...

Hello Tommy Rohner,

i'm afraid the routertype will change back again
that why I've not yet suggest a "fix" as it might not persist.

Well, I just did a test changing a few letters in the Parent's name (in \rms\mrinit.conf), with the next update a Sophos RMS Install log was created in %windir%\Temp\. I've found the following (not the complete log, a snippet with some lines shortened):

Installation canceled - RMS will be managed only by the SUM installer.
CopyPrerequisite(from=C:\ProgramData\Sophos\AutoUpdate\cache\rms\, ...
Backing up `C:\Program Files (x86)\Sophos\Remote Management System\mrinit.conf`
Copying from `C:\ProgramData\Sophos\AutoUpdate\cache\rms\mrinit.conf` ...
Applying MrInit.conf settings: [ClientMRInit.exe] ...

This suggests that ClientMRInit has been called and indeed the registry values have been changed. ReportData.xml though has not been updated - apparently the Router service has not been restarted. Did the obvious, restarted the service and the NetworkReport reflected the changes in mrinit.conf. Please restart the Sophos Message Router and check if it reconfigures.

Christian

Hi Christian

No this won't help because i've already restarted the service after running configcid.
I also restarted the server so see if it helps but unfortunately it doesn't.

Hello Tommy Rohner,

the SEC server isn't involved. Is there an RMS Install log with contents similar to those I've posted? If not, could you try to change mrinit.conf (changing the case of one or more letters in one of the hostnames is safe and sufficient) and check if a log is created?

Not a solution but a workaround is modifying the registry keys to match the values (near the end under Technical information) in configuring message relay computers.

Christian

yeah i've found a log, but it's already a few days old:

Install from:[C:\ProgramData\Sophos\AutoUpdate\cache\rms]
Install to  :[(null)]
RMS: Current product is not installed.
TP: Successfully requested Sophos Endpoint Defense disable tamper protection of RMS.
MsiPackagePath: [C:\ProgramData\Sophos\AutoUpdate\cache\rms\Sophos Remote Management System.msi].
Result of loading C:\Program Files (x86)\Sophos\AutoUpdate\SAUConfigDLL.dll is: [71bf0000]
Installation canceled - RMS will be managed only by the SUM installer.
CopyPrerequisite(from=C:\ProgramData\Sophos\AutoUpdate\cache\rms\,                 to  =C:\Program Files (x86)\Sophos\Remote Management System,                 file=mrinit.conf)
Missing source file `C:\ProgramData\Sophos\AutoUpdate\cache\rms\mrinit.conf`

Restoring backup `C:\Program Files (x86)\Sophos\Remote Management System\mrinit.conf.orig`
Applying MrInit.conf settings: [ClientMRInit.exe] [-logPath "C:\WINDOWS\Temp" -filePath "C:\Program Files (x86)\Sophos\Remote Management System"]
TP: Successfully registered for tamper protection with Sophos Endpoint Defense.

Hello Tommy Rohner,

was the server protected before you installed SUM? The mrinit.conf.orig is usually created when the CID an endpoint updates from is configured with a custom mrinit.conf. If later the endpoint updates from an unconfigured CID it falls back to the original mrinit.conf.

Nevertheless, just modified mrinit.conf another time and the MR/SUM created a new RMS Install log. If your doesn't I wonder whether it is updating from the correct CID?

Christian

yes, the Server was protected by our old Sophos Environment.

I first uninstalled every Sophos product and then i installed the new SUM.

after modifying mrinit.conf, no RMS Install.log has been created. i've just tested this 5 minutes ago. but as i mentioned before, rms is not installed on the Server.

how can i check if the Server is updating from correct CID?

we have 2 cids on each Server (total 4).

Clients are updating from MR and MR is updating from SEC.

Hello Tommy Rohner,

how can i check
several ways (assuming you know which is the right CID [:)]): the console's Endpoints view, tab Update Details; the local Sophos GUI on the MR updating configuration; or (preferred) its Updating log which will show the location actually used.

MR is updating from SEC
please note that an endpoint running SUM has two distinct update processes: the regular AutoUpdate for the Endpoint software and SUM's product update. Also note that the contents of a CID are important, not where it's hosted. Normally a SUM/MR hosts the CIDs configured with an mrinit.conf that has the MR in the ParentRouterAddress. In order to recognize itself correctly as an MR the MR must update from such a CID.
You can have both a (MR-)configured and an unconfigured CID on one or both servers. Why two CIDs - different subscriptions?

Christian 

I'll try to explain a little bit better what our Scenario Looks like:

We have 2 Servers.

Server1 is SEC/SUM in LAN.
Server2 is MR/SUM in DMZ.
Server 2 has an internal and an external IP with Split DNS.
SUM on Server 1 gets Updates from Sophos.
SUM on Server 2 gets Updates from Server 1.

MRInit.conf in CIDs on Server 1 contain:
"MRParentAddress"="Server1"
"ParentRouterAddress"="Server1"

MRInit.conf in CIDs on Server 2 contain:
"MRParentAddress"="Server1"
"ParentRouterAddress"="Server2"

we have 2 Update Policies:
Default: for all Clients -> Primary update path: \\server2\SophosUpdate\...
SOPH: for the both Servers -> Primary update path: \\server1\SophosUpdate\...

for Updates we use WebCID (http).

we have 2 CIDs because we need previous recommended (for all Clients) and recommendend (for test Clients) Software Updates.
the 2 CIDs on Server 1 are identical with the 2 CIDs on Server 2, only the MRInit.conf files are different.

I'll try to explain a little bit better what our Scenario Looks like:

We have 2 Servers.

Server1 is SEC/SUM in LAN.
Server2 is MR/SUM in DMZ.
Server 2 has an internal and an external IP with Split DNS.
SUM on Server 1 gets Updates from Sophos.
SUM on Server 2 gets Updates from Server 1.

MRInit.conf in CIDs on Server 1 contain:
"MRParentAddress"="Server1"
"ParentRouterAddress"="Server1"

MRInit.conf in CIDs on Server 2 contain:
"MRParentAddress"="Server1"
"ParentRouterAddress"="Server2"

we have 2 Update Policies:
Default: for all Clients -> Primary update path: \\server2\SophosUpdate\...
SOPH: for the both Servers -> Primary update path: \\server1\SophosUpdate\...

for Updates we use WebCID (http).

we have 2 CIDs because we need previous recommended (for all Clients) and recommendend (for test Clients) Software Updates.
the 2 CIDs on Server 1 are identical with the 2 CIDs on Server 2, only the MRInit.conf files are different.

Hello Tommy Rohner,

seems almost correct, but only almost.

If all endpoints update from \\server2 then all would use server2 as message relay - probably not what you really want

If server2 updates from server1 it would use the mrinit.conf with "ParentRouterAddress"="Server1". The logic is as follows: If RMS finds its host's IP or name in at least one of the MRParentAddresses it knows it's on the management server. If there's a match with at least one of the ParentRouterAddresses it configures itself as relay. Otherwise it's on an endpoint and uses ParentRouterAddress as upstream router.

So if I understand you correctly - it is clear why the SUM/MR acts as endpoint.

Christian

yes, all clients using server2 as MR is exactly what i want :)

oh okay, thank you for the explanation. i see the problem now.
but when i set server2 to use the same update policy as all other clients it should be correct, right?

I've done that but now server 2 shows up as disconnected (red cross) in SEC console.
and reportdata.xml still shows "endpoint" on server 2.

Hello Tommy Rohner,

there should be an associated RMS Install log and if the service has been restarted reportdata.xml should have been updated. Apparently RMS has "downgraded", can't say if it works or should work in the other direction (upgrade to an MR) as well. Don't have a SUM/MR server to test.

If you restart the service the Router log should show potential issues in the first few dozen lines.

Christian

i can't see any issues in that logfile.

but apparently the clients are still communicating with the MR.

the only problem i have is that the MR can't communicate with the SEC.

so None of the Clients is up to date..

i'm gonna reinstall Server 2 and hope this will fix it.

now the reinstalled SUM Server (Server 2) won't show up in the console anymore..

router logs of server 2:

01.03.2017 16:38:01 0558 I SOF: C:\ProgramData/Sophos/Remote Management System/3/Router/Logs/Router-20170301-153801.log
01.03.2017 16:38:01 0558 I Sophos Messaging Router 4.1.0.140 starting...
01.03.2017 16:38:01 0558 I Setting ACE_FD_SETSIZE to 138
01.03.2017 16:38:01 0558 I Initializing CORBA...
01.03.2017 16:38:01 0558 I Connection cache limit is 10
01.03.2017 16:38:01 0558 I Router::ConfigureSslContext: keeping legacy compatibility of TLS 1 and TLS 1.1.
01.03.2017 16:38:02 0558 I Creating ORB runner with 4 threads
01.03.2017 16:38:02 0558 W No public key certificate found in the store. Requesting a new certificate.
01.03.2017 16:38:02 0558 I Getting parent router IOR from server2.domain.com:8192
01.03.2017 16:38:02 0558 I This computer is part of the workgroup WORKGROUP
01.03.2017 16:38:03 0558 I This computer is part of the workgroup WORKGROUP
01.03.2017 16:38:03 0558 E Failed to get parent router IOR
01.03.2017 16:38:03 0558 W Failed to get certificate, retrying in 600 seconds

shouldn't sever 2 try to connect to server1 instead of server2 ??

Hello Tommy Rohner,

looks like it doesn't know it's a relay (it's normally supposed to say Creating ORB runner with 16 threads). What does the Network Report say? To repeat, Parent should be server2 and MRParent server1. Even if it incorrectly tries to get the IOR from itself it should get a response - or perhaps not if it has not yet a certificate.
It seems to be able to resolve server2.domain.com. I think (and might be wrong) that when mrinit.conf contains just a FQDN and no IP, a potential MR must successfully reverse-resolve its IP to the FQDN.

BTW (I had to leave so I couldn't respond to your previous post): It's not an installation but a configuration issue so the reinstall wasn't necessary (and apparently doesn't help). Anyway, even if it seems tedious the resolution will be simple.

Almost forgot to mention: You should perhaps temporarily turn on verbose logging for the Router.

Christian

it works now :)

I did the following steps:

uninstalled SUM again
deleted all sophos folders in c:\program files(x86) and in c:\programdata
deleted all sophos registry keys in hklm\system... and hklm\software...
reinstalled SUM from \\server1\suminstallset

after that, Server 2 showed up in console and in reportdata.xml it says "message relay" again.

then i edited the 2 registry keys (serviceargs & imagepath) --> don't know if this is necessary

now everything looks like before..

just to be sure, is this correct now?

in the 2 cids of server 2 the parentadress of the mrinit.conf files point to Server 2.
-> updates for clients & MR

in the 2 cids of Server 1 the parentadress of the mrinit.conf files point to Server 1.
-> only Server 1 updates itself from here

is it still necessary to copy the mrinit.conf files in rms subfolders?
because there is no mrinit.conf file in these subfolders..

Hello Tommy Rohner,

is it still necessary to copy the mrinit.conf files in rms subfolders?
normally mrinit.conf is in the CID's root. It's applied during initial installation, later changes are ignored. If you want to "redirect" already protected endpoints putting it into the \rms subdirectory is one way to achieve this. If the the correct mrinit.conf was used for the initial install of the SUM, MR and the endpoints the copy isn't necessary.
Please note that you can't have CIDs with different mrinit.conf in the root directory on the same server and that changes to mrinit.conf in a CID's root do not persist as a SUM (over)writes the mrinit.conf from the location defined in the tag <RMSConfigPath> in %ProgramFiles(x86)\Sophos\Update Manager\system.xml to the root when deploying (updating) a share.

Christian

thank you very much for your help!
everything is fine now...
i just hope it won't happen again :)