October, 2015

WINPE 10 Problems and work arounds

To successfully deploy Windows 10 Microsoft recommends using WINPE 10 however there has been a few issues with Powershell and .Net Framework

You may see randomly the errors

The operating system reported error 2147943401: Recursion too deep; the stack overflowed.

The exception Illegal Instruction. An attempt was made to execute an illegal instruction.


A work around is to not use WINPE10 however you're going to run into issues applying driver packs

Dism failed with return code 50
Failed to add driver to driver store. Code 0x80070032
Failed to provision driver. Code 0x80070032


Johan has a great post on adding the WINPE 10 Dism files for the preview preview release and fortunately the steps work with current WINPE 10 dism files.



The basic steps without updating your toolkit files:

Launch Powershell and mount your WINPE10 Wim

Mount-WindowsImage -ImagePath C:\Bootx64.wim -Index 1  -Path C:\mount

Copy the Dism.Exe and also the DISM folder from C:\mount\Windows\System32 to a folder and create an SCCM Package


Unmount the Wim

Dismount-WindowsImage -Path D:\temp\mount -Discard

In the task sequence create the 2 steps using the package before the Apply Driver step:

Copy Windows 10 dism.exe:  cmd /c copy dism.exe x:\windows\system32\ /y

Copy Windows 10 DISM subsystem:  cmd /c copy .\dism\*  x:\windows\system32\dism\ /y


Then change your boot Image to the Winpe 5 wim. This may be a disadvantage if you have upgraded your Site Server to ADK 10, have not tested the scenario of going back to previous ADK. This should only really be used until Microsoft has resolved the issues.

MDT Bitlocker Step completes successfully however logs Verify %OSSKU% is defined.


Bitlocker is only supported on Windows Enterprise or Windows Ultimate or Windows Server
Verify %OSSKU% is defined

During the Bitlocker step a few checks are made including one that attempts to determine whether the install.wim is enterprise, to work around this define the task sequence variable OSSKU to ENTERPRISE.

ALTERNATIVELY Use the SCCM built-in step to enable bitlocker.

Ensure the Operating System applys to C: drive not D: drive


This problem will increase more and more as everyone starts to use wim's instead of the OS media in SCCM.

There are a few workarounds for this problem however the best method is to force the new OS the reevaluate Drive Letters with 3 easy steps after applying the OS

Create a Run Command Line step for each of the 3 commands

Reg.exe load HKLM\Temp %OSDTargetSystemDrive%\Windows\system32\config\system

Reg.exe delete HKLM\Temp\MountedDevices /va /f

Reg.exe unload HKLM\Temp


This forces the default behaviour of Windows to choose the drive letter.


For more information and other workarounds see http://blogs.technet.com/b/configurationmgr/archive/2014/04/28/how-to-ensure-that-windows-installs-on-c-during-a-system-center-2012-configuration-manager-osd-task-sequence.aspx