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,

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

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