Duplicate PC names in enterprise console

We are aware of the issue seen by some of our customers when using AD Sync and have been working on a solution that does not involve temporary workarounds or disabling functionality. I am pleased to be able to tell you that a patch for customers already running SEC 4.5.0 with this problem can be found here:

http://www.sophos.com/support/knowledgebase/article/111697.html

This should fix this issue for all of the cases that we are currently aware of. It has been tested by some customers who have seen the issue and it has worked well for them.

We are also looking to release a maintenance version of SEC (4.5.1) shortly which will include this patch.  This will ensure fresh installs do not encounter this problem.  For existing customers with this problem the patch will be required as 4.5.0 cannot be upgraded to 4.5.1.

Sophos Endpoint Product Management Team.

Following on from the previous post.

Please note this only occurs with Enterprise Console 4.5.0 to which a patch is available via http://www.sophos.com/support/knowledgebase/article/111697.html 

Enterprise Console 4.5.1 has now replaced Enterprise Console 4.5.0 as the default download for Enterprise Console 4.5 which incorporates this fix.

You will be  unable to upgrade from Enterprise Console 4.5.0 to 4.5.1 this will damage your database and RMS.

I found this thread from a Google search, and I too have literally a couple hundred duplicate entries in Sophos. I was hoping to find a fix here, but I am already running SEC 5.1.0 and Endpoint 10.3.1. Supposedly this problem has already been patched, but apparently not. If anybody else has some further suggestions, I am all ears (er... eyes). I will also be submitting a support request.

I am attaching screen captures of only a few to show what I am talking about.

Hello AppliedMedical,

your (surprisingly small and therefore lacking some important details) screenshots don't prove that your installation suffers from the duplication blight. 

this problem has already been patched

Not only has it been patched for 4.5.0 and the code updated in later releases, the logic has been completely revamped for later versions. There are many details which might not apply to your suspected issue so I'll try to present it in digestible bites.

