[Update 2015 June 3: Windows 10’s kernel version number has changed from 6.4 to 10.0 – as a result, some additional updates to MDT are required as outlined below]
When Microsoft released the Technical Preview of Windows 10, I was excited to try deploying it using WMP’s Automated Build Environment (ABE) deployment tool. For those that have not yet used ABE, it is a customized version of the Microsoft Deployment Toolkit (MDT). ABE extends MDT by automating operating system import, task sequence creation, and by automatically including support for all the major hardware manufacturers’ drivers. We designed ABE to get MDT functional on an enterprise scale very quickly. The current version of MDT 2013 does not support the deployment of Windows 10. I expect that Microsoft will add support for deploying Windows 10 in a new version of MDT released in preview/beta sometime in the first half of 2015.
In the meantime, our customers count on us to be well versed in operating system deployment, so it was important for us to find a way to test Windows 10 deployment right away. Not surprisingly, in MDT 2013, the deployment of Windows 10 failed when DISM.exe applies the unattend.xml control file to the operating system. MDT 2013 uses the Windows 8.1 version of the Windows Assessment and Deployment Kit (ADK), which includes the Windows 8.1 version of DISM.exe. Unfortunately, this version of DISM.exe does not support Windows 10 – hence the failure.
To work around this problem, we can copy DISM.exe and its supporting subsystem from the Windows 10 ISO’s boot image (boot.wim), from the Windows 10 ISO’s installation image (install.wim), or, in the case of a custom image file, we can pull the DISM files from the custom image WIM file. To understand how this could work, it is important to understand that MDT deploys Windows using Windows PE (WinPE for short). WinPE is a lightweight version of Windows that loads into a temporary memory space known as a RAM disk. Therefore, any changes we make to Windows binaries, including DISM, while we are booted in WinPE are temporary. This is important because we would not want to use the technical preview versions of DISM to deploy our existing Windows 7 / Windows 8.1 images.
Anyway, I wrote a script that mounts the appropriate WIM file, pulls the DISM binaries from it, and loads the WIM files into the temporary WinPE RAM disk. This way, even though we are booted into a Windows 8.1 WinPE boot file that would not ordinarily support Windows 10 deployment, we will have the DISM binaries that we need to pull it off.
Before I explain how to implement this work around, let me explain that Microsoft will NOT support this procedure. Additionally, please take a backup of your MDT environment before implementing this script. Most importantly, do not blame me if something goes horribly wrong!
Without further ado, here are the instructions to implement the script to allow MDT 2013 to deploy Windows 10:
- Download the attached ZTILoadDISMFromWIM ZIP file and extract it. Copy the extracted ZTILoadDISMFromWIM.wsf script file to your MDT Deployment Share’s Scripts folder. For example, copy ZTILoadDISMFromWIM.wsf to C:\DeploymentShare\Scripts
- In your Task Sequence for Windows 10 (create a new one if you have not done so already), expand the Preinstall phase. Click on the Enable BitLocker (Offline) step. Next, click on the Add dropdown, then click General > Run Command Line. This will insert a new step after the Enable BitLocker (Offline) step.
- Name the step something like: Stage DISM from WIM File. For Command line, enter:
(note: be careful when copying and pasting the quotation marks – I recommend retyping them because some programs will replace the intended ANSI character with a different one)
The script allows you to specify an optional parameter to tell it which Operating System folder to use when trying to find an appropriate WIM file. If you need to specify this parameter, you can modify the Command line field as follows:
cscript.exe “%SCRIPTROOT%\ZTILoadDISMFromWIM.wsf” /OSDirName:W10CTP64
Where W10CTP64 is the folder name that you used when you imported the Windows 10 ISO. To find the folder name, use the MDT Deployment Workbench to find the imported operating system. Double-click on it and view the Path field. It will read something like:
In this case, W10CTP64 is the folder name that we would use.
So when do you need to specify the additional parameter? First, let me explain the logic that the script uses when trying to locate a WIM file:
- If you supplied the OSDirName parameter, the script will use it to find the boot.wim file. For example, if the OSDirName specified was W10CTP64, then the script will try and find the boot.wim file here:
- If you did not supply the OSDirName parameter, or if the script could not find the boot.wim file within the specified folder, the script will use the INSTALLFROMPATH variable to locate a boot.wim file. MDT populates the INSTALLFROMPATH variable once you select a task sequence, and the variable points to the install.wim or custom image file. So if the INSTALLFROMPATH variable is:
\\MDTServer\DeploymentShare$\Operating Systems\W10CTP64\sources\install.wim, then the script will replace “install.wim” with “boot.wim” and try to use that path to locate the boot.wim file.
- If the boot.wim file was not found, the script will use the WIM specified at the INSTALLFROMPATH variable
With that background, you should not need to specify the OSDirName parameter. I included it just in case you encounter a use case that I did not think of. I did not need to specify this parameter at all during my testing.
Once the script locates a suitable WIM file, it mounts it against the operating system’s target volume (OSDisk). Next, it copies dism.exe and the system32\DISM folder to a temporary folder on the OSDisk and unmounts the WIM. Finally, it copies the staged DISM files to the WinPE volume (X:\) and deletes the temporary files from the OSDisk.
I wrote the script such that it is not specific to the Windows 10 Technical Preview version released in early October 2014. Theoretically, this script will work with any future not-yet-supported releases of Windows, Windows Server, or Hyper-V Server.
The script’s activity will be logged in MDT’s standard log folder (e.g., C:\MININT\SMSOSD\OSDLOGS or C:\WINDOWS\Temp\DeploymentLogs), and the log file will be called ZTILoadDISMFromWIM.log. If you have a problem or need to diagnose the script’s activity, the log is the best place to look.
Update: 2015 June 3:
As many of you have realized, the kernel version number of Windows 10 changed from 6.4 to 10.0. Long story short, this change caused some problems for MDT 2013 (that will be fixed when MDT 2013 Update 1 is released). In the meantime, if you need to get MDT 2013 (without Update 1) working for Windows 10 deployment, please follow these additional steps:
- Browse to your MDT Deployment Share’s Scripts folder and make a backup copy of LTIApply.wsf. For example, browse to C:\DeploymentShare\Scripts, make a copy of the LTIApply script and name the copy LTIApply_Backup_Win10Workaround
- Repeat step 1 for DeployWiz_ProductKeyVista, LTICleanup, ZTIDiskpart, and ZTIUserState
- Download the attached MDT2013ScriptsUpdatedToAllowWin10 ZIP file and extract it. Copy the extracted script files to your MDT Deployment Share’s Scripts folder, overwriting the existing files. For example, copy LTIApply.wsf to C:\DeploymentShare\Script, and repeat for the three other script files.
- Open the Windows 10 / Windows Server 2016 / Hyper-V Server 2016 task sequence, created earlier.
- Expand State Restore -> Imaging -> Capture Image, then click on Apply Windows PE (BCD). Click on the Options tab.
- Click on the condition “Task sequence variable ImageBuild greater than or equals 6”, then click Remove. Click OK.
The updated DeployWiz_ProductKeyVista script file parses the OS kernel/build version numbers correctly to support Windows 10 and allows the user to complete the product key page in the Deployment Wizard (if enabled). The LTIApply script file parses the OS kernel/build version numbers correctly to support Windows 10 and includes the fix in KB2797676. LTICleanup is just updated to parse the OS kernel/build version numbers correctly for Windows 10. ZTIDiskpart is updated not only for Windows 10 support, but also to include support for Push Button Reset disk partitioning on Windows 8.1. Finally, ZTIUserState is updated not only for Windows 10 support, but also to include the workaround to allow XP user state capture (as detailed on this webpage).
These scripts will get your Windows 10 deployment up and running on MDT 2013. I hope that you enjoy using them. Drop me a comment; I would love to hear how your Windows 10 deployment is coming along!