We'd love to hear about it! Click here to go to the product suggestion community
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.
- 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.
Hi Jeremy Reyes
You can install Sophos Enterprise console on 2016 server, and re-direct the endpoints using this article. The error you are facing that the endpoints are showing disconnected, I would suggest you check this link for the same and see if it helps. You can also post this query or either join the Endpoint and security group so that I can move this post to the relevant group if required so that other users might help regarding this issue.
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
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 SECthis 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 remotelyAs 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 clientsa 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 ....
In reply to QC:
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.
In reply to Jeremy Reyes:
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?
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.
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?
mrinit.conf.origI'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).
Looks like I fixed all the issues I was having.
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
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\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\
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.
recomposing, the files you deleted will re-populate with it's own information and will be able to talk with SEC.