1. The problem you're referring to was that computers "popped up" twice (or even more often) even if you deleted (note that this only makes the objects invisible) all instances, (all but) one appearing managed and connected,  one in the "correct" place and one in the Unassigned group.
2. The current code is rather rigorous when "folding" computers (please see Computers with the same name, domain and user name are considered to be the same computer, while written for the Cloud product it applies to SEC as well (except for the User name attribute which doesn't exist there).
3. As you have apparently unmanaged duplicates - did they appear out of the blue or were they added by one of the find/import/discover methods? If so, which of the "main attributes" (ComputerName, DomainName/Workgroup and OS) are set for them? Have the "live" ones been protected from the console or by other means?
4. If you think you don't need the duplicates for further investigation use PurgeDB to get rid of them (caution: Depending on the parameters this might also take managed ones with it).
5. Check for duplicates to recur. The following statement lists the n-plicate names together with the number of instances

   sqlcmd -E -S .\SOPHOS -d SOPHOS51 -Y 20 -Q "SELECT Name,COUNT(Name) FROM ComputersandDeletedComputers WHERE Deleted=0 GROUP BY Name HAVING COUNT(Name)>1"

Please follow up here  

Christian

Hi Christian, I'm looking for some clarity on your reply. I too have several duplicates. I have tried deleting both instances...when they come back they are automatically redeployed to. At this stage I only notice 1 entry.  Somepoint after the synchronized deployment the machine shows a duplicate again. One in unassigned, and another in the correct AD location.

As you have apparently unmanaged duplicates - did they appear out of the blue or were they added by one of the find/import/discover methods? If so, which of the "main attributes" (ComputerName, DomainName/Workgroup and OS) are set for them? Have the "live" ones been protected from the console or by other means?

I'm not following your comment regarding main attributes. I'm also a tad confused on PurgeDB. Does that command find duplicates automatically and delete? Do you have to specify the name of individual duplicates? I've never tried PurgeDB...I remember attempting to use it once but it apparently only likes 32bit OS's, and the server running the database is 64

I'm beginning to wonder if my problem is due to auto-deployments. I had several duplicate entries, but after I deleted all of them, and disabled auto deploy in sync properties, the returning machines came back green. Could there be a bug related to Syncing and deploying at the same time?

Hello LoXodonte,

let's start with the easier ones.

PurgeDB

has no intelligence whatsoever, in particular it has no "holistic" view.

attributes

SEC has to identify new endpoints, to distinguish between different ones and to recognize known ones. Furthermore one should be able to match a computer in SEC to a certain (physical or virtual) endpoint. For deployment from the console you need some attribute with which you can find (and contact) a computer on your network. I'm not going into the details here.

At install time the endpoint creates an IdentityTag which is used to recognize it even if its name changes (that's why certain procedures must be followed if you clone from an image - otherwise all clones are folded into one entry). OTOH an as yet unknown IdentityTag does not necessarily indicate a new endpoint - SESC might have been reinstalled or the computer reimaged. Thus if an endpoint presents an unknown IdentityTag but the combination of Name, Description, OS and Domain/workgroup matches an existing entry no new computer entry is created but the IdentityTag in the existing is replaced.

So - the duplicate entries differ at least in the IndentityTag, the question is: What else could make them unique?

Christian

Not really sure where that leaves me on bulk cleaning these up. At this point I've received the best results from deleting both entriest when a duplicate is present, re-syncing the OU with Auto-deploy disabled, either waiting, or reploying the client to the re-detected machines.

From what you've described this leads me to believe that a new IdentityTag is being prematurely created during an active directory sync. Perhaps the install has already initiated and created the new identifier, but then aborts when an existing client is discovered? I really have no idea...if active directory syncs could operate indepdently from auto deployments it might be easier to narrow this down.

Hello LoXodonte,

if you delete a computer using the console (as opposed to SQL DELETE it from the database) the entry is just flagged, i.e. made "invisible". If the same endpoint (or one whose attributes "sufficiently" match) the entry is undeleted. Thus a short time after deleting an active endpoint you should see it reappear in the same place with all associated information still there.

AD sync takes a computer object from AD and looks it up in the database using the available attributes (name, description, OS and, naturally, domain). If it's not found a skeleton entry is inserted into the appropriate group. Protect is scheduled if automatically is selected, the endpoint is subsequently contacted and the install task created and started. AFAIK - and perhaps a little bit surprising - no special parameter is used (not even -G grouppath). Thus when RMS contacts the server for the first time it can't send any information which would unambiguously identify it.

The subsequently commencing logic has been refined with (almost) each SEC version to correctly deal with various scenarios (endpoint reprotected, renamed, ..., duplicate names in a multi-site enterprise, domain join/unjoin, explicit initial group and so on) with the aim to correctly discern (as far as this is possible) but also to recognize (i.e. to avoid creating additional entries for the same machine) individual endpoints. Keep in mind that the processing doesn't run in a single serialized thread - looks like there's still the possibility of a race condition.

Anyway, one of the two entries (ideally that in the Unassigned group - there was a time when the "live" entry was in Unassigned) should be "transient" (i.e. perhaps show as disconnected and in any case not reappear once deleted). If you delete both instances one of them should reappear (i.e. get undeleted) the next time it sends a message (you might have to increase the sync-interval to observe this). If this is the case then it should suffice to delete the computers in Unassigned. - annoying but not a real problem. Further insight could likely only be gleaned from a trace - you'd need Support's assistance though.

Christian

Thanks for the detailed explanation Christian. Sounds like it would be a good idea to be familiar with the PurgeDB tool. I hate to ask, but could you provide a brief explanation on how I would use PurgeDB in a 64bit environment. Everything I've seen previously looks as though PurgeDB is run locally on a 32bit machine, so if I have to run it remotely what commands would I type to:

1.) delete a specific duplicate entry

2.) delete multiple duplicate entries (if possible)

3.) delete all machines that have been disconnected for more than 90 days

https://www.sophos.com/en-us/support/knowledgebase/109884.aspx