Image upload & deploy taking a long time
-
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.
-
@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.
-
@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 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”
-
@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?
-
@sebastian-roth I will update to latest working. I don’t believe I have any machines to test with though at the moment.
-
I know this is an old topic at this point, but I was running into the exact same issue on Lenovo ThinkPad T470’s using version 1.4.4. I’m very new to FOG and we only need to image a couple of these laptops a month usually, so I just planned way ahead for the raw image capture and deployments, but it was still bothering me that things weren’t working as expected. Finally, I thought I would dig into this a bit more and am so thankful I found this discussion! When I saw that the drive on a freshly imaged laptop had the bitlocker encryption I almost put a hole in the suspended ceiling tile above my chair! @THEMCV Thanks so much for the solution, everything works great after running the commands!
-
@uofadevil said in Image upload & deploy taking a long time:
When I saw that the drive on a freshly imaged laptop had the bitlocker encryption I almost put a hole in the suspended ceiling tile above my chair!
Now that is funny! Thanks for letting us know.
-
@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.
Tagging this for the #wiki