Building reference images like a boss!

It’s a great week here at TechEd 2014 in Houston, later this afternoon I will present the never-dying “Creating the perfect reference image” with my partner in crime (and good friend), Mikael Nystrom. If you ever attended one of my deployment sessions before, you know I recommend using MDT Lite Touch for most scenarios, but what if you want to speed up the process?

All in all, by following these tips you can speed up the image capturing process by about 400 percent 🙂

 

 

 

Free Resources

If you haven’t created reference images with MDT before, check these Microsoft resources:

Microsoft TechNet guide: Create a Windows 8.1 Reference Image
http://technet.microsoft.com/en-us/library/dn744290.aspx

Microsoft TechNet Virtual Lab: Creating a Windows 8.1 reference image
http://go.microsoft.com/?linkid=9845755

TechEd 2014 video: Building the Perfect Windows 8.1 Image
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/WIN-B346 

 

Make the image smaller by deleting setup files for already installed updates

Mikael Nystrom (deploymentbunny.com) has created a nice VBScript for some cleanup operations, including running the DISM.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase command – Effectively shaving of about 1 GB of the image size. Simply add the script as an application, and configure your task sequence to run it before sysprep. You can download the script from his post: http://deploymentbunny.com/2014/06/05/nice-to-know-get-rid-of-all-junk-before-sysprep-and-capture-when-creating-a-reference-image-in-mdt

 
A Windows Server 2012 R2 reference image, fully patched, with and without cleanup.

Make sure ALL updates are installed into the reference image

Because of an issue with the ZTIWindowsUpdate.wsf script, not all updates will be installed during build and capture. There reason is that some updates actually have to be reinstalled, and the script logic prevents that. The workaround is simply to reset the updates list in between the two Windows Update actions. Alexey Semibratov and Keith Garner came up with a simple workaround back in the MDT 2010 days that still is valid for MDT 2012/2013.

ZTIWindowsUpdate.WSF does not install all patches
http://blogs.msdn.com/b/alex_semi/archive/2010/03/17/ztiwindowsupdate-wsf-does-not-install-all-patches.aspx

The script from Alex and Keith added to a Windows 7 task sequence.

Note: Mikael Nystrom also posted an updated version of the script that includes logging here: http://anothermike2.wordpress.com/2015/03/30/nice-to-know-reset-the-wsus-update-count-during-osd-allows-automatic-reinstallation-of-patches-that-failed/

Bump up the speed using a VM with multiple vCPUs

Capturing a 4 GB image with MDT typically takes 40 minutes on a virtual machine with 1 vCPU, but only 25 minutes when assigning 2 vCPU’s.

 

Bump up the memory to at least 4 GB

Windows 7 currently has quite many updates (almost 200) that needs to be deployed, so many in fact you may run out of memory. Settings the VM memory to 4GB solves that problem.

Update the Windows Update agent

Make sure that the latest Windows Update agent (currently July 2015) is installed by the task sequence before the Windows Update action. Here is the link: http://support.microsoft.com/en-us/kb/3065987 

Bump up the speed using DISM instead of ImageX

Of the above numbers, when using MDT with the default scripts to capture Windows 8.1 and Windows 10, about 15 minutes is used just scanning the file system (bug in ImageX which MDT is using). You can use DISM instead, which is much faster, see be below post by Mikael. This is not needed for build and capture of Windows 7, but since DISM works for Windows 7 and Windows 8.1/10, it makes sense to make the change anyway.

Nice to Know – Switch from ImageX to DISM in MDT
http://deploymentbunny.com/2014/05/19/nice-to-know-switch-from-imagex-to-dism-in-mdt/

Bump up the speed using a RAM disk

If you already have SSD’s in your Hyper-V or VMware Hosts, you won’t gain to much speed from this tip, but if you have SAN disks, or local 10k/15k disks, you can shorten the build and capture time quite a bit by deploying the VM to a RAM disk instead. Pretty good number of IOPS, and transfer rates 🙂

In my environment I use the free RAM disk from StarWind (http://www.starwindsoftware.com ). Simply create a 20 GB RAM disk, and then create your VM on it.

Note: Don’t let the StarWind app format the disk, do it yourself from disk manager or server manager after the RAM disk is created. I run into weird issues when StarWind was allowed to format the disk.

The 20 GB RAM Disk created.

The RAM disk in File Explorer.