Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, January 15, 2016 12:11 PM
System setup:
So yesterday I set up an iSCSI disk using the server manager, copied all of my files (1.31TB) into it, connected it with the initiator, and it worked fine on my server machine. I have used CHAP authentication.
Today I connected it with my Surface, and it showed that the disk was locked using BitLocker, which I did not do it myself, it said that the BitLocker version is incompatible, and I could not unlock it.
I was able to access the disk locally on my server, though. I thought it was some weird connection problem, reconnected it for a few times, and it didn't help at all. So I restarted my server, only finding something worse had happened, and I could not access the disk even on my server, because it too was BitLocker locked.
Since there's no BitLocker UI in TP4, I tried the PowerShell scripts, but it said my password (which I always used for anything that requires something complex, including all of my BitLocker drives, and CHAP for this disk) could not be used to unlock the drive. So now I have a 1.31TB virtual disk sitting in my storage space, and I can't do anything about it.
Also, I disabled and removed the iSCSI disk, and now it won't let me import it again, because "A virtual disk with that file path already exists".
I really need some help here because these files are everything I have and I cannot afford to lose them all at once. Thank you.
All replies (41)
Friday, January 15, 2016 3:50 PM
Since I enabled BitLocker on Surface, could it be because of something weird had happened and my Surface encrypted it automatically? I have done absolutely nothing to encrypt the VHDX myself, though.
Friday, January 15, 2016 6:11 PM
When you say connected it on the surface, how? Over what protocol?
I suppose if you attached it as iscsi or something it could have seen it as a local disk and applied bitlocker. Would not imagine that would be the case with a mapped SMB share though...
Friday, January 15, 2016 6:21 PM
It is a VHDX file, which I created for iSCSI sharing, a function you can get using the server manager.
I have done absolutely nothing to encrypt it. I used the iSCSI initiator on that server to connect to it, and it was all good. When I connected it to the Surface using the initiator, it told me that the disk was BitLocker locked and the version is incompatible, and wanted me to open it with a newer version of Windows. But, well, I am (I have Windows 10 10586 installed on my Surface, and obviously, TP4 on my server).
Friday, January 15, 2016 6:24 PM
So people are telling me not to use Windows for an iSCSI target server when I was going all crazy and raining down "what should I do?" on them. For a server noob like me, I like the familiarity, and really don't want to just throw away these percious memories... Argh.
Friday, January 15, 2016 6:25 PM
Let me make sure I have this right:
TP4 server with a VHDX file shared out as iSCSI target. No form of bitlocker enabled
Surface with windows 10 connecting to that iSCSI target. Bitlocker enabled on the device, but not specifically for that drive
Correct?
Friday, January 15, 2016 6:26 PM
It was not encrypted on the server side, until I restarted the server, and the VHDX became encrypted.
Also, I tried to connect to it with other laptops I had, and they all showed it was encrypted, and incompatible.
And yes, it was a TP4 server with a VHDX file shared out as iSCSI target with no form of bitlocker enabled.
Friday, January 15, 2016 6:28 PM
Using Windows as iSCSI target is not bad in and of itself really (though it has not traditionally been that strong). Bad plan is to put valuable data on a technical preview build of anything, doubly so when you don't have a backup. Not sure if this is recoverable or not yet, but lets walk through some troubleshooting and see what may have caused it.
Friday, January 15, 2016 6:30 PM
Please do help me with it.
I had just lost a drive and that's why I decided to use the storage pool's mirroring capability. Then I switched from SMB to iSCSI, and I have even searched about what to do if VHDX gets corrupted, but I have never ever thought that something like this would happen.
I am running some file recovery programs right now to try saving some of my data that I had before placing them into the VHDX (which I just did about 24 hours ago), but I don't know they will actually work under the storage pool or not.
Friday, January 15, 2016 6:34 PM
Is the iSCSI drive still mounted on the surface?
Friday, January 15, 2016 6:37 PM
Well, nope... In fact, I installed Windows 10 onto my server to try see if the VHDX can get unlocked that way, but sadly it couldn't.
Friday, January 15, 2016 6:44 PM
Ok, here is my best guess this far:
Surface has bitlocker enabled system-wide. When you mounted the iSCSI target it shows to the surface as a local disk that needs encrypted and starts that process automatically.
Did you try and decrypt the drive from the surface? If so what error did you get?
The error posted above seems to be more related to an incorrect key than an issue reading the encryption. Maybe the drive encrypted with a certificate instead of the key you were trying. Check this article and see if you can restore using an export of your pfx: https://deploymentramblings.wordpress.com/2014/12/03/using-a-bitlocker-data-recovery-agent-to-unlock-a-bitlocker-encrypted-drive/
Friday, January 15, 2016 6:47 PM
That is also what I think, but what's funny (not really) is that the Surface said the BitLocker version on that disk was incompatible with the Surface's version, which really frustrates me, how in the world can that be possible?
Thank you for the link, I am reading it right now.
Friday, January 15, 2016 6:51 PM
Can't say I have tried bitlocker to a MS iSCSI target before (as that sounds like a bad plan to me), but maybe it offloads the encryption to the hosting server. This would mean TP4's presumably newer version of bitlocker would have been used which win10 probably has not been patched to understand quite yet. That's kinda why I am leaning towards exporting the pfx from the surface and trying to do the actual decryption on TP4.
Still a shot in the dark at this point, but it makes some sense logically.
Friday, January 15, 2016 6:54 PM
I hope it is and somehow that will be fixed with newer patches.
Question, will this work even after I have unmounted the disk and reinstalled the OS? Because, you know, I really went all over at that time...
Friday, January 15, 2016 6:57 PM
Assuming the VHDx has not been modified it "should" presumably be mountable/decryptable within TP4. You could even spin up a TP4 VM and access the VHDX file via a file share to mount/decrypt if you wanted. I would assume you are getting all kinda of errors if you try and mount that VHDX in Win10....?
Friday, January 15, 2016 7:00 PM
Not really, I just get the "version incompatible" error and the disk is quite intact as far as I know, except the fact that it is locked.
Also, about the link you sent me, it said I needed "A public .CER certificate which will be deployed to all your systems, and a private .PFX certificate which allows you to decrypt systems that were encrypted and have the DRA installed." Where would I get those?
Friday, January 15, 2016 7:07 PM
It's running very late here and I need to go to bed now... Your kind help is really appreciated, I will keep looking at those pages tomorrow. Thank you.
Friday, January 15, 2016 7:17 PM
Are your systems on a domain of some sort? I assumed so as I think domain policy is the only thing that might auto-bitlocker a drive. If so you probably have your domain controller set up as a certificate authority which is where that cert would be.
If not on a domain then I am really confused...
Friday, January 15, 2016 7:19 PM
No. This is my home server, and all of the devices belong to the default WORKGROUP. I am not advanced enough to do any sort of those things yet...
Also, I have connected iSCSI drives from the same server to that Surface before (with unimportant things in them to test how it worked), and nothing like this have ever occured.
Friday, January 15, 2016 8:32 PM
I am sorry to say I am not sure how much more help I can be. Never seen a non-domain system used this way much less auto-encrypt a drive. I do think the encryption somehow was applied by TP4, so I would try working with the VHD from a TP4 install. Maybe try some of the other powershell commands, like so:
full list: https://technet.microsoft.com/en-us/library/jj649829.aspx
Maybe one of the bitlocker gurus will chime in with more specific steps, but I have a feeling that drive may be lost to you =(
Saturday, January 16, 2016 8:36 AM
After hours have passed, I have calmed down quite a lot, and I think you made a point: my Surface probably thought it was a internal disk, sent the encryption signal to the server, and TP4 used its new encryption method to encrypt it, and since the Surface (probably) use its own TPM during the process, I wasn't asked for a password, and TP4 couldn't decrypt it because it doesn't have the TPM or keys.
I have decided to keep that VHDX and remove the disks from my computer for now (because I get upset when seeing that file), buy a couple of new hard disks as I should have done when configuring the iSCSI, wait for the next big release of Windows 10 and see if the new stuffs have come in.
Or do you think the TPM keys be intact if I install TP4 on my Surface for decrypting that disk?
I hope a BitLocker guy would come some time, even if he can't help me with the files, I am still very interested in the causes of this incident, because it is really a mystery.
Again, thank you for your kind help.
Saturday, January 16, 2016 2:34 PM
Omar, you haven't provided important info.
As you could see in your own powershell screenshot, there is no password protector set.
So to make progress, we need to know what protectors are set. You can find out by mounting the vhdx file (to x: maybe) and running the command (in cmd):
manage-bde -protectors -get x:
Then tell me what result you get.
--
There won't be any automated bitlocker encryption. I repeat: not possible. The only thing that does automated encryption is a close relative of bitlocker: device encryption ("DE" from here on). DE is active on devices that
-run windows 8.1 home/core or 10 home, but not on windows 8.1 pro or 10 pro and not on servers.
-also these devices need an activated TPM
-and only if you use a microsoft account (because then, the key will be backed up to your oneDrive).
Sunday, January 17, 2016 9:32 AM
Thank you for pointing that out!
I thought BitLocker and DE were the same thing.
I have a Surface Pro 3 with TPM of course (with the system SSD encrypted), and I have a Microsoft Account signed in on both devices. The problem is, I run my Surface on Windows 10 Pro.
Currently I have my server's CPU removed for a replacement, it has become very unstable lately (what kind of bad luck am I getting!)
Hopefully I will have a desktop working tomorrow, and I will show you the results of the CMD!
Cheers!
Sunday, January 17, 2016 9:44 AM
Also, I looked online for a bit, and found out that some other users using Windows tablets have similar issues: A locked up network accessed storage after accessing them from a tablet:
Monday, January 18, 2016 12:00 PM
Hi, so, I mounted the storage space on my desktop and the virtual disks locally (no iSCSI because my server's under repair, so it's not the Surface) and here's what I got:
Monday, January 18, 2016 12:33 PM
Omar, that's bad. "No key protectors found" means, there are no more keyholes. Even if you found a key, it is unusable. I have no idea, how you could get rid of the protectors, because you wouldn't lose them but have to delete them manually.
What I would do: use repair-bde on that volume.
Tuesday, January 19, 2016 6:41 AM
Hi Sir,
>>So yesterday I set up an iSCSI disk using the server manager, copied all of my files (1.31TB) into it, connected it with the initiator, and it worked fine on my server machine.
>>Today I connected it with my Surface, and it showed that the disk was locked using BitLocker, which I did not do it myself,
Based on my understanding , iSCSI target server wouldn't encrypt the virtual disk , it may happens on serface side (server side , bitlocker feature was not enabled by default ).
I would suggest you to enable bitlocker on a windows 10 computer then mount that vhd to check if bitlock works .
Best Regards,
Elton
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 [email protected] .
Wednesday, January 20, 2016 6:54 PM
Hi,
The thing is, any BitLocker enabled Windows 10 device (including the Surface that I had it encrypted, I suppose) said that the BitLocker version is incompatible.
Here's a screenshot:
Is there some sort of new BitLocker version used on TP4?
Wednesday, January 20, 2016 7:57 PM
Hi, so, I was looking through the BitLocker keys on my OneDrive, and found one that was created on the exact date my drive was locked, and the computer's name match as well.
As Thildemar pointed out, the Server Preview might be using a newer version of BitLocker, and the CMD stuffs I showed you were from a Windows 10 device, because I still didn't manage to get a Windows Server 2016 TP4 working, and that's probably the reason why the key protector can't be found. As soon as I get my server working, I will see if TP4 can see the key protector, and if I can use the recovery key on it.
I'm sorry to cause any confusions about how could this be possible, because myself was confused as hell too, since I have done absolutely nothing about BitLocker and one day I suddenly found out that all my stuffs were locked up.
Thursday, January 21, 2016 5:06 PM
Omar, the bitlocker version is 2.0 since win7, but win10 v1511 introduced a new encryption method: AES XTS. If you use that, it cannot be mounted and or decrypted on anything prior to win10 v1511 or (I assume) server 2016 TP4.
Friday, January 22, 2016 7:52 AM
That's what it told me, though. I'm using Windows 10 10586, so I think I will try repair-bde.
So, thank you for clarifying it, I think the disk might have became corrupted because I disconnected my Surface when it was encrypting it without my knowledge, much like a removable drive removed when encrypting, am I correct?
Friday, January 22, 2016 8:07 AM
Could be. Good luck.
Tuesday, February 2, 2016 8:01 AM
Hi,
So finally I have been able to have some free time and I bought myself a 2TB disk. I did try repair-bde, but it gave me a "Not enough free space" error, although obviously I have the space needed. Also something interesting happens, when I mount the VHD, the BitLocker icon shows up and when I double-click it it shows the "version incompatible" thingy. When I run repair-bde, the little lock icon in file explorer disappears and when I try to open it I was told "Access denied." Any clue?
Tuesday, February 2, 2016 9:27 AM
Your error message indicates that 2.9 TB are needed, that's indeed to large for your drive.
Repair-bde is called from a non-v1511 system, that's not good, use the current version of win10, v1511.
What I don't understand: what did you buy the new disk for?
Tuesday, February 2, 2016 11:58 AM
Erm, Okay, I was too lazy to do the calculations, I guess.
I don't think I can make such a big mistake, but I do think I am running 1511 (or 10586 as Insiders call it) I will double check.
As for the new disk, first, to store the unencrypted files because they need to erase everything from the destination disk first, and I will also use to extend my storage space once I'm done with that.
Wednesday, February 3, 2016 7:39 AM
Ok, but where are you using repair-bde on, on the new drive? If so, why on the new one, you'd have to do it on the old one.
Wednesday, February 3, 2016 8:15 AM
Um, the 2TB disk was my destination disk for files recovered, and I was recovering files from the VHDX.
Sunday, February 7, 2016 12:09 PM
Hi, terrible news.
I ran through the repair-bde process, but it gave me some errors.
Am I out of luck? This is the only key that matches the machine's name on my OneDrive. As you said it should be done with device encryption, the key should be saved on OneDrive.
Could it be due to the error of "No key protectors found"?
PS C:\Windows\system32> manage-bde -protectors -get x:
BitLocker Drive Encryption: Configuration Tool version 10.0.10011
Copyright (C) 2013 Microsoft Corporation. All rights reserved.
Volume X: []
All Key Protectors
ERROR: No key protectors found.
PS C:\Windows\system32>
I don't know why are the BDE tools on version 10011. I am indeed running Windows 10 10586.
Monday, February 8, 2016 8:32 AM
Yes, no key protectors found is a death sentence for opening the drive.
If repair-bde cannot do anything for you, then maybe nobody can. Even data recovery specialists will have a hard time, sorry. The version of manage-bde is alright, by the way.
Please remember to backup your data at any time so you won't need to care, next time.
Monday, February 8, 2016 8:57 AM
Argh. Sad.
Thank you for your help, anyway. I thought it was already enough to have a mirrored volume, and I read sooo many articles about how ReFS will never fail, and thought I was safe. Never thought something like this would happen.
Will remember to back up things periodically. Also, what's the best way to prevent such corruption from happening on virtual drives? A pair of mirrored VHDX? Or something else?
Monday, February 8, 2016 10:02 AM
Backups. Mirroring would also mirror corruption.