This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Duplicate PC names in enterprise console

I've noticed after upgrading the Enterprise Console to version 4.5 and AV to 9.5 that duplicate PC names have started appearing.  This normally happens after a PC's AV has either not upgraded properly or has stopped updating so i've uninstalled and it and then redeployed it down.  One of the PC names will say its connected & managed (although not properly as the 'up to date' colum is blank and you can't deploy any policies down)  whilst the other will be greyed out.

I've tried deleting both entries in the Enterprise Console in an attempt for the AD sync to sort it but they both re-appear again.  Is this a known issue with the 4.5 upgrade?

:4224


This thread was automatically locked due to age.
Parents
  • 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

    :57429
Reply
  • 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

    :57429
Children
No Data