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.
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
Hello Peter,
it has changed over time, the SID is no longer used.
Basically the endpoint generates a GUID during install and registers with the management server and requests a client certificate. Apart from this IdentityTag a number of other attributes is also recorded, the main potentially identifying attributes are Name, OS (version), and workgroup/domain. If you take an image at this point all machines derived (without performing additional steps) from this image will appear as the same.
This is because the management server attempts to identify a machine as "the same" in two disparate scenarios
Please note that identical names are permitted if
Thus if an endpoint registers with a yet unknown name and IdentityTag a new computer object is created. If it registers with a known Name,OS,workgroup triple the IdentityTag of the existing computer object is updated. V.v. if the IdentityTag is known. In case of AD Sync a computer object with the applicable triple is searched for, if none is found one with an empty IdentityTag is created.
Actually it's a little bit more intricate, the logic has been refined over the years, and it's not perfect. It can't be without added complexity.
Christian
Found another way to create duplicates.
Had a W7 PC that a tech installed AV on and the PC was still in the default Computer OU (which is excluded from AD Sync).
The install will complete buy communication to the SEC fails which is normal and the PC is added to the Unassigned group.
I moved the PC to a custom group (non-AD Sync) and then did an update.
The updated worked and I restarted.
I then moved the PC to its correct OU which is part of the AD sync and magically I now have duplicates.
I deleted the PC and forced an AD sync. My grey out PC is in the AD sync group and my green PC is in the custom group.
SEC gets confused why to easily.
More weird Duplicate issues.
Seeing how the AD sync is only a one-way process you have to find you stale endpoints in SEC and delete them. A normal process.
So I did my SQL query and delete the duplicates.
I then deleted unmanaged and stale (over 45 sense last checkin) workstation.
Came back an hour later (AD sync is set to every 30 minutes) and noticed that my unmanaged number had really jumped.
Queried the for duplicates and had a 160 duplicates. Weird as I had none before the clean up.
Hello Navar Holmes,
communication to the SEC fails which is normal
not sure what you mean by communication as and the PC is added to the Unassigned group suggests that RMS did correctly register and communicate (otherwise the endpoint wouldn't appear in the console). One important detail is whether the computer joined the domain before or after the Sophos install and, as said, depending on the order of actions timing can be critical.
[SQL] delete the duplicates [...] deleted unmanaged
delete is overloaded as for the database it means actual removal but a console delete just "hides" a computer but leaves it in the database. Again it's not clear what exactly you are referring to: If delete the duplicates means deleting computers with names that exist more one time then this should already have taken care of the unmanaged ones. That it causes lots of duplicates to appear indicates that something is fundamentally wrong with this specific procedure (and not with SEC).
Christian
I deleted all of my duplicates from the SQL database. The SQL query deletes the endpoint twice. 2 x 84 = 168 as this is the only and best way to delete duplicates.
For actively managed endpoints that had a duplicate, they will re-populate in the Sophos Enterprise Console when they check in for updates or is restarted.
There are now no duplicates showing in the Sophos Enterprise Console.
I then deleted all my stale endpoints that were in the Sophos Enterprise Console.
Why? Because the AD sync in the Sophos Enterprise Console is a one way process and the Sophos Enterprise Console has no way of knowing when an Endpoint has been deleted from AD.
Note: This is also a normal maintenance process to the Sophos Enterprise Console Administrator if you want to keep your numbers accurate.
I then checked for duplicates in the SQL database and found none.
I then forced an normal AD sync to run.
Then checked for duplicates in the SQL database and found a 168 of them.
Why??? When the AD sync happened it should have only pulled in endpoints that were still in AD.
Either AD is keeping multiple copies of endpoints. Impossible. So that only leaves Sophos Enterprise Console and its SQL database.
I deleted all of my duplicates from the SQL database. The SQL query deletes the endpoint twice. 2 x 84 = 168 as this is the only and best way to delete duplicates.
For actively managed endpoints that had a duplicate, they will re-populate in the Sophos Enterprise Console when they check in for updates or is restarted.
There are now no duplicates showing in the Sophos Enterprise Console.
I then deleted all my stale endpoints that were in the Sophos Enterprise Console.
Why? Because the AD sync in the Sophos Enterprise Console is a one way process and the Sophos Enterprise Console has no way of knowing when an Endpoint has been deleted from AD.
Note: This is also a normal maintenance process to the Sophos Enterprise Console Administrator if you want to keep your numbers accurate.
I then checked for duplicates in the SQL database and found none.
I then forced an normal AD sync to run.
Then checked for duplicates in the SQL database and found a 168 of them.
Why??? When the AD sync happened it should have only pulled in endpoints that were still in AD.
Either AD is keeping multiple copies of endpoints. Impossible. So that only leaves Sophos Enterprise Console and its SQL database.
Hello Navar Holmes,
they will re-populate in the Sophos Enterprise Console when they check in for updates
(minor) correction: When they send a message to the management server. This can be a status message, an alert (detection, cleanup, change of settings), an event, or an error. Of course after an update the status is sent, likewise after a stop/start of certain Sophos services, and naturally a reboot.
delete stale endpoints [because SEC] has no way of knowing when an Endpoint has been deleted from AD
SEC does detect that a computer is either moved outside a synchronized OU or deleted (which of the two it can't tell as it does not query OUs outside the synced containers), in this case it moves the endpoint to the Unassigned group. Actually it can never tell that an endpoint is gone for good - my "record" endpoint resurfaced after almost five years(!), really.
I deleted ...
using DELETE FROM whichTable? WHERE ... ?
168 duplicates - Why???
indeed this is the serious question and a puzzler. Your description is coherent (up to this point), the procedures are appropriate, and I agree with AD not keeping multiples. I'd also expect that the SQL database is consistent and records that are gone are truly gone. SEC's AD Sync doesn't keep a slave cache and SEC doesn't keep a copy of the data outside the SQL database. Hm ...
So these 168 computers ...?
You do have computers that are correctly synced, haven't you? Do you have sub-OUs (and thus sub-groups under the syncpoint), if so can you move a computer to another sub-OU and is this move reflected in SEC?
It is AFAIK possible to trace synchronization (as well as other actions performed by the management service), I don't have the details on how to enable it at hand though and even if I could find them they are perhaps outdated. You'd need assistance from Support.
Christian
