Book Image

Mastering the Microsoft Deployment Toolkit

By : Jeff Stokes, Manuel Singer
Book Image

Mastering the Microsoft Deployment Toolkit

By: Jeff Stokes, Manuel Singer

Overview of this book

Topic The Microsoft Deployment Toolkit (MDT) provides a comprehensive collection of tools, processes, and guidance for automating desktop and server deployments. It considerably reduces deployment time and standardizes desktop and server images. Moreover, MDT offers improved security and ongoing configuration management. Microsoft Deployment Toolkit is the official supported method of creating and customizing Windows images for deployment. Description: Starting from scratch, this book walks you through the MDT setup, task sequence creation, and image deployment steps in detail. Breaking down the various MDT concepts, this book will give you a thorough understanding of the deployment process. Beginning with imaging concepts and theory, you will go on to build a Microsoft Deployment Toolkit environment. You will understand the intricacies of customizing the default user profile in different versions of Windows. Driver handling can be a challenge for larger organizations; we’ll cover various driver concepts including mandatory driver profiles. ]Other important topics like the User State Migration Tool (USMT), configuration of XML files, and how to troubleshoot the USMT are also discussed in the book. We will cover the verifier and Windows Performance Toolkit for image validation scenarios. Furthermore, you will learn about MDT web frontend implementation as well as how to utilize the database capabilities of MDT for deeper deployment options. We’ll wrap it all up with some links to resources for more information, blogs to watch, and useful Twitter handles.
Table of Contents (18 chapters)
Mastering the Microsoft Deployment Toolkit
About the Authors
About the Reviewers

Imaging history

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 /generalize switch, 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~~

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.