Experimenting with WIMBoot using MDT 2013

  • Article

With the release of the Windows 8.1 Update, there is a new mechanism available for running Windows called Windows Image Boot, or WIMBoot for short.  For details about what this is and how it works, see the Springboard blog.

Although MDT 2013 doesn’t include any specific support for WIMBoot (maybe something that could be considered for a future release), there’s nothing preventing anyone from following the instructions available in the ADK to create a task sequence that does it.  So I decided to try it.  Let’s walk through the process at a high level.

Step #1:  Create an image with Windows 8.1 Update

Because WIMBoot is a new feature with the Windows 8.1 Update, it makes sense that you first need to have a Windows 8.1 image that contains the Windows 8.1 Update.  The easiest way to do this is to download a pre-patched ISO from the Volume License Service Center on April 14th, but you can also inject the Windows 8.1 Update fixes into an existing Windows image.

Step #2: Get MDT 2013 to create a Windows PE 5.1 boot image

In order to deploy WIMBoot, you need to use a version of Windows PE that supports it.  That would be Windows PE 5.1.  But that’s not a version that you just download and use.  Instead, it’s a version that you (or ideally MDT) need to create.  The first step in that is to update the ADK to the latest version.  Download the new ADKSETUP.EXE and run it to install all the patches. 

After you’ve done that, the process for creating a Windows PE 5.1 image involves injecting the Windows 8.1 Update into Windows PE.  That’s not something MDT knows anything about, but since MDT includes the ability to run a script during the boot image generation process, it can be “taught.”  That means dropping in an updated UpdateExit.vbs script that injects the six Windows 8.1 Update fixes to the boot image.  And of course it needs to have those updates available to it, so you need to download those from the Download Center and place them where the script can find them.

After that’s done, update the deployment share, completely regenerating the boot image.  This will take quite a while, as the Windows PE generation process itself isn’t very fast to start with, but when you add in the patch installation process the time will easily double.  Maybe you want to try this in a lab :-)

Step #3: Teach MDT how to deploy using WIMBoot

The steps necessary to apply a WIM using WIMBoot are not surprisingly different than what MDT typically does, so the existing LTIApply.wsf script won’t do it.  So we need a new script.  Fortunately, because we can focus exclusively on this one scenario, the scripting needed to this, which follows the ADK steps documented at https://technet.microsoft.com/en-us/library/dn605112.aspx, isn’t too hard.  To add more flexibility and to solve some challenges, I added a few features:

  • The script will dynamically determine the size of the “Images” volume needed to hold the WIM file, then shrink the OS partition by that size.  That way, you don’t need to modify the “Format and Partition Disk” step to specify an explicit size, which is nearly impossible to do anyway because you want a fixed-size partition after the OS partition, where the OS partition says “100% of the remaining free space”, an impossible combination in the UI.
  • The script will export an existing WIM to make it ready for WIMBoot.  This export process, done using DISM.EXE /Export-Image /WIMBoot, ends up adding a lot of time to the deployment process though, because it ends up decompressing and recompressing the contents of the WIM in the process of exporting it.  As an alternative, you can do this once ahead of time (manually) and tell the script that you’ve done this.
  • If for some reason you want to explicitly specify the size of the images partition, you can through a command line parameter.
  • Ideally the machine would be set up properly so that the system recovery options (Reset My PC/Refresh My PC) work.  To do this, you need a Windows RE boot image that has been updated with the Windows 8.1 Update fixes, using the same basic steps documented at https://technet.microsoft.com/en-us/library/dn613859.aspx.  That part must be done manually, but the script will look for the WinRE.wim file in the same folder as the OS WIM and copy it to the same “Images” volume and register it as a recovery image.

The next piece is a task sequence.  Since WIMBoot is really only useful for bare metal deployments, I took the standard client task sequence template and chopped it down to the bare minimum needed to perform a bare metal WIMBoot deployment, while still supporting things like driver injection, app installation, Windows Update installation, etc.  The original “Install Operating System” is left in but disabled, since that’s the step that provides a simple way to associate an OS with the task sequence.  Instead of running this step, a new step was added to run “LTIApplyWIMBoot.wsf”, the new script discussed above.  The net result is something that looks like this:

image

Step #4:  Deploy

Find a machine that meets the requirements and you’re ready to do a bare metal deployment:

  • 16GB or 32GB SSD or eMMC solid-state storage.
  • UEFI 2.3.1 system (Windows 8 logo-certified).

Ideally these would be machines that come already configured for WIMBoot (since you know it meets the requirements and has been tested by the OEM to ensure good performance).  But if you just want to test it out, you can try it on Windows Server 2012 R2 Hyper-V or Windows 8.1 Hyper-V, since both support “type 2” virtual machines that use UEFI. 

