In the beginning there was DOS, and it was good. But then there was a need for more and Windows came into being. At first, it was OK to pop the floppy disks that contained Windows for Workgroups into machines one by one on each computer individually in an enterprise environment. But soon, businesses started asking for things such as configuration settings for deploying Windows en masse.
And so, Unattend.txt and Sysdiff.exe and other fun things were created, where the intrepid NT 3.5 admin could build a machine, tweak it, and run Sysdiff to create a template with which other installations could follow and be identical, more or less. Later, as things progressed, the need was strong for a way to really clone machines!
And so, in the distant past (10+ years ago), the world of imaging and deploying the Windows Client came to be ruled by disk sector duplication deployments. This process was fairly involved, in that a technician would install a copy of Windows XP, patch it, install updated drivers, configure Windows XP's look and feel, install applications, patch the applications and finally configure the applications. After that was done (a process that could take a day or more) it was captured with a tool in a sector-by-sector fashion into a file for later deployment over network or media, again, sector-by-sector. Thus the technician would have an image, for a single model of computer, with a single set of applications.
So imagine an enterprise-level environment with say, 10 models of computers (I've seen some with over 100 models so 10 is a good example) and 1-3 sets of applications installed per model. Now the technician (or now it's most likely technicians at this point) is patching and managing roughly 10-30 images in our conservatively estimated enterprise environment. We didn't even throw 32 bit versus 64 bit into the equation.
So this poses a few problems for deployment projects that may not be readily apparent:
Each image is say 15-20 GB in size post-compression. Particularly in computing ages past, maintaining a library of images of this size was a daunting proposition.
Each image needs to be updated on a semi-regular basis to take into account service packs, OS patches, application patches, driver updates, and random configuration tweaks requested by management and marketing departments. Not doing so increases the deployment time as all the work of applying updates and patches then occurs at every deployment process instead of once before capture.
Each machine had the same globally unique identifier (GUID), because it was in fact a clone of another machine. So when you joined both to the same Windows domain (even with different names) hilarity ensued. Tools were created, such as NewSID and Sysprep's
/generalizeswitch, which helped get around this.
But around 2006, with the release of Windows Vista, things changed. There was a new paradigm in image deployment that would change everything: the Windows Imaging Format (WIM) format. The WIM format is essentially a container for an image. With it, and some tools from the Assessment and Deployment Kit (ADK), one can service the Windows image offline, which allows us to add patches, drivers, and remove components such as games from our image, all without having to install it first on bare-metal hardware.
An example of this would be something like the Deployment Image Servicing and Management (DISM) command (in an elevated command prompt) to remove a hotfix from your running system:
DISM /online /remove-package /packagename:Package_for_KB2868623~31bf3856ad364e35~amd64~~6.1.1.1
Around this same time enters a tool known as BDD. The Business Desktop Deployment (BDD) toolkit was a set of scripts that could be used to customize, configure, and deploy the Windows image in the enterprise environment. BDD 2.5 was released in August 2005, prior to the RTM of Vista.
BDD had several iterations and even had a Microsoft Certified Professional Exam created for one of its versions. These iterations were each an improvement upon the last until finally, in November 2007, the MDT was released.
Fast forward to the present, and MDT 2013 Update 2 is current at the time of writing. At this point, MDT is essentially System Center Configuration Manager (SCCM) "lite". You can backend it with a database, put a web frontend on it, do dynamic actions based on hardware make and model, install previous applications, and much more.
This tool, the MDT, will be the focus of this book. There are other (typically more expensive) solutions out there to be sure, but if one is preparing to perform deployments at scale, MDT should be looked at as it can easily do a lot of manual work and, while it costs nothing, it is supported by Microsoft Support.