Deploy Windows 10, Windows Server 2016, and Hyper-V Server 2016 Technical Preview Using MDT 2013

[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:

  1. 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
  2. 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.
  3. Name the step something like: Stage DISM from WIM File. For Command line, enter:
    cscript.exe “%SCRIPTROOT%\ZTILoadDISMFromWIM.wsf”
    (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)
New step inserted below Enable Bitlocker (Offline)
Screenshot of DISM Workaround

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:
.\Operating Systems\W10CTP64
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:
    %DeployRoot%\Operating Systems\W10CTP64\sources\boot.wim
  • 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:

  1. 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
  2. Repeat step 1 for DeployWiz_ProductKeyVista, LTICleanup, ZTIDiskpart, and ZTIUserState
  3. 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.
  4. Open the Windows 10 / Windows Server 2016 / Hyper-V Server 2016 task sequence, created earlier.
  5. Expand State Restore -> Imaging -> Capture Image, then click on Apply Windows PE (BCD). Click on the Options tab.
  6. 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!


  • todd January 5, 2015 11:59 am

    still prompts for product key at later phase of install even tho “SkipProductKey=YES is set.

  • Frank Lesniak January 13, 2015 8:21 am

    Todd, which edition of Windows 10 or Windows Server vNext were you trying to deploy?

  • steve January 21, 2015 10:58 pm

    This is not working as it should 🙁
    I started a brand new deployment share and just downloaded version 6.4.9879.0 for Windows 10 Enterprise
    My MDT server works flawlessly with Windows 7
    There errors I get are

    I see the DISM folders and file under X:\Windows\System32
    I made sure to delete and retype the quotes
    This is on VM Workstation
    When I build a new VM, I use Windows 8 x64
    MDT 2013 on Server 2012

    • steve January 21, 2015 11:00 pm

      it didn’t allow me to paste in my errors
      failed to mou WIM image using DISM
      event 41002

  • Frank Lesniak January 22, 2015 12:16 pm

    Hello Steve, thanks for reaching out. Would you mind trying this again? When you receive the error message, please grab your log files from either X:\MININT\SMSOSD\OSDLOGS or C:\MININT\SMSOSD\OSDLOGS. Since you will be in WinPE at this point in the process, it would probably be best to copy them to a network share using the command prompt.

    Once you have them copied, take a look at the ZTILoadDISMFromWIM.log file. It should indicate the whether or not the DISM workaround to support Windows 10 succeeded. If you do not see this log file, then the “Stage DISM from WIM File” step was not executed (check your task sequence to find out why).

    To clarify, when you check X:\Windows\System32, are you seeing the updated DISM binaries (i.e., have you confirmed that the DISM binaries loaded there are the ones from the Windows 10 ISO and not the ones that would already be there from the Windows 8.1 ADK)?

    Are you, by chance, booting to a WinPE environment that has a different bit-width than the version of Windows 10 that you are deploying? For example, are you booting to a 32-bit WinPE environment but deploying the 64-bit version of Windows 10?

    If you need some help interpreting the logs, please ZIP them up and send them to me at flesniak at (remove the capital MAIL from the email address).


  • John January 28, 2015 12:33 pm

    Cant seem to get Win 10 build 9926 to deploy.
    In the logs I can see your script running but on reboot I get “An operating system wasn’t found”

  • Todd April 6, 2015 1:49 pm

    Frank Lesniak writes:
    January 13, 2015 at 8:21 am
    Todd, which edition of Windows 10 or Windows Server vNext were you trying to deploy?

    Windows 10 Standard Edition

  • Mike May 6, 2015 2:48 pm

    What .wim should we be using the Tech Preview 1?

    • Frank Lesniak June 5, 2015 1:47 pm

      Hey Mike, I wrote some up additional instructions so that you can deploy the newer preview builds of Windows 10. Check them out and let me know what you think.

  • Henry June 22, 2015 1:59 pm

    any place I can get tech preview 1

    • Frank Lesniak June 22, 2015 2:03 pm

      Henry, there are no reputable places to obtain Tech Preview 1 at this point. Out of curiosity, why are you trying to use the older build?

Phone: 312-602-4000
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons