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
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.
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
