Is there a method to find duplicate computer names in SEC easily? Finding I have to go through each one of our groups and go down the list and eyeball them, which takes a long time with 30+ groups and 6800+ clients. How is this not a built-in feature
Hi,
Is this not supported "fix" still the only option? We have 76 duplicates of machines that definitely have Sophos on (and in some instances are servers) yet they are appearing twice. Deleting both entries from the SEC make them disappear for an hour and they the AD sync happens and they are both back. The greyed out one shows the correct OS info, but the "connected" one shows it as unknown.
Its getting a little tedious now :(
This is a known bug with SEC.
I had 609 duplicates which was about 20% of my endpoints.
Worked with support to delete all 609 endpoints.
For anyone having this issue, it would be best to go thru support so they can log another customer that is having this issues and to have them run all SQL query to clean it up.
One of the reasons this happens is the AV is installed on the endpoint before it was joined to the domain. And the other is the wind changed direction.
This is a known bug with SEC.
I had 609 duplicates which was about 20% of my endpoints.
Worked with support to delete all 609 endpoints.
For anyone having this issue, it would be best to go thru support so they can log another customer that is having this issues and to have them run all SQL query to clean it up.
One of the reasons this happens is the AV is installed on the endpoint before it was joined to the domain. And the other is the wind changed direction.
Do you know what the queries they ran are? Interesting how they see and know that this is a bug, but won't come up with a more complete fix.
Ha!
We ran the delete from computersanddeletedcomputers where name = 'COMPUTERNAME' and the duplicates disappeared-great. Once the sync happens the machine in question appears-but greyed out. Connected to the machine and it appears on the client to be working fine and updating.
At a total loss now on fixing this.
When support run the query that deleted the duplicate name it was done to delete all 609 (304 computer names).
I then forced an AD sync. Any endpoints that came back greyed out but had a working AV installed, I just did Protect Computer which really need to be done so the SEC and the endpoint synced up. I could have waited until the endpoint checked in but I felt that the wind had been blowing to much outside and the endpoint might not check in correctly.
A week later I ran the query that identifies duplicates and there was 61 of them. Not sure why this happened. I had communicated with staff to only install AV once the PC had been joined to the domain. Not sure if this is an issue with our 4 DC not syncing fast enough but I would see other DC issues and I am not. It could be that the techs are joining the domain, restarting and then installing AV but the SEC AD sync has not happened, currently set to 30 minutes, and the SEC thinks the PC is not joined to the domain yet and this is what I am thinking is happening. But what I don't know is SEC intelligent enough to know if the PC is a member of the domain or does it just look at if it is part of the OU sync.
I am going with SEC Security Made Simple not intelligent because the AD sync is a one way process, it only looks at what is in the OUs it is syncing, and if a PC is deleted from AD, it doesn't get deleted from SEC on the next AD sync. You have to manually find all of your stall PCs and deleted.
I still have an on-going ticket with support on this and will update when and if we figure out why duplicates keep showing up.
Thanks for this. Seems as though this is a "know issue" yet we don't have a proper fix in place.
On Thursday (just before a long bank holiday in the UK) we ran into a issue where no machines were showing as connected on the SEC-not a single machine was showing connected. This was of course of serious concern and a call to Sophos Support resolved it (essentially the envelope folder went into six figures). Support engineer was excellent, however looking at the time when the machines stopped talking to the SEC was about the time we ran the SQL script to delete one duplicate. Coincidence? Not sure, but I will proceed with caution next time.
My approach to this know issue/bug is to have Sophos support do all the deleting of the duplicates.
This way they document in their records that they had another customer call in with the duplicate issue/bug and this forces Sophos to take ownership of the issue/bug.
When support deleted my 609 duplicates, I saw no issues with SEC other than more duplicates show up again.
We are hosting the SEC database on an Enterprise MS SQL server.
From what I have seen just because you have duplicates doesn't mean your endpoint is not protected. They might not be getting the most current polices, and they might not be able to communicate with the SEC but they should be communicating with Sophos directly for updates. Should be....
I will say this it appeared that after the 609 were deleted, SEC started preforming better.
With SEC being a 110% reliant on DNS, your endpoint might be confusing SEC when their IP change and a Duplicate created. This is just a thought.
To reduce the DNS issue and permissions to the update folder, Support and I created an Alternate update location. I set the share to full control for everyone, and the security to read for everyone. this appears to have helped with updating and duplicate issues.
Thanks for this, very informative. I agree that DNS is probably critical to how Sophos operates (and lets be honest AD in general relies upon DNS working properly), so makes sense. The alternative update location is an interesting one- at the moment it is set to Sophos
We have laptops flipping between LAN and Wireless LAN quite often if people do to meetings, etc. Perhaps this is causing an issue with the SEC?
Our setup is similar to yours that the SEC database is on a separate MS SQL Server (Cluster)/
We host SEC internally. But looking at Sophos Central.
If you did a standard default install, the primary location should be a share off the SEC which took all the default share and security permissions which I feel some of our endpoints get confused with. As you might have figured out already Sophos doesn't like netted security groups. This is why you must add your domain admin account directly into the PCs local Sophos Administrator group if you want to uninstall Sophos AV. This is also also why Sophos gets confused (also a factor that creates duplicates) when you install AV before you join the PC to your domain as the cloned local security groups will not get updated once the PC is joined to the domain with domain security groups.
This was one of the reasoning why I set the alternate update location share to Everyone and the security to Everyone Read.
You might want to try creating an alternate location for updates and have these laptops use it.
Hello Navar Holmes,
you must add your domain admin account directly into the PCs local Sophos Administrator
I've already dissented from the must. As you say you encounter problems when you install AV before you join the PC to your domain - admittedly there's no documented recommendation to first join the computer and then install Sophos (AFAIK there has been one when the groups' SIDs instead of the names were used in the configuration). It's by design (and documented) that the Sophos groups are not modified after the initial install. I can't see why Sophos has to be installed before joining the domain.
Definitely Sophos' local security groups and the update location(s)/policy are not related in any way.
Christian
