The fix MBR command from a Windows Command Prompt will overwrite the encryption MBR. The will result in Drive Encryption tools unable to know what sectors are and are not encrypted. The steps you will need to follow to resolve the issue are:
1. Backup the drive using a sector level backup utility
2. Identify if the machine is booting using UEFI Native or Legacy.
3. Build the UEFI or Legacy EETech Stand Alone disk following the steps in PD24871
4. Export the systems Recovery XML from ePO and place on a FAT32 USB
5. Boot to DETech Stand Alone
6. Authorize using the code of the day
7. Enable USB
8. Authenticate using the XML
9. Click Restore MBR and select MDE MBR
10. Remove all USB drives from the system
11. Verify the Key using the workspace
a. Click Disk Information and copy down the start sectors and sector counts of the “Crypt List” and click OK
b. Click Workspace and select “Load from Disk”
c. Enter the “Start Sector” found in “Disk Information” for the crypt list
d. Enter a sector count of 1 (Do not enter the count from Disk Info, you only want to load 1 sector)
e. Click OK
f. Click “Decrypt Workspace”
g. The text on the right side of the workspace should be somewhat legible and verified that the key is the correct key
h. Exit the workspace
12. Click Remove EE
The machine will now start to decrypt, once finish, the original Windows MBR should be put in place and all standard recovery tools can be utilized to recover data from the machine.
Thank you for your prompt reply, I have an issue here also as the laptop has been reimaged under the same name and encryption reinstalled, so the xml willl be for the new laptop not the old one. I am assuming this will be a problem or is there any other way round this?
If the machine was not deleted from ePO, click the machine and select Actions | Drive Encryption | Export Recovery Information
Select the check box "Export Old Keys if Available". If the machine was not deleted, the key should be there. Multiple keys may exist and regardless if only one old key exists or multiples, they must be verified using the workspace to ensure it is the correct key before attempting to perform a decryption. Using the wrong key to decrypt the disk will result in the disk becoming double encrypted.
If not, because the keycheck value is stored in the MBR which was wiped, there is no way to find the key. Although, all the old keys can be exported, you would need to test each one individually. A better option would be to spin a new ePO server up in a sand box and following KB66616 restore a backup of the ePO with a copy of the database from before the machine was reimaged in which the key would be available.