Go to ...

RSS Feed

July 5, 2020

War Stories: Sysprep and BitLocker

Yesterday, I decided to do a clean install of the latest Windows Insider build 17711 on my HP ProBook laptop. I do traditional installs quite seldom, usually creating deployment images in Hyper-V. This is practical because Hyper-V standard checkpoints offer an easy way to restore a VM to any point throughout the process whenever something does not work as expected or I want to undo something I’ve already done.

But, this time it was a clean install. Mostly I wanted to time it, to see how long it would take this laptop to boot from WinPE, wipe both the 128 GB M.2 SSD and 1 TB HDD, partition them according to my needs, install W10 from network share, and finally customize it in Audit Mode before sysprepping to OOBE and further to the desktop.

With all this in mind, I prepared a DISKPART script to do the wiping and partitioning as I prefer, run it from WinPE and in less than 7 minutes I was already in Audit Mode. For this laptop, that is quite a good time. Wanting to make this image complete for my personal recovery drive for simple “factory recovery” (read more), I installed my standard software and customized Windows. When everything was done, I ran Sysprep with a custom answer file, and was somewhat taken back when I got a validation error:

I was quite sure it couldn’t be an app provisioning error, so I went to check the log. I was surprised to see that although DISKPART > CLEAN had wiped both disks and Bitlocker which I had previously had running was turned off, according to the log the reason generalizing with Sysprep failed was that BitLocker was on. I had to check this: I opened the BitLocker settings and as I already knew, it was not on:

My first idea was that as TPM is naturally enabled in UEFI settings because I had earlier used BitLocker, if I just restarted to UEFI and disabled it, then returned back to Audit Mode, I could generalize the image. Then I thought that if Windows 10 now thinks BitLocker is on even when it’s off, what if I turn it on now and then immediately off again? Shouldn’t that tell Windows that it is OK to generalize now, BitLocker being turned off. I was also interested to see how long it would take the M.2 drive to decrypt.

The standard software I want pre-installed on my images includes Visual Studio and the Windows ADK (which take quite a lot storage space), in addition to Office 365 and some other software I use so regularly that it’s practical to include it in the image. In other words, at this point the size of Windows and installed software was over 30 GB, with free space on the system disk at over 80 GB.

I was surprised to see that decrypting only took less than 5 minutes. Restarting to UEFI settings, disabling TPM, booting back to Audit Mode, sysprepping and finally after OOBE and first boot to desktop restarting back to UEFI settings to re-enable TPM would have taken about the same time. No time lost, subject to my idea being correct and Sysprep now working.

It did work. No errors, Windows was sysprepped. The captured image for custom recovery partition was complete, the system booted to OOBE and further to the desktop. Curious as I am, I wanted to test the theory. So I created a Macrium Reflect full backup, and repeated the WinPE boot > wipe and repartition disks with DISKPART > clean install from share > boot to Audit Mode cycle. I then tried to generalize with Sysprep, but got the same error with the same culprit: BitLocker. Again it showed up as on although it was off. So I turned Bitlocker on and then off again. This time decrypting took just a minute and a half because the system drive only contained a basic Windows installation, just over 10 GB in size. And again, Sysprep worked like a charm.

I restored the new Macrium image, and am now writing this blog post on the laptop in question.

Conclusion: For some reason unknown to me, Windows had false information about BitLocker being on when in fact it was off. Next time I will remember this: If I need to reinstall and generalize Windows 10 on a computer which has had Windows previously installed and encrypted with Bitlocker, TPM enabled in UEFI, before sysprepping it I’ll switch BitLocker on and off again. It does not take long and enables generalizing. That’s how one often learns new tricks about Windows 10: through trial and error!




Author: Kari Finn

A former Windows Insider MVP, Kari started in computing in the mid 80’s writing code for VAX / VMS systems. Since then, he’s worked in a variety of IT positions. He specializes in Windows image capture, customization, repair and deployment as well as Hyper-V virtualization. Kari is a proud Team Member at number #1 Windows site TenForums.com.

2 Responses “War Stories: Sysprep and BitLocker”

  1. Arshad
    May 28, 2019 at 22:02

    Thanks so much. I was getting the error about Bitlocker being on even though it was off when running sysprep (in the setupact.log file). Per your suggestion, I turned on the Bitlocker and then turned it off again. Process took about 5 minutes. I was able to run sysprep without any problem after that.

    • May 29, 2019 at 13:52

      You are welcome! Good to know you could syprep.

Leave a Reply

More Stories From Bitlocker