Image upload & deploy taking a long time

[george1421]

@brad-schumann Dind, ding, ding we have our answer.

Bitlocker encrypted drive == raw data file to fog.

Bitlocker needs to be activated after the target system has been created not before its captured.

[Brad Schumann]

@george1421 But we don’t activate/use Bitlocker…

[THEMCV]

@brad-schumann Try this, I ran into this on Surface’s.

Open command prompt as admin.

manage-bde -off

manage-bde -status

Fingers crossed that it will fix it. In my case, Windows was by default encrypting the free space which caused issues.

[Sebastian Roth]

OMG!!! Thank god we figured this out. I thought I was lost in this.

[x23piracy]

@themcv said in Image upload & deploy taking a long time:

@brad-schumann Try this, I ran into this on Surface’s.

Open command prompt as admin.

manage-bde -off

manage-bde -status

Fingers crossed that it will fix it. In my case, Windows was by default encrypting the free space which caused issues.

@Wayne-Workman #wiki worthy!

[THEMCV]

@Sebastian-Roth Glad I could help. Yeah, I hate that Windows gives you the option to “Turn On Bitlocker”, but don’t tell you that the free space is encrypted. I am not sure if this is a something with the latest update/service pack for Windows 10, but I know that I’ve only seen it on Surface’s so far. I haven’t made an image for the latest Windows 10 so we’ll see.

@x23piracy You’re too kind.

[Brad Schumann]

@themcv @Sebastian-Roth That is looking to be the fix… The on server size now shows ~48GB and only took 15min to upload to the server. I am deploying the image to another laptop and the ETA is 12min. Thank you for your help. FYI, we build our images from scratch with Win10 download from Microsoft with a SA agreement so it must be a built in thing .

[Wayne Workman]

@THEMCV @Sebastian-Roth @george1421 I need to clairify because I’ve not been following this thread and don’t really understand fully the problem or solution.

I understand the hardware is: Dell latitude 5580 laptop & Surface Pro

FOG was taking an image as RAW for some reason? Why?
@THEMCV What does the answer you posted do to fix it?
Might other hardware models have this problem?
What’s the best way to word the problem?

[THEMCV]

@wayne-workman The problem is Microsoft is pushing for more BitLocker, so while it is technically off, it is encrypting the free space on the drive causing FOG to want to make it a raw image. I don’t know if this is just on pre installs or with the latest version of Windows, but I ran into this with the latest Surface Pro.

[THEMCV]

@wayne-workman manage-bde -status shows if BitLocker is encrypting the free space and -off starts the decryption process

[Sebastian Roth]

Though this is fixed I wanted to look into this a bit more to understand why this has happened and if we can do something about it to detect this. I am not sure if I can confirm the “free space encrypted” information. Reading this it sounds as if BitLocker was in a state of already encrypted (full disk) but not “activated” (whatever that means):

Waiting for Activation - BitLocker is enabled with a clear protector key and requires further action to be fully protected.

Though I am still not sure if and how we would be able to detect this. Oh wow, reading about this I just found out that you can actually mount bitlocker partitions from linux. Shall we add this to FOG?!? Well, we would need to ask people if they want to clone fast but have an unencrypted clone (mount bitlocked drive and do a file-aware cloning) or slow and have it encrypted on the destination. I don’t think we will be able to generate a fast and also encrypted target. So I reckon it’s not worth adding this feature at all.

[x23piracy]

@themcv afaik this is only enabled in the preinstall of the os the surface is shipped with (recovery).
I never saw that problem with my own images.

Regards X23

[Taspharel]

Same here, working with a clean Windows 10 1703 Professional Version, no such problems.

[george1421]

@sebastian-roth I would wonder if a cloned bitlocker drive (copied in block mode) would be even usable. If it was usable someone who wanted access to the data could just clone the drive and access the data on a different computer. Also on the second computer the tpm chip would be different so in theory the cloned image shouldn’t boot. Again would good would encryption be if a second computer could just access the drive?

I also question the value of encrypting only the free space. I can’t see any value at all for that, other than someone couldn’t access any data files that were erased.

I haven’t seen this issue before either, but we always build our reference images on virtual machines that don’t have access to a tpm chip.

In a way FOG IS already detecting this drive state, it knows its not a readable NT formatted drive and it switches to raw mode. We would just have to understand what FOG was seeing in this instance to see if we could identify the drive being protected by bit locker and notify the IT admin. That notification could also present the commands kindly provided by @THEMCV so the IT admin would know how to fix the issue.

[Quazz]

As far as I understand, by default in Surface Pro images, Bitlocker encryption exists, but if you ‘turn it off’, what actually happens is that it simply grants access to everyone. The drive will appear ‘not valid NTFS’ to most tools as a consequence, of course, but it should work.

[george1421]

@quazz So should that be added to a KB somewhere? i.e. if you have a surface pro, before you sysprep run these commands to remove bit locker so it can be cloned by FOG? Like in the FOG Client section similar to the requirements we have for the FOG Client Service? It is a prep step that is required to be successfully cloned by fog.

General question: Is this “condition” isolated to only MS Surface or is it any OEM installed Win10?

(I have no clue on this since I haven’t been exposed to bit locker as of now) The other part of me wonders if FOG copies that volume as RAW and since it is encrypted with Bit Locker, is that unused space even usable on the cloned system? The TPM chip key would be different so I would assume the encrypted bits would be inaccessible on the new system.

[Quazz]

@george1421 It will probably depend on the vendor whether it’s enabled in their image or not. You can expect it on every Microsoft device at least.

I don’t think bitlocker encrypts just empty space or anything, simply the entire volume. But if bitlocker is ‘off’ then it doesn’t check with TPM chip. You’ll likely only run into issues when you try to enable it since the bitlocker key won’t match the TPM chip.

[Sebastian Roth]

I just had a quick look at the dislocker code and figured that it’s fairly simple to detect a bitlocker partition. For those interested, see here and here. Should be fairly simple to add some detection code to our inits. I’ve got that on my (long) list of things to do…

[Wayne Workman]

@sebastian-roth said in Image upload & deploy taking a long time:

I just had a quick look at the dislocker code and figured that it’s fairly simple to detect a bitlocker partition. For those interested, see here and here. Should be fairly simple to add some detection code to our inits. I’ve got that on my (long) list of things to do…

I think if we could at minimum accomplish detecting if a disk is a bitlocker partition or not would be a large advancement - if the inits detect it, they can throw a fat error saying “Please turn off bitlocker in the OS, use this command to do it: blah, Then try to capture again”

[Sebastian Roth]

@Brad-Schumann @george1421 @Quazz @Taspharel @THEMCV @Wayne-Workman @x23piracy Bitlocker detection has been added to the code (currently being reviewed). Is anyone able and keen to test?