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 Computers in SEC

Running 5.4.0

I know that SEC lacks the function to clean up (its a manual process) stale computers in SEC but I am having issues with duplicate servers and workstations showing in SEC.

SEC is fully managing the computer as the icon is green but just under it is a greyed out computer with the same name.

If I delete the greyed out computer it will just show back up.

Sometime this is caused by a stale DNS entry but in this case there is not one.

If I delete both computers, they both come back.



This thread was automatically locked due to age.
Parents
  • Hello Navar Holmes,

    are you using AD Sync?

    the icon is green but just under it
    there's no under - it just depends on the column used for sorting. Without AD sync only one is supposed to come back if you delete both. Which groups do they belong to?

    Christian

  • I am using AD sync.

    I can delete the just the greyed computer but it comes back.

    I can delete both the green and grey but they both come back.  Force a AD sync.  Grey shows up first and then the green when the local client checks in.

  • Hello Navar Holmes,

    guess the unmanaged (grey) one is the computer object created by AD sync, it should be in the expected group. The other one is likely (but not necessarily) in the Unassigned group. That both reappear suggests that the attributes in AD and those sent to SEC by the endpoint differ (please see this recent thread).

    Christian

  • It appears that the SEC database for some endpoints is getting corrupt or SEC just gets confused.

    One of the PCs in question has not moved from its AD OU.

    The only way I have found to correct the problem is to run "Protect Computer" from the SEC on the grey computer.

    And then restart the PC and duplicate is gone or is the green one gone only to be replaced with new one???

    This works OK for PC but not for servers.

  • Hello Navar Holmes,

    SEC just gets confused
    won't rule this out. The logic is a little bit complex and supposed to handle most scenarios (not only sync but e.g. reinstall, or computer rename as well) and yes, under certain circumstances SEC can get confused but normally it can eventually be resolved from the console.

    In stubborn cases some unsupported (but otherwise safe if reasonably done) fiddling with the database is apt, just search this forum for delete from computersanddeletedcomputers

    Christian

  • In a few cases I was able get just one to show up.

    I would delete green and grey and then force an update from the endpoint.

    Then wait which was over night.

     

    I will look at deleting from the database.

    From what I have seen having a green and grey doesn't affect AV protection, it just skews the unmanaged numbers.

  • I have decided the SEC and Endpoint are affected by the wind.

    What makes this problem even worst is you can even run a report to identify them.

    Deleting from the database might be workaround but having to go into the database only tells means that is far bigger issue with SEC that Sophos doesn't know how to fix or how to identify the problem.

  • Hello Navar Holmes,

    as said, the logic tries to cover several different and partially contradicting scenarios. So if a computer is renamed one expects that this change is reflected in SEC (name changes but all alerts, errors, and events are kept with this computer object). If OTOH the SESC software is reinstalled for whatever reason this should not result in an additional computer object to be created. Not accounted for is the option to choose whether a re-imaged computer should be treated as the same (keeping its historical data) or new. If the Windows version doesn't change it's the former, otherwise the latter. You can force it to be considered as new by first giving it some arbitrary name and after SESC has been installed renaming it to its final name. Consequently the matching logic isn't executed on a rename.
    This begs the question whether it's actually an issue, bad design, or simply a consequence of not imposing too strict and complex rules and procedures. Also keep in mind that AD Sync has been added quite some time after SEC's inception. Some of the issues have been ironed out since then, if the database is "clean" and you follow certain procedures (e.g. install Sophos when the computer has its final name and after it has joined the domain) no inconsistencies should crop up.

    Christian   

Reply
  • Hello Navar Holmes,

    as said, the logic tries to cover several different and partially contradicting scenarios. So if a computer is renamed one expects that this change is reflected in SEC (name changes but all alerts, errors, and events are kept with this computer object). If OTOH the SESC software is reinstalled for whatever reason this should not result in an additional computer object to be created. Not accounted for is the option to choose whether a re-imaged computer should be treated as the same (keeping its historical data) or new. If the Windows version doesn't change it's the former, otherwise the latter. You can force it to be considered as new by first giving it some arbitrary name and after SESC has been installed renaming it to its final name. Consequently the matching logic isn't executed on a rename.
    This begs the question whether it's actually an issue, bad design, or simply a consequence of not imposing too strict and complex rules and procedures. Also keep in mind that AD Sync has been added quite some time after SEC's inception. Some of the issues have been ironed out since then, if the database is "clean" and you follow certain procedures (e.g. install Sophos when the computer has its final name and after it has joined the domain) no inconsistencies should crop up.

    Christian   

Children
No Data