Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 6 subscribers
  • Views 17274 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

Duplicate Computer Account - but can't delete one of them

StephenCooper

I have a duplicate computer account in Users and Computers.  One can be found but the other comes up with 'Object <CN and Domain info removed> cannot be found.  Please reset the filter settings and try again'.   I've looked at the filter and it's listing over the amount for devices we have on the estate.  (when I search active directory it only finds one device - so it's looking like a Safeguard DB issue)

I've run the relevant database checks from the console and via the SGNKeytester but nothing is showing as an issue.   Now I could delete the one that actually opens but we've got a desktop engineer attempting to a challenge / Response on the device in question.


He's getting....

Missing POA or key information. Please check computer's inventory.The Virtual Client is required.
The XML recovery file is required.


....on the web console


Any idea I can figure out which one is the real device?  

/edit if anyone has a solution please let me know - so it's here for future reference :) -  it's not an issue any more as we deleted both entries (it let me delete the 'other' one after deleting the first) and the device is being re-imaged.



This thread was automatically locked due to age.
Parents
  • FormerMember
    0 FormerMember
    Hi Stephen,

    Do you get one machine in auto-registered while the other is in the right place?

    Basically, if a computer or user is auto-registered while an Active Directory (AD) sync is performed, two objects may be generated in the SafeGuard directory. The situation can be solved by deleting the object that was added by the AD sync and leaving the one in the ".Auto registered" folder.
    The next AD sync will correctly move the object from the ".Auto registered" folder into the desired organizational unit.

    When the SGN Client has version 5.60 or 6.0 and users log on using the format name@domain or domain\name, then auto-registration of these users leads to a problem with the Active Directory synchronization later. Instead of moving the auto-registered user to the correct organizational unit, the Active Directory synchronization instead will generate a duplicate user object. This issue can be solved by importing new users into the Management Center before they do their first logon on the Client. Another workaround would be to correct the pre-Windows 2000 user name of the user in the auto-registered folder in the Management Center (via context menu > Properties). If a duplicate user object already exists, the one imported from Active Directory should be deleted.

    If a computer is missing its inventory it's best just to slave and decrypt the hard drive, recover the data, then re-image the machine. Hope that helps Stephen!
  • 0 in reply to FormerMember
    Hi Toby,

    Thanks - there was nothing (well not the device I was looking for) in Auto Registered but I'll bear that in mind for future issues like this. Looking at the details on the 'device' I could see there was nothing in the inventory so it's possible that the device never fully encrypted or didn't communicate with the server. Thanks for the help anyway.
  • FormerMember
    0 FormerMember in reply to StephenCooper
    Sorry to hear that Stephen, if you still need to recover the data you'll need to slave and decrypt it.

    These instructions describe how to slave a drive to an SGN client, and decrypt that slaved drive. Upon completion, in order to boot to the drive the MBR must be re-written.

    Start by following the process in KBA 108156, page 18, to slave a hard drive:

    Article ID: 108156
    Title: SafeGuard Enterprise: Recovery scenarios
    URL: https://sophos.com/kb/108156

    Once the hard drive is slaved you will need to create a decryption policy.
    **Decryption is never automatic. It must be manually triggered from the client machine.

    1) Create a new device protection policy in the Management Center
    2) Set the target to 'Local Storage Devices\Drive Letters'. This will allow you to decrypt any hard drive connected to the computer.
    3) Set the Media encryption mode to 'Volume based'
    4) Change the setting 'User may decrypt volume' to Yes
    5) Change the Media encryption mode to 'No encryption'
    6) Click Save
    7) Apply this policy to the OU or group containing the user or computer that will be decrypting the slaved hard drive. Click Save.
    8) Synchronize the client. You should have received new policies. After receiving the new policies you should be able to right click the slaved drive in Windows Explorer and see that the 'Encryption' context menu item is no longer greyed out, and you can now click 'Decryption'
    The drive will take roughly as long to decrypt as it did to encrypt. Once decrypted you may want to re-write the MBR to skip over the SafeGuard kernel. You can use either a Windows disk or WinPE (KB 108805) to do this.

    Article ID: 108805
    Title: Recovering data from a volume-based encrypted SafeGuard Device Encryption Client
    URL: https://sophos.com/kb/108805

    The following related KBA may also be of some assistance

    Article ID: 108411
    Title: How to allow a user to decrypt a SafeGuard Enterprise Client
    URL: https://sophos.com/kb/108411

    Hope that helps Stephen.
Reply
  • FormerMember
    0 FormerMember in reply to StephenCooper
    Sorry to hear that Stephen, if you still need to recover the data you'll need to slave and decrypt it.

    These instructions describe how to slave a drive to an SGN client, and decrypt that slaved drive. Upon completion, in order to boot to the drive the MBR must be re-written.

    Start by following the process in KBA 108156, page 18, to slave a hard drive:

    Article ID: 108156
    Title: SafeGuard Enterprise: Recovery scenarios
    URL: https://sophos.com/kb/108156

    Once the hard drive is slaved you will need to create a decryption policy.
    **Decryption is never automatic. It must be manually triggered from the client machine.

    1) Create a new device protection policy in the Management Center
    2) Set the target to 'Local Storage Devices\Drive Letters'. This will allow you to decrypt any hard drive connected to the computer.
    3) Set the Media encryption mode to 'Volume based'
    4) Change the setting 'User may decrypt volume' to Yes
    5) Change the Media encryption mode to 'No encryption'
    6) Click Save
    7) Apply this policy to the OU or group containing the user or computer that will be decrypting the slaved hard drive. Click Save.
    8) Synchronize the client. You should have received new policies. After receiving the new policies you should be able to right click the slaved drive in Windows Explorer and see that the 'Encryption' context menu item is no longer greyed out, and you can now click 'Decryption'
    The drive will take roughly as long to decrypt as it did to encrypt. Once decrypted you may want to re-write the MBR to skip over the SafeGuard kernel. You can use either a Windows disk or WinPE (KB 108805) to do this.

    Article ID: 108805
    Title: Recovering data from a volume-based encrypted SafeGuard Device Encryption Client
    URL: https://sophos.com/kb/108805

    The following related KBA may also be of some assistance

    Article ID: 108411
    Title: How to allow a user to decrypt a SafeGuard Enterprise Client
    URL: https://sophos.com/kb/108411

    Hope that helps Stephen.
Children
Unfiltered HTML