I’ve been working with a client recently to get a Windows 10 master image created for deployment on new laptops by the vendor. To achieve this, and without a viable deployment server in the business, I’ve gone back to basics, using the built in DISM tools available in WinPE.
After the comfort blanket provided by tools such as WDS, SCCM and the Microsoft Deployment Toolkit task sequence editor, capturing and deploying images manually came as quite a shock. A whole raft of customisations are required that the GUI-based tools and scripts helpfully hide from you, the most obvious being the drive partition structure and requirements.
It’s a measure of just how rarely I undertake manual captures that my first thought was to use Imagex.exe. Shipped with Windows Server 2008 and Vista, this was the tool of choice for image capture and maintenance, whereas DISM was used to inject things like drivers and language packs.
Skip forward to Server 2012, Imagex is deprecated, and its features are bundled into the DISM tool. However imagex remains in the Windows Automated Installation Kit (WAIK), and I’m reliably informed that the current version can still be used to capture and mount Windows Image Format (.Wim) files. So, I have my laptop, configured ‘just so’ (nobody breath on it), with all required drivers. What’s next?
Understandably, the client is keen for the out-of-box experience (OOBE) to be as clean as possible, with the start menu decluttered, including the removal of some of the less corporate Windows applications like the Xbox Launch centre, and the ‘Mixed reality portal’. However, because we are now in the future, removing these applications using a GUI is no longer acceptable. It can only be done on a per-user basis, and then only via PowerShell. I found this guide (and comments) very useful as a reference for achieving this. The per-user removal is not an issue because we will be copying the admin profile when complete, however this whole process feels more complex than it should, especially given that this is a Windows 10 Enterprise installation.
We added Office and a few LOB applications to this image, which isn’t best practice. Office I can comfortably live with, as it will always be on all laptops, and windows update will provide updates for it automatically. The LOB applications are a short-term fix, the goal here is to rebuild these machines via an SCCM instance in the near future.
Next comes one of the least intuitive steps, the creation of the sysprep answer file using the System Image Manger (SIM). This is another tool that has been around since Windows Vista, and it shows. It really is not much fun to use. Its purpose it to configure settings at installation, and supports the Microsoft Single Instance Storage model, but it boils down typing obscure settings into components that you add to one of the five configuration passes, in the hope that the unattend.xml you create can be successfully parsed by Windows. If you make a mistake, let’s hope you took a snapshot, because you will be left with a half-prepped machine that has lost one of its rearm counts.
The 3 key things we are looking to configure via the answer file are (1) the locale and language settings for the machine (2), the persistence of hardware drivers for the image through the inclusion of the PersistAllDeviceInstalls=true setting, and (3) the configuration of a custom default profile using the CopyProfile=true setting.
In this case, working on a physical machine, I did not have the luxury of snapshots. So I decided to take a full, un-syspreped image of the machine using DISM as a backup. This approach has limitations (it captures the machine HAL, so can only be re-applied to the same machine), but it provided some insurance against a failed sysprep attempt.
So, our machine is exactly as we need it to be, Windows and Office updated with all current critical and security patches, we have our answer file, which hopefully can be parsed. It’s time to kick off the sysprep process. Incidentally, Sysprep has been around for a lot longer than any of the other tools we are looking at, and has been used to capture images since NT 4.0.
Running the command below kicks off the process, and if the syntax is correct, shuts down the machine, which is then ready to be ‘generalized’ on next boot.
c:\Windows\System32\Sysprep\sysprep.exe /generalize /unattend:c:\<PATH> /oobe
Luckily for me this works without issue, however just make sure you haven’t updated any of the windows 10 apps via the Windows Store, as this could lead to failure.
Next up, a boot into WinPE is required. From the command prompt we can capture the local syspreped image using DISM, which is built into the WinPE file structure. This guide provides all the information required for this process.
In this instance, I only need to capture Windows, as the system partitions will be set up by the vendor at build time. Helpfully, MDT automatically detects the machine config at build time to determine the correct partition structure.
After around five minutes of waiting, the capture process is complete, and we can test our newly captured image on a reference machine. To speed this up, I chose to apply the image to a newly created VM on my laptop.
Although the Laptop was configured with BIOS/MBR partitions, I chose to configure the VM with UEFI/GPT based partitions. The nice thing about the .WIM file-based format is that it is essentially partition agnostic, as long as the partitioning pre-requisites have been met. Then it’s simply a case of applying the image and copying the boot files to the system partition.
If everything has worked, a reboot should reveal a working Windows install, which boots to the OOBE, and in my case configured the user’s start menu due to the use of the CopyProfile=true flag in the answer file.
Although I’d always rather be using the full-fat management tools for this type of activity, its still nice to get back into the weeds, and discover the changes and tweaks that have been made to the underlying toolsets over the last few years. I often think how much I rely on the lite-touch scripts of MDT without having a detailed understanding of them all. Going through this process has given me more insight in this respect.
In future, I’m keen to take a look at the newer .FFU format, which marks a return to sector-based, rather than file based imaging, although it removes a lot of the flexibility associated with .WIM files, and is designed as an alternative rather than a replacement, it may prove to be a quicker, simpler alternative in the right scenario.
