Fresh Install Instead Of Migration?

Hello Jeremy,

before (perhaps) suggesting a course of action I want to dispel some common misconceptions and add some remarks.

disconnected (red x), but they are still getting the updates ⊕ add them to the SEC for monitoring

• Although they interact, updating (AutoUpdate) and communication (RMS - monitoring and management) are in principle independent
• Each component can work without the other being present or in a working state
• They don't have to connect to the same server
• Communication is always established by the endpoint, the management server can't "find" an endpoint and commence monitoring and management (or be told to do it)

In an air-gapped environment the SEC versions should be identical (although it obviously causes no problem at the moment)

no problems with the physical clients talking to SEC
this suggests that the problem is not the server, SEC, or your basic setup. Rather it's probably the handling and integration of the VDI clients and likely neither migration nor a fresh install will solve the issue

I'm not able to protect computers remotely
As your network consists of mainly VDI clients I assume this statement applies also to them. Normally you prepare the VM image with either AutoUpdate installed and ready to set up the rest or all of Endpoint appropriately pre-installed

VDI clients
a lot depends on the details. Whether they are persistent, naming/DNS, turn-around

As said, your basic setup seems to be correct. The, IMO, first question is why endpoints apparently don't communicate with the server when [you] protect [them] manually. In order to establish communication they first connect to the server's port 8192. The response usually directs them to the server's port 8194. For details please see Troubleshooting disconnected endpoints ....

Christian 

Christian,

Thanks for the reply.

I've done a little more digging and I found that in the router logs on the VDI clients have different CertificationIdentityKeys in the registry than the keys in the MRinit file on the Sophos Server. Even if I re-protect the client manually or remotely it sets it back to the wrong keys.

I've tried searching for all the MRinit files on the server to see if the Keys were the same as each other and they were, but for some reason when I try to protect it, it still gives the wrong keys. 

Do you know what could cause this problem? Thanks.

- Jeremy

Hello Jeremy,

as reprotect is one way to "move" the endpoints to a different management server it's supposed to change the keys ... hm, no idea at the moment what would set them back. Where are those keys from? An old server long gone?

Christian

Hello Jeremy,

as reprotect is one way to "move" the endpoints to a different management server it's supposed to change the keys ... hm, no idea at the moment what would set them back. Where are those keys from? An old server long gone?

Christian

Christian,

So I installed a fresh install of SEC 551 on our new Server 2016. I had to put the server in a different OU in Active Directory in order for us to use our domain admin accounts to initially install SEC 551. After installing Enterprise Console, it was giving the same issues as mentioned above and after digging around I found that when I protected a client, remotely or manually, it was taking the mrinit info from 'mrinit.conf.orig' and not the 'mrinit.conf' file. So I copy/pasted the data from 'mrinit.conf' to 'mrinit.conf.orig' and everything working perfectly.

So here is my problem now... As I said before, I move the server to a different OU so I can install SEC551 with a Domain Admin account. When I moved it back to the original OU and open SEC, I now get a error saying that my account needs to be apart of at least 1 sub-estate, which it is. I moved it back to the OU with domain admin access to see if it works again, but I still get the same error.

I reverted back to snapshot and try to do exactly what I did before to make it work and now I still get the same error. Do you know where it could be hung up on? Thank you.

- Jeremy

Hi Jeremy Reyes 

I just wanted to confirm if you have already performed the steps mentioned in this article? Also, kindly check under Frontendservice.log( C:\Users\<logged-on-user>\AppData\Local\Sophos\Sophos Endpoint Management\log\ </logged-on-user></logged-on-user>) if you see any error? 

Hello Jeremy,

mrinit.conf.orig
I'm a little bit surprised that this is seemingly the cause for the different keys. mrinit.conf.orig is usually created when you add a message relay or modify mrinit.conf for some other reason. Until SAV 9.7 (sic!) a reprotect/reinstall left it behind but since then this should no longer be the case. RMS should AFAIK refuse a re-initialization that changes the keys.

As to the sub-estate issue: I'm not sure I understand correctly how the OU comes into play. 
Hm ... found a not too old unresolved thread that describes a similar (or the same) issue. Can't say what the cause is or how to solve it (other than by contacting Support).

Christian

Looks like I fixed all the issues I was having.

Sub-Estate Error:

   When I first built the 2016 server and installed SEC 551, I allowed ports 8192, 8193, and 8194 so RMS can communicate through the firewall. To my mistake I put those ports for

   Inbound and Outbound. Inbound was correct, but for some reason, putting those ports for Outbound gave me the Sub-estates error.

Issue with machines always saying disconnected, but still updating A/V Def:

  This also fixed my ability to Protect my endpoints remotely (from SEC). 

  The main problem was in the registry. The registry showed old information that was taken from an older mrinit file. The values for DelegatedManagerCertIdentityKey,

  ManagedAppCertIdentityKey, RouterCertIdentitykey, and also the ParentRouterAddress were different in the endpoint's registry than what was showing in the mrinit file in CIDs location on

  the A/V server. No matter how many times I tried re-protecting the client/endpoint, it kept populating with the same old mrinit information. I dug deeper and found it was taking it from

  the mrinit.conf.orig file located in 'C:\Program Files(x86)\Sophos\Remote Management System' on the client. So I just copied the updated mrinit information from the A/V server

  and pasted it in the mrinit.conf.orig file that was on the client. I re-protected the endpoint and everything was good after that. SEC showed it was connected and I was able to protect and 

  update remotely. 

Issue with VDI clients communicating with SEC:

  This is a similar issue with the problem above, but in order so ALL VDI clients to communicate with SEC, you have to edit the master image. 

  In the Master image protect the endpoint regularly, if it's the same situation as above, then you must do that first. Once Sophos Protection is installed successfully and communicating

  with SEC, you have to stop all the Sophos services and go into the registry of the master and delete pkc and pkp files located in the following locations:

    [HKEY_LOCAL_MACHINE\Software\[Wow6432Node]\Sophos\Messaging System\Router\Private]

    [HKEY_LOCAL_MACHINE\Software\[Wow6432Node]\Sophos\Remote Management System\ManagementAgent\Private]

  You must also delete the machine_ID.TXT file located in the following:

       C:\ProgramData\Sophos\AutoUpdate\ or C:\ProgramData\Sophos\AutoUpdate\data\

  Without starting the services back up, shutdown the master server, create a snapshot then recompose the VDI clients with that master image you just created. When it's

  finished recomposing, the files you deleted will re-populate with it's own information and will be able to talk with SEC.