How to restore a system image backup to a hardware encrypting SSD (eDrive)

Has anyone figured out how to restore a system image backup to a hardware encrypting SSD (eDrive)? The problem I am experiencing is that I can successfully restore the system image to the SSD but hardware encryption is no longer enableable like it was before the backup and restore.

Here is a basic overview of the procedure: How to Restore System Image Backups on Windows 7, 8, and 10

Here are the specific steps I followed to reproduce and document this problem:

1. Install Windows 10 (1607) onto a Crucial M500 SSD eDrive.

2. Turn on Bitlocker and the C: drive is instantly encrypted on reboot.

3. Confirm hardware encryption using Manage-bde -Status.

4. Create a system image backup using the "Create a system image" command under "File History/System Image Backup" or "Backup and Restore (Windows 7)" in the Control Panel.

5. Boot to a Windows thumb drive or DVD, open a command prompt and Clean the SSD using Diskpart.

6. Restore the system image backup to the SSD. Process completes successfully and Windows runs normally.

7. Re-enable Bitlocker but only software encryption is available. The hardware encryption which was working fine before the image backup and restore is now inoperative.

I have tried this several times with various changes, such as clearing the TPM, turning Bitlocker off before creating the system image, and using a 1511 version of Windows 10 instead of the 1607 version. The results are always the same.

Conclusion: System image backups of a hardware encrypted drive are unusable because the hardware encryption can never be turned on again after the image is restored to a new, or even the same, SSD.

If anyone has figured out how to make this work I would love to hear your solution!

However, I think it is currently impossible because of a bug in Bitlocker, System Image Recovery, or both. I'm hoping that someone from Microsoft will take notice of this post and address the problem, either by providing a procedure that actually works or by fixing the malfunctioning code in Windows.

 

Question Info


Last updated June 2, 2019 Views 2,407 Applies to:

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

For those of you unfamiliar with eDrive hardware encryption, here is the only Microsoft documentation which I could find describing this feature.

Please note, I have no problem enabling hardware encryption on my SSD when doing a clean install of Windows 10, it's only after the (previously working) Windows system image is restored (to the same previously working SSD eDrive) that hardware encryption fails.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

This weekend I did some more testing using a new self-encrypting solid state drive, a Crucial MX300, which supports Microsoft's eDrive standard.

What I learned is that restoring a Microsoft system image backup from the M500 breaks the hardware encryption capability but otherwise works normally. I also tried cloning the M500 to the MX300 using Paragon Hard Disk Manager but that broke the hardware encryption capability as well. And lastly, I tried imaging and then restoring the M500 to the MX300 using Paragon HDM but got the same results: Windows works fine but the hardware encryption is not re-enableable.


So the conclusion from all of these tests seems to be that if your eDrive fails, or if you want to migrate to a new eDrive, you will have to reinstall Windows and all of your programs from scratch.

I wish that some Microsoft engineers working in the Bitlocker department would address this shortcoming by either explaining why this behaviour exists (maybe they think it is necessary for security reasons) or treating it as a bug and working on fixing it.

I can't believe that no one else has raised this issue already! To me it seems like as a major problem with the whole self-encrypting eDrive architecture. You should be able to replace a drive without the hardware encryption breaking and your system image backups becoming useless. 

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

I was able to get this working and am responding in case you [or others] are still interested in doing so. I won't cover the process of getting eDrive working since it sounds like you have already done so [and since there are already a number of detailed articles on it].

I believe the files that actually control eDrive are actually stored on the non-OS partitions created by Windows at install. Since Microsoft's restore process forces you to re-write all of the partitions I don't believe it will work for this.

Anyway here are the steps I used to get it working:

1. Backup your disk using software of your choice. The software must support individual partition restoration [from an alternate boot source]. I used a 30 day trial of Acronis.

2. Create a bootable cd/usb from the partition restoration software. 

3. Install a fresh copy of UEFI Windows [ensure that you are able to enable hardware encryption at this point, but don't actually turn it on]. 

4. On the fresh install backup the ReAgent.xml file found at: C:\Windows\System32\Recovery\ to an external drive. This step may not be necessary but I found out with earlier issues that this file controls Bitlocker, so I did so to be safe. There were significant differences between the files. 

5. Load up a bootable partition restoration software [Acronis]. 

6. Restore only the C: drive, DO NOT restore the EFI, or recovery partitions. 

7. Boot back into windows and replace the ReAgent.xml with the file you backed up earlier. 

8. Enable Bitlocker. You can verify that it is working properly by typing 'manage-bde -status' at an admin command prompt. 

3 people were helped by this reply

·

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Thanks, Tennessee, for checking into this and sharing your results.

There is one piece you may have missed which would affect the results: if your SSD died, or you were simply upgrading to a newer/larger SSD, the drive would have to be initialized prior to installing Windows. This assigns some unique identifiers to the drive which I believe the trusted boot process and Bitlocker care about. For this reason I specified in step 5 of my procedure that the drive be Diskpart Cleaned. 

I have been able to restore only the C: partition (using Paragon Hard Disk Manager) without breaking hardware encryption, but ONLY if the image was from the exact same drive and no drive re-initialization had occurred.

If your technique (restoring a virgin ReAgent.xml file) works when cloning/restoring to a new SSD or to the same but DiskPart Cleaned SSD, then you might be onto something!

The two solid state drives which I was using for these experiments have been put back into service, so I cannot test the results of using your technique on a new or reinitialized/cleaned drive for myself right now.

Dexter


Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

It's been more than a week, Tennessee, and you haven't responded to my question. What happens when you DiskPart Clean the drive or restore to a different SSD?

Also, have you tried restoring the partition without copying the ReAgent.xml file?

I've looked into my ReAgent.xml file but don't see anything in there that would make any difference. It's all just default settings with no specific locations or GUIDs even mentioned. Here's what it contains:

<?xml version='1.0' encoding='utf-8' standalone='yes'?>
<WindowsRE version="2.0">
<WinreBCD id=""></WinreBCD>
<WinreLocation path="" id="0" offset="0"></WinreLocation>
<ImageLocation path="" id="0" offset="0"></ImageLocation>
<PBRImageLocation path="" id="0" offset="0" index="0"></PBRImageLocation>
<PBRCustomImageLocation path="" id="0" offset="0" index="0"></PBRCustomImageLocation>
<InstallState state="0"></InstallState>
<OsInstallAvailable state="0"></OsInstallAvailable>
<CustomImageAvailable state="0"></CustomImageAvailable>
<WinREStaged state="0"></WinREStaged>
<ScheduledOperation state="4"></ScheduledOperation>
<OperationParam path=""></OperationParam>
<OsBuildVersion path=""></OsBuildVersion>
<OemTool state="0"></OemTool>
</WindowsRE>

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Hi Dexter,


We suggest that you post your concern to Microsoft TechNet as this matter is best handled by their level of support and expertise.

Regards.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Hi Dexter,

I haven't experimented with this any further as I was only interested in doing so for one device. On that device I needed to convert the Windows install from BIOS [MBR] to UEFI [GPT] and enable eDrive support while maintaining the Windows portion [so I did not lose some difficult to recover software installations].

That said I did review my current ReAgent.xml file and it appears to have reverted to a standard file [matching yours, though still engaged - see below], so I don't believe it had any effect on the process. I believe the key is leaving the EFI and recovery partitions [from the fresh install] intact when restoring the OS [which can't be done from Windows System Image Backup]

C:\Windows\system32>manage-bde -status
BitLocker Drive Encryption: Configuration Tool version 10.0.10011
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Disk volumes that can be protected with
BitLocker Drive Encryption:
Volume C: [Windows]
[OS Volume]

    Size:                 465.21 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Encryption Method:    Hardware Encryption - 1.3.111.2.1619.0.1.2
    Protection Status:    Protection On
    Lock Status:          Unlocked
    Identification Field: Unknown
    Key Protectors:
        TPM
        Numerical Password

1 person was helped by this reply

·

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

I understand your desire to not break a working system. And I'm glad that we've both reached the conclusion that copying the ReAgent.xml file is probably not part of the solution. But it looks like we will have to wait for someone else to verify if copying the C: partition as you suggested will work on a drive that has been DiskPart Cleaned or when restoring to a different SSD. In my experiments it didn't work.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

I have been jumping through the same hoops all night trying to restore an image to a SSD that was originally initialized and unencrypted. 

I tried following these steps but it failed. 

I was able to "diskpart clean" and install Windows 10 fresh and successfully tested that I can hardware encrypt a brand new install after running diskpart clean. 

I then attempted to restore an image of only the C: partition from when the drive was unencrypted, leaving the EFI and Recovery partitions alone. Windows booted fine, but I was only able to use software encryption. 

I got concerned when after recovering the partition windows went into startup repair - my guess is that's when it initialized the disk, and it appears it's always going to do that if you restore C: into a drive with EFI/recovery partitions from another install. 

I do wish Microsoft would address this, as its a bit of nonsense and there should be no technical reason why a disk can't be re-initialized when online if one can first-time initialize in such a situation. 

There's probably some esoteric edge-case "but for security.." explanation here, but I can't think of it. At the very least, Windows could ask if you want to re-initialize prior to restore. 

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

I stand corrected.

I actually finally got this working tonight.  Running presently on a hardware-encrypted Crucial MX300 using an image from another drive.

My first attempt to restore the C: partition while leaving the EFI and System Recovery/Volume Information partitions in place failed - at that time I was using EaseUs Todo Backup, which claimed single partition restore (and from all signs that's what it was doing.)

That didn't work - but out of curiosity, I tried using Acronis like TennesseeTater said, and it worked.

I made sure to use the native (Non-PE) bootable Acronis media, and I selected to NOT restore the MBR and Track 0 (which Acronis prompts for) on the target drive - leaving the EFI and other partitions in place.

To my surprise, I was able to boot up in my previous install, and then turn on bitlocker using hardware encryption. All seems to be running well at the moment.

They key appears to be that some recovery tools mangle whatever fields/locations (who knows) that need to remain uninitialized after a diskpart clean. Acronis apparently does not. Maybe that "do not restore track 0" selection was what did it.

Either way, it shows that A) Microsoft can make this work if they wanted to, and B) SSD SED's are way more of a pain than they should be at this point.

Either way, I hope this helps someone out. I know it ate up all my night (after an earlier problem that also had no answers from Microsoft's illustrious MVPs) - so give it a try using Acronis and being particular to ONLY restore that C: partition while leaving everything else from the fresh install in place.

3 people were helped by this reply

·

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.