Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 3750 views
  • Users 0 members are here
Options
Suggested
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?

wjohnson2k1

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

    Hello Wayne,

    are you using sync with or without automatic protection (will not show up or install - suggests the former)?

    When you rename the old to _temp - is this change correctly reflected in SEC (does it still show in the correct group) and AD? Or do you unjoin it during rename? What's you synchronization interval? When are the _temp computers switched off "forever"?

    Keep in mind that SEC will not re-protect a "known" computer - this said, I haven't tested how SEC deals with a rename. 

    It seems to be a timing issue - don't have the time right now to dig into the details but it looks like follows:

    If the name change is reflected to AD and picked up by sync before the client re-connects to SEC after reboot that name change for the (in database terms) ComputerID is correctly performed in the database. If the client happens to report to SEC with its new name before the change in AD is seen a second entry is created belonging to the Unassigned group. The name later detected in AD results in a new ID to be created. Guess some more testing is required here ...

    Christian

    :14953
  • 0
    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
  • 0

    Thanks for the reply! It sounds like you reproduced our exact problem. Althought sometimes it seems that even after waiting a day or two the "stub" entry will still stick, and not allow for deployment of the new computer. I think that deleting this entry from the database would solve that, but do I manually need to log into the database to accomplish this task? Deleting from the enterprise console simply doesn't work, once it does and AD scan its added right back in even though the "stub" compy doesn't exist in AD. 

    :14991
  • 0

    Hello,

    deleting from the console "just" sets a Deleted flag in the database so the entry exists and can be and is revived (undeleted) whenever SEC "thinks" the entry matches a  computer sync'ed, imported or connecting.

    There's a number of posts in this forum about deleting computers from the database (just click the link) - please back up you database first though.

    As mentioned Support should look into the issue (even if deleting from the database solves your problem).

    Christian

    :15007