This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Fresh Install Instead Of Migration?

Hi All,

Currently I have SEC 5.5.1 running on Server 2008 R2 and there are many problems with it I tried fixing the past few months with no avail. For example the majority of my VDI clients say disconnected (red x), but they are still getting the updates definitions when I upload them, I'm not able to protect computers remotely, when I protect new endpoints manually and add them to the SEC for monitoring, it stays greyed out.

Instead of migrating it, is there a way to give my Server 2016 a fresh install and still have the endpoints point to the new server instead of the old one? I've tried migrating 4 times already and either SEC doesn't open or if it does open, the same problem persists or even worse, it shows none of the endpoints are connected.

 

Network Details:

- Standalone Network

- We get our A/V defs from a computer that has internet connection and SEC 5.5.0, transfer it to a external drive then place the files in the necessary locations for the standalone A/V server to download the new binaries.

- Network consists of mainly VDI clients and VM Servers with a handful of physical desktops and servers (no problems with the physical clients talking to SEC).

- Server 2008 uses local accounts to administer SEC, but I would like to use only network accounts for the new server.

Any guidance will be greatly appreciated. Thank you.

 

Jeremy



This thread was automatically locked due to age.
Parents
  • 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

Reply
  • 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

Children
  • 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  

    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? 

    Shweta

    Community Support Engineer | Sophos Technical Support
    Are you a Sophos Partner? | Product Documentation@SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
    The New Home of Sophos Support Videos! - Visit Sophos Techvids
  • 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.