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

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!

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.

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.

Thanks, that should help with any data we need (providing the engineer hasn't wiped it).

Thanks, that should help with any data we need (providing the engineer hasn't wiped it).