WinRE / WinPE rescue media with bitlocker support can't backup an "unlocked" drive
Finally thought I'd test bitlocker a little more in depth. I can successfully use WinPE rescue media to "unlock" an encrypted bitlocker drive, making the contents of the drive accessible to file explorer, command prompt, etc. It also shows the drive is successfully unlocked in manage-bde -status afterwards and via file explorer unlock icon too. But, even if I close and restart True Image in the WinPE, it still won't proceed to backup the drive and says to "unlock" it or decrypt it. Well, it is unlocked. This is a bug and needs to be fixed. I've submitted feedback through the app with the attached screenshots and a system report.
***EDITED - want to note all screen shots are from within the same WinPE session. I am using a custom WinPESE that has components of Windows such as native Windows File Explorer, to specifically show that the WinPE explorer detects the drive as locked and unlocked after using the encryption key password, but the current Acronis 2019 WinPE application still believes the disk to be "locked" anyway.
(01). MVP WinPE Builder (02). MVP LogViewer
(03). MVP Google Drive (04). Cleanup Utility
(05). Cloning Correctly (06). Clone vs Backup
(07). Community Tools (08). Contact Support
(09). Product Documentation (10). OS MBR vs UEFI
(11). BOOT MBR vs UEFI (12). Common OEM Drivers
Rob, have you submitted a Support ticket for this issue as well as the feedback? Sounds that it should be fairly easy for the Acronis Support folk to replicate the issue here!
I submitted via email - no point in chat or live assistance with this one since it's all rescue media based. I'll add the ticket # here when I get it.
Rob, thanks for the update, look forward to the next installments of this saga...!
I decided to test backing up a Bitlockered drive from the recovery media myself because it always worked before as long as I unlocked the drive before the backup operation. I tested using the Acronis created WinRE media that was made using the Simple method. I did it with TI 2019 on a Windows 10 1809 64 bit system.
I booted the media and closed the TI 2019 GUI to gain access to the command prompt. I used the manage-bde -unlock command to successfully unlock the drive. Then I copy and pasted the line to restart the TI 2019 GUI. I proceeded to make a full disk backup of the system. There were no error messages or warnings of any kind. The backup competed successfully.
I then decided to test a full disk restore using the backup that just completed. I again booted the recovery media. I didn't unlock the drive.The restore started with no problems. It completed successfully. When I booted the recovered drive back into Windows, Bitlocker was still intact. I needed to enter the Bitlocker password as usual. That was a surprise since the disk was unlocked during the backup.
Here's where it gets even more interesting. I tried to mount the C: drive from the backup while in Windows. It went through the motions of mounting and assigning a drive letter. However, I could not explore the mounted volume. Windows Explorer said the mounted volume needed to be formatted. I then booted back into the recovery media and selected the backup and tried to restore individual files from it. TI would not see into the C: drive to allow files to be recovered.
All in all, TI did quite well. It seems the backup is secure even though the disk was unlocked during the backup. I should mention that I elected the "New" method of encryption when I turned on Bitlocker in the first place. That may have made a difference in how TI handled the situation verses a system that was encrypted using the old Bitlocker method.
See my post below! The disk was not fully encrypted when the backup was run.
Interesting stuff Mustang. I'm not super familiar with Bitlocker - what's the difference between the old method and the new one? I only had the option to turn on bitlocker in Windows and the result (according to manage-bde) was bitlocker 2.0 AES 128. I'm running it off of a cheap-o Asus Transformer T200A 2-in-1, but it is running Windows 10 x64 Education edition (converted long ago in an older version of Windows 10 from home edition). So, I'm not sure why bitlocker would use a different method in this case. My media was built with 1809 ADK using WinPE method and Windows 10 Education 1809. I had the same experience in my WinPESE custom build, the WinPE created default in Acronis and the WinPE created by the MVP tool with ADK 1809.
I may have to go back and build it with WinRE to see if it behaves differently somehow.
Also, does it make a difference if you build with WinRE before or after bitlocker is enabled? On my system, it built a new recovery partition when bitlocker was enabled.
I see the option now. I used the option to encrypt the entire disk originally - that doesn't give the new or compatibility option.
Maybe try that and I'll try the other way you did now and we'll see if it behaves differently.
I did originally select the option you have high in yellow to encrypt the entire drive. The next screen did give me the choice of the new method versus the compatibility method. It may make a difference because I am using Windows 10 Pro. There are too many variables here to make any blanket statements about how it should act.
I spoke too soon about TI 2019 making a successful backup of an unlocked Bitlocker system from the recovery media. It turns out that the system was not fully encrypted when I did the backup. I didn't understand how the new encryption method works. The drive is encrypted after an initial reboot totally in the background. I didn't wait very long after the reboot, so the drive only had a small portion encrypted when I ran the backup.
I did it all over again and waited until manage-bde -status told me the drive was 100% encrypted. This time TI 2019 would NOT backup the drive even after it was unlocked! Sorry for the confusion.
I went back and tried your method (with the partial disk encryption) and made sure the status was 100% with manage-bde -status, then booted to winpe recovery.
I still get the same behavior as before - this is just with attempting to backup the encrypted drive (no recovery at all), but after unlocking it. Unlock was again successful. Drive content is viewable in WinPE via A43 file explorer, explorer++ and command prompt at this point and manage-bde -status shows unlocked too.
I launch Acronis True Image 2019 from winPE and it says the disk cannot be backed up because it is still encrypted and needs to be unencrypted or unlocked. Well, it is unlocked, so to me it's bugged.
This could potentially be just this system, but i suspect it's more than just me and it's a bug. I know I saw this on a recent thread that I replied to the other day regarding backup not running on an unlocked in Windows (that was what prompted me to test bitlocker out in the first place), but I can't find it!
However, I did see this one which sounds about the same...
I think the reason unlocking the drive isn't making any difference to TI is that the volumes are enumerated by the fltsrv driver at boot time because fltsrv is a kernel level driver. There is no way to refresh the enumeration of the volumes. Therefore, TI is just going by the initial enumeration that says the volume is locked by Bitlocker even though it has been unlocked. Acronis has much work to do to support Bitlocker.
I'd agree it needs work :) I'm about to use my "super winpese" with a couple other backup products also built into it to see if they are able to backup the drive in it's encrypted, but "unlocked" state or not for comparison.
I had previously done some testing of other product. Some are able to backup the drive in a locked state by using a sector by sector approach. Most are able to do the backup in an unlocked state.
Yeah,the unlocked state should be a given with winpe after unlocking with manage-bde since that's essentially what is being done by the backup application when you are booted into the full Windows OS on a bitlocker enabled drive.
Thanks Steve, that was the post i was looking for! I searched all over for it in my comments and the first couple of pages of each main topic and it never came up!
Just got round to re-encrypting my external USB drive (also bootable as Survival Kit using MVP Custom media including BitLocker & Powershell support) - this uses BitLocker to Go for Windows 10.
Checked that my Windows ATI backup to same drive was fine then booted from MVP media and took the following steps.
First, checked the drive showed as locked via manage-bde -status and the file explorer.
Next, ran Powershell unlock script for the Bitlocker drive (L:), then repeated manage-bde -status which now showed the drive as unlocked.
Tried to make a backup of the external drive but got the error that cannot do as drive is locked!
Terminated ATI in the PE to see if made any difference when it was restarted but didn't!
Tested backing up to the Bitlocker drive and Acronis very happy to do so!
Yup. It's broken. I have gotten nothing back from my original ticket submission yet.
I've been contacted and requested to send logs and system reports in all 3 rescue media and my original system.
I've explained there is no log since no backup is allowed to proceed and the linux media has no bearing here since it has no bitlocker support. Sending my OS system report but can't see it being much use since it backs up just fine as the disk is automatically unlocked at boot with TPM. The behavior occurs only in winpe and WinRE and I've asked they test it too as it's not system specific.
Will pass on any feedback received.
Sent all details to support today via FTP - including system report from the booted Windows OS and the WinRE rescue media after bitlocker unlock was applied. Here are the additional screenshots I provided as well.
All looks clear as day to me Rob and exactly the same as I am seeing myself with testing!
Humor me here a bit, from Windows Control Panel\Bitlocker Drive Encryption, click "Turn off auto-unlock" for the affected drive to turn auto-unlock off, there will be a slight delay after turning it off. After the drive is unlocked click the same option again to "re-enable auto-unlock".
Now boot to WinPE and see if you can run a backup. :)
Bob, sorry tried your suggestion but it made no difference whatsoever - ATI from the WinPE media simply does not see the drive as unlocked as far as a Backup of the drive is concerned, but is quite happy to use the same unlocked drive as a Backup destination!
So you are saying you can backup TO a locked drive but cannot backup the locked drive ITSELF correct?
That's correct Enchantech - it thinks it's still "locked" when you try to back it up, yet has no issue using it as a backup location when it's unlocked. Definitely seems to be a bug.
Not much luck so far. I did receive an elevated email earlier this week, but I won't go into details as I was not happy with the response.
I replied to it again, hoping to further clarify about what was not working now, that it used to in 2018, and that the same base WinPE was usable when unlocked with some other products that I manually added and could function correctly for backups when the drive was unlocked. I also cc'd a few others in hopes it will get some additional attention/priority.
I also tested with the version that was just released (2019 17750) and no change - still not working. Didn't see it in the list of fixes, so didn't really expect it to be in there, but was still hoping.
I've brought up this thread to the attention of the RnD (Bobbo, also sent the logs and screenshots you've provided in the support ticket) - we'll continue investigation (internal ID for ref TI-167227). I'll inform you about the results at the earliest.
Thanks! I received a note this week that the developers are investigating too!
I've had this issue for the last few weeks, now resolved. For me although it said I needed to unlock or decrypt the drive it turned out VSS was unable to create a snapshot due to insufficient space.
I don't know if this is the same problem for you. if you can (don't really know WinPE) you could check the application event log for catastrophic failures of VSS. But, even if that precise problem is not the cause here, it's worth being aware that Acronis may be mistakenly reporting this error message for other, unrelated, problems with backup creation.
p.s. Looking at some of the other similar threads it seems problems with VSS are a common theme. Even where backups "succeed", some also report problems with file backups with locked files because a snapshot could not be made. I too had this problem although I didn't realise it at the time. I would definitely check if VSS is correctly functioning here.
Jon, there is no VSS involvement when booting from the WinPE Rescue Media, so that is not going to be a factor with this issue. This was working fine but was broken by ATI 2019.
OK good. Still it's interesting that TI can report bitlocker issues when the fault is not really in the state of the bitlocker volume. It just looks like their error reporting is a bit messed up.
This issue is definitely strange as you can backup to a BitLocker volume in the rescue media but not backup from it as it tells the lie that is is not unlocked!
Yeah, as in my case clearly the volume is unlocked. Mine was the system drive which has to be unlocked, by definition. Also, in my case Acronis was very happy to backup individual files which is would not be able to do if it truly thought the volume was locked (all files would be inaccessible).
So, it looks like Acronis is mistakenly displaying this error message for a much larger set of failures than intended and the true cause may be nothing to do with bitlocker.
no change in status so far.
I just tested with ATI 2020 beta and the issue is still present in the new rescue media as well :(
New 2020 bug report in forum:
Did a second test with ATI 2020 beta rescue media after upgrading a New/Different Windows 10 Pro x64 system from 1809 to 1903 in hopes that the updated WinRE environment might help and also to see if the behavior was just on one system or both.
Still, no dice. Same behavior as before :(