Duplicate Computers in SEC

Hello CR Hiestand,

could you post a partial screenshot of duplicates on the top level view, tab Computer Details (minimize the IP address and Last user columns)? Would make it easier to guess what could be the cause.
If the computers in Unassigned are unmanaged (grey) or Disconnected (Last message time "old") you could simply delete them (don't worry if you accidentally hit a live one, it will reappear).

Christian

Hello CR Hiestand,

you've blanked the Domain/workgroup column - I assume the managed entry contains the correct value, the other none?
AD sync had its peculiarities, thought most of them have been sorted out. If you delete the Unassigned ones - do all of them pop into existence again with the next sync? And is this a new issue or has it been going on for quite some time (i.e. previous SEC versions and the database has been migrated)?

I'm not sure why they're returning - me too. Tried to find some idea in older threads (did I say that the Search in this Community ... has still some potential for development?), nothing that looks like a solution though. Just in case you are curious:
https://community.sophos.com/products/endpoint-security-control/f/3/p/8773/21956
https://community.sophos.com/products/endpoint-security-control/f/3/p/2694/4076#4076
https://community.sophos.com/products/endpoint-security-control/f/3/p/8773/18275#18275      

Christian

Hello CR Hiestand,

as the logic apparently fails to manage this correctly it's either that
a) the logic is (still) flawed or
b) there's an inconsistency in the database that the logic isn't supposed to be able to handle
You'd have to contact Support for investigation (can't say though if they are able/willing to analyze and if necessary escalate it or just try to help you "fix" it). The Management Service permits to trace a lot of things (including AD sync and subsequent actions) - did this once in a Beta.

I wonder if you have not only duplicates but more than two computers for each name (and perhaps this is what confuses the logic)?
sqlcmd -E -S .\SOPHOS -d SOPHOS521 -Y 20 -Q "SELECT Name,COUNT(Name) FROM ComputersAndDeletedComputers GROUP BY Name HAVING COUNT(Name)>1"

I'd check one or two of the multiples
sqlcmd -E -S .\SOPHOS -d SOPHOS521 -Y 20 -Q "SELECT Name,ID,DomainName,Deleted,Managed,InsertedAt,LastMessageTime FROM ComputersandDeletedComputers WHERE Name='computer'"
might or might not give some insight.

On second thoughts - might suffice if you use PurgeDB to get rid of the unmanaged entries. Nevertheless it's a good idea to perform the above checks before and after to see what PurgeDB did.

Christian

Hello CR Hiestand,

ran the commands (actually a slightly modified combination of them) against my database and - lo and behold! - I too have a few duplicates. I am not using AD sync and all are managed ones (we do not discover/find and use protect, only rely on the endpoint contacting the server after install a custom package with the GroupPath option). I've in addition selected the MessageSystemAddress and IdentityTag. The results suggest that at least one object in each tuple has been renamed (after it has contacted the management server for the first time).

a group path [...] so policies are applied
you can apply initial policies to the base image as per 12561 section 2, members of the Unassigned group do not receive policies but nevertheless keep the existing ones (in other words, moving an endpoint to Unassigned does not clear or reset the policies). Just in case: GroupPath is a one-shot parameter but perhaps you have read and are referring to Moving a computer between groups ....

... and please follow up with what Support said or how you decided.

Christian

Hello CR Hiestand,

was asked to run the diag utility
boilerplate reply for problems with non-obvious cause. I doubt that the standard logs will give any insight though. BTW: Do you know SophServ? Click    All other products   on the Contact Support page. Be insistent. As said, the current SEC versions should handle sync correctly and perhaps your particular workflow exposes a flaw - but that's mere speculation. But whatever Support intends to do they should keep you updated. 

Christian

Hello CR Hiestand,

was asked to run the diag utility
boilerplate reply for problems with non-obvious cause. I doubt that the standard logs will give any insight though. BTW: Do you know SophServ? Click    All other products   on the Contact Support page. Be insistent. As said, the current SEC versions should handle sync correctly and perhaps your particular workflow exposes a flaw - but that's mere speculation. But whatever Support intends to do they should keep you updated. 

Christian