What do you have to do?

Just complete the previous four steps.  OK, but those steps leave out the details, so let’s use a checklist instead.

  1. Create a Windows 8.1 Update operating system image by injecting the Windows 8.1 Updates into an existing Windows 8.1 image, or download a new Windows 8.1 Update ISO already containing the updates from VLSC (available on April 14th).  Import the operating system into your MDT deployment share.

  2. Download the updated ADKSETUP.EXE for the ADK for Windows 8.1 and use it to install the updated ADK components released with Windows 8.1 Update.

  3. Download the Windows 8.1 Update prerequisite (a servicing stack update) for both x86 and x64 from https://support.microsoft.com/kb/2919442, and place them into the “C:\Program Files\Microsoft Deployment Toolkit\Samples” folder.  (Note that both x86 and x64 versions are needed because they will be used to update x86 and x64 boot images.)

  4. Download the individual x86 and x64 Windows 8.1 Updates from the download center and place them into the “C:\Program Files\Microsoft Deployment Toolkit\Samples” folder.  (Note that both x86 and x64 versions are needed because they will be used to update x86 and x64 boot images.)  With the downloads from step #3 and these, you should have a total of 12 different MSU files in the folder.

  5. Place the updated “UpdateExit.vbs” file in the attached zip file into the same “C:\Program Files\Microsoft Deployment Toolkit\Samples” folder, replacing the version that is already there.  (If you’ve made any other changes to this, you’ll need to merge your changes into the attached version.)  This script will be called during the deployment share update process to inject the Windows 8.1 Update into the boot images, which is what is needed to make Windows PE 5.1 boot images.

  6. Update your deployment share by right-clicking on it and choosing the “Update deployment share” option.  Make sure you check the “Completely regenerate the boot images” option, as this is needed the first time to get Windows PE updated.

  7. Check the results of the “update” process to make sure all the MSU files were injected successfully by making sure all the steps have good return codes.  Here’s an example:

    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2919442-x86.msu"
    Return code from command = 0
    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2919355-x86.msu"
    Return code from command = 0
    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2932046-x86.msu"
    Return code from command = 0
    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2937592-x86.msu"
    Return code from command = 0
    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2938439-x86.msu"
    Return code from command = 0
    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2934018-x86.msu"
    Return code from command = 0
    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Cleanup-Image /StartComponentCleanup /ResetBase
    Return code from command = 0

  8. Place the new “WIMBoot.xml” task sequence template from the attached zip file into the “C:\Program Files\Microsoft Deployment Toolkit\Templates” folder.

  9. Place the new “LTIApplyWIMBoot.wsf” script into the deployment share’s “Scripts” folder.

  10. Create a new task sequence, selecting the “WIMBoot Task Sequence” template and the operating system image that you imported.

  11. Perform a bare metal deployment using the updated boot images (update WDS if using PXE, generate new boot CDs, etc.), selecting your new task sequence.

In this scenario, you’ll notice during the task sequence execution that the operating image is exported to make it ready for WIMBoot.  This export process takes a long time, because it changes the compression method used for the WIM.  It's the easiest option since it requires no additional steps on your part, but it’s not the quickest.  If you want to make the process faster, you can follow these steps:

  1. Export the existing WIM image using this DISM command:
    DISM.EXE /Export-Image /WIMBoot /SourceImageFile:<original WIM> /SourceIndex:1 /DestinationImageFile:<new WIM to create>
  2. Import the new WIM into your deployment share.
  3. Update your existing WIMBoot task sequence to use the new image.
  4. Modify the task sequence step “Apply WIM Boot Image“ to add a “/Optimized:TRUE” switch to the LTIApplyWIMBoot step to indicate that no export is required.

Note that this WIM image can still be used for non-WIMBoot deployments – it’s ready for WIMBoot, but not optimized for WIMBoot.  If you want to take it a step further, you can optimize that exported image (following the above three steps first) using these steps:

  1. Mount the WIMBoot-ready image using DISM:
    DISM.EXE /Mount-Image /ImageFile:<WIM file> /Index:1 /MountDir:C:\Mount
  2. Optimize the image for WIMBoot using DISM:
    DISM.EXE /Image:C:\Mount /Optimize-Image /WIMBoot
  3. Commit the changes to the WIM file:
    DISM.EXE /Unmount-Image /MountDir:C:\Mount /Commit
  4. Import the modified image into your deployment share.
  5. Update your existing WIMBoot task sequence to use the new image.
  6. Modify the task sequence step “Apply WIM Boot Image“ to add a “/Optimized:TRUE” switch to the LTIApplyWIMBoot step to indicate that no export is required.

And one more thing:  You need to perform some additional steps if you want Windows RE to work for recovering a WIMBoot system.  This is needed to ensure the refresh/reset my PC options work from PC Settings, that the machine can self-repair if something happens during the boot process, that BitLocker recovery can work properly, etc.  So it’s highly recommend that you do this.  To do this, follow these steps:

  1. Mount your Windows image using DISM:
    DISM.EXE /Mount-Image /ImageFile:<WIM file> /Index:1 /MountDir:C:\Mount
  2. Move the WinRE.WIM out of the image (since recovery can’t boot a WIM within a WIM):
    move C:\mount\Windows\Windows\System32\Recovery\winre.wim C:\winre.wim
  3. Commit the changes to the WIM file:
    DISM.EXE /Unmount-Image /MountDir:C:\Mount /Commit
  4. Mount the WinRE.WIM file:
    DISM.EXE /Mount-Image /ImageFile:C:\winre.wim /Index:1 /MountDir:C:\Mount
  5. Inject the downloaded Windows 8.1 updates into the WIM image:
    DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2919442-x86.msu
    DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2919355-x86.msu
    DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2932046-x86.msu
    DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2937592-x86.msu
    DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2934018-x86.msu
  6. Cleanup the image as described in the ADK documentation:
    DISM.EXE /Image:C:\Mount /Cleanup-Image /StartComponentCleanup /ResetBase
  7. Commit the changes to the WIM file:
    DISM.EXE /Unmount-Image /MountDir:C:\Mount /Commit
  8. Export the contents of the WIM into a new WIM to reduce the size of the image:
    DISM.EXE /Export-Image /SourceImageFile:C:\winre.wim /SourceIndex:1 /DestinationImageFile:C:\winre-new.wim
  9. Copy the resulting file into the same folder as the operating system WIM on the deployment share, e.g. “C:\DeploymentShare\Operating Systems\WIMBoot”.  Make sure the file is named “winre.wim” so that the LTIApplyWIMBoot.wsf script can find it; the script will take care of the remaining steps.

And that’s all there is to it. 

Well, almost.  I need to point out a few more things:

  • I am providing these scripts and the task sequence template as-is.  It’s not supported by Microsoft, so don’t call support about it.  Feel free to e-mail me at mniehaus@microsoft.com, but I can’t guarantee a quick response – might take weeks or months before I get to the e-mail :-)
  • When you use a non-WIMBoot image (one not exported using the steps above), the recompression process that happens when the image is exported causes the new image to be larger than the original one.  The LTIApplyWIMBoot script attempts to guess at how big, assuming it will be about one-third bigger, but that might not be accurate.  If you run into issues where the OS image and winre.wim won’t fit, you can either go through the export steps above (so no guessing needs to be done), or you can explicitly specify how big you want to make the images partition by adding an “ImagesSize” switch to the LTIApplyWIMBoot command line.  See the script comments for more information.
  • If you choose to optimize the operating system image using the steps above, you might also want to export the image into a new WIM file to make it as small as possible.  It won’t be a huge difference, but on a 16GB system, every little bit helps.
  • Remember, WIMBoot is intended for new hardware that has smaller (16GB or 32GB) SSD or eMMC disks, and requires Windows 8 certified UEFI systems.  I would only recommend using it on systems that originally shipped from the manufacturer configured for WIMBoot.  For example, let’s say you purchased a new 16GB tablet that was configured with WIMBoot and the Windows 8.1 “core” SKU, and you wanted to deploy Windows 8.1 Enterprise to it.  You could use the provided task sequence to completely wipe the device (no data migration) and reload it.
  • If you want to try this in a VM, feel free – but remember it needs to be a UEFI virtual machine (e.g. Hyper-V on Windows 8.1 or Windows Server 2012 R2).  But this isn’t intended for virtual machines, VDI, or other scenarios.
  • If you’ve set everything up correctly, you should be able to see in the Disk Management tool that the C: drive is using WIMBoot.  And more importantly, the refresh and reset recovery options should work.  Try them out at least once to make sure.
  • I included steps in the task sequence template to restore user state (useful for a “replace” scenario), to inject drivers, to inject updates, and to install apps.  But there is nothing to capture state.  That’s because this is a bare metal-only scenario.
  • Make sure you have a lot of free disk space, as the Windows PE generation process will likely require at least 3GB of available space to inject the Windows 8.1 Update files (before the cleanup process shrinks it back down again).
  • You won’t see any progress reported while the updates are being injected into Windows PE, as the UpdateExit.vbs script doesn’t have the ability to provide any real-time status information back to Workbench.  Just be patient – you can see via Task Manager that the DISM commands are still running.

Please try this out when you have some spare time, and post some comments indicating if it worked or not.  Most of the validation of the steps in this blog was done in hotel rooms, airports, and airplanes…

WIMBoot.zip