Got a IM today from a Consultant who was having trouble creating an end to end deployment of Windows 10 for some Surface Pro 3 devices. Hey, I love Surface Pro 3 devices ( I have 3 in my office :^), so I thought I would help out.
The error message was when he tried to enable BitLocker, but that turned out to be a red-herring.
The Error
He had enabled BitLocker Pre-Provisioning and was trying to enable the protectors at the end, but kept getting errors like
“This PC Doesn’t support entering a BitLocker recovery password during startup. Ask your administrator to configure Windows Recovery Environment so that you can use BitLocker.”
What does WinRE have to do with bitlocker? OK, we ran REAgentC.exe /Info to see what the status of Recovery was, and turns out that it was *NOT* installed.
OK Let’s run the REAgentC.exe /enable command to turn it on:
“REAGENTC.EXE: Windows RE cannot be enabled on a volume with BitLocker Drive Encryption enabled.”
BitLocker wont’ start because it’s missing WinRE, and WinRE won’t install because of BitLocker. Super!!
Well after digging some more, we found out from the panther logs that the REAgentC.exe command was attempting to copy the WinRE.wim file from the OS partition to the WinRE partition created by MDT’s ZTIDiskPart.wsf but failed because the size was too small. Too small?
The Root Cause
I Went back and looked at some WinRE sizes from current and past OS’es:
- Windows 7 SP1 x86 – 145,287,084
- Windows 7 SP1 x64 – 169,213,970
- Windows 8.1 Update x86 – 193,132,205
- Windows 8.1 Update x64 – 236,122,267
- Windows 10 x86 – 238,226,804
- Windows 10 x64 – 302,808,595
Wow, the Windows 10 x64 WinRE image is *far* bigger than the other versions.
Well, sometimes MDT can use the LitetouchPE WIM file as a WinRE file, how does the Win 10 ADK look:
- LiteTouchPE_x64.wim – 305,928,022
- LiteTouchPE_x86.wim – 246,698,134
Well, since the Surface Pro 3 will *only* use x64, we better account for at least 310MB on our Recovery Partition.
What does ZTIDiskPart.wsf allocate? Easy it’s hard coded (in Mega Bytes):
Const WINRE_DRIVE_SIZE = 300
Our 302MB image is just *not* going to fit on a 300MB partition. Nope.
Bug
I opened this bug against the small partition size back in October of 2014:
Additionally, can you up the size of WINRE_DRIVE_SIZE in ZTIDiskPArt.wsf to something like 400?
If you would like MDT to install WinRE.wim for Windows 10 scenarios, please log into connect and up-vote this connect bug. :^)
-k
ZTIWinRE.wsf
P.S. Additionally, please do *NOT* ask me about ZTIWinRE.wsf, it’s a piece of junk and should be completely removed from MDT. I will not speak of it (unless you are on the MDT team, and I will be happy to explain why it is evil and wrong, and should be deleted ). :^p
Keith's Consulting Blog 
Wow this is an interesting one. I just updated a new Surface Pro 3, ran the Windows 10 update using Media Creation Tool, and now I face this issue. Is there a workaround?
If you are talking about MDT, then yes, my fix above to MDT should resolve the issue for future updates.
I believe this page proposes some solutions:
https://social.technet.microsoft.com/Forums/en-US/9801aa0a-d876-4699-a31d-ba4ca08eea50/solved-how-do-i-prepare-windows-recovery-environment-on-windows-10-taking-backup-measures-on-your?forum=WinPreview2014Setup
Not really, my uber bug was a bug in MDT, should be fixed in the next version of MDT.
Why do you mention it sometimes uses the LiteTouch wim? Is there a reason that happens. I’m running in to this exact issue after upgrading to the most recent version of MDT.
Bug should be fixed in the latest MDT version out this week.
My lighttouch wim file is larger than the 499 MB that it sets up.