The case was eventually escalated and I spoke to an engineer for a while on the phone. The issue comes down to computers being reimaged and keeping the same name (something that occurs very often here with ~9,000 computers in SEC). When the reimaged computer reports to SEC, it has a new ID and thus is not matched to the synced computer from AD which has the old ID. 

I'll have SQL remove duplicate computers on a daily basis which seems to resolve the issue. I'm not sure this is something that can ever be resolved given that the name is not being used as a primary key in the DB and since the DB keeps all "deleted" computers. 

Hello CR Hiestand,

I spoke to an engineer
now I'm not qualified to second-guess the engineer's statements but this is IMO no satisfactory explanation. Reimaging is not an unusual case and it is provided for, it definitely works when AD sync is not involved (and basically it's the same as an uninstall and reinstall). .... I've just done that with a computer in a synced group (and made sure that it has a new IdentityTag, MessageSystemAddress and cert), no second entry has been created. Did this once more installing with an explicit GroupPath. Endpoint disappeared from the synced group as expected, checked the database - no duplicate, it was the same computer with changed attributes. Next sync move it to the synced group.
Then I renamed the endpoint (but not in AD), as expected it appeared in Unassigned and they sync created a new computer with the original name in the synced group. Upon renaming the computer back the two (now identically named) computers weren't merged or changed places (regardless of their console-deleted status). Once all (but one) computers with the same name are database-deleted it automatically gets in sync (forgive the pun).

Thus after the database-delete duplicates shouldn't recur except when a reimaged computer has a generic or temporary name, has Sophos already installed and contacts the management server before it receives its final name. 

Christian     

I did express to the engineer that it'd be nice to have an actual solution to this, instead of scheduling an automated task to remove duplicates in SQL. 

Perhaps this is really related to Sophos being pre-installed on all computer images. It seems that because of this, when a computer is imaged, it generates a random ID (not sure if it is the IdentityTag or MessageSystemAddress), which no longer matches the endpoint that is being synced from AD. 

Hello CR Hiestand,

as said, my test showed that if Name (and DNSName), Domain, and OS match (upon the first contact of the endpoint with the management server) the ID of an existing computer object is (correctly) replaced. But I'll think (ovver the weekend) about other scenarios and whether the could cause duplicates. [:)]

Christian

Hello again,

I'm dense, apparently. Letting the endpoint contact the server before it has joined the domain should cause duplicates. When it first contacts the server it doesn't match the entry from AD (might also apply in case of a "stub" entry from AD) because of a different Workgroup/Domain. Afterwards the joined endpoint matches the (known and new) ID and thus not the old object.

Didn't think of it first as we install most software (including Sophos) after joining the endpoint. If Sophos is (should be) already on the image, have the Sophos services disabled (perhaps reenable them with a GPO), using a DomainNameOverride value in the registry (it should be deleted later) might also do.

Christian

That's probably the issue. I'll test with our imaging process with disabling the Sophos services until after the join to AD is completed. We definitely need to keep Sophos on the image given the number of endpoints we have and only one SEC.

Since the DB keeps all of the old Deleted entries, did this stop you from having new similarly named systems not deploy properly? Ending up with blank or minimal computer details? 

We install Sophos on base images, so deploying isn't an issue with the duplicates, but I imagine it would be. It's been working much better now that duplicates are automatically removed from the DB on a daily basis. 

Hi,

Have a similar scenario here. Machine appears twice. Our SEC is sync'ed with AD and the "Connected Machine" is in unassigned and the duplicate machine name is in the group sync'ed with AD. I have previously deleted both entries and then a day or so later both appears. I uninstalled Sophos as per http://sophos.com/kb/12360 and then re-installed and this hasn't fixed it either. 

Any other ideas?

Hello pdturbo80,

uninstalled Sophos
then deleted both entries?
a day or so later both appears
either a sync is performed before Sophos is reinstalled, then the computer in the synced group should be "undeleted". The subsequent install should prefer the visible entry for the match. Question is, which entry becomes visible when the install completes before the sync? And what happens when the sync is performed?

Did you check the two (or more) entries with the mentioned SQL command? 

Christian