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.
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.
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 :-)
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 http://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 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:
Find a machine that meets the requirements and you’re ready to do a bare metal deployment:
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.
Just complete the previous four steps. OK, but those steps leave out the details, so let’s use a checklist instead.
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:
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:
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:
And that’s all there is to it.
Well, almost. I need to point out a few more things:
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…