Fresh Install Instead Of Migration?

Question

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

Jeremy Reyes · Accepted Answer

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.