Hardware encryption is not enableable after a system image backup is restored RRS feed

  • Question

  • Here is the procedure to reproduce 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 "Backup and Restore (Windows 7)" in 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.

    • Edited by DexterG Saturday, September 17, 2016 4:51 AM typo
    Saturday, September 17, 2016 4:45 AM

All replies

  • Hi Dexter.

    I guess this is expected behavior. diskpart cleaning is not the correct way to reset a hardware encrypted drive. instead, you'd need to use secure erase using a tool by crucial or the parted magic boot cd. Afterwards, I guess you would succeed.

    Sunday, September 18, 2016 8:52 PM
  • Ronald, have you ever tried restoring a system image to a self-encrypting SSD (which meets the Microsoft eDrive specification used by Windows 8 and 10)?

    Crucial tech support says that it is not possible, and their secure erase tool, Crucial Storage Executive, does not work. I talked to 3 different SSD product support technicians at Crucial and they all confirmed this.

    The only Microsoft documentation I could find for enabling this feature (eDrive hardware encryption) states that the drive must be in an uninitialized state and a security inactive state (which I assume means unlocked), not that it be secure wiped or PSID reset, and the only procedure which Microsoft provides for accomplishing this (uninitializing a drive) is Diskpart Clean.

    Ron, you may have overlooked the fact, stated in my post, that I am having no problem getting Windows to recognize the SSD eDrive and automatically enabling hardware encryption on a fresh install. The problem I am documenting here, and exploring along with the rest of the community, is how to restore a system image backup so that hardware encryption is still enableable. Which so far no one (here or elsewhere) has reported being able to achieve. 

    Tuesday, September 20, 2016 10:51 PM
  • Hi,

    Would you please post back the current information when running manage-bde -status?

    Let me know if you have several partitions or just one system partition on your computer.

    For further troubleshooting, please also post back the screenshot you state this problem.

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact

    Wednesday, September 21, 2016 10:00 AM

  • This is a screenshot of the output of "Manage-bde -Status" after restoring a system image backup to the SSD. It corresponds to step 6 in my procedure outlined above.

    If Bitlocker is enabled at this point hardware encryption fails and software encryption is used. Reminder: both the restored system image and the SSD which it was restored onto had hardware encryption working fine before the restore operation.

    There is only 1 drive in the computer and only 1 usable partition on the drive. Since this is a clean Windows 10 instal there are also 3 non-accessible partitions which the Windows installer created: a recovery partition, an EFI system partition, and a hidden partition of type Microsoft reserved. I did not change anything.

    As I explained above, this is a default Windows 10 (1607) clean install with nothing added or changed by me. Anyone with a self-encrypting SSD (eDrive) should be able to reproduce the problem I described above. 

    Friday, September 23, 2016 12:22 AM
  • I have very well understood what you are trying to do and no, I have not done that but what I have done was to reuse an edrive. Simply formatting it or simply using diskpart clean led to unwanted effects but after secure erase (using the parted magics boot cd), I could at least reuse it as an edrive.

    At that point, I already gave up the thought of deploying edrives, so the restore process wasn't even tried. I have to say that bitlocker and edrive in combination does not look mature to me. If you are interested in reading about my problem, have google translator translate my thread here:

    You may want to omit reading all comments since most people that try to comment are clueless, so maybe just read the initial posting and

    Saturday, September 24, 2016 9:10 AM
  • The most probable issue here is Step 5. What OS did you boot into to run the diskpart? You need to make sure you run 8.1+ OS to run the diskpart.


    Monday, October 3, 2016 6:26 PM
  • I tried it with both the 1511 and the 1607 versions of Windows 10.

    Have you been able to restore a system image to a self-encrypting SSD (eDrive) without breaking the hardware encryption capability? I have not found a single report of anyone being able to do so, which means that Windows system image backups are effectively useless for restoring an existing Windows installation to a cleaned or new self-encrypting SSD (eDrive). One has to reinstall Windows from scratch in order to get hardware encryption working again.

    Tuesday, October 4, 2016 9:50 PM
  • 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. 

    • Edited by DexterG Wednesday, October 12, 2016 4:46 PM fixed a typo
    Monday, October 10, 2016 2:08 AM
  • I can confirm Dextor's findings.  My edrives are Samsung 850 Pro and the imaging software is Macrium Reflect.  After restoring the Win10 image, the edrive is decrypted, boot and run normally but hardware encryption is no longer enableable.

    Besides, using the Diskpart clean command during Windows 10 installation is sufficient to enable hardware encryption so far as you have set IEEE 1667 to ready to enable hardware encryption.  Of course you can use Parted Magic or Secure Erase of Samsung Magician to secure erase the edrive.  They produce the same result.
    Sunday, October 16, 2016 9:15 AM
  • 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. 

    • Proposed as answer by Denis_TDG Tuesday, April 11, 2017 2:09 PM
    Monday, October 31, 2016 1:23 AM
  • 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.


    • Edited by DexterG Monday, October 31, 2016 2:01 AM
    Monday, October 31, 2016 2:01 AM
  • 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>

    Thursday, November 10, 2016 6:13 PM
  • Hello,

    Just to confirm this actually works.

    Anyway I did not restore ReAgent.xml file. It seems that it is not necessary as DexterG pointed out.

    Those are the steps I followed on my own laptop (HP Elitebook 850 G3 with Crucial MX100 SSD). This should work anybody providing that your computer meets the Windows 10 Bitlocker Hardware Encryption requirements :

    • Uninstall Intel Rapid Recovery Technology
    • Check that you are using Microsoft Standard AHCI driver
    • Disable Bitlocker software encryption and wait for the process to finish.
    • Use an imaging tool like Acronis and boot on the imaging tool media
    • Image your complete drive with Acronis
    • Reboot your computer and double check that UEFI AND Secure Boot are ENABLED (disable CSM or any compatibility/legacy boot mode)
    • Boot to the Windows 10 Pro/Enterprise install UEFI media
    • BEFORE choosing where to install Windows 10, press SHIFT+F10 (that should bring you a command line), then use Diskpart utility to clean your SSD drive (usually the commands are diskpart > select disk 0 > clean).
    • Choose your empty drive to install Windows 10 on.
    • Right after first boot, check whether Bitlocker is providing hardware encryption but do not complete the wizard.
    • If OK, boot with your imaging tool and restore ONLY the C: drive. DO NOT touch the other partitions as it appears that one of them contains something that enable (or prevent) Bitlocker to use hardware encryption.
    • After the restore of you C: drive, you should be able to enable Bitlocker with hardware encryption.

    I assume that those steps should also work in case you are replacing or upgrading to another SSD.


    • Edited by Denis_TDG Tuesday, April 11, 2017 2:30 PM
    Tuesday, April 11, 2017 2:28 PM