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

Active Directory Sync pulling old computer names?

Hey guys, we currently are running Sophos Endpoint 9.7 Sync'ed up with Active directory. Right before we did the upgrade from 9.5 this issue started popping up.  We are currently in the midst of replacing older computers, during the replacement old computers are renamed to (computername_temp) while we process and finish setting up a replacement, we then name the replacement (computername) and put the temp in the outgoing pile. Well about 1/5 times Sophos will not delete the (computername_temp) and no matter what we do it continues to show up in the enterprise console and the new computer (computername) will not show up or install. 

Does that make sense? Any ideas what could be causing this? 

Things I've tried-

Deleting Sync with AD and recreating

Checked AD to ensure computername_temp no longer exists

Manually insall on new (computername) works fine.

Thanks!

-Wayne  

:14943


This thread was automatically locked due to age.
Parents
  • As "my curent browser" doesn't support editing a rich text post I post it as a reply
    Tests suggest that more often than not at first you end up with the renamed client in the Unassigned group and a "stub" entry in the AD sync'd group. After another reboot (or restart of the Message Router service) SEC usually correctly identifies the client as belonging to the AD group.
    All this suggests that the sequence and timing of events has some significance and if you don't "wait" long enough at a certain step, SEC might get "confused". At least it seems to be reproducible.
    As immediate "solition" you can "just" delete the computer and its _temp name from the database. The underlaying cause should be taken to Support.

    Christian
    :14959
Reply
  • As "my curent browser" doesn't support editing a rich text post I post it as a reply
    Tests suggest that more often than not at first you end up with the renamed client in the Unassigned group and a "stub" entry in the AD sync'd group. After another reboot (or restart of the Message Router service) SEC usually correctly identifies the client as belonging to the AD group.
    All this suggests that the sequence and timing of events has some significance and if you don't "wait" long enough at a certain step, SEC might get "confused". At least it seems to be reproducible.
    As immediate "solition" you can "just" delete the computer and its _temp name from the database. The underlaying cause should be taken to Support.

    Christian
    :14959
Children
No Data