Automating Windows 7 Installation For Desktop and VDI Environments

Automating
Windows 7 Installation
for Desktop and
VDI Environments
Greg Shields
Automating Windows 7 Installation for Desktop and VDI Environments

Introduction to Realtime Publishers
by Don Jones, Series Editor
For several years now, Realtime has produced dozens and dozens of high‐quality books
that just happen to be delivered in electronic format—at no cost to you, the reader. We’ve
made this unique publishing model work through the generous support and cooperation of
our sponsors, who agree to bear each book’s production expenses for the benefit of our
readers.
Although we’ve always offered our publications to you for free, don’t think for a moment
that quality is anything less than our top priority. My job is to make sure that our books are
as good as—and in most cases better than—any printed book that would cost you $40 or
more. Our electronic publishing model offers several advantages over printed books: You
receive chapters literally as fast as our authors produce them (hence the “realtime” aspect
of our model), and we can update chapters to reflect the latest changes in technology.
I want to point out that our books are by no means paid advertisements or white papers.
We’re an independent publishing company, and an important aspect of my job is to make
sure that our authors are free to voice their expertise and opinions without reservation or
restriction. We maintain complete editorial control of our publications, and I’m proud that
we’ve produced so many quality books over the past years.
I want to extend an invitation to visit us at http://nexus.realtimepublishers.com, especially
if you’ve received this publication from a friend or colleague. We have a wide variety of
additional books on a range of topics, and you’re sure to find something that’s of interest to
you—and it won’t cost you a thing. We hope you’ll continue to come to Realtime for your
educational needs far into the future.
Until then, enjoy.
Don Jones
i

Introduction to Realtime Publishers ................................................................................................................. i
Chapter 1: Installation Fundamentals: Automatically Deploying Windows 7 with Windows
Deployment Services .............................................................................................................................................. 1
Step One: Installing and Configuring Windows Deployment Server ............................................ 2
Stepping Back: What Can You Now Do? .................................................................................................... 3
Step Two: Configuring WDS for Over‐The‐Network Image Deployment .................................... 5
PXE Response Tab .......................................................................................................................................... 6
Boot Tab .............................................................................................................................................................. 7
DHCP Tab ........................................................................................................................................................... 9
Multicast Tab ................................................................................................................................................. 10
Advanced Tab ................................................................................................................................................ 11
Step Three: Deploying Your First Windows 7 Image ........................................................................ 12
Just a Few Steps to Basic Automation ...................................................................................................... 17
Chapter 2: Creating a Universal Image that Installs Everywhere .................................................... 18
Step Four: Dealing with Drivers ................................................................................................................. 19
Unpacking Drivers ....................................................................................................................................... 19
Adding Drivers to Boot Images .............................................................................................................. 23
Step Five: Automating the WinPE Boot Image ..................................................................................... 24
Preparing WSIM ........................................................................................................................................... 25
Locating the Right Questions and Inserting Answers .................................................................. 27
The Remaining Questions and Answers ............................................................................................ 29
Validating, Saving, and Adding the Answer File to WDS ............................................................ 30
Step Six: Automating the Set Up Windows Phase ............................................................................... 31
Time for Applications ..................................................................................................................................... 34
Chapter 3: Techniques in Installing Applications During Windows Deployment ..................... 35
Step Seven: Creating a Master Image with Applications ................................................................. 35
ii

Invoking Sysprep ......................................................................................................................................... 36
Creating a Capture Image ......................................................................................................................... 37
Capturing the Master Image .................................................................................................................... 39
Stepping Back: Application Delivery Mechanisms ............................................................................. 43
From Thick to Thin ..................................................................................................................................... 45
Thick to Thin: What Do You Need? ...................................................................................................... 45
The Microsoft Deployment Toolkit ...................................................................................................... 46
Coming Up: Folding Your Deployment Infrastructure into the MDT ......................................... 47
Chapter 4: Layering Applications on Top of Deployed Windows Images ..................................... 48
Step Eight: Installing and Preparing the MDT ...................................................................................... 48
Importing an MDT Image ......................................................................................................................... 50
Importing Drivers ........................................................................................................................................ 52
Creating a Task Sequence......................................................................................................................... 53
Updating the Deployment Share ........................................................................................................... 54
Deploying a Basic Desktop with MDT ................................................................................................. 55
Step Nine: Learning Silent Installations and Repackaging ............................................................. 56
Three Ways to Silence Applications .................................................................................................... 58
MSI‐Based Installations ............................................................................................................................ 58
EXE‐Based Installations ............................................................................................................................ 59
Differential‐Based Installations ............................................................................................................. 60
Step Ten: Laying Applications Atop a Windows Image ................................................................... 61
Adding the Application to the MDT ..................................................................................................... 62
Configuring the Application for Deployment .................................................................................. 63
Thin Is Most Definitely In! ............................................................................................................................ 65
Chapter 5: User Virtualization: Tools and Techniques in Preserving User Data ....................... 66
Step Eleven: Preserving User Data ............................................................................................................ 68
Requirement One: Upgrading Windows XP to Windows 7 ....................................................... 69
iii

Requirement Two: Refreshing a Windows 7 Instance ................................................................ 74
Requirement Three: Moving a User to New Computer Hardware ......................................... 74
Stepping Back: Real User Virtualization ................................................................................................. 77
Encapsulation and Decoupling .............................................................................................................. 78
The Benefits of Decoupling ...................................................................................................................... 78
User Virtualization Goes Beyond OS Deployment .............................................................................. 79
Chapter 6: Automating Application Inventory and Overcoming Incompatibility ..................... 81
Step Twelve: Inventorying Applications and Drivers on the Network ..................................... 82
Installing the MAP and Collecting Inventory ................................................................................... 82
Creating and Using MAP Reports .......................................................................................................... 87
Step Thirteen: Resolving Application Incompatibilities .................................................................. 89
Installing the ACT ........................................................................................................................................ 89
Creating a Data Collection Package ...................................................................................................... 91
Analyzing and Keeping Track of Results ........................................................................................... 93
Fixing Incompatible Applications ......................................................................................................... 94
Solving Incompatibility: Not Hard but Time‐Consuming ................................................................ 98
Chapter 7: Creating a Complete Solution for Automating Windows 7 Installation .................. 99
Stepping Back: Understanding LTI, ZTI, and UDI ............................................................................. 100
Step Fourteen: ZTI with ConfigMgr ........................................................................................................ 101
Integrating ConfigMgr with MDT ........................................................................................................ 101
Adding the State Migration Point ....................................................................................................... 102
Creating an OS Deployment Share ..................................................................................................... 103
Creating a Deployment Task Sequence in ConfigMgr ................................................................ 103
Importing Drivers ...................................................................................................................................... 111
Updating Distribution Points ................................................................................................................ 113
Viewing the Task Sequence and Creating the OS Deployment Advertisement .............. 115
Stepping Back: What Haven’t You Seen? What’s Left? .............................................................. 120
iv

The Automations Virtually Never Stop ................................................................................................. 121
Chapter 8: Integrating Automated Windows 7 Installation into VDI Environments ............. 122
Step Fifteen: Integrating MDT into VDI Deployment ...................................................................... 123
Creating a Virtual Machine and Deploying an OS ........................................................................ 123
Injecting Drivers and Virtual Tools .................................................................................................... 127
Tuning the Virtual Machine ................................................................................................................... 128
Guidance for Services .......................................................................................................................... 128
Guidance for Additional Configurations and Scripting ......................................................... 131
Tuning Personal Desktops vs. Pooled Desktops ........................................................................... 133
Preparing and Templatizing the Deployed Virtual Machine .................................................. 134
Automating Windows 7 Installation: Start to Finish ....................................................................... 135
Download Additional eBooks from Realtime Nexus! ...................................................................... 135
v

Copyright Statement
© 2011 Realtime Publishers. All rights reserved. This site contains materials that have
been created, developed, or commissioned by, and published with the permission of,
Realtime Publishers (the “Materials”) and this site and any such Materials are protected
by international copyright and trademark laws.
THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice
and do not represent a commitment on the part of Realtime Publishers or its web site
sponsors. In no event shall Realtime Publishers or its web site sponsors be held liable for
technical or editorial errors or omissions contained in the Materials, including without
limitation, for any direct, indirect, incidental, special, exemplary or consequential
damages whatsoever resulting from the use of any information contained in the Materials.
The Materials (including but not limited to the text, images, audio, and/or video) may not
be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any
way, in whole or in part, except that one copy may be downloaded for your personal, non-
commercial use on a single computer. In connection with such use, you may not modify
or obscure any copyright or other proprietary notice.
The Materials may contain trademarks, services marks and logos that are the property of
third parties. You are not permitted to use these trademarks, services marks or logos
without prior written consent of such third parties.
Realtime Publishers and the Realtime Publishers logo are registered in the US Patent &
Trademark Office. All other product or service names are the property of their respective
owners.
If you have any questions about these terms, or if you would like information about
licensing materials from Realtime Publishers, please contact us via e-mail at
info@realtimepublishers.com.
vi

[Editor's Note: This eBook was downloaded from Realtime Nexus—The Digital Library for IT
Professionals. All leading technology eBooks and guides from Realtime Publishers can be found at
http://nexus.realtimepublishers.com.]
Chapter 1: Installation Fundamentals:
Automatically Deploying Windows 7 with
Windows Deployment Services
You’ve just been handed a new project to migrate your desktops to Windows 7.
Congratulations! That’s a big job; one that’s sure to make you look good to your peers and
your bosses—if you get it right.
Among IT projects, none so dramatically impacts users than a desktop operating system
(OS) upgrade. With it, users get new icons and a new desktop look and feel, not to mention
a few new ways of accomplishing their daily tasks. That’s something they can see, feel, and
touch. Completing an upgrade project successfully means doing so without a major
interruption to the flow of your users’ workday.
In contrast, doing a poor job means leaving a bad taste in the mouth of your business. That
bad taste makes down‐the‐road upgrades that much more difficult to get approved. If your
company can’t see value in an OS upgrade—or if they see more pain than value—you’ll
surely be stuck at this OS version for far longer than you want. And businesses have long,
long memories.
That’s why this book exists. Although installing Windows the manual way requires as few
as seven clicks and a bit of time, that manual method is rife with pain and trouble. Fully
automating the installation of Windows 7 requires a bit more up‐front effort, but the result
is a more seamless process—that just works. Better yet, that same process will continue to
benefit you for years to come, creating a platform for quickly refreshing computers
whenever necessary. All you need is a project plan to get you started and a cookbook of
step‐by‐step solutions to finish the job. You’ll get exactly that in these pages.
In the next few chapters, I’ll show you the steps required to automate Windows 7
installation, click‐by‐click. But we won’t stop there. I’ll dig deep into the ways in which that
automated installation will fundamentally change how you do IT. You’ll learn exactly how
to automate Windows for an OS migration project, whether from Windows XP or Windows
Vista. You’ll even discover the steps to wrap your automated installation into a VDI
infrastructure, enabling hosted virtual desktops to be provisioned automatically and on‐
demand. More importantly, you’ll learn tips and tricks for layering the Windows OS,
enabling you to fix common IT problems by simply rebuilding the user’s computer—all the
while maintaining their applications and user profile information.
1

Best, you’ll learn how to do all of this using Microsoft’s no‐cost deployment solutions.
Admittedly, these solutions might not be the slickest ones around, but they’re free. In
addition, they are overloaded with an alphabet soup of three‐ and four‐character acronyms
whose complexity makes them a “why bother” for many IT pros. But wade through the silly
acronyms and the overly‐complicated Microsoft documentation, and underneath it all is a
powerful automated deployment solution. I’ll help you navigate, showing you which
features to use and which to avoid.
Keep this guide handy. In it are the step‐by‐step instructions you’ll find yourself turning
back to again and again as you fully automate one of the most time‐consuming parts of your
job: Windows 7 installation.
Step One: Installing and Configuring Windows Deployment Server
Many authors might begin this discussion by explaining the complex file format Microsoft
uses for Windows deployment. That format is called Windows Imaging (WIM) format. Like
the GHO files from Symantec Ghost’s days of yore, WIM files are those that contain your
Windows 7 images.
That’s really about all you need to know right now. I could spend pages talking about the
intricacies of how it works (and actually will a bit later). But it’s my belief that
understanding WIM’s format is less important at first than knowing what to do with it.
Thus, Step One in your exploration of automatically deploying Windows 7 starts by
installing Microsoft’s solution for actually deploying Windows 7. That solution is called
Windows Deployment Services. Commonly shortened to just WDS, it is available as an
installable role inside Windows Server 2008 R2.
Note
WDS is also available in Windows Server 2003 and Windows Server 2008,
but those versions don’t include the capabilities you’ll really want. Thus, this
book’s server side will focus exclusively on Windows Server 2008 R2.
Installing the WDS role is a very simple process that you complete in Server Manager. Start
by right‐clicking Roles to add the Windows Deployment Services role. Installing this role
also installs two role services: Deployment Server and Transport Server. Both of these role
services are required for WDS to function.
2

Once the WDS role is installed, you will complete an initial configuration to get started. Do
so by right‐clicking the server in the WDS console, and selecting Configure Server. The
Configure Server wizard will query you for information in three areas:
• Remote installation folder location. Your image files obviously need a storage
location. These files will be large, measuring in the tens of gigabytes, and you’ll
eventually have more than one of them. For this first area, provide a path to a
sufficiently‐large local folder where you will be storing your image files. This path
should not be the system partition.
• PXE server initial settings. Although it is possible to start a Windows 7 image
deployment by booting the computer from a DVD or USB drive, you get the best
automation by booting computers via the Preboot eXecution Environment (PXE).
This “pixie booting” enables computers to automatically download an image from
the network as they boot. Transferring Windows 7 images over the network can
have a big impact on network performance (a topic I’ll discuss in a minute), so for
now, select the Do not respond to any client computers option. Don’t worry, we’ll be
changing this option shortly.
• Add Image Wizard. The third query asks whether you want to add images to this
server now. In this first chapter, I’ll be showing you how to deploy default images
that are right off the Windows media. Automating the customization of these images
won’t happen just yet. That comes later. For this first example, you’ll install only the
default configuration of Windows 7—just like what you get after a manual install
from the DVD.
To get started, select the Add images to the server now check box, and click Finish. You’ll be
prompted for a file path. Insert your copy of the Windows 7 DVD into the drive, and supply
the right path. The Add Image Wizard will ask you to create an image group. Do so, giving
that group a friendly name. One or more images will be added to your server, depending on
which version of the Windows 7 media you have. This process can take a few minutes, so
grab a cup of coffee and meet me back here in 10.
Stepping Back: What Can You Now Do?
So what can you do now? Right now, not much. What you’ve achieved at this point is the
very beginning of your image deployment system. Remember your Ghost Server? On that
server, you would create multicasting sessions to deploy images you specified to clients
you connect. You’re doing much the same here, except Microsoft’s “Ghost Server” is
accessed through the WDS console in Administrative Tools.
Figure 1.1 shows an example of what you might be seeing at this point. There, five install
images have been uploaded to the server from the Windows 7 DVD media. Each image
corresponds to one of the editions of Windows 7. The steps up to this point have uploaded
another image as well. This image is called a boot image, and it is found in Figure 1.1’s Boot
Images folder.
3

Figure 1.1: The WDS console.
WDS uses two types of images to install Windows. The boot image has nothing to do with
the OS you’ll eventually install onto that computer. Rather, it is a miniature version of
Windows called the Windows Preinstallation Environment (WinPE). You need WinPE just
to boot the computer to which you’ll eventually deploy an image. As it boots the computer,
WinPE also loads other niceties, such as a lightweight Windows GUI for interacting with
that computer. A network stack is also loaded, so you can conveniently transfer images
over your LAN. WinPE is actually a tiny version of Windows, so some (though far from all)
of your usual Windows commands will work with it. I’ll talk more about WinPE later, but
for now, be aware that the boot image is what starts this ball rolling.
The real juice with WDS comes in its install images, found in the Install Images folder in the
console. You’ve just uploaded a set of install images right off the Windows 7 media. Yours
might have a few less or more than mine, depending on where you got your media. One of
these install images and a boot image is all you need to start automatically deploying
Windows. Really.
Note
It’s at this point where I should highlight how Microsoft’s overly‐complicated
documentation can really confuse people. Reading it, you might discover that
Microsoft wants you to PXE your machine to WDS using an Unattend.XML file
built from WSIM in the WAIK after pre‐staging your GUID inside the ADUC.
Oh, and don’t forget MDT (formerly BDD!), who’s Deployment Workbench
wraps around all this ridiculousness.
My response: Hooey. In attempting to define everything, Microsoft has
inadvertently confused everything. Bear with me in this book because I
intend to bootstrap you through those same services but without all the
confusing alphabet soup.
4

So obviously that right‐off‐the‐DVD image isn’t terribly customized for your environment.
All by itself, your computer won’t have Office installed. It won’t have any special drive
partitioning. Any customizations you normally add to your “golden image” won’t be on it.
All those things are the topic in Chapter 2.
Before you start customizing your image, you need to know how to actually deploy an
image. That’s what we’re about to do in step two.
Step Two: Configuring WDS for Over‐The‐Network Image Deployment
I mentioned before that one mechanism to boot a computer is by using a DVD or USB hard
drive. You can start that process by right‐clicking a boot image, and selecting Create
Discover Image (and then perform another dance of multiple steps I won’t get into). The
problem is that the manual method of booting computers is a process you don’t want to do.
It’s not terribly automatic. So the much more exciting solution is to use PXE and your
network. Before you start, however, check out this sidebar for an important warning about
WDS and network bandwidth consumption.
A Warning about OvertheNetwork Image Deployment
Kicking off an over‐the‐network image deployment is a lot like turning on a
fire hose of data through your network. Not properly segregated, that data
hose can severely bog down entire sections of your LAN. For example,
turning it on in a non‐segregated network of a dozen computers can
essentially shut down the network for everyone else until the installation is
complete. Multicast domains can protect you from this situation, but they’ll
need to be specifically configured on your networking equipment.
If you intend to use over‐the‐network image deployment, you might start by
splitting off a little network subnet just for use in deploying computers. That
subnet might include your WDS server and a few network connections for
computers who need imaging. That way, you can learn about WDS’ traffic and
effects on your network equipment before you stage it throughout the rest of
your network.
Let’s get your WDS server ready for deploying default images across the network. Doing so
requires two network services: PXE, which we’ve already discussed, and DHCP. PXE
handles the very first bootstrapping step for the computer, directing it to the WDS server
where it can find its boot image. DHCP is used to give those PXE clients an address and
route them to the WDS server.
I’ll show you a fairly open example of how to configure the two, and let you lock it down
later as you see fit. Start this process by right‐clicking your server name in the WDS
console, and selecting Properties. If you’ve done everything correctly, you should see nine
tabs in the resulting properties screen. You’ll need to make changes in five of the tabs to get
started.
5

PXE Response Tab
The first tab where configuration is required is PXE Response, seen here in Figure 1.2. Any
computer whose boot order has been configured to boot first from a network card will
attempt to find a PXE server every time it boots. Obviously, this means that every time that
computer starts, it will essentially be looking for a new OS vis‐à‐vis WDS. This is an OK
thing, based on some other configurations you’ll make shortly. But, as you can imagine, the
default setting is for WDS to not respond to client computers.

Figure 1.2: The PXE Response tab.
To begin listening for PXE clients, change this setting to Respond to all client computers
(known and unknown). By setting the configuration in this way, any PXE client that
attempts to connect to WDS will be heard and receive a response.
6

Notice also that Require administrator approval for unknown computers has been selected.
Using WDS alone, administrator approval is a necessary evil because this action provides
the mechanism to name new computers as their OS is installed. If you don’t select this
check box, computers will be given a default name that is based on the username of the
individual who hits F12 and starts the installation. Virtually all of us use a special naming
convention for our computers. So naming all your computers after yourself isn’t a great
solution.
Note
Be aware that there’s a missing piece in WDS’ installation that causes this
naming process to fail unless you make a small change to your Active
Directory (AD) permissions. The problem exists because the process to name
that computer and add its account token into AD happens using the server’s
AD authentication token and not your user token. You’ll need to make this
small change to enable the correct permissions: In Active Directory Users
and Computers, right‐click the domain, and then select Delegate Control.
Change the object type to include computers, and add the computer object of
the WDS server into the dialog box. Click Next. When prompted, select Create
a custom task to delegate. Select Only the following objects in the folder. Next,
select the Computer Objects check box, then Create selected objects in this
folder. Click Next. In the Permissions box, select Write all Properties, and
click Finish.
Boot Tab
As you can imagine, setting the previous tab to listen for every PXE boot could be a bad
thing. “Connect every computer to WDS as it boots? Greg, are you nuts?”
Quite the opposite, my friends. You can still listen for every client but allow most of them to
continue on through the regular boot process by forcing the user to hit the F12 key when
the user is ready for an OS installation. You can setup this configuration on the Boot tab
(see Figure 1.3). Notice that known and unknown clients are separated out, with each class
of client being given one of three different options.
7

Figure 1.3: The Boot tab.
Hitting F12 presents a great way to automate. Think of how this might work: You recognize
that a computer needs rebuilding. That computer’s BIOS is already configured to boot first
from its network card. Assuming that a transmission is ready for approval, all you need to
do from the client is reboot and hit F12 to start the process. Every other computer passes
by this situation after a few seconds on their way to a standard boot.
You’ll also see in this figure that it is possible to specify a default boot image. This setting is
optional for now, as you should at this point only have a single boot image (for at least one
processor architecture) if not more. If you have more than one for each architecture,
consider selecting one as the default.
8

DHCP Tab
On the third tab of interest, you begin the process of setting up DHCP services (see Figure
1.4). The verbiage on this tab is a bit confusing. Allow me to translate. There are in fact
three scenarios that can exist between WDS and DHCP:
• WDS and DHCP are on the same subnet but on different servers. This setup is
the most‐likely case. It is also the easiest, as there is nothing additional that you
need to do. You can move to the next step.
• WDS and DHCP are on the same server. If your DHCP server is also your WDS
server, select both of the offered check boxes. Move on.
• WDS and DHCP are on different servers on different subnets. This setup
involves the most work. Select none of the check boxes. Then, in the DHCP console of
your DHCP server, view the properties of each relevant DHCP scope. There, select
the check boxes to enable scope options 66 and 67. You’ll need to enter the fully‐
qualified domain name of your WDS server in the String Value box for option 66.
Enter the name of your boot image into option 67. This name is typically boot.wim,
although you can double‐check the file name by viewing the properties of the boot
image on the General tab.

Figure 1.4: The DHCP tab.
9

Multicast Tab
The Multicast tab (see Figure 1.5) has two sections you’ll need to review. At the top, you
can set the network addresses you’ll use when multicasting. These addresses can either
source from a static range or be distributed through DHCP. Depending on how your
network is configured, these addresses may be different than the default settings. Consult
your network settings (or your network administrator!) for your specific addresses.

Figure 1.5: The Multicast tab.
The bottom section can be very important for speeding up the transmission of images to
multiple clients at once. You can obviously imagine that some Windows computers are
faster than others. Maybe they have faster processors or disks, or they’ve got a better
connection to the LAN. One historical limitation of multicast is that its transmissions are
always limited to the slowest member of the group.
That limitation hasn’t changed. But what has changed is the ability to break apart a
multicast transfer into multiple smaller transfers when slow machines cause slowdowns. In
the Transfer Settings box, you can separate those clients. More multicast transmissions
obviously means simultaneously duplicating that aforementioned fire hose of data. So be
careful before you make any changes because you can really turn on the faucet here.
10

Advanced Tab
Finally is the Advanced tab (see Figure 1.6). If you’re using a Microsoft DHCP server, you’ll
need to click the radio button to Authorize this Windows Deployment Services server in
DHCP. You can also specify a domain controller (as opposed to having WDS discover a local
one), although doing so isn’t common.

Figure 1.6: The Advanced tab.
11

Step Three: Deploying Your First Windows 7 Image
You’re now ready to deploy your first Windows 7 image over the network. Start this
process by right‐clicking Multicast Transmissions in the WDS console, and selecting Create
Multicast Transmission. You’ll have three areas to address:
• Transmission name. Each transmission requires its own name. Clients will use this
name to identify which transmission they want to follow. Give the transmission a
friendly name, and continue.
• Image selection. Your second selection will identify which image you want to
transfer. Each image group contains one or more images. Select the one you’re ready
to deploy.
• Multicast type. Creating a multicast transmission only prepares it for clients. Once
that transmission is prepared, it will sit in waiting for those clients based on the
behaviors you set. As Figure 1.7 shows, you’ve got options. You can instruct the
transmission to begin after a certain number of clients or amount of time passes. A
much more powerful alternative is to simply tell the transmission to begin when the
first client connects. Subsequent clients will join later, picking up the data at
whatever point it is at, and finishing up where necessary. I particularly like this
setting, as it gives me the most flexibility for starting transmissions and joining
clients a bit later.

Figure 1.7: Multicast Type.
12

Finishing the wizard sets the multicast transmission to a Waiting status until the Multicast
Type conditions are met. Now, ready a computer that needs an OS. Set its network boot
order in the BIOS to boot from its NIC first. Then boot it, and hit F12 when prompted. If
you’ve done everything correctly, the computer will boot and pause as it awaits approval
for its pending OS installation request. Figure 1.8 shows how the boot screen will appear as
the client waits. Note that this computer’s pending request ID is set to 1.

Figure 1.8: Awaiting administrator approval.
That same pending request ID number will be displayed in the WDS console under Pending
Devices (see Figure 1.9). To approve the request and name the computer, right‐click the
appropriate request ID and choose Name and Approve. Enter a name for the computer into
the resulting dialog box, and click OK. The installation will begin.

Figure 1.9: Pending Devices.
13

The client will download its boot image from the WDS server and present you with a screen
that looks similar to Figure 1.10. As you can imagine, at this point you don’t have full
automation just yet. You’ll learn about those steps in future chapters. But what you do have
is a mini‐setup screen for Windows 7. Figure 1.10 shows that the mini‐setup screen needs a
Locale and Keyboard as well as credentials to connect to the WDS server (in my case,
wdsserver.company.pri).

Figure 1.10: The boot image’s setup screen.
Entering those credentials brings you to Figure 1.11, where your selection of OS edition can
be made. You should note an interesting behavior here. When you created the original
multicast transmission, you identified an edition for distribution, yet on this screen you’re
allowed to choose any edition in the image group. That edition selection will become
important down the road as you add automation pieces.
14

Figure 1.11: Selecting an edition.
This wizard’s final screen (not shown here) provides a location to configure any disk
partitions that will be used by this computer. Moving on from this screen begins the
installation.
Monitoring the status of installations occurs back in the WDS console, where useful
instrumentation data is presented for each client: name, IP address, time connected, status
(as percent complete), and even CPU, memory, and network utilization statistics. I’ve
scrolled Figure 1.12 a bit to the left to show some of its more interesting columns. This date
is useful for identifying when one or more slow clients needs to be disconnected or
reverted to its own multicast transmission. You can do so by right‐clicking any running
transmission, and selecting Disconnect or Bypass multicast.
15

Figure 1.12: Client instrumentation for an active multicast transmission.
Give your installation a few minutes to complete. As with a manual installation, the
installation process will reboot the computer a few times and offer a few pop‐up status
screens. Once the installation is again ready for user input, you’ll be presented with the
post‐installation configuration screen called Set Up Windows (see Figure 1.13).

Figure 1.13: The Set Up Windows screen.
You’ve seen the next set of screens before. They’re pretty much the same configuration
screens you see when you install Windows manually: setting a username and password,
accepting the license agreement, configuring Windows Update, and setting the time and
time zone.
16

Just a Few Steps to Basic Automation
You’ve complete the few steps required to achieve basic automation, and there are just a
few more to get you to even greater levels of automation. This first chapter has hopefully
demystified some of the steps required to start automating the installation of Windows 7
with Microsoft’s tools. If a default installation from the Windows 7 DVD media is all you’re
looking for, you can stop here and begin deploying clients.
But most of us would probably like just a few more of these processes taken off our plate.
We don’t want to deal with answering questions during WinPE’s initial boot. We probably
don’t want to answer questions at the post‐installation configuration screen either. If we
have drivers that aren’t part of the Windows DVD media, we want them added to our
installation. And, most importantly, we want our initial installation to start with a set of
applications like Microsoft Office and others.
All of these are valid requirements as well as completely feasible automations that you can
add with just a bit more work. And all of these are topics explored in Chapter 2.
17

Chapter 2: Creating a Universal Image that
Installs Everywhere
As you complete the steps from the previous chapter, you’re absolutely ready to start
deploying Windows 7 images. They’re not terribly customized images yet, but they’ll work.
Once deployed to desktops, these images will look almost exactly like the generic Windows
7 installation you would install directly from the DVD media.
There’s nothing wrong with a generic image, especially considering that many of us have
used the walk‐around‐the‐office‐DVD‐in‐hand approach for years. But there’s also nothing
particularly automated about them. Worse yet, these images aren’t truly universal. If the
computers to which you’re targeting the images need a set of drivers that aren’t on the DVD
media, they might not work properly. Let’s think for a minute about what this solution
lacks:
• Driver injection. Windows 7 comes with a massive stack of drivers right inside its
DVD media and through Windows Update. But computers today often need their
own custom drivers over and above the defaults. Our solution doesn’t yet have a
way to inject those custom drivers into our images.
• Automating the WinPE phase. Remember that deploying an image requires a boot
image as well as an install image. Currently, our boot image asks us a set of
questions we’d prefer not to answer, things like locale, keyboard, username and
password to deployment server, operating system (OS) to install, and disk
partitions. Real automation means answering these questions beforehand and
letting our solution do the work.
• Automating the set up Windows phase. Even after answering all of WinPE’s
questions, there’s still a full second set of questions required by the Windows
installation itself. The Set Up Windows wizard asks for a username and password,
accept the license agreement, configuration settings for Windows Update, identify
network settings, and set the time and time zone settings. We also want these
questions answered beforehand, so we can zip past this manual step.
Thus, our solution is indeed still incomplete. It hasn’t evolved yet to using a universal
image, one that can install everywhere. Nor is it fully automated so that it takes care of the
heavy lifting on our behalf.
18

There’s good news: It is possible with today’s Windows 7 deployment technologies to add
these three capabilities with not much extra effort. I’ll show you how to do just that in this
chapter. As with the previous chapter, I’ll be supplying you with a receipt to get started. I’ll
then point out a few places where you can explore on your own for even greater
automation. Let’s begin with the drivers.
Step Four: Dealing with Drivers
Windows Deployment Server (WDS) got a very nice new feature in Windows Server 2008
R2. That new feature takes most of the pain out of automatically injecting drivers into a
deployment. Navigate over to the WDS console in Server Manager, and scroll down to its
Drivers node. Here you can add sets of drivers, called Driver Packages, to your WDS server.
Those Driver Packages contain the drivers that a computer might want. Remember Plug
and Play? Windows’ Plug and Play supplies the automation framework for installing these
drivers inside a Windows deployment.
Plug and Play: Awesome for Windows Installations
During Windows installation, the real power of Microsoft’s Plug and Play
shines. You already know that Plug and Play is the service that watches for
new hardware to be connected. When it detects new hardware, it matches
the hardware component’s characteristics to the drivers available. When it
finds a match, the correct driver is automatically installed, making the
hardware ready for use.
Although you’re used to seeing its actions when you plug in a new device,
Plug and Play is also in action during the install process. During install,
Windows invokes Plug and Play to detect the installation hardware. The
correct drivers are then installed if they’re available. If they’re not, Windows
uses a generic driver when one is available.
In the end, what you need is a mechanism to make custom drivers available
during the install. If they’re available, Windows will take care of the rest.
Drive Packages enable you to make custom drivers available during install. Once created
and added to WDS, Plug and Play will find and install the custom drivers as the OS
deployment begins.
Unpacking Drivers
The hard part here is getting drivers into a format that WDS can use. WDS cannot work
with drivers that are packaged into .EXE or .MSI files. Drivers need to be extracted from
their .EXE or .MSI file so that WDS can find each driver’s .INF file.
19

Remember how most drivers, when they’re fully unpacked, arrive with some combination
of .SYS, .CAT and .INF files? You can consider the .INF file to be a kind of instruction manual
for installing the driver. It is the .INF file, usually one for each driver, that WDS needs to
find. It needs the other files as well, but consider the .INF as your starting place. Everything
else WDS needs is usually found in the same location.
As you can imagine, locating the .INF can be difficult. Finding it is sometimes a game of
educated guessing. Sometimes drivers arrive with their .INF files already extracted. Other
times, they are packaged into a .CAB or .ZIP file. Your mileage will vary, with each driver
being a little different.
Unpacking the VMware Tools’ Drivers
Don’t worry if this unpacking process is a bit confusing the first time around.
Most of us are used to using install files to automate everything after we
double‐click. Unfortunately, that double‐click doesn’t work for this specific
need. Let me step you through a quick example that can illustrate one
mechanism to locate the files you need.
If you’re following along using VMware Workstation as your lab
environment, you know that VMware’s custom drivers are found in the
VMware Tools. Every OS that runs inside VMware Workstation needs its
VMware Tools installed if it’s to work properly. For Windows, those tools are
found in the file C:\Program Files (x86)\VMware\VMware
Workstation\windows.iso.
Mount that ISO using a tool such as Virtual Clone Drive, and take a look at its
contents. Inside are two .MSI files that contain the VMware Tools’ drivers:
VMware Tools.msi and VMware Tools64.msi. You want the contents of these
files. You can extract them to a folder by running an administrative install
using the command:
msiexec /a VMware Tools64.msi
Doing so will launch a mini‐setup that asks for a location to store the
unpacked drivers. Store them somewhere they can be later accessed by WDS.
You’ll use these drivers in the next step.
Caution: Although this process makes for a great example, don’t use this
process to install the VMware Tools on production computers. VMware
strongly recommends installing the tools through their usual mechanisms
inside VMware Workstation.
Once you’ve unpacked drivers, you can add the entire folder’s worth of them in one fell
swoop by right‐clicking Drivers in the WDS console, and choosing Add Driver Package.
Figure 2.1 shows the screen that appears. You can select either a single .INF file or tell WDS
to search a folder for every driver package it finds. I’ve chosen the second option because
it’s easier and adds everything at once.
20

Figure 2.1: Driver package location.
The wizard’s second page provides a place to select the drivers to add from the set WDS
has found (see Figure 2.2). Some of these you won’t want. For those, you have two options:
clear the check box to prevent a driver’s package from being loaded to WDS, or double‐click
the driver and change its status to Disabled if you want it loaded but not enabled for
deployment. Double‐clicking individual drivers also gives you more details about that
driver, its files, and other characteristics.
21

Figure 2.2: Available driver packages.
Click through the remaining wizard pages and add the drivers to the default DriverGroup1
to complete the wizard. DriverGroup1 is the default group that can be used by all
computers as an installation is deployed. Thus, right out of the box any driver that is
contained in DriverGroup1 will automatically be available for any deployment to any
computer.
You might at this point want to add to DriverGroup1 the set of drivers you know your
desktops will need. Once added, try a test installation to see whether those drivers are
successfully installed during a deployment. You’ll be able to tell by logging into a desktop as
Administrator after deploying an OS. Once there, check the list of drivers in Device
Manager. You’ve done everything correctly if the right drivers appear.
22

Note
Although this tool is great when drivers are perfectly matched to computers,
you might experience the situation where drivers conflict with each other.
For example, drivers from one hardware type might be very close to those of
another. As a result, the wrong set of drivers can be installed by WDS.
In this case, you’ll need to configure WDS driver groups in combination with
filters. WDS’ filters restrict driver installations to certain hardware
characteristics such as manufacturer, BIOS vendor, UUIS, OS version, and so
on. They provide a way to target specific sets of drivers to specific sets of
hardware.
Configuring these filters is out of scope for this book; you can get more
information about them at http://technet.microsoft.com/en‐
us/library/dd348456(WS.10).aspx.
Adding Drivers to Boot Images
Up to now, I’ve showed you only the steps to add drivers to install images. If your hardware
will not function with the generic drivers included in WinPE, you’ll need to add custom
drivers to your boot image as well. This process is slightly different than with install
images. The boot image process requires specifically adding drivers into the boot image
rather than just making them available.
Before you start, driver packages for boot images must first be added into the Drivers node
using the method I’ve already explained. Once added, inject them into a boot image by
right‐clicking the boot image, and choosing Add Driver Packages to Image. This selection
brings up a multi‐screen wizard for selecting the appropriate driver packages. Figure 2.3
shows the most important page in that wizard.
This page locates driver packages based on the search terms you set in the Search box. The
settings in Figure 2.3 are the defaults for my standard x64 boot image. Adjust your search
terms, then click Search for Packages to reveal the results at the bottom. Select the check
boxes for the appropriate drivers, and complete the wizard to add them to the boot image.
23

Figure 2.3: Add Driver Packages to Boot Image Wizard.
Note
Although adding driver packages to boot images is easy, removing them is
less so. Thus, it is recommended that you make a backup copy of the image
before making any changes. Otherwise, a wrongly‐placed driver can corrupt
the boot image.
Step Five: Automating the WinPE Boot Image
With the right set of custom drivers, your images can now be made universal. That makes
you ready for the next step in constructing your deployment solution: automating
responses to the set of questions asked by WinPE prior to starting an OS deployment.
These questions relate to locale, keyboard, the username and password WinPE needs to
download an install image, OS and edition, and disk partitions.
24

Things get a little more challenging in this step. First, you’ll need to learn two more of the
acronyms in the Microsoft deployment alphabet soup: WAIK and WSIM. The WAIK is the
Windows Automated Installation toolKit. Among many other deployment‐related tools, the
WAIK is the home of the Windows System Image Manager (WSIM). Your first job is to locate
the Windows 7 version of the WAIK (they are versioned by OS). For this book, download
and install the WAIK to your WDS server.
Once installed, launch WSIM. WSIM provides a workbench for creating unattended
installation files. Figure 2.4 shows what WSIM looks like after completing some of the
preparations I’ll explain next. As you’ll immediately note, it’s a pretty busy interface. I’ll
walk through each of its panes in the next section.

Figure 2.4: An example WSIM interface.
First a little background on what you’re about to create. The files WSIM generates provide
the “answers” to the “questions” you’ll want to eliminate from your automated installation.
You’ll in fact use WSIM twice to do this. For its first run‐through, you’ll be answering the
questions WinPE asks during its portion of the installation. For the second—which I’ll
explain in Step Six—you’ll follow up with an additional set of answers that will be used by
the Windows installation itself.
Preparing WSIM
To get started with WSIM, create a Distribution Share. For our purposes, create a folder
called C:\DistroShare on your WDS server. Then, in WSIM, right‐click Select a Distribution
Share | Create Distribution Share. Navigate to C:\DistroShare, and click Open to set this as
your share.
25

Your next action will be to export an install image from WDS to the share. This image is
needed so that WSIM can analyze it to discover the questions that might need answering.
Right‐click an install image that you plan to eventually deploy (yes, that’s an install image
and not a boot image), and choose Export Image. This will be the image that you later plan
to deploy to your desktops. I’ll be choosing the Windows 7 ENTERPRISE edition image for
mine. Export that image to C:\DistroShare and give it a name. Then, back in WSIM, right‐
click Select a Windows image or catalog file | Select Windows Image, then choose the .WIM
image you just exported.
You’ll be immediately prompted with the error message you see in Figure 2.5. This is OK
because you haven’t yet created a catalog file that is associated with this image. Create that
catalog by clicking Yes. This catalog file takes a few minutes to generate as WSIM analyzes
the image for all the possible questions that could be asked. Once it is complete, you’ll be
able to pick and choose from the questions it discovers and answer those of interest.

Figure 2.5: Cannot find a valid catalog file.
Figure 2.6 shows what the Windows Image pane will resemble once this process has
completed. You’ll see that a very large number of questions are available to be answered,
many of which are difficult to understand and all of which have cryptic names. Many
questions have sub‐categories of further questions.

Figure 2.6: WSIM’s Windows Image pane.
26

You might spend quite a bit of time here simply finding the questions of interest. Many of
these are intended only for the activities in Step Six. Others are intended for what we’re
doing here with WinPE in Step Five. To be honest, this process is mostly a guess‐and‐test
activity. I’ll help get you started with the minimum you’ll need to fully automate this step.
Later, you can add more answers as you see fit and desire more customization.
Before you can begin working with questions, you’ll need to create an answer file. You’ll
eventually add this .XML file into WDS. Create it by right‐clicking Create or open an answer
file | New Answer File in the Answer File pane (see Figure 2.7).

Figure 2.7: An answer file.
Note
Every answer file has seven numbered sections. These seven sections
correspond to the seven “passes” of the Windows installation, starting with
windowsPE and finishing with oobeSystem (OOBE stands for Out‐Of‐Box
Experience). For Step Five in our process, we’ll be working only with
questions that relate to Pass 1.
Locating the Right Questions and Inserting Answers
At this point, you’ll need to locate the questions you want and insert whatever answers
make sense for your Windows 7 deployment. I’ll kick off this process by explaining how to
answer one question in detail. Then, in the next section I’ll follow up with a table of the
remaining questions and their answers. Remember that I am using the x64 installation of
Windows 7. Questions for x64 installations begin in WSIM with amd64. If you will be
installing the x86 version, look for those that start with x86.
The first question you want to answer relates to the regional language to be used by the
installation. In the Windows Image pane, navigate to amd64_MicrosoftWindows
InternationalCoreWinPE_{version}_neutral where {version} is whatever version number
you see. Right‐click this element, and select Add Setting to Pass 1 windowsPE (see Figure
2.8).
27

Figure 2.8: Adding a setting to Pass 1 windowsPE.
Doing so adds the question to your answer file. Once added, you’ll then answer it in WSIM’s
upper‐right pane. That pane’s title will always be the name of the question you’ve currently
selected in the Answer File pane. Figure 2.9 shows both panes with the question
highlighted that I’ve just selected.

Figure 2.9: Answering a question.
If your language choice is United States English, the correct answer for this question is en
us. Enter this value into each of the boxes except for LayeredDriver under settings in the
upper‐right pane.
Note
You wouldn’t necessarily know this by looking, but LayeredDriver is only
used by Japanese and Korean keyboards. I bring up this point to highlight
how much research, guessing, and testing you’ll be doing when you attempt
to customize. So, yes, what you’re thinking is correct: This isn’t easy. Keep
following along, and I’ll at least get you started.
Also notice in Figure 2.9 that amd64_MicrosoftWindowsInternationalCore
WinPE_{version}_neutral has another question below it in the subfolder marked
SetupUILanguage. You’ll want to answer that question as well. Click to view
SetupUILanguage, and enter enus again next to UILanguage in the upper‐right pane.
28

The Remaining Questions and Answers
You have now completed answering the first question. Table 2.1 provides all the questions
and answers. For each, I’ll explain the question as well as possible corresponding answers.
Remember that these answers are for my environment as I’ve been building it in this book.
Thus, yours might be slightly different. Locate and answer each of these before moving on.
Windows Image Pane (Question) UpperRight Pane Explanation
(Answer)
amd64_Microsoft‐Windows‐ InputLocale = en‐us This item configures the

International‐Core‐ SystemLocale = en‐us WinPE language to US English.
WinPE_{version}_neutral UILanguage = en‐us
UILanguageFallback = en‐us
UserLocale = en‐us
amd64_Microsoft‐Windows‐ UILanguage = en‐us
International‐Core‐
WinPE_{version}_neutral\
SetupUILanguage
amd64_Microsoft‐Windows‐ Domain Enter the domain, username,

Setup_{version}_neutral\ Username and password of the user who
WindowsDeploymentServices\ Password connects to your WDS share
Login\Credentials (the same user as in Chapter 1,
Figure 1.10).
amd64_Microsoft‐Windows‐ DiskID = 0 This item begins working with

Setup_{version}_neutral\Disk the first disk in the computer.
Configuration\Disk
amd64_Microsoft‐Windows‐ Extend = true This item creates a single

Setup_{version}_neutral\Disk Order = 1 primary disk to install
Configuration\Disk\Create Type = Primary Windows.
Partitions\CreatePartition
amd64_Microsoft‐Windows‐ Active = true This item modifies that

Setup_{version}_neutral\Disk Format = NTFS partition to create the C: drive
Configuration\Disk\Modify Label = Windows as the first NTFS drive and
Partitions\ModifyPartition Letter = C partition.
Order = 1
PartitionID = 1
amd64_Microsoft‐Windows‐ DiskID = 0 This item installs Windows to

Setup_{version}_neutral\ the disk and volume created in
WindowsDeploymentServices\ PartitionID = 1 the rows above.
ImageSelection\InstallTo
amd64_Microsoft‐Windows‐ Filename See the note below.

Setup_{version}_neutral\ ImageGroup
WindowsDeploymentServices\
ImageSelection\InstallImage ImageName
Table 2.1: Step Five’s remaining questions and answers.
29

Note
The InstallImage question is a special case. If you want complete automation,
enter the filename, Image Group, and Image Name of the image you want to
deploy from WDS. You can get this information by reviewing the properties
of the image in WDS. In my case, the filename will be install.wim, the
ImageGroup will be Windows 7 Default, and the ImageName will be Windows
7 ENTERPRISE.
If you do not enter values, you will be given the option to select an image at
the time of installation. Thus, there’s a tradeoff between full automation and
being able to choose an image at every OS deployment. Remove the question
entirely from the answer file if you won’t be supplying answers.
Validating, Saving, and Adding the Answer File to WDS
The hard part is done! Three easy steps are next: validating the answer file, saving it, and
finally entering it into WDS. The first step is validation. Run a validation by selecting Tools |
Validate Answer File.
Your answer file should validate with no warnings or errors. If one exists, WSIM will tell
you what needs to be fixed. For example, Figure 2.10 shows the error message you would
see if your DiskID item under Disk was missing a value. Fix any errors and re‐run the
validation again until it reports No warnings or errors.

Figure 2.10: A validation error.
Save the answer file to the C:\RemoteInstall folder on the WDS server by selecting File |
Save Answer File. Because this answer file will be located under the Client tab in WDS, let’s
name this file unattend_x64_client.xml.
Answer files for WinPE are configured on a per WDS server basis and not a per boot image
basis. Thus, a single answer file will be used for all deployments of a particular architecture
(x86, ia64, or x64) for the entire WDS server. You can attach answer files you just created
by navigating back to the WDS console, and right‐clicking the server name | Properties.
Under the client tab (see Figure 2.11), select the Enable unattended installation check box,
and click Browse next to the correct architecture (x64 in my case). Provide the path to the
unattend_x64_client.xml file, and click OK.
30

Figure 2.11: Adding the unattended installation file to WDS.
At this point, you might want to re‐run another OS deployment, just to see how the
installation has now automated its first steps. As you’ll discover, you won’t be asked any
questions until you get to the Set Up Windows wizard after the installation completes.
Fixing that is a job for Step Six.
Step Six: Automating the Set Up Windows Phase
Getting rid of that pesky Set Up Windows wizard requires one more step in fully
automating the installation. By combining this step, what we accomplished in Step Five,
and the driver work in Step Four, you’ve fulfilled this chapter’s goal of creating a universal
Windows image that installs anywhere.
31

You already know that WSIM provides you an almost‐too‐much‐to‐handle list of possible
questions and answers that customize your Windows installation. At this point, however,
what you want is that universal image that installs everywhere with no added effort. This
step will show you the few additional questions and answers WSIM can manage in order to
eliminate the Set Up Windows wizard. Any further customization I’ll leave to your own
curiosity. You can spend literally days tweaking unattend files in WSIM to get the process
just right.
Getting through Set Up Windows means addressing four areas: Setting the time zone,
accepting the EULA, setting up the network location, and creating a local administrator and
password. Each of these steps can be pre‐answered through the same WSIM tool you’ve
already experienced in Step Five. Different here is where you’ll attach that file once created.
Rather than attaching it to the Clients tab for the WDS server, you get to apply your
unattend file directly to the image you plan to deploy.
Rather than go through the process again for using WSIM, let me give you a second table of
questions and answers that you’ll need. As in Step Five, use WSIM to create an unattend file
with these questions and whatever answers make sense for your environment. However,
there is one important difference. For Step Six, you’ll be adding your questions and answers
to different passes in the installation process, specifically Pass 4 and Pass 7, rather than
Pass 1. Table 2.2 includes the correct passes to get you going. Remember that, as before,
these answers are for my environment as I’ve been building it. Yours might be slightly
different.
Windows Image Pane UpperRight Pane Explanation
(Question) (Answer)
amd64_Microsoft‐Windows‐Shell‐ ComputerName = Setting ComputerName to

Setup_{version}_neutral (Pass 4) %MACHINENAME% %MACHINENAME% will
TimeZone pass through the name you
set in WDSs Name and
Approve. Set TimeZone to
your correct time zone, such
as Mountain Standard
Time. 1
amd64_Microsoft‐Windows‐ InputLocale = en‐us This item configures the

International‐ SystemLocale = en‐us Windows language to US
Core_{version}_neutral UILanguage = en‐us English.
(Pass 7) UserLocale = en‐us

1
See technet.microsoft.com/en‐us/library/cc749073(WS.10).aspx for a list of applicable time zone strings.
32

Windows Image Pane UpperRight Pane Explanation
(Question) (Answer)
amd64_Microsoft‐Windows‐Shell‐ HideEULAPage = true Hides the EULA and

Setup_{version}_neutral\ oobe HideWirelessSetupIn OOBE wireless setup screens, sets
(Pass 4) = true the network location to
NetworkLocation = work work, and enables
ProtectYourPC = 1 Automatic Updates.
amd64_Microsoft‐Windows‐Shell‐ DisplayName = LocalAdmin This item adds a local

Setup_{version}_neutral\ Group = Administrators administrator account
UserAccounts\LocalAccounts\ Name = LocalAdmin named LocalAdmin.
LocalAccount
(Pass 7)
amd64_Microsoft‐Windows‐Shell‐ Value = {Password} This item configures the

Setup_{version}_neutral\ password for the
UserAccounts\LocalAccounts\ administrator account
LocalAccount\Password created earlier.
(Pass 7)
Table 2.2: WSIM questions and answers for Step Six.
As before, validate this file and save it to complete this step. I’ll name my file
C:\RemoteInstall\unattend_w7_enterprise.xml as this file corresponds specifically to the
Windows 7 ENTERPRISE deployment in WDS.
Note
I mentioned that you could add customization. One place to do so is in the
subfolders of amd64_MicrosoftWindowsShellSetup_{version}_neutral. You
can either further personalize your installation by answering their questions,
or remove them from the file by right‐clicking each, and choosing Delete.
Be aware that your validation may display a set of yellow warnings if these
subfolder items are not populated with information or not removed from the
unattend file. So plan on either answering them or deleting them so that
validation completes successfully.
As in Step Five, the final part of Step Six is to attach this file to its correct location inside
WDS. To do so, navigate to the WDS console in Server Manager, then go to Install Images
and find the install image for the unattend file you just created. Right‐click that install
image, and view its properties.
You’ll see a check box at the bottom of the properties window (see Figure 2.12). Select this
check box, and click Select File. Provide the path to the unattend_w7_enterprise.xml file,
and click OK.
33

Figure 2.12: An image’s properties.
You’re done! At this point, re‐run your installation one more time and amaze yourself with
a Windows 7 OS that fully deploys without additional input.
Time for Applications
In two chapters, we’ve started with little more than the manual installation of Windows
and added six steps of automation. You now know how to extend the basic image to
virtually any kind of hardware through drivers and Plug and Play. You also know how to
automate the WinPE and Set Up Windows portions of the installation so that you can kick
off a deployment and come back to a CONTROL+ALT+DELETE screen.
Yet there are still a few things that remain ominously missing at this point. The first and
most obvious of these are those pesky applications. A Windows computer isn’t terribly
useful for users if they’ve got no applications to run on that computer. That will be the topic
for the next chapter. In it, I’ll show you different approaches for getting applications onto
computers, some of which might surprise you.
34

Chapter 3: Techniques in Installing
Applications During Windows Deployment
Chapter 2 covered the first six steps in creating a fully‐automated and universal Windows 7
image. With those six steps, you’re ready to start deploying Windows with fully‐automated
ease. However, you can probably imagine that there’s an important piece of this
deployment that’s still missing: the applications.
In this chapter, I’ll discuss two very different techniques that you can use to install
applications onto Windows 7 desktops during a deployment. I’ll start by explaining the
thick approach, and will then begin the dive into a discussion of the layered approach.
The thick approach is probably similar to how you’ve been handling applications. Using the
thick approach, you create one or more master images that contain the operating system
(OS) along with any applications you want deployed. Once created and configured to your
liking, this master image is captured back to your WDS server and later redeployed to
computers around your network. The approach is called thick because the images grow
large as applications and configurations are added.
The thick approach with master images has long been used because it is easy to
comprehend. Simply create an image, make any configuration changes, install and
configure applications, and finally capture that image back to the deployment server.
Although the approach requires extra steps, it is easy to visualize what the user will get
when the captured image is redeployed: If you created it on the master image, the user will
get it.
Step Seven: Creating a Master Image with Applications
The creation of a master image starts with the deployment of a basic image to a master
computer. This master computer will be the location where you will perform the image
customization work. Deploy that basic image using the process you learned in the previous
two chapters.
Once the image is deployed to the master computer, make the changes you want eventually
deployed to users. In addition to installing applications, you might want to set a few of their
initial configurations to make things easy. You might also want to install any licenses that
can be legally replicated throughout your network. Remember that any change you make
on this master image will be copied to every other computer when the image is later
deployed.
35

Audit Mode
Windows Vista and Windows 7 now include a special configuration “mode”
called Audit Mode. Although you can absolutely make changes to your master
computer without using Audit Mode, this special mode enables a set of
protections for master images during this customization process.
Using Audit Mode is optional and out of scope for this book. For more
information, see http://technet.microsoft.com/en‐
In my sample master image, I deployed a copy of Windows 7 using our process thus far and
then installed Microsoft Office. For grins, I also changed the theme and configured the
power settings for the computer. For our sample solution, these simple changes represent
the only custom configurations I’ll set in my master image.
Invoking Sysprep
You’ll need to Sysprep the computer as the very last step in this customization process. A
Sysprep must be completed to prepare the computer for being deployed, as it completes a
process called generalization. The generalization process eliminates all the data on the OS
instance that links it to the hardware on which it was installed. By generalizing, you can
later redeploy this image to other hardware.
Older versions of Sysprep were quite painful to use. Luckily, it has gotten quite a bit easier
in Windows 7 to complete this task. Sysprep is now available directly on every Windows 7
instance. To launch Sysprep, run the command
C:\Windows\System32\sysprep\sysprep.exe
Running sysprep.exe will bring forward the dialog box you see in Figure 3.1.

Figure 3.1: The System Preparation Tool dialog box.
36

Note in Figure 3.1 that the System Cleanup Action is set to Enter System OutofBox
Experience (OOBE), and that the Generalize check box is selected. These two settings revert
the computer back to a point where the Set Up Windows wizard will be displayed upon the
next reboot. This action puts the computer into the correct position for deployment. That is
the same position we experienced with our basic image in the previous chapters. You’ll also
note that I’ve configured the Shutdown Options to Shutdown the computer once it has
completed generalizing. This is important for the next part of this process.
Note
Pre‐staging the computer into this mode means that our original unattend
files—those we worked on in the previous chapter—should still work in
customizing and automatically deploying this computer in the same way as
our basic image.
You should still be able to use your original unattend files, even against this
customized image. Just make sure that you re‐attach them to the new image
back in WDS after capturing the image in the next step.
Creating a Capture Image
To deploy this image, you’ve first got to capture it to your WDS server. Capturing that
image requires the use of a special boot image I’ll call a capture image. This capture image
boots the computer to WinPE just like a boot image. But instead of handing off to an install
image, the capture image instead gathers the computer’s data into a master image.
Let’s create that capture image. Go to your WDS server, and click Boot Images. Right‐click a
boot image, and choose Create Capture Image. You’ll be presented with the Create Capture
Image Wizard just like you see in Figure 3.2. Give the capture image a name and description
as well as a storage path. You’ll notice that I’m storing my capture image with the boot
image in C:\RemoteInstall\Boot\x64\Images. Click Next to create the image, which will take
a few minutes to complete.
37

Figure 3.2: The Create Capture Image Wizard.
After the image has been created, you’ll be presented with a Task Progress screen (not
shown here). There will be an Add image to the Windows Deployment Server now check box.
Select that box, and click Finish. This step adds the just‐created capture image back to the
WDS server, enabling the capture image to be deployed over the network just like we’ve
been doing with every image so far.
Run through the resulting Add Image Wizard to add the new capture image back to WDS.
Figure 3.3 shows how I’ve given this image a name of Microsoft Windows Capture (x64).
Completing this wizard and adding the image takes a few minutes once again, but as a
result, you’ll be able to capture a master computer’s image in the same way that you deploy
an image—over the network!
38

Figure 3.3: The Add Image Wizard.
Capturing the Master Image
That was the hard part. Your last task in this step is to capture the image you’ve just
generalized and made ready for deployment. At this point, the master computer should be
powered down if you configured Sysprep per the instructions. Sysprep needs it to remain
powered down so that its power‐back‐on‐into‐Set‐Up‐Windows state is captured by the
capture image.
You’ll do that now, but be terrifically careful with this step. Power on the powered‐down
master computer and connect it to your WDS server via PXE boot. You must make sure not
to power on the computer into its Windows installation. Quickly power it back down if you
have any problems with PXE. Assuming you’re successful with the PXE boot, you’re ready
to capture its image.
39

Note
There’s another important change to be made here first. Remember back in
Chapter 2 when we attached the unattend_x64_client.xml unattend file to our
WDS server? That unattend file boots computers and immediately begins
deploying our basic Windows 7 boot image. You don’t want to deploy an
image at this point, you want to capture one. So, the unattend file needs to
disappear for a while.
To ensure that you boot to the correct image, right‐click to view the
properties of the WDS server, and select the Client tab. Clear the Enable
unattended installation check box. You can re‐select the check box after
you’ve completed the capture.
If you’ve done everything correctly, your master computer will boot to a
screen similar to the following image. There, you’ll want to select the capture
image to start the capture process. Be very careful with this process, as
booting back to Windows may require needing to re‐Sysprep and shut down
the computer before trying again.

Don’t forget to select the Enable unattended installation check box once
you’ve completed your capture. That returns your WDS server back to its
normal operation for automatically deploying images.
The next set of steps is a manual process; however, this is OK because you’ll be doing them
relatively rarely. After booting with the capture image, you’ll see an initial welcome screen.
Click Next to see the Directory to Capture screen, similar to Figure 3.4.
Anyone think it’s funny they call this the directory to capture? Sorry, I digress…
40

Figure 3.4: Directory to Capture.
The drop‐down box on this screen is exceptionally important. In it should be the volume of
the computer you’ll want to capture back to WDS. You can see in my example that C:\ is the
volume I’m interested in capturing. If you do not see a volume here, your Sysprep did not
complete successfully. If you don’t see a volume, log out of the capture mode before
attempting any other action, power on the computer back to its installed OS, manually
answer the Set Up Windows questions, make any necessary changes, and re‐Sysprep the
computer before starting this process again.
In Figure 3.4 are also Image name and Image description boxes. These are intended for the
name and description of the image as will be seen in WDS. I’ve named mine to show that
this image is comprised of my basic Windows 7 ENTERPRISE image plus Microsoft Office.
Click Next to continue.
The next screen, shown in Figure 3.5, identifies where you want to store the install image.
Be aware that this New Image Location screen behaves a little strangely. Follow along
closely because I experienced some problems the first few runs through.
41

Figure 3.5: New Image Location.
Remember how creating a capture image required two steps? In the first step, the image
was created, then it was uploaded to the WDS server. This rather‐confusing window needs
to accomplish both of those tasks. Problem is that you don’t necessarily want to store your
image on the master computer; you want to store it on your WDS server.
It’s here where things get tricky. Click Browse in the Name and location box to browse to
the Images folder on your WDS server. For me, the correction location was
\\wdsserver\c$\RemoteInstall\Images\Windows 7 Default. There, give the image a name,
which in my case was Windows7_Office.wim. You will be prompted to enter credentials to
make this connection.
After completing this step, select the Upload image to a Windows Deployment Services server
(optional) check box. Enter the name of your WDS server under Server name, and click
Connect. You will be prompted again for credentials. After successfully authenticating to
your WDS server, a list of image groups will appear under Image Group name. Select the
correct image group, and click Next to continue.
42

Note
I’ve seen some very strange behavior at this configuration screen. Namely,
that the authentication session used to connect to the WDS server’s disk
could not be shared by the WDS server connection. To get around this odd
limitation, I used the server name for the disk connection and its IP address
for the WDS connection.
You might experience different results. If your connection attempt results in
an error message, consider using my dual name and IP address trick to
connect.
You’re done! The capture process should begin. Capturing an image takes a bit longer than
deploying one, so plan on quite a few minutes passing. Also, as with image deployments, be
conscious about the large amount of network traffic that an image capture can generate. At
its conclusion, you should find your newly‐created image in the WDS console. Consider
performing a test deployment to see how well it works and whether your configurations
deploy correctly.
Your configuration should not have affected many of the questions and answers in your
unattend file. If you have configured a specific image to be deployed in your Client file,
you’ll want to change its name and filename. The other settings should remain effective and
should correctly answer the questions required by this custom image’s Set Up Windows
prompt. If you’ve done everything correctly, you should be able to deploy your custom
images using exactly the same process as your basic images from Chapters 1 and 2.
Stepping Back: Application Delivery Mechanisms
Step Seven seems pretty involved, particularly when you pair it with the realization that
every little change to a Windows image will require a deployment, a configuration change,
and a capture. That’s a lot of steps when you consider how often changes can be necessary.
An interesting thing about the Windows XP‐to‐Windows 7 upgrade in comparison with
previous OS upgrades are the new mechanisms now available to actually deliver
applications to users. Before I get into any step‐by‐step processes, I want to step back a
minute and really focus on the concept of application delivery. Remember back not too
many years ago when we didn’t have many options for delivering applications. For most of
us, when a user needed an application, we arrived at their desk with a DVD and installed it
locally.
43

That “DVD” application delivery mechanism suited us well for many years, but over time,
we grew tired of needing to show up at every desk after every request. It is at that point
where other application delivery mechanisms grew compelling:
• Group Policy Objects (GPOs) began delivering applications through our Active
Directory (AD) infrastructure.
• Application management solutions like System Center Configuration Manager,
System Center Essentials, and others from third parties gained widespread use.
• Application virtualization solutions like Microsoft’s App‐V, among other third‐party
solutions, can now stream an application through what can only be called a glorified
file copy.
These nifty solutions enable us to evolve towards a kind of layered approach in managing
our desktops—and, indeed, our desktop images. Rather than installing applications and
other customizations directly into images—the thick approach—smart administrators
know that a thin approach is a lot more manageable.
With the thin approach, deployed images remain relatively basic, containing few
applications that are directly installed into the image. Pairing down the image to a
configuration that is as simple as possible reduces the need for updates over time. Instead,
applications are installed (layered!) on top of the basic image using one of the other
mechanisms discussed in the previous bulleted list. You’ll obviously have a bit more setup
in constructing that layering infrastructure, but the result will be a much cleaner and more
elegant solution. More importantly, after the up‐front work is complete, your day‐to‐day
operations became far, far easier.
Figure 3.6 shows a graphical representation of this layering that I first created for TechNet
Magazine back in December 2009 2 . In it, take a look at the Core Operating System and its
Drivers. These elements, which we worked on in Chapter 2, are only part of the giant stack
that makes up every desktop.

2
http://technet.microsoft.com/en‐us/magazine/ee835710.aspx
44

Figure 3.6: Layering Windows OS deployment.
I’ll spend some time with the other elements in this stack in other chapters. For now,
however, I want to continue the conversation by talking more about the layer marked
Applications.
From Thick to Thin
Think about how the thin approach will dramatically change your management of desktop
images. Let’s compare “thin” with “thick”: How many desktop images do you have today?
Ten? Dozens? Hundreds? You’ve needed each of those desktop images because they’re
slightly different in composition. One may have Office 2010 on it, while another still holds
Office 2007 or even 2003. Even others may be different only in their drivers.
We fixed the driver problem in the previous chapter. There, we used WDS’ Drivers node to
create a pool of drivers that any deployment can pull from when Plug and Play finds a
hardware match. Accomplishing this means we can now get rid of every image that’s only
different because of its driver composition.
This chapter’s goal is to get you started down the road of eliminating the rest of your
images. Those images exist because their application composition is different. This chapter
won’t yet give you the complete solution, but it starts the discussion. Actually getting to
that thin nirvana will take many of the remaining chapters.
Thick to Thin: What Do You Need?
Think about the only real way to get to this single‐image nirvana: Stopping the practice of
installing applications and customizations directly inside the image. That’s kind of a neat
thought, yes? If I deploy an image that doesn’t contain applications—or that contains only
the applications I want everywhere—I can then layer on top of that image everything else
during subsequent steps.
45

What would I need to do this?
1. I need some mechanism to automatically install applications to desktops after
they’re deployed.
2. I need some mechanism for identifying which applications should be installed onto
which desktops.
3. It would be nice to have another way to inventory applications on my existing
desktops and hold that information in reserve. I could then use it to redeploy the
correct applications after the desktop is upgraded.
4. I need a way to repackage those applications so that they can be installed via this
magical automatic installation system. As with the Windows installation, fully‐
automated application installation needs to ask no questions during an installation.
It needs to start, finish, and be done.
5. I need to recognize that the applications themselves are only part of the job. Along
with applications, most users have data that needs to be transferred with the
application. Users don’t like it when their data isn’t available after their computer is
upgraded, and the manual steps to make that data available are painful for them and
us. As a result, any upgrade project should probably automatically manage my user
data as well.
That’s a pretty tall order of features. And you’re right in thinking that we’ll need to add
capabilities into our automated solution if we’re to get there.
What’s great is that you can actually fulfill these needs using Microsoft’s free solutions. You
can also fulfill these needs using for‐cost solutions. As I mentioned in Chapter 1, although
Microsoft’s no‐cost solutions might not be the slickest ones around, they’re free.
If your deployment project is small, low in complexity, or suffers under a really small
budget, Microsoft’s no‐cost solutions integrate perfectly to create most of this single‐image
nirvana. If you’ve got a few more bucks, use them to expand that solution to include some
of the costlier bits—either from Microsoft or third parties. Those additional spendy bits
bring greater administrative control, more reporting, and better granularity in the actions
they perform.
The Microsoft Deployment Toolkit
But this book is all about the free tools, so that’s where we’ll focus. I’m sure there are plenty
of third‐party solution salespeople who’ll be happy to explain how their products make all
of this simpler.
Once you’ve implemented what I’ve told you in Steps One through Seven, you have
everything you need to create a fully‐automated and universal system for deploying
Windows 7. You can actually put down this book and start deploying Windows with
success. In fact, if your upgrade project is really small, these seven steps are probably all
that you need.
46

If your upgrade project is more than really small, the steps to this point probably don’t
fulfill your needs. You’ve got to be pretty curious at this point how to get to this layered
approach for applications, user data, and other customizations. Even if you’re small, after
going through that painful deploy, reconfigure, and capture process a few more times, this
layered concept will probably become compelling.
Unfortunately, we’ve pretty much come to the end of the capabilities that we can squeeze out
of WDS alone. In order to take that next step in evolving our solution towards real
automation, we need to layer another of Microsoft’s acronyms (and applications) on top of
WDS. That new acronym and application is called the MDT or the Microsoft Deployment
Toolkit.
If you’ve been around the block for any period of time, you know that Microsoft’s
deployment tools have for years been…well…awful. They worked, but they were very
technology focused in the capabilities they presented. What the world has really wanted is
a more process‐focused solution; one that could truly automate all the usual workflows
that make up an upgrade project: user data collection, application inventory, application
compatibility checking, application installation, and user data injection—all those “other”
tasks that had for so long not been there in RIS, WDS, and the other tools alone. What the
world wanted was a way to create sequences of the tasks that go on in an upgrade project.
Those sequences would be codified instructions that automatically did all those nifty things
on behalf of the administrator. What a neat idea, eh? Well, Microsoft listened, and the MDT
was born.
Coming Up: Folding Your Deployment Infrastructure into the MDT
The next chapter will start our exploration into the MDT. As you’ll discover, the MDT
arrives as a kind of procedural wrapper around all the technologies that we’ve already
explored to this point. You won’t necessarily be throwing away anything you’ve already
learned. In fact, by navigating your learning in this way, you’re particularly prepared to do
well with the MDT’s task sequence method of deploying Windows desktops.
The next chapter continues the conversation on techniques in installing applications,
focusing on the ways in which the MDT streamlines the process and moves you towards a
more layered approach. I’ll start by helping you get the MDT installed and initially
configured. Then, I’ll show you the steps you’ll need to implement to incorporate
application installations within your Windows deployment.
You also know that applications aren’t everything. Applications by themselves are only of
limited assistance. You also need to return user data back to a computer after it’s been
upgraded. Following Chapter 4, I’ll continue by discussing the all‐important topic of user
data and show how the MDT will assist in preserving that data during an upgrade.
47

Chapter 4: Layering Applications on Top of
Deployed Windows Images
The previous chapter offered a half‐chapter of step‐by‐step Automating Windows 7
Installation content. In that chapter, you learned about Step Seven of the deployment
process: where you can customize your basic Windows 7 images—those right off the DVD
media—through the deploy‐modify‐capture method commonly called the thick approach. I
mentioned that at the conclusion of Step Seven you’re absolutely ready to begin deploying
images. Step Seven and those prior give you everything you need to be successful in
deploying Windows 7 using that thick approach. Rejoice!
Yet the second half of Chapter 3 focused less on the step‐by‐step; it was dedicated towards
pointing you in the direction of a new and arguably smarter approach: the thin approach.
Using the thin approach, applications, customizations, and user data are not configured
directly on the image; instead, those changes are layered on top of a basic image. They’re
deployed using other tools. One tool that is commonly used (at least among Microsoft’s no‐
cost options) is the Microsoft Deployment Toolkit (MDT).
This chapter will reposition your Windows 7 deployment solution inside the framework of
the MDT to gain added flexibility in deployment. Yes, we’ll for a minute lose some of the
automations that we’ve worked so hard to implement; but we’ll replace them with a much
more capable interface for the real needs of our project. And don’t worry, I’ll help you add
those customizations back by the book’s conclusion.
In this chapter, you’ll learn how to install and initially configure the MDT, how to deploy an
image, and how to link applications to that deployed image. At its conclusion, you’ll see why
the thin approach can be far superior to its thick alternative in dealing with applications.
Time for an applications diet.
Step Eight: Installing and Preparing the MDT
As of this writing, the MDT’s current version is MDT 2010 Update 1. Thus, start this step by
locating and downloading this version from Microsoft’s Web site. Install it to your WDS
server. You’ll find that the MDT installation is exceptionally simple, requiring only a few
very basic questions to get started.
48

Note
The MDT requires the WAIK for its installation, which you already installed
to the WDS server back in Step Five.
Once installed, your first step will be in creating a deployment share. It is within this
deployment share where much of your work will be stored. You’ll find yourself here during
most of your MDT administration. Right‐click the Deployment Share link, and choose New
Deployment Share to begin. Six questions are asked as part of the New Deployment Share
Wizard. You’ll need to provide a path, share name, and descriptive name for the location on
disk where deployment data will be stored. I’ll use the location C:\DeploymentShare.
You’ll also be asked three questions regarding whether you want the MDT to confirm
whether an image should be captured (see Figure 4.1), whether you want users to set a
local administrator password during deployment, and whether you want users to enter a
product key. Accept the defaults for each of these questions to begin.

Figure 4.1: Allow image capture.
Completing this task creates the deployment share in the workbench. Figure 4.2 shows an
example of how the workbench will look. You’ll notice that the deployment share comes
equipped with a few additional components that weren’t available in WDS, such as the
Applications, Packages, and Task Sequences nodes. As I mentioned in the previous chapter,
MDT wraps around the knowledge you’ve already gained at this point. Using MDT, you’ll be
able to create useful task sequences that better define the characteristics of images as
they’re deployed to desktops.
49

Figure 4.2: The Deployment Workbench.
Importing an MDT Image
But before we get there, let’s get the MDT up to a level of capability we’ve already
accomplished with WDS. You’ll be happy to know that this won’t take much effort. Start by
right‐clicking Operating Systems, and choosing Import Operating System.
We’ve already created a set of images that the MDT can import. These images are located
on our WDS server; we now just need to make them available in the MDT. Do so by
selecting Custom image file in the OS Type window (see Figure 4.3). Click Next, and enter a
path to the image’s .WIM file. If you’ve been following along, I will be uploading the custom
image we created in Chapter 2 called Windows 7 ENTERPRISE + Office. That image is
located in C:\RemoteInstall\Images\Windows 7 Default.
50

Figure 4.3: OS Type.
I didn’t select the Windows Deployment Services images option because there appears to be
an issue with this option in the current MDT version. Part of that issue relates to the need
to import Windows 7 setup files with the custom image. In the end, choosing the Custom
image file route made everything work just fine.
Figure 4.4 shows the screen you’ll see next if you select Custom image file in Figure 4.3. At
this screen, select the second option to Copy Windows Vista, Windows Server 2008, or later
setup files from the specified path. Enter Setup source directory path to the Windows 7 DVD
media, and click Next. Failure to complete this task may generate an error message as you
attempt to deploy an OS image in a later step. Click through the remaining screens in the
wizard to import this image.
51

Figure 4.4: Specify OS files.
Importing Drivers
After uploading an image, you’ll want to upload the set of custom drivers you collected for
WDS in the previous chapter. Do so by right‐clicking OutofBox Drivers, and selecting
Upload Drivers. The wizard, seen in Figure 4.5, will ask for the folder where the drivers are
stored. You created this folder in Step Four in Chapter 2.

Figure 4.5: Specify directory for the Import Driver Wizard.
52

Note
If you’re following along at home and using VMware Tools device drivers, be
aware that these drivers don’t function in WinPE. There is a way around this,
however: View the properties of your deployment share and look at the
Windows PE x86/x64 Components tabs. For now, set their selection profiles to
Nothing to prevent a WinPE boot failure.
Pay attention to the WinPE configurations in this screen. It is here where
drivers from your Out‐of‐Box Drivers node are injected into WinPE. Even if
you’re not using VMware Workstation, you’ll want to specifically tailor your
driver selections here so that inappropriate drivers aren’t injected into
WinPE.
Creating a Task Sequence
Next, you need to create a task sequence for deploying a Windows image. This task
sequence adds the MDT’s useful workflow components into a deployment. You will create a
basic task sequence at this point and add to it in a later step.
Right‐Click Task Sequences, and choose a New Task Sequence to start the New Task
Sequence wizard. This wizard starts the creation of a task sequence by asking six questions:
The task sequence’s name, the template, OS, and product key to use, the name and
organization of the user as well as the Internet Explorer home page, and finally the local
administrator password.
Most of these settings should be self‐explanatory with the exception of the Select Template
page (see Figure 4.6). There, you’ll find seven task sequence templates to choose from. The
sequence you’ll want to create is a standard OS deployment. What we’re doing is not
performing a capture. We’re not replacing a client. We don’t intend to upgrade, but instead
deploy a fresh OS that assumes no existing user data. Therefore, select the Standard Client
Task Sequence, and complete the rest of the screens in the wizard.

Figure 4.6: Selecting a Task Sequence template.
53

Take a minute and peruse the properties of the task sequence you just created. Under the
Task Sequence tab, you’ll notice the impressive list of tasks (see Figure 4.7) that can be
customized as part of this sequence. I’ll return to these in a minute, but spend some time
familiarizing yourself with what you’ll soon be able to do.

Figure 4.7: The Task Sequence tab.
Updating the Deployment Share
Next up is updating the deployment share. Among other things, this activity links the MDT
to WDS. The linkage requires two parts: First, right‐click your deployment share and view
its properties. Under the General tab, select the Enable multicast for this deployment share
(requires Windows Server 2008 Windows Deployment Services) check box, then click OK.
Next, right‐click your deployment share again, this time choosing Update Deployment Share.
This process updates the MDT’s needed configuration files and creates the necessary boot
images that you’ll use shortly. Accept its default values, and complete the wizard. This
process will take an extended period of time.
54

The section action is to replace WDS’ original boot images with those that the MDT just
created. Don’t worry; they’re much nicer than the boot.wim that we’ve been using! Disable
any boot images currently on your WDS server by right‐clicking the image, and selecting
Disable. Then right‐click Boot Images, and choose Add Boot Image. The boot image can be
found in C:\DeploymentShare\Boot\LiteTouchPE_x64.wim if your deployment share is in
the same location.
Note
If in Chapter 2’s Step Five you configured your WinPE unattend file to point
towards a specific Filename, ImageGroup, and ImageName, now would be a
good time to remove those settings.
Deploying a Basic Desktop with MDT
After completing the previous steps, you’re ready to deploy your first desktop with the
MDT. PXE boot that desktop just like you’ve been doing up until this point. Notice as its
booting that you are now booting from the MDT’s LiteTouchPE_x64.wim rather than WDS’
boot.wim file.
Once booted, you’ll be greeted with a very different desktop and a welcome screen than
what you saw with WDS. This new welcome screen comes equipped with quite a few more
options than in WDS (see Figure 4.8). Click the very large button marked Run the
Deployment Wizard to install a new Operating System, then enter appropriate credentials in
the resulting screen.

Figure 4.8: The Welcome Windows Deployment screen.
55

Now things begin to get very, very interesting. That task sequence we created just a minute
ago can be selected inside this wizard. In fact, any task sequence is now available for
selection. If you select a task sequence (see Figure 4.9, in my case Windows 7 ENTERPRISE +
Office) and continue through the wizard, you’ll be asked common questions like the
computer name, domain joining information, whether you want to restore user data
(new!), language, time zone, BitLocker configuration (also new!), and other preferences.

Figure 4.9: Select a task sequence.
You’ll even be asked if you want to use this deployment as a capture rather than a
deployment. All of these options are available in the same task sequence. Complete the
series of wizard pages and the deployment will begin.
It is important to recognize that although task sequences are all managed inside the MDT,
WDS continues to handle all the deployment responsibilities. That means WDS remains
responsible for your PXE boot infrastructure and all network transport requirements for
deploying images. You will, however, begin working with images now inside the MDT.
Step Nine: Learning Silent Installations and Repackaging
One of the areas where the MDT truly shines is in its ability to layer applications on top of
an existing OS image. If you recall the second half of Chapter 2, this layering of applications
allows you to create a relatively thin OS image. That thin image has few configurations.
Thus, it has little in terms of regular maintenance needs, alleviating you from the need to
deploy, modify, and recapture the image with each change.
Applications are layered into images by adding them into the MDT’s Applications node. If
you right‐click that node, and choose New Application, you’ll be greeted with a wizard for
adding such an application. Figure 4.10 shows an example of the three types of applications
that can be added: those with source files, those without source files or located elsewhere
on the network, and application bundles (which are collections of applications).
56

Figure 4.10: New Application Wizard
The second of these selections comes in especially handy if you have already generated a
stockpile of applications that have been repackaged to run silently. This repackaging process
is fundamentally important to application layering, and represents the biggest hurdle most
IT organizations have in making the thick‐to‐thin jump. Why? The process to repackage
applications can be complex, and is in many ways a bit of an art form.
The issue goes a bit like this: Remember how we reconfigured our images back in the early
steps of this book so that they would function without prompting for questions? By using
unattend files, we were able to answer those questions prior to a deployment, allowing the
deployment to continue through without prompting. The same holds true with thin‐
deployed applications. These applications need to be repackaged so that they operate
silently; essentially, so that they do not ask any of the normal questions an application
would ask when it is installed.
Let me give you a short primer that will get you started with repackaging your applications.
This isn’t a step‐by‐step process because every application is a little bit different. You’ll
need to do some sleuthing and more than a bit of detective work to accomplish this task
correctly. Once you learn the basics, you will be ready for Step Ten, in which I’ll show you
how to incorporate one silenced application—WinZip—into a task sequence.
57

Three Ways to Silence Applications
Let me help you with the science behind the art. There are three common ways in which
software is typically installed to a computer:
• MSIbased installations. These installations, all of which have an .MSI extension,
leverage the built‐in Windows Installer Service to complete their task. They share
this commonality, so they tend to be the easiest to repackage.
• EXEbased installations. A software installation with an .EXE extension typically
uses its own built‐in mechanism for installing itself. With a set of potential tools to
create these files, there are an equal set of ways to silence them. With these, you’ll
find yourself needing a little sleuthing to discover their secrets for silence.
• Differentialbased installations. When neither of the other two mechanisms work
for an installation, tools are available that can snapshot the configuration of a
computer before and after an installation to determine which files and registry keys
changed.
For the first two installation types, the solution for repackaging is in finding their silent
switches. These switches, such as /silent, /s, or /v /qn for example, instruct either the built‐
in installation code or the Windows Installer Service to install the package without
prompting the user. For the third mechanism, special tools are required. We’ll discuss all
three in the following sections.
MSI‐Based Installations
MSI installations are generally the easiest to repackage to run silently. Every MSI
installation uses the Windows Installer Service. Thus, every MSI installation tends to have
similar silent switches that install the package silently.
Generally, all MSI‐based installations use the msiexec.exe command to invoke their
installation. The general syntax looks a bit like this:
msiexec.exe /qb‐ /l* {logfile.txt} /i {setup.msi} {NAME=Value}
In the code, each switch instructs the Windows Installer Service to accomplish a different
task associated with the installation. Table 4.1 explains the job of each switch.
Switch Description
msiexec.exe Invoke the Windows Installer Service
/qb- Use a basic user interface with no (modal) dialog boxes
/l* {logfile.txt} Log all information about the installation to logfile.txt
/i {setup.msi} Install the setup.msi application (as opposed to repairing
or uninstalling it, which use different switches)
{NAME=Value} [Optional] Set the NAME setting to the configured Value
Table 4.1: Common msiexec.exe switches.
58

{NAME=Value] at the bottom of Table 4.1 requires additional explanation. Customizations
for MSI‐based installations are stored in a database‐like format. Thus, settings that
customize the installation for your environment—such as installation location, post‐
installation reboot suppressing, or other elements—can be set at the time of installation.
With MSI installs, these are typically completed in one of two ways—either by setting
individual values at the command line or by using a transform file. Transform files are used
when the number of customizations is large, as it allows individual customizations to be
wrapped into a single file. For example to install a version WinZip, you might use a
command similar to:
msiexec /qb‐ /l* logfile.txt /i WinZip.msi SERIALNUMBER={value} REBOOT=SUPRESS
In this example, the WinZip.msi file is launched with two customizations. The first inputs
the serial number as it installs the software. The second instructs the installer not to reboot
the machine after the installation.
If a transform file were available for this same installation, it would change the installation
to resemble the following:
msiexec /qb‐ /l* logfile.txt /i WinZip.msi TRANSFORMS={transform.mst}
The hardest part about repackaging MSI files can be in finding the right customization
settings for the command line. MSI interrogation tools are available to do this, and some
application vendors provide tools for generating your own transform files. The “art” in this
process is in determining what they are and how to use them.
Note
One very good way to find this information is to check out the Web site
www.appdeploy.com. This location includes a clearinghouse of many
common installations and their customization options.
EXE‐Based Installations
EXE‐based installs can be more difficult than MSI‐based installations because each EXE‐
based install has its own built‐in mechanisms for repackaging for silent installation.
Sleuthing to find the appropriate switches is much of the “art” of software packaging.
The easiest place to start is by simply attempting to run the software installation with the
/? switch. This switch—as well as /help, help, and others—can often display a dialog box
that presents the proper switches to be used for silent installation. Other common switches
that are known to work are /s and /s /v/qb. These switches are used by some of the
common enterprise packaging solutions for silent installation.
59

Note
There is no common schema among EXE‐based installations, so other
switches can also be configured to run the package silently, such as /q:a /r:n,
/silent, /passive, /quiet. The clearinghouse at www.appdeploy.com as well as
on the Web site of the application’s vendor can provide information about
EXE packages.
Another commonly used tactic is wrapping an EXE installation around an MSI file. Here,
when double‐clicked, the EXE file actually launches an MSI installation inside itself. With
these sorts of installations, the use of the /a switch can sometimes assist with extracting
the MSI file from its host EXE.
Try this process with the /a switch: From a command prompt, run
setup.exe /a
This launches what is called an administrative installation of the software. Often, this
administrative installation can prompt you through the installation as if you were installing
it on a computer. Instead of actually installing the package, it results in an unpacked MSI
file that has been preconfigured with your stated customizations. That MSI file can then be
launched silently using the techniques discussed earlier.
A second tactic to unpack the MSI file is to double‐click the EXE file and allow it to unpack
itself. When the first screen of the installation presents itself, leave the screen open and
look in the computer’s %TEMP% folder. Often, you’ll find the MSI file you’re looking for in
that location.
Differential‐Based Installations
Last is the situation where no matter of sleuthing can determine how to directly convert
the software’s installation to silent mode. Such is often the case when the software’s
developer didn’t include the necessary code to make it run silent. In these cases, the
optimal solution for repackaging this software is through what I’ll call a differentialbased
installation or diff.
In a diff, a special piece of software is used that snapshots a computer. The computer used
for these snapshots should be relatively free of configurations. It should include the same
OS on which you eventually intend to deploy the software. It should also contain the
minimum amount of software necessary to install the piece of software you intend to
repackage.
60

Two snapshots are created. The first captures each file, folder, and registry key present on
that system. Once the first snapshot has completed, the software to be repackaged is then
installed to the computer. After installing the software, a second snapshot is taken. The diff
tool then scans the two snapshots to look for changes to files, folders, and the registry.
Changes are presented to the administrator through a tree‐like interface that allows you to
selectively remove any extraneous findings (these can be common). Once removed, the
remainder is then repackaged into a new MSI file that automatically runs silently.
Software Is Really Just Files and Registry Keys
At its core, a software installation is little more than a process that copies a
set of files and folders to a target system, adds, updates, or removes a set of
registry keys. Sometimes drivers are registered, but at the end of the day, a
software installation isn’t much more than a file copy and a registry change.
Professional installers may include additional functionality that streamlines
this process, but in the background, these are the main two steps used to
install virtually all pieces of software.
Thus, if you merely watch to see which files and registry keys have changed,
you’re probably going to capture what the software installation program
actually accomplished. Just repackage those changes, and you’ve got your
silent installation.
Many diff tools are exceptionally expensive and are parts of enterprise‐class software
distribution platforms. These expensive software packages can be too costly for the small
IT shop. One long‐standing and no‐cost solution still available today is the software tool
called WinINSTALL LE (found at http://www.scalable.com/wininstall‐le). This tool should
be installed onto a clean reference computer. Once installed, run WinINSTALL LE’s Discover
menu item to begin the snapshot/installation/re‐snapshot process.
Step Ten: Laying Applications Atop a Windows Image
Though the information in Step Nine only scrapes the surface of the dark art of software
packaging, it serves as a starting point moving towards the thin approach to application
installations. Out of each of the steps in this book so far, Step Nine will probably take you
the longest to comprehend. So don’t get too discouraged if you don’t understand its
processes at first. I didn’t.
In Step Ten, I want to show you the step‐by‐step processes you can use to layer an
application—once silenced—into a Windows image. Be aware that you may not want to do
this with every application. Those applications that you anticipate every user needing, such
as Microsoft Office and/or other common applications, may be better managed by being
directly installed (using the thick approach) onto the image. The decision about how to
deliver an application will depend on your environment’s individual needs.
61

Let’s assume that for Step Ten, I have already repackaged the WinZip application using the
diff method from Step Nine. Using that method, I have an installation that runs silently.
When invoked, its MSI installation automatically installs the WinZip application onto a
Windows desktop. Rather than applying it directly to the image, I want to layer WinZip only
for those users who need it. This application currently resides in my IT share found at
\\wdsserver\ITApplications\WinZip.
Adding the Application to the MDT
Back in the MDT, right‐click the Applications node, and choose New Application. Just like in
Figure 4.10, I’ll choose Application without source files or elsewhere on the network because
I don’t want to import the application directly into the MDT.
Figure 4.11 shows the next screen in this wizard where I’m prompted for the publisher,
application name, version, and language of the application. This information is useful when
the time comes to deploy the application. Thus, although the four selections are optional,
consider filling them in.

Figure 4.11: Application details.
The wizard’s next screen, which Figure 4.12 shows, provides a location to enter the full
path to the packaged application’s executable along with a working directory. This path
must be accessible by the user whose account will be used for deploying the OS image.
Ensure that appropriate permissions are applied to the share and NTFS permissions. Click
through the remaining screens to complete the wizard.
62

Figure 4.12: Command details.
Configuring the Application for Deployment
Two methods are available for adding the application to the OS deployment. It is possible to
select one or more applications during the deployment activity. This occurs while you
answer the questions inside the MDT task sequence. Every application that has been added
to the MDT server’s Application’s node will be available for installation in this screen.
You can see in Figure 4.13 that check boxes are available for installing the WinZip
application. Other applications that have been added to the MDT, such as Company App
ABC, are also available for installation in this wizard page. Select the check box next to the
applications to be installed, and continue through the wizard. Applications are installed in
the State Restore phase of the MDT task sequence.

Figure 4.13: Select one or more applications to install.
Applications needn’t necessarily be optional activities inside a task sequence. In fact, full
automation means not making these options inside the deployment. As with many
customizations inside the MDT, you can direct those actions right inside the MDT task
sequence.
63

Figure 4.14 shows the task sequence for the Windows 7 ENTERPRISE + Office image that
we’ve been working with in this chapter. In the State Restore phase, you can see the Install
Applications task. I have selected to Install a single application in this task, with the
application set to Nico Mak Computing WinZip 11. Notice how this is subtly different than
the alternative, which installs multiple applications based on decisions made inside the
deployment wizard. Installing additional applications happens by clicking Add | General |
Install Application in the task sequence.

Figure 4.14: Installing applications in a task sequence.
64

Note
Although not to the level of a dedicated application deployment solution, the
MDT’s granular management of applications is fairly rich. For example, you
can define collections of applications to be deployed together by creating an
application bundle.
You can also ensure that strings of applications that have dependencies on
each other—such as when a line‐of‐business application requires Microsoft
office—are installed in order. This is accomplished through the
Dependencies tab inside the properties of the application.
More detail about accomplishing these tasks is out of scope of this chapter,
but you can learn more by exploring the options under the Applications tab
to familiarize yourself with what capabilities the MDT provides.
Thin Is Most Definitely In!
Chapters 3 and 4 have hopefully expanded your knowledge and your expectations in terms
of what an automated Windows 7 installation solution should look like. Such a solution
should absolutely be able to deploy Windows 7 images. But a smart solution—one that
really and truly augments the business process of IT—should also be able to layer in those
extra bits.
And yet applications aren’t the only thing that such a solution needs to handle. We haven’t
even gotten to the arguably more important scenarios surrounding the protection of user
data. The only way your Windows 7 upgrade project will be considered a success is if you
can protect that data and ensure it arrives back on users’ upgraded computers. Even the
smallest amount of missing data creates stress and negative attitudes that cause upgrade
projects to failure.
That’s why the next chapter is all about user data. You’ll find that the thin approach works
very well here. The MDT in combination with Microsoft User State Migration Tool (USMT—
yet another acronym!) will enable you to layer user state data over the top of a deployed
OS.
You’ll also probably recognize that our shift from WDS to the MDT has removed a few of
the automations that we so carefully built in the previous three chapters. That’s OK. We
gain critical granularity in the process, but a holistic solution needs to include those
automations to be fully complete. Over the next few chapters, we’ll be adding those
automations back in. The final chapter will then be a wrap‐up, consolidating everything
into a final and fully‐workable solution.
65

Chapter 5: User Virtualization: Tools and
Techniques in Preserving User Data
We’re getting ever closer to that full solution for automating Windows 7 installation. To
this point, you’ve learned about the image deployment process. You’ve experienced how to
create your own universal images. You’ve even discovered how to layer applications into
those images, a process that converts an administratively‐challenging thick image into a
much‐cleaner thin image.
But, if you recall back in Chapter 3, the many layers of a complete Windows instance
(shown again in Figure 5.1) aren’t complete with just the applications. Layering over the
top of those applications are specific configuration changes and even user personality
information that you’ll need to incorporate for success.

Figure 5.1: Layering Windows OS deployment.
In short, if your users don’t find all their data on their new Windows 7 computer, they’re
not going to care about all its nifty new features. That data is to them more important than
any new operating system (OS). Without it, your Windows 7 deployment project will not
succeed.
66

It’s for this reason that this chapter focuses on the all‐important facet of user data.
Interestingly, locating that user data, offloading it to temporary storage, then injecting it
back into an upgraded or replacement computer aren’t terribly easy activities. If you’ve
ever been responsible for manually locating a user’s data that’s strewn around their
computer, you know this pain. We’ve all sat in that seat at some point in our careers; I’d
prefer not to have to again.
That’s why automation of this user data preservation is important. You want an automated
solution that takes care of these steps for you. A highly‐successful tool will automate the
processes to such a degree that you’ll be able to abstract the user data from the individual
computer. That same tool will create a kind of virtualization of the data, removing the
direct ties between user data and specific machines.
I’ll be spending the majority of my time in this chapter talking about the tools inside the
Microsoft Deployment Toolkit (MDT) that can accomplish this task. The MDT 2010 Update
1 comes equipped with Microsoft’s (here comes another acronym!) USMT, or User State
Migration Toolkit. Although nowhere near a perfect solution, the USMT does a fairly good
job of collecting and later injecting the right data. It is also extensible. You can adjust its
behaviors should your users or their applications store data in other areas that aren’t part
of its default collection pass.
You should, however, be aware that the MDT and USMT combo only represents one
approach towards virtualizing user data. In fact, by default (as you’ll learn in the sidebar),
USMT does not capture everything. I’ll talk about other approaches towards the end of this
chapter that you might consider if your Windows 7 deployment requires more capabilities.
What Does the USMT Collect by Default?
The USMT indeed can’t know every file and registry setting for every
application in existence. It can, however, know what it needs to migrate for
most Microsoft applications and even many from third parties. It can also
make educated guesses about data that must be captured based on
commonly‐accepted coding practices. If your applications follow those
accepted practices, there’s a good chance that their data will get collected
right out of the box. For the rest, you’re going to need to customize USMT’s
behaviors.
Three files, found in the \USMT subfolder of your deployment share, are the
primary means for telling USMT what it needs to collect. Those three files are
MigUser.xml, MigApp.xml, and MigDocs.xml. As you can imagine, MigUser.xml
contains commands for migrating user folders, files, and file types;
MigApp.xml focuses on migrating application settings; and MigDocs.xml deals
with user folders and files throughout the system.
67

Right out of the box, USMT will gather common user folders, such as My
Documents, My Video, My Music, My Pictures, Desktop files, Start menu
items, Quick Launch settings, and Favorites. It will gather information out of
specific user profiles as well as the All Users or Public profile (depending on
the OS). It will even gather user settings, such as Accessibility settings, EFS
files, Favorites, Fonts, ODBC settings, among others.
An extensive list of files to migrate is managed by file extension. Everything
from .CSV, to .DOC*, to TXT, and many others are captured right out of the
box. You can modify the MigUser.xml file to extend this list to other files that
your needs require, or you can create your own custom XML files that
augment the defaults. Microsoft provides extensive documentation regarding
the settings that are captured at http://technet.microsoft.com/en‐
Step Eleven: Preserving User Data
Let’s begin by exploring the options the MDT has available for your Windows 7 deployment
project. I’m going to guess that your project probably has three requirements. I’ll assume
that for the first, you want to implement an automated process to upgrade Windows XP
computers to Windows 7. As part of that upgrade, you want to save as much of the existing
user data that you can.
I’ll also assume that your second and third requirements are fairly similar. Both come into
play after the upgrade. For the second, you’ll need another automated process for
refreshing a Windows 7 computer with a new Windows 7 image. This process means you
can quickly bring a failed computer back to a known‐good state.
There is a third use case. Sometimes users want new computers, or you need to deploy
them new hardware. Thus, your third requirement will be a process to replace a user’s
computer hardware while keeping their user data.
We already have a completely‐functional image that we can use for all three of these
requirements. That image is the one called Windows 7 ENTERPRISE + Office, and it’s the
same image I’ve been using for the past few chapters. We’ll use that image for the examples
in this chapter as well.
Take a look at Figure 5.2 where I’ve again brought up the default Standard Client Task
Sequence. This is in fact the very same Task Sequence that we started using upon installing
the MDT. In Figure 5.2, you can see the Capture User State task highlighted. This task
invokes the ZTIUserState.wsf script during the relevant part of the installation.
68

Figure 5.2: Capture User State.
What’s interesting about this script is that we’ve yet to see it get invoked, even though it is
a part of the sequence. That’s because, as configured in the default sequence, the Capture
User State task will not invoke when an installation is started via the boot‐from‐PXE
method we’ve used to this point. Instead, there’s a completely different method that you’ll
need to use if you want to invoke the script and gather user data during an upgrade. That
method I’ll talk about in the following section.
Requirement One: Upgrading Windows XP to Windows 7
Consider the situation where you’re ready to upgrade a user’s computer. When that
happens, you’re probably going to be somewhere physically close to that computer. Maybe
you’ve brought it back to a central IT room where you’re performing the upgrade. Or
perhaps you’ve travelled to their desk to help them through it. For this and other reasons,
an image deployment that involves user data preservation starts not from a PXE boot but
instead from a running instance of the OS itself. In this case, that OS will be Windows XP.
69

To kick off a deployment that preserves user data, don’t boot the machine to PXE. Instead,
run the command
\\{serverName}\deploymentshare$\scripts\LiteTouch.vbs
from inside the running OS. This command is installed by the MDT installation to the
deployment share’s scripts folder. It launches a Windows Deployment Wizard screen
similar to what you see in Figure 5.3. You’ll notice that the same Windows 7 ENTERPRISE +
Office task sequence we’ve been working with is available for deployment.

Figure 5.3: Running the LiteTouch.vbs script on Windows XP.
After you click Next, the next page in the wizard (see Figure 5.4) is new as well. You’ll see in
this page that two options are available for deploying the image: Refresh this computer and
Upgrade this computer. You’ll also notice that only the Refresh this computer option can be
selected. Recall that there is no direct upgrade path from Windows XP to Windows 7. Thus,
you can’t kick off a traditional upgrade and get the new OS (although you could if the
original OS were Windows Vista).
70

Figure 5.4: Choose a migration type.
That means that every Windows XP to Windows 7 upgrade is in fact a fresh installation. As
a fresh installation, you’ll need to ensure that you’re preserving the user data because it
will be formatted by the installation. Select the Refresh this computer option, and click Next
to advance to the next page.
The next three pages provide locations to change the computer name (if you wish), join the
computer to a domain or workgroup, and specify where to save data and settings. Figure
5.5 shows an example of this third screen. Of the two options that actually save user
settings, choose the first if you want to store the captured user data on the computer
during the refresh. Choose the second if you want it transferred to a file share somewhere
on your network.

Figure 5.5: Specify where to save data and settings.
71

Both options have merit. In the first, you’ll reduce the level of network traffic necessary to
complete the upgrade. In the second, you’ll create an off‐computer copy of the user’s
information should you experience a problem with the deployment. But, in doing so, you’ll
increase the amount of time required to deploy as well as the network consumption.
Your concerns about mid‐deployment issues are absolutely warranted. Sometimes OS
upgrades just don’t complete perfectly, and there’s nothing more heart‐wrenching than
having to look back at the user after a failure and say, “Oops.”
That’s why the very next page in this wizard provides the option to create a complete
computer backup prior to the deployment (see Figure 5.6). This complete computer backup
is intended to be used in an emergency should something go wrong. As with the previous
page, you can store that backup locally (if space permits) or send it to a remote location.
Remember that this full computer backup will be many orders of magnitude larger in size
than just the user data. So storing it somewhere else can have a big impact on storage as
well as network consumption.

Figure 5.6: Specify where to save a complete computer backup.
After the page that Figure 5.6 shows, you’ll see another series of wizard pages (not shown).
Those pages ask the same questions you’ve seen in other deployments so far: language,
time, currency, keyboard layout, time zone, and applications to install. The second‐to‐last
wizard page will ask for credentials used in connecting to network shares, followed by a
Ready to begin page. Click Begin to start the capture, deployment, and user data injection
process.
The script will capture the user state information to the location you identified in Figure
5.5. Figure 5.7 shows the installation progress bar that keeps you advised on the status.
When data collection is complete, the computer will reboot into WinPE, install the image,
and ultimately inject the collected user data from its storage location.
72

Figure 5.7: Capturing user state.
You’ll know that everything has completed successfully if you see the final screen, which
looks like Figure 5.8. This screen shows that no errors or warnings were reported during
the installation. That’s a good thing.

Figure 5.8: Deployment summary.
Customization Resources
I mentioned earlier that you can customize the data the USMT will collect.
What I didn’t mention is that customization isn’t a trivial task and will
require sleuthing in terms of what data you actually want—files, registry
keys, and so on. Once you know what you want, you’ll need to encode that
information into the USMT’s XML files.
These tasks are not easy nor can I explain them in the space I have available.
Thus, the specifics of this aspect of customization are best left to Microsoft’s
Web site. Two URLs provide sample XML code you can borrow to modify
USMT’s configuration files. Information on including files and settings can be
found at http://technet.microsoft.com/en‐
us/library/dd560778(WS.10).aspx. Information on excluding files and
settings can be found at http://technet.microsoft.com/en‐
us/library/dd560762(WS.10).aspx. Both of these locations offer example
code to create a custom.xml file that works with the default MigApp.xml,
MigUser.xml, and MigDocs.xml files. The combination of these files will
control what data is preserved between OS installations.
Numerous third‐party solutions also exist that do a much slicker job of this
customization. It is in fact these customizations that present the strongest
case towards looking to third parties for better capabilities.
73

Requirement Two: Refreshing a Windows 7 Instance
With the information in the previous section, you have what you need to truly start
upgrading Windows XP and Vista machines to Windows 7. But that only finishes the
immediate project; what you really want is a Windows 7 deployment solution that
continues to benefit you over the long term.
That’s why your second requirement is refreshing an existing Windows 7 instance. In this
situation, a user’s computer does not need to be upgraded. Instead, their instance of
Windows 7 just needs a quick rebuild. In completing that rebuild, all the same applications
and user data must be injected back onto the computer after the rebuild completes. You
essentially want them to walk away and come back to a functioning computer.
You can use the same process to accomplish this that you did with the first requirement.
Again, instead of booting to PXE, kick off the
\\{serverName}\deploymentshare$\scripts\LiteTouch.vbs script inside the running
Windows 7 OS. As before, this script will ask you a series of questions that are similar to
those I discussed in the previous section. Once the questions are answered, the user data
capture will begin, followed by the image deployment, and concluding with the user data
injection. You’ll know you’ve done everything correctly when you see a Deployment
Summary screen similar to Figure 5.8.
Requirement Three: Moving a User to New Computer Hardware
As you can imagine, the steps involved with the first two requirements are more or less the
same. Their only difference is their starting OS. In them, you’ll be kicking off the script from
within the running OS instance, answering its questions, and then allowing it to complete
the process—all on the same computer.
But there sometimes comes the need to move a user to a completely new set of computer
hardware. Perhaps your company is going through a hardware refresh, replacing older
hardware with new. Or maybe the user’s computer is experiencing problems and needs a
hardware replacement. In either of these cases, you don’t want to deploy another image to
the same hardware. Instead, you want to capture the user data and then inject it to a
completely different computer. Accomplishing this task requires two Task Sequences, one of
which you haven’t seen or created yet.
To begin, you’ll need to create that brand‐new task sequence. This time, you’ll be creating a
Standard Client Replace Task Sequence, as Figure 5.9 shows. This task sequence is
somewhat different from any that we’ve used so far because it does not actually deploy an
image to a computer. There also aren’t many settings to configure as part of this sequence.
I’ll name mine Windows 7 Replacement.
74

Figure 5.9: Standard Client Replace Task Sequence.
Figure 5.10 shows the default tasks that are created as part of the default Standard Client
Replace Task Sequence. If you look very closely, you’ll notice that none of the typical image
deployment tasks are part of this sequence. In fact, the PreInstall and Install phases are
both essentially empty, containing only the Next Phase task.

Figure 5.10: Tasks in the Replace Task Sequence.
A replace task sequence is used to capture user data off an existing computer and send it to
a remote server for storage. Remember in Figure 5.5 where you were given the option for
storing user data either locally or remotely? In this sequence, you’ll be forced to store the
data remotely so that it can later be accessed by the new computer.
75

As with the other steps, you will begin this process at a running instance of the OS. Also,
just like the other steps, the process begins by launching the
\\{serverName}\deploymentshare$\scripts\LiteTouch.vbs script. This time, however,
select the Windows 7 Replacement sequence you see in Figure 5.11.

Figure 5.11: Selecting a task sequence.
As I mentioned earlier, the only option available now (see Figure 5.12) is to specify a
location somewhere on the network. I’ve created a share called \\wdsserver\userdata, so
I’ll store mine in the gshields subfolder of this path. Obviously, make sure that you’re
setting your permissions appropriately so that the user whose credentials the installation
is using has appropriate access. A replacement sequence also gives you the ability to create
a complete computer backup, although that backup must be transferred to somewhere on
the network. I’ll skip that backup for now. Lastly, provide a set of credentials and the user
state capture will begin.
76

Figure 5.12: Specify a location for user data.
Restoring this information to another computer happens in much the same way as the
steps in the second requirement. The only difference here will be the need to point the task
sequence back to the remote location for the user data. Be aware that the computer will
reboot back into WinPE for a very short time after the state capture is complete.
Stepping Back: Real User Virtualization
You’re probably wondering at this point why this chapter’s title starts with the term User
Virtualization. That’s because this concept of layering user data and configuration
information on top of an OS represents a kind of virtualization. Remember that
virtualization at its most basic represents the abstraction of one layer of resources from
another. In server virtualization, you’re abstracting the server from its physical resources.
Application virtualization abstracts applications from their underlying OS. In this concept
of user virtualization, user data is abstracted from applications and OSs altogether.
I wrote about this concept of user virtualization in a recent book, The Shortcut Guide to User
Workspace Management, which you can download for free from
http://nexus.realtimepublishers.com/sguwm.php. In that guide, I talked about some of the
fantastic benefits one could get out of fully and completely abstracting the user’s
workspace from the rest of the OS.
77

What’s important to recognize here is that the MDT doesn’t get you there fully and
completely. The MDT is more of a point solution that’s used for a specific problem. Smart
organizations recognize that virtualizing the user’s workspace presents very compelling
administrative benefits for ongoing operations—even after the upgrade or when users
don’t necessarily need new OSs.
Let me quote a section from Chapter 1 of that book, to tease you towards external solutions
that are always on and always managing user data. These always‐on solutions create user
virtualization by allowing users to seamlessly move across OSs, computer instances, and
even OS delivery infrastructures. The solutions are available today, and the future state
they present is something I think every IT professional would love to have in their own
data center.
Encapsulation and Decoupling
With this understanding in mind, let’s assume that through the use of one or more
software products, it becomes possible to logically encapsulate these layers. This
process of encapsulation creates hard lines between the user workspace and the
applications and OS it customizes. It does the same thing between applications and
the OS, as well as between the OS and the hardware on which it rests.
Without this logical encapsulation in place, managing that computer is a very
difficult thing to do. Without some automated software deployment or application
virtualization solution, adding a new piece of software means I have to manually
touch each and every computer. Updating a piece of software requires a lengthy
uninstallation‐followed‐by‐reinstallation process. Lacking solutions like these,
working with OSs and applications in any form is both difficult and time consuming.
The same holds true at the user workspace layer as well. User data is natively stored
within a Windows user profile, with that profile containing all the customizations
that elevate a freshly‐installed Windows OS into something that’s personalized for
each user. Lacking logical encapsulation at this layer, moving that user data between
different computers becomes challenging to the point of absurdity. If you’ve ever
spent four hours trying to upgrade a single user’s computer from one OS to another,
you know this pain.
The Benefits of Decoupling
Now, envision an environment where each of these layers has been fully
encapsulated. Such an environment would see a full decoupling of each layer from
the others. Here, for example, a hard line would exist between the user’s workspace
and their applications. The user’s workspace would be independent from the OS as
well as its hardware.
78

In such an environment, that user’s workspace would immediately become fully
mobile. This becomes possible because that workspace is no longer directly reliant
on the layers below it. Because the decoupled workspace now exists in its own
independent and isolated layer, that layer can trivially move between different
computer instances. Such an environment would gain some very interesting benefits
to administration.
For example, consider the change that is represented in Figure 1.2. Here, the user
workspace has been decoupled from its OS and installed applications. With the
aforementioned encapsulation in place, it becomes possible to swap out the
underlying OS along with its applications.

Figure 1.2: Decoupling the user’s workspace enables it to work atop new
computer instances.
This process sounds vaguely similar to the manual steps I went through to locate the
user’s information, copy to an offline location, and merge it back with the upgraded
OS. However, different with a User Workspace Management solution is the logic that
fully automates these steps.
User Virtualization Goes Beyond OS Deployment
It is my hope that you take two important points away from reading this chapter.
Obviously, the first point relates to the steps you can implement today to add user data
capture and injection into an MDT task sequence. If your needs relate solely to a Windows
upgrade, the MDT and the USMT can perform most of what you need.
For the rest of us, the second take‐away relates to the need for pervasive user virtualization
and/or user workspace management in our desktop environments. By elevating what we
know we can do through tools like the USMT into always‐on solutions, we can create a
future‐state where users get their settings at every desktop, at anytime, anywhere, no
matter what the delivery mechanism. That future state makes users very happy. It also
makes us very happy because it opens up the ability for IT to make underlying changes
without impacting users in the slightest. If you haven’t taken a look at the user
virtualization solutions out on the market, they’re a game changer for even small
environment needs.
79

That said, this book still has a few topics to cover to round out the complete solution for
Windows 7 deployment. Next up is the recognition that many applications simply won’t
function atop Windows 7. Windows Vista and Windows 7 both enjoy a much more secure
kernel architecture that protect them from many of Windows XP’s nefarious attacks. At the
same time, that more‐secure architecture eliminates the functionality from many poorly‐
coded applications.
In the next chapter, I’ll show you Microsoft’s free tools for inventorying your environment.
I’ll also show you the tools Microsoft provides for helping you get through the application
compatibility part of this story. Lastly, I’ll show you smart ways that you can “punt” on
some applications so that those with conflict don’t need to delay your Windows 7 upgrade.
80

Chapter 6: Automating Application
Inventory and Overcoming Incompatibility
Step Eleven, covered in the previous chapter, really concludes the “deployment” activities
in Windows 7 deployment. By navigating through the first eleven steps, you know how to
create and deploy images. You’ve seen how to layer applications on top of those images
during deployment. You’ve also learned tricks you’ll need to preserve important user data
between old and new OS instances.
Congratulations! You’re ready to start deploying!
Or are you? If you’ve been around the IT industry for long, you know that every OS upgrade
is never as simple as it seems. Although deploying OSs is pretty easy, making sure
applications work with that OS often isn’t. Here’s a chilling statement: Many of your
applications that run just fine on Windows XP won’t automatically run on Windows 7. Yikes.
You should already know some of the reasons that this is the case. Windows Vista and
Windows 7 arrive with significant changes to their security model. These two OSs no longer
grant applications and drivers direct access to the OS’s most‐secure kernel code. The new
security model along with a host of other updates make Windows Vista and Windows 7
significantly more secure than Windows XP. Significantly.
Unfortunately, those changes also mean many older applications—those that abused
Windows XP’s overly‐open and inviting nature—aren’t going to work automatically. Some
will require configuration adjustments. Others will need software “shims.” Even others
won’t work at all.
Thankfully, Microsoft knows about the problem. To assist, they’ve created two tools (along
with accompanying acronyms) that inventory your network and apply known fixes that’ll
make many applications work again. The first of these tools is called the Microsoft
Assessment and Planning Toolkit (called the MAP). A simple tool, the MAP collects a list of
applications and drivers on your network. With its data, you can identify the applications
on your network and a list of drivers your computers will need. The second and more
powerful tool is the Microsoft Application Compatibility Toolkit (aka the ACT), which assists
in identifying and fixing incompatible applications.
81

Step Twelve: Inventorying Applications and Drivers on the Network
Step Twelve begins with the installation of the MAP. With it, I’ll show you how to gather a
report of the software that’s installed on computers around your network. With that
information in hand, I’ll point you to Microsoft’s Windows 7 Compatibility Center. This site
is an online clearinghouse of applications and their compatibility status. You can compare
the software in your report to those in the Compatibility Center to see which will work and
which won’t.
But that’s not all the MAP is good for. Remember back in Step Four (and again in Step
Eight) where I showed you how drivers can be automatically injected into images as they’re
deployed? Wouldn’t it be useful to know exactly which drivers your computers will need?
The MAP can also collect that information for you, if you know where to look.
Installing the MAP and Collecting Inventory
Begin by downloading the MAP from Microsoft’s Web site and installing it to the WDS
server we’ve been using throughout this book. Using the MAP requires first installing a
copy of Microsoft Office 2007 SP2 as well as the .NET Framework. The MAP will
automatically install a copy of SQL Server Express to the computer as it begins its
installation. Once installed, you’ll be asked to create a new inventory database just like you
see in Figure 6.1. I’ve named my database MyInventory.

Figure 6.1: Creating a new MAP database.
Figure 6.2 shows what the MAP’s console will look like after installation. You should
immediately notice that the MAP has far more capabilities than simply searching your
network for installed software. Other assessments are available that help determine
Windows Server roles that have been installed on servers, where SQL server components
have been deployed, and even where virtual machines might be hiding on your network.
82

Figure 6.2: The MAP console.
Inventorying the software in your environment starts by clicking the Inventory and
Assessment Wizard link you see in the right pane of Figure 6.2. Clicking this link brings
forward a wizard that you’ll use to configure the types of inventory to be collected.
Windows, Linux, VMware, Exchange Server, and SQL Server computers are all options for
inventorying. I’ll be using only the Windows‐based computers scenario in this chapter, as
this scenario provides the information I’ll need for a Windows 7 upgrade.
The wizard’s second page (seen in Figure 6.3) shows the multitude of methods the MAP
will use in discovering computers to inventory. My computers are all members of an Active
Directory (AD) domain, so I can select the first and second check boxes to find them. Other
computers not on the domain can be discovered via IP ranges, by entering in computer
names manually, or via a text file.
83

Figure 6.3: Selecting methods to discover computers.
Subsequent wizard pages provide locations to enter AD credentials, to restrict inventory to
specific organizational units (OUs), and to add domains or workgroups if they are
discovered by the tool. The page titled All Computers Credentials allows you to enter in a
list of possible credentials the tool can use in attempting to inventory discovered
computers.
It is within the All Computers Credentials and Credentials Order pages where the MAP truly
shines. You can see in Figure 6.4 that I have entered credentials for two different domains:
COMPANY and SPECIALIZED. Additional workgroups or specific computer credentials can
be added as well. Doing so will give the inventory process plenty of username and
password options as it authenticates to discovered computers.
84

Figure 6.4: Setting an order of credentials.
Click Finish to complete the wizard and begin the discovery and inventory process. Be
aware that this process can take a considerable quantity of time, particularly if your scope
is large. Version 5.0 of the MAP, the version used in this example, is reported to discover
and inventory as many as 100,000 computers. Gathering information from that quantity of
computers, as you can imagine, is going to take a while.
Note
The MAP’s inventory process uses WMI queries to gather its information.
Ensure that the Remote Administration firewall exception has been enabled
on any computers that will be queried by the MAP.
Figure 6.5 shows a report on the products the MAP found in my network. You can see that
the Adobe Reader 9.4.0 was discovered on two computers. A set of three Apple applications
was found on another two, as well as an entire list of software from all sorts of vendors.
This screen inside the report is relatively static, giving you little more than a view of the
software that the MAP has found inside your network.
85

Figure 6.5: Product inventory results.
A much more useful representation of the data found by the MAP can be created by clicking
the Windows 7 Readiness link in Figure 6.5’s left pane. The resulting Windows 7 Readiness
summary provides high‐level information about the computers found in the discovery and
inventory process. You can learn in this screen how many computers have hardware that is
powerful enough to support Windows 7. You can also learn how many drivers your
computers will need and which of those drivers are included on the Windows 7 DVD.
Figure 6.6 shows a snippet of the summary screen. That screen tells me I’ll need to locate
manufacturer drivers for 61 of the 194 drivers my computers say they need.

Figure 6.6: Device compatibility summary.
86

Creating and Using MAP Reports
There’s a link (not shown) on the right pane of this Windows 7 Readiness Summary Results
page that’s labeled Generate Report/Proposal. Click that link to generate a report. Then
click View | Saved Reports and Proposals to bring forward an Explorer window. In this
window, you’ll find a Microsoft Word document that contains useful project planning
information about your Windows 7 readiness.
You’ll find even more useful information in the accompanying Excel spreadsheet. Inside
that spreadsheet is detailed information about each inventoried computer, its hardware
configuration, and any installed software and drivers.
Figure 6.7 shows one of the tabs in that spreadsheet. In it you can see that at least one
computer on my network reports it will need the Realtek High Definition Audio driver.
Happily, that driver is available on the Windows 7 DVD media, so I don’t need to worry
about it. Another computer reports it needs the Realtek PCIe GBE Family Controller, which
isn’t on the Windows 7 media. I’ll need to locate that driver from its manufacturer’s Web
site and add it to my Out‐of‐Box Drivers node in my MDT Deployment Share.

Figure 6.7: A MAP report’s Excel spreadsheet.
By reviewing the drivers inside this Excel spreadsheet, I now know which drivers I’ll need
to make available in MDT so that my images will deploy correctly. This report all by itself
gives me the data I need to ensure my deployment goes as smoothly as possible.
87

A second tab on this Excel spreadsheet gives me a punch list for tracking down the
compatibility status of applications that are installed on my computers. That tab, labeled
Discovered Applications, lists each application, its version number, and the number of
instances found on the network during the last inventory pass.
I mentioned at the beginning of this step that Microsoft has created an online clearinghouse
of application compatibility status information. That clearinghouse is called the Windows 7
Compatibility Center. Navigate to
http://www.microsoft.com/windows/compatibility/windows‐7/en‐us/default.aspx to
check out its constantly‐updated list.
Figure 6.8 shows the results of going to the site and running a search on Adobe reader. I
already know from my MAP report that I have two copies of Adobe Acrobat 9.4.0 in my
network. Running this search tells me that Adobe Reader version 9 is compatible with
Windows 7. It also tells me that version 8 compatibility requires an action, specifically a
free upgrade. That’s useful information.

Figure 6.8: The Windows 7 Compatibility Center.
Combining the information provided by this Web site with the information in my MAP
report, I can quickly identify which applications will work and which won’t. For some, I
may learn that they’ll require a patch or some other special configuration to function.
88

Step Thirteen: Resolving Application Incompatibilities
I told you that two tools are necessary to fill out Windows 7’s application compatibility
story. The second of these two tools is the Application Compatibility Toolkit (ACT). While
the MAP is a simple tool that gathers a relatively simple set of information, the ACT is a
robust solution for locating and applying fixes to applications that otherwise won’t work.
That said, using the ACT isn’t nearly as simple as the MAP. You can’t just install it and
immediately run an inventory. Rather than using WMI to query computers for their
contents, the ACT gathers its information through the use of an agent. That agent allows the
ACT to gather a greater level of detail than MAP can get with its WMI approach. Although
great for data collection, this agent isn’t exactly trivial to install. It must be deployed and
launched through an external software delivery mechanism. That mechanism can be a
logon script, Group Policy Software Installation, or even System Center Configuration
Manager. You can even double‐click and invoke the agent manually on any computers you
want to inventory. Launching that agent through any of these means will gather the data on
the system and transfer it to a file share that you designate on your network. For Step
Thirteen, I’ll show you how to set up the ACT, gather information from agents, and use that
information to locate fixes for known‐incompatible applications.
Note
In the interest of space, I’ll assume that you know how the steps necessary to
automatically deploy a piece of software through one of the aforementioned
tools. Should you need assistance, consult Microsoft’s deployment guide with
the ACT that walks you through the process.
Installing the ACT
Start by downloading the MAP from Microsoft’s Web site. In my case, I’ll be using the MAP
version 5.6. Install it to the server we’ve been using throughout this book, and launch its
Application Compatibility Manager to begin the initial configuration.
Note
If you’re using the ACT on the same server where you installed the MAP,
you’ll need to perform one step prior to launching the Application
Compatibility Manager. Navigate to C:\SQLEXPRESS and double‐click the
installation file you find. Doing so will launch the SQL Server setup wizard.
You’ll need to install an additional SQL Server instance for the ACT to use.
Click through the wizard screens and create a new named instance. In my
case, I’ll name that instance ACT. You’ll use that instance in the following
steps.
Three information pieces are required to initially configure the ACT (see Figure 6.9). You’ll
need a SQL Server database instance to store its information. You’ll also need a file share
with plenty of storage space, which will be used for collecting agent log files. Lastly, you’ll
need an account that is used for the ACT Log Processing Service.
89

Figure 6.9: The ACT Configuration Wizard.
The ACT Configuration Wizard will step you through setting up these three pieces. This will
be your primary server for collecting and processing log files as well as viewing reports, so
you’ll want to use the ACT’s Enterprise configuration when prompted.
Configuring the ACT database requires a somewhat confusing wizard page (see Figure
6.10). Clicking the drop‐down box should provide a list of local SQL Server Express
instances (see the earlier note for an extra step if you’re using the same server where the
MAP is installed). Select the instance you want, and click Connect (not shown) to connect.
Then enter a database name, and click Create to create that database. I’ve named my
database MyActDatabase.

Figure 6.10: Configuring the ACT database.
90

In a following screen, you’ll be asked for your share path and name. Be aware that the
Domain Computers group must be given write access to this location. The configuration
wizard’s final screen will ask for account credentials for the ACT Log Processing service.
You may select either Local System or a domain user account.
You’ll notice as the ACT launches that there’s not much to see at first. Figure 6.11 shows
ACT’s Collect view. It is in this view where Data Collection Packages are configured and
generated. Those packages are essentially a software installation in .MSI format that
installs silently. Inside the package is the necessary logic that will evaluate computers,
gather data, and report back application and compatibility information to the file share.

Figure 6.11: The ACT’s console.
Creating a Data Collection Package
Creating a Data Collection Package begins by double‐clicking the white space inside the
ACT’s right pane. Doing so brings forward a wizard screen similar to what you see in Figure
6.12. Each package’s .MSI file can be installed by double‐clicking it on a candidate system or
by distributing it through a software delivery system. For this example, I’ll create a package
and simply double‐click it on my WDS server, \\wdsserver.
91

Figure 6.12: Creating a Data Collection Package.
I’ve named this package Verify Windows 7 App Compat, as you can see in Figure 6.12. I’ve
also set the package to begin monitoring application usage as soon as possible after
installation. The package has a duration of 10 minutes and will output its data to the ACT’s
log location. When you click Advanced, you will see a secondary screen that allows you to
enable or disable any of the three compatibility evaluators: inventory collector, User
account control compatibility evaluator, or Windows compatibility evaluators.
Choose File | Save and Create Data Collection Package to complete this step and ready the
package for deployment. This process creates that .MSI file in the location you specify. Once
created, double‐click that .MSI file on any computer to begin collection, or deploy it through
your software deployment solution.
This ACT Thing Seems Hard
You might be asking why this process seems somewhat more complicated
than the MAP’s inventory process. Recall that although WMI can be remotely
queried over the network, it can only provide a limited set of data about
installed applications. Some applications may not be exposed properly or
completely within WMI. Thus, some of your applications simply won’t be in
the MAP’s list.
The ACT is intended to scale to thousands of computers. It is also designed to
collect and report on other data, with that reporting to occur over a
distributed amount of time to prevent abusing your file share. For all of these
reasons, Microsoft uses an installable “agent” to accomplish these tasks. In
the end, it is more work to get the data you need, but the data you’ll get will
be of much higher quality.
92

After letting the agent run for 10 minutes or so, you should begin seeing data in the log
location’s \Processed folder. When you do, return to the ACT and take a look at its Analyze
view. Within the Analyze view, you’ll find information about the applications the agents
have found on your computers.
Analyzing and Keeping Track of Results
Now, here’s where the exciting part happens. While in that view, click Send and Receive.
Clicking this button shares your application information with Microsoft, while at the same
time downloading Microsoft’s corresponding compatibility information. You’ll have an
opportunity to see what data is sent to Microsoft before sending (it isn’t much, but you’ll
want to confirm this sharing with your corporate security policies).
Once the synchronization is complete, the ACT’s report will update to include information
collected from the IT community about your applications. You can see in Figure 6.13 that
the community has rated most of the applications on my \\wdsserver computer fairly well,
with a slightly lesser rating for Microsoft Visual Studio .NET and the Microsoft SQL Server
Browser. You should know that although the software seen in Figure 6.13 is all Microsoft
software, this report will provide information on other software as well.

Figure 6.13: The Windows 7 Application Report after synchronizing.
You can safely assume that information gathered in this report is equivalent to what you
would be seeing on Microsoft’s Windows 7 Compatibility Center Web site. That’s a good
thing. What it means is that the ACT’s Application Compatibility Manager is a kind of
workflow management solution for keeping track of all your applications. As you click
through its settings, you’ll notice that you can set your own assessment of each application
as well as its deployment status, category, and priority. You can also document issues with
applications and corresponding solutions. Figure 6.14 shows an issue with the Office
Diagnostics Service conflicting with a custom application once upgraded to Windows 7.
93

Figure 6.14: Documenting an issue with an application.
Note
The ACT is useful for more than verifying compatibility with Windows 7. It
can also be used for verifying compatibility with Microsoft updates prior to
deploying them with WSUS.
Fixing Incompatible Applications
All of this setup merely gets you to the point where you can begin analyzing and tracking
your applications for incompatibility. ACT also provides a set of tools for actually fixing
incompatible applications. One tool that you’ll use in modifying applications to help them
run is the ACT’s Compatibility Administrator. Inside the Compatibility Administrator are
more than 6500 known applications along with their accompanying fixes.
Two versions of the Compatibility Administrator are available, one each for 32‐bit and 64‐
bit applications. In either, click the Applications node to expand the list of known
applications. As you’ll quickly find, fixes are available for many known applications, such as
the HP Web Jetadmin application that Figure 6.15 shows. There you can see that the
VistaRTMVersionLie fix can resolve an issue with the HPWJAUpdateService.exe file.
94

Figure 6.15: Compatibility Administrator.
Although this information is useful if your applications are in the list, many applications
won’t be available. Any custom and uncommon applications your company uses aren’t
likely to be present.
For applications not in the list, you’ll need to test which compatibility fixes might resolve
the problem. Built into the ACT are more than 360 compatibility fixes (sometimes called
shims) that can be integrated into an application to return it to functionality. These fixes, a
list of which can be seen in Figure 6.16, resolve issues with User Account Control,
permissions, file virtualization and repathing, and numerous others.
95

Figure 6.16: The ACT’s compatibility fixes.
What Fixes Do What?
With 360 possible compatibility fixes to choose from, how do you know
where to start? Good question, because the answer isn’t immediately
obvious. Check out the TechNet Web site at
http://technet.microsoft.com/en‐us/library/cc722305(WS.10).aspx. In this
location, you’ll find descriptions of each fix, along with symptoms that
suggest when the fix might be applied.
Even with the symptoms and fix descriptions on this Web site, finding the fix
that actually works will be a guess‐and‐check exercise. Problematic
applications will require substantial work to see which fix (if any) will work.
The ACT exists to create a singular database where discovered fixes can be
logged so that you can measure your progress over time and document your
findings.
To run tests against applications, you’ll want to install the Compatibility Administrator to a
reference computer that is running Windows 7. On that computer, install the application
and verify that it is incompatible. Take careful note of exactly how that application is failing
as well as error messages it gives or other notable behaviors.
To test a fix, create a Custom Database in the Compatibility Administrator on the Windows
7 computer. Right‐click that database, and create a new Application Fix. Doing so will
launch the Create new Application Fix wizard.
96

In this wizard, you’ll be asked for information about the application, including its program
file location. You’ll also assign potential fixes to the application. Using this wizard enables
you to tag applications with potential fixes until you find the correct set that works. Figure
6.17 shows one of the wizard’s pages where compatibility fixes are tagged to an
application. You can click Test Run to test the execution of that application after fixes are
applied. The goal here is to verify whether assigned fixes indeed resolve an incompatibility.

Figure 6.17: Tagging a compatibility fix to an application.
Note
One easy starting point is to try setting the Compatibility Mode for the
application to Windows XP. This Compatibility Mode automatically adds a
series of adjustments to the application’s execution space that may quickly
solve the incompatibility. If an adjustment to the Compatibility Mode does
not resolve the problem, trying out specific fixes should be your next step.
After configuring the fix, save it to a location on the computer. The file will have an .SDB
extension. Then right‐click the custom database and choose Install to install the fix. Once
installed, try re‐launching the application to see whether the incompatibility is resolved. If
not, iterate through the previous steps until you locate the set of fixes that work with your
application. Make sure to right‐click the custom database, and choose Uninstall to remove
the fix before adding a new fix.
97

Once you’ve discovered the correct set of fixes your application needs, you’ll want to
deploy those fixes along with the deployment of your application. That deployment will be
different based on how you deploy applications. You can do so by including the
compatibility fix database in your deployed image, distributing it via a software
distribution system, or including it in a logon script by calling the sdbinst.exe file. Each of
these options is explained in greater detail in the Microsoft TechNet article at
http://technet.microsoft.com/en‐us/library/cc794691(WS.10).aspx.
Solving Incompatibility: Not Hard but Time‐Consuming
Reading through this chapter, you’re probably thinking to yourself, “This seems like a lot of
work.” In all honesty, it is. Not all applications work well atop Windows 7, although that
number is growing every day as vendors realize the need to update their code. There will
always, however, be a set of applications that will never run just right. For those, tools like
the MAP and particularly the ACT give you a mechanism to track down and potentially
resolve their incompatibilities. Getting those fixes just right will take a bit of effort.
In just thirteen steps, you’ve been introduced to nearly all the pieces you need to be
successful with your Windows 7 deployment. You can now deploy images with the
assurance that user data and now applications will run successfully atop the new OS.
What you’re likely still looking for is a way to pull all these steps together into a cohesive
solution. You’re nearly there. If you’ve been following along as we’ve been building this
solution together, you’ve already got most of the pieces connected that you need to fully
automate the solution. Taking that last step and completing the solution is the topic for the
next chapter.
98

Chapter 7: Creating a Complete Solution
for Automating Windows 7 Installation
You should by now recognize this book’s pattern of introducing new technologies and
approaches into the Windows deployment story. That story involves plenty of layers, each
of which builds on the infrastructure of the layer below. It started in Chapter 1 with the
very basics of deploying images—and weren’t those basics, indeed! The images back then
weren’t even customized. They were little more than the default configuration you get by
Next, Next, Finishing your way through a manual installation.
The next chapters then led you through greater customization and introduced additional
automations. By now, you’ve learned how to create single images that deploy everywhere.
You’ve automated the installation of drivers, applications, and user state information.
You’ve also discovered the MDT, and how its Task Sequences are the glue that ties your
automations together.
Throughout this book, I’ve shown you how Microsoft’s free solutions can accomplish
necessary deployment tasks. Those free tools get you pretty far. Using them, you can kick
off a relatively‐automated Windows installation with little effort and good results.
Yet even with substantial automation in place, there’s always an underlying desire to fully
automate everything. A complete solution for automating Windows 7 installation should
take you out of the picture entirely. That solution should be able to upgrade or refresh
computers without needing to touch them at all. This topic, the zero‐touch approach, is the
final layer that creates your complete solution. Just like each of the previous chapters,
getting there requires leaning on the infrastructure you’ve built up to this point.
There is, however, one downside: Taking that final step requires a new piece of software
that isn’t free. Getting to the complete solution, at least with today’s options, requires
assistance from Microsoft’s System Center Configuration Manager (or ConfigMgr for short).
ConfigMgr isn’t free, but it is valuable in ways that go beyond desktop deployment. If this
book’s exploration of automations for Windows installation excites you, then ConfigMgr’s
many automations for Windows management will excite you even more. It’s a fantastic
administrative tool with a long history, bringing much to the table in addition to OS
deployment.
99

Before it can deploy operating systems (OSs), ConfigMgr must be installed. Its agents must
also be distributed to your desktops. Doing so requires an exercise in design work and
more than a few initial configurations. Those initial steps by themselves are a big topic. So
in the interests of space, this chapter will assume you’ve already completed the setup
activities. If you need assistance, numerous books and guides exist that’ll get you started.
As I begin this chapter, I’ll assume you’ve already completed the installation of ConfigMgr
and have deployed its agents to the computers on your network.
Resource
ConfigMgr’s initial installation and agent deployment can be exceedingly
complex activities. If you’re looking for a little help, Alberto Ortega has
written an excellent blog post that I use when building new ConfigMgr
servers on Windows Server 2008 R2. Found at
http://blogs.southworks.net/aortega/2009/09/16/deploy‐sccm‐2007‐sp2‐
rc‐on‐windows‐server‐2008‐r2/, this post does an excellent job of
documenting the exact steps that will complete ConfigMgr’s initial
installation and agent distribution.
Stepping Back: Understanding LTI, ZTI, and UDI
Before we get started, let’s spend a minute understanding why ConfigMgr is necessary for
full automation. In short, it’s the ConfigMgr agent that’s needed. Microsoft’s acronym‐filled
MDT documentation refers to three deployment approaches. These they refer to as LTI,
ZTI, and UDI. These three acronyms reference Microsoft’s LightTouch Installation, Zero
Touch Installation, and UserDriven Installation approaches.
MDT alone supports only the LTI approach. That’s because the “Light” in Light‐Touch
Installation refers to the fact that some of its activities must be accomplished at the desktop.
You’ve seen this in previous chapters where someone at the desktop is needed to launch a
PXE boot or run the LiteTouch.vbs script.
But this chapter’s goal is full automation. Getting there means not having to physically be
present at any desktop for an installation. That said, even if it’s not you in person, kicking
off that installation requires something to exist at the desktop. That’s why ConfigMgr, and
specifically its agent, is a requirement. The ConfigMgr agent is that something at the
desktop. Being installed there, the agent is perfectly positioned to facilitate an OS upgrade
or refresh, resulting in a ZTI.
Note
Although I won’t be discussing it in this chapter, ConfigMgr is similarly well‐
positioned to handle the extra steps necessary for users to initiate their own
deployment. This approach represents Microsoft’s UDI, and is an added
capability you can layer on top of what you learn in this chapter.
100

For the ZTI installation approach to work, that ConfigMgr agent must be present at every
desktop. As you can imagine, this means that you won’t be using ZTI for fresh installs. A
fresh install starts with an empty hard drive, which means no ConfigMgr agent is present
on the machine. Thus, this chapter will focus on the processes used to upgrade an existing
machine (one that already contains an agent) as well as refreshing one with a clean OS.
Step Fourteen: ZTI with ConfigMgr
As I mentioned, getting to complete automation with Microsoft’s tools requires the
assistance of a ConfigMgr agent. Among its other tasks, this agent must be present to
receive the signal from the ConfigMgr server that an installation package has been
advertised and is ready for distribution.
I’ve built my ConfigMgr server on a new computer named \\sccm. Although I’m using a
different computer here for ConfigMgr, be aware that there are no technical limitations that
prevent you from collocating ConfigMgr with WDS and MDT. If you do intend these services
to coexist, make sure to use the full version of SQL Server and not SQL Server Express for
all your deployment services. That’s because ConfigMgr requires a full version of SQL
Server to function.
Upon completing the initial installation of ConfigMgr, my server shows a set of systems
with installed and functioning agents. I know this because the Client column in Figure 7.1
shows Yes for each of the computers shown.

Figure 7.1: Three computers, each with a ConfigMgr agent.
A few configurations must be set before you start deploying OSs. These configurations go
above and beyond the typical ConfigMgr installation. They integrate ConfigMgr with your
existing MDT infrastructure. They add a State Migration Point, which will be used in storing
user state information during upgrades. Finally, they create a folder and file share
ConfigMgr will use to store package information.
Integrating ConfigMgr with MDT
First up is integrating your ConfigMgr console with MDT. Start by installing the ConfigMgr
console to your MDT server. The console is available on the ConfigMgr media by clicking
the Install Configuration Manager 2007 SP2 link. Once launched, choose to Install or
upgrade an administrator console.
101

Without launching the console after its installation, select the Configure ConfigMgr
Integration link under Microsoft Deployment Toolkit in the Start menu. You’ll be prompted
for a Site server name and Site code. These will correspond to your ConfigMgr site and site
server. Now you can launch the ConfigMgr console, and right‐click Computer Management |
Operating System Deployment | Task Sequences. If you see a selection titled Create
Microsoft Deployment Task Sequence, you’ve got a successful integration.
Adding the State Migration Point
Your next task is to add the State Migration Point role to the ConfigMgr server. Navigate to
Site Management | <siteCode> | Site Settings | Site System, then right‐click the link for your
ConfigMgr server, and choose New Roles. You’ll be greeted with a screen that’s similar to
Figure 7.2.

Figure 7.2: New Site Role Wizard.
This first role assignment is to the ConfigMgr server itself, so you need only click Next to
continue. At the next screen (not shown) choose to add the State migration point role, and
click Next. The screen that follows (see Figure 7.3) sets the location for storing user state
information as well as settings for the deletion policy and whether to enable restore‐only
mode. Click the upper‐right yellow star, and enter a folder path to your storage location. As
you can see in Figure 7.3, I’ve chosen C:\ConfigMgrUserState as my path, and limited the
number of clients and minimum free space. Click through the wizard’s remaining pages to
finish the installation.
102

Figure 7.3: Configuring the state migration point.
Creating an OS Deployment Share
The next preparation step is easy. OS deployment with ConfigMgr requires a folder and
associated share to store package information. On my server, I created a folder called
C:\OSDPackages and shared it as \\sccm\OSDPackages with appropriate permissions. Do
the same on your server, as you’ll be adding data to subfolders of that share in a moment.
Creating a Deployment Task Sequence in ConfigMgr
Most IT professionals don’t realize that WDS and MDT aren’t even necessary to deploy OSs
with ConfigMgr. That said, there’s a reason this book delays ConfigMgr until its second‐to‐
last chapter: Getting here requires understanding the underlying infrastructure first. You’ve
developed that understanding through the previous chapters. You now know how WinPE
functions. You’ve also created at least one image that can be deployed. You’ve gathered a
list of drivers and applications that need installation with the deployment, and you’re
familiar with the complexities of user state migration.
By first knowing each of these tasks, your efforts in working with ConfigMgr are eased
because ConfigMgr itself is a complex application. It needs to be, in part because of how it
can scale from just a few computers to tens of thousands. Having built your MDT and other
infrastructures before now enables you to leverage that experience within ConfigMgr. In
fact, thanks to the MDT‐to‐ConfigMgr integration you just completed, the Create Microsoft
Deployment Task Sequence menu item is about to become your best friend.
103

Right‐click Task Sequences in ConfigMgr, and select Create Microsoft Deployment Task
Sequence. What appears is a lengthy wizard that requires numerous settings to complete.
The first time you run this wizard, you’ll be creating many of the items it asks for in its
pages. You’ll be able to reuse many of those items during subsequent uses of the wizard.
You can consider the Client Task Sequence template (see Figure 7.4) to be the core
template for many ZTI deployments. This template will scan for applications and user state,
offload user state information, rebuild the computer, reinstall applications, and ultimately
replace user state information onto the upgraded or refreshed computer. Select this
template in this screen.

Figure 7.4: Choosing a template.
In the next screen, (not shown) enter a Task Sequence name and any comments. Then fill
out the Details page with information about your domain and Windows settings (see Figure
7.5). If your organization uses volume license keys for desktops, you can enter that license
key into the provided blank.
104

Figure 7.5: Providing template details.
Figure 7.6 defines how the Task Sequence might be used. A ConfigMgr Task Sequence can
be used for deploying images or deploying and subsequently capturing an image. We
already have an image to use that was captured back in an earlier chapter, so we won’t
need to use this image for a later capture. Thus, configure the screen as you see it in Figure
7.6.

Figure 7.6: Specifying template capture settings.
105

You’ll find Microsoft’s wizard verbiage to get a little confusing in the next series of screens.
The first is seen in Figure 7.7 where the wizard asks for a boot image. Know that the boot
image used by ConfigMgr is slightly different than the one used by WDS and MDT during
previous examples.

Figure 7.7: Specifying a boot image.
This alternate boot image is configured with extra code that facilitates its integration with
ConfigMgr. Thus, you won’t be using the same boot image you used in previous chapters.
Here, select the Specify an existing boot image package option, and click Browse. Two
ConfigMgr boot images should be automatically available, one each for x86 and x64. In this
example, I’ll use the x86 boot image.
Another point of confusion with this wizard is in its next screen (see Figure 7.8) where
MDT files package information is required. This package is a collection of scripts and other
data from the MDT that is used by ConfigMgr for deploying an OS. This is a new ConfigMgr
instance as well as the first execution of the Microsoft Deployment Task Sequence, so the
MDT files package does not exist. Thus, it must be created. To do so, select the second radio
button and provide a UNC path to a subfolder of your choice within the OS deployment
package share created earlier in this chapter. For my environment, I’ll use
\\sccm\OSDPackages\MDTFiles.
106

Figure 7.8: Providing an MDT package.
This location will be populated with information from MDT after the wizard is complete
and the Task Sequence is generated. In later Task Sequences, you may simply reference an
existing ConfigMgr package through the top radio button.
In the following screen (not shown) you will be asked for name, version, language,
manufacturer, and comment information for the package that will eventually be created
that includes this data. A name is required at minimum; however, the other information
will be useful down the road for identifying the characteristics of this package. In my
environment I’ll name the package MDTFiles.
One of the biggest benefits of layering ConfigMgr atop an existing MDT instance is that
you’ve already built the OS image you intend to deploy. You’ll see multiple options in Figure
7.9 for creating or specifying the OS image to be deployed. Choosing the first option will
select an image that has already been converted into a ConfigMgr package.
107

Figure 7.9: Specifying an OS image.
You haven’t created that package yet, so choose to Create a new OS image. In doing so, enter
the path to the image’s WIM file that you created in a previous chapter. You’ll see in Figure
7.10 that I have selected Windows7_Office.wim, which is the WIM file created earlier that
currently resides on the WDS server. I’m also providing a path to new subfolder of the
ConfigMgr OS deployment package share. Doing this copies the WIM file to the new location
once the wizard is complete. It at the same time reconfigures the WIM file into a ConfigMgr
package for deployment.
In the next screen (not shown), you’ll be asked for name, version, and comment
information. As with the MDT package, enter as much detail as possible in these blanks to
assist with later identification.
Note
During later uses of this tool, you can select to Specify an existing OS image
instead. This will direct you to the list of packages currently installed on the
ConfigMgr server.
In order for ConfigMgr to manage the client after deployment, it will need to add a
ConfigMgr agent to the image as the OS is deployed. That ConfigMgr agent is part of its own
package. (Notice how everything that is to be deployed in ConfigMgr must be encapsulated
into a ConfigMgr package?) As this is a fresh installation of ConfigMgr, that Client Package
does not yet exist.
If yours does, you may choose the top radio button option in Figure 7.10, click Browse, and
locate the Client Package you’ve already created. If yours does not, select the second radio
button, and click Next to continue.
108

Figure 7.10: Determining which client package to use.
As with the other packages so far, a USMT package must also be created. This USMT
package collects the USMT code from the location in the upper path box and copies it to the
path in the lower box (see Figure 7.11). The upper path should be automatically filled in for
you as this location is supplied from the WAIK. As with the other packages, the lower path
will be a subfolder of your choice within the OS deployment package share. The screen that
follows (not shown) will ask for the usual package characteristics: name, version, language,
manufacturer, and comments.
109

Figure 7.11: Specifying a USMT package.
One final package is required for Task Sequences that deploy Windows 7 computers. This
package, called the Settings Package, includes a set of configurable settings that define how
the OS is deployed as well as the behavior of the installation. Choose at this time to create a
new one, as one has not yet been created (see Figure 7.12). Give it a subfolder path to your
OS deployment share, and (not shown) provide name, version, language, manufacturer, and
comment information.

Figure 7.12: Creating a settings package.
110

You may click through the remaining screens, choosing the defaults to complete the
Microsoft Deployment Task Sequence creation. Notice that no Sysprep package is required
because this Task Sequence deploys Windows 7, an OS that natively includes the needed
Sysprep code.
Once you’ve completed the wizard, the process to create the Task Sequence will take a
period of time. This process transfers a large quantity of data from various locations to
your OS deployment share.
Note
Once the creation is complete, spend a minute reviewing the contents of the
OS deployment share. You’ll find that a number of subfolders have been
created, with some containing information that will be used during the
installation.
This data collection is stored in file format so that it can be modified or
otherwise customized to change the behaviors of the installation or the OS
that is delivered. Although this topic is out of scope for this chapter, know
that you can edit any of the configurations found in this share to modify the
behavior of the installation. As you’ll discover later, any changes here must
be uploaded to a distribution point to be used.
Importing Drivers
ConfigMgr handles driver injection using the same plug‐and‐play approach seen with WDS
and MDT. Thus, the driver store you created during the previous chapters can be
automatically imported into ConfigMgr. Do this now by right‐clicking the Drivers node, and
choosing Import.
If you’ve been following along throughout this guide, you probably have a folder of drivers
on your WDS server in a subfolder of the C:\RemoteInstall folder. Mine is
at\\wdsserver\REMINST\Stores\Drivers. You can see in Figure 7.13 that the wizard can
interrogate drivers within a stated path and its subfolders to automatically import those
drivers into ConfigMgr.
111

Figure 7.13: Importing drivers.
Once imported, drivers can be added (not shown) to categories for filtering. This prevents
similar‐looking drivers from accidentally being installed onto incorrect equipment. It also
prevents drivers from one OS from being inadvertently added to another, which can cause
conflicts. Be particularly careful with your drivers, as driver mismatches will cause
problems with OS deployment.
Note
In fact, a driver problem that warrants additional attention is caused by
drivers used for networking. The WinPE instance used by ConfigMgr requires
a functioning network driver so that its installation can communicate with
the ConfigMgr server to download images.
If you are following along using VMware Workstation, you may have
difficulties with the VMXNET driver used by some versions of VMware
Workstation. One workaround is to alter the driver used by your Windows
XP desktops by adding the line ethernet0.virtualDev = "e1000" to your VM’s
VMX file. This line forces the virtual machine to use the more‐common Intel
e1000 NIC driver, which must be subsequently downloaded from the
Internet and installed to the Windows XP desktop.
Drivers must be added to at least one driver package and distributed to distribution points
before they can be used by computers during deployment. Figure 7.14 shows how the set of
drivers specified in Figure 7.13 have been gathered into a package and sent to the
ConfigMgr distribution points.
112

Figure 7.14: Adding drivers to packages.
The next screen (not shown) provides a location to add drivers to boot images. If candidate
desktops require non‐native drivers to boot properly into WinPE, make sure to add them to
the correct boot image or the boot and/or deployment process will fail. Click through to
finish the wizard.
Updating Distribution Points
At this point, you have the data you need to begin your first deployment. The next step is to
add each of the newly‐created packages to a ConfigMgr distribution point. This distribution
point is different than the file share in which you’ve been storing data up until now. It is the
location agents will query for package data.
Separating your working file share from the “production” distribution point allows you to
work with the data in your file share, only updating it to the distribution point when it is
ready for deployment. Distribution points are not updated through any of the previous
wizards. You’ll need to manage them separately. The process to accomplish this task is the
same for all packages. I’ll show you how to complete this step with one package, then point
you towards the series of packages that require attention.
Start by clicking the Packages node. Right‐click any of the recently‐created packages in the
middle pane, and choose Manage Distribution Points. Click Next, then choose to Copy the
package to new distribution points. Figure 7.15 shows an example of the distribution
points where package data can be uploaded. Select one, and click Next to update that
distribution point with the new software.
113

Figure 7.15: Selecting distribution points.
Note
Remember that you can at any point alter the data that is stored within your
OS deployment share; however, when you do make changes to that data, the
distribution point must always be updated with a new copy of the data. This
can be done by selecting the package, and choosing to Update distribution
points.
At this point, you can copy the remaining packages to the distribution point. This will be
the MDT Files package, Settings package, USMT package, Microsoft Configuration Manager
Client Upgrade package, Boot image package, Driver package, and the Windows7_Office
Operating System Image package.
Note
Some of these packages are not found under the Packages node. They will be
found elsewhere in the Computer Management hierarchy.
One caution is important as you update distribution points with new data. Be aware that
the process to copy packages to distribution points takes time. Although smaller packages
will be updated almost immediately, larger packages such as your OS images will take
much longer. You should not begin advertising packages until they have completed their
installation to distribution points.
114

Figure 7.16 shows how to verify installation status by navigating to System Status | Package
Status. Notice here that the Windows7_Office 1.0 en‐US package has been targeted to one
distribution point but has not completed its installation there. This Package Status view
will help you ensure that ConfigMgr has completed its transfer of data to the distribution
points prior to creating an advertisement.

Figure 7.16: Package status.
Viewing the Task Sequence and Creating the OS Deployment Advertisement
You’re nearly ready for deployment. Prior to creating the advertisement that announces
the availability of the OS upgrade, you might want to review the Task Sequence created in
the earlier step. Navigate to Task Sequences, right‐click, and choose to Edit the Task
Sequence you just created.
You’ll immediately see the incredible number of steps that are automatically generated as
part of the Task Sequence. One of those steps, the Apply Operating System Image step, is
shown in Figure 7.17. In this step, the captured image is selected to be deployed as part of
the Task Sequence.
115

Figure 7.17: Task Sequence.
You can at this point adjust any of the characteristics of this Task Sequence as well as add
steps by clicking the upper‐left Add button. By default, this Task Sequence will
automatically install the selected image to a targeted computer after gathering user state
information. It will restore that user state information to the new computer once the
installation is complete. Considering the very large number of steps and possible outcomes
that exist in this sequence, I’ll leave the exploration to you for how you will customize your
Task Sequences.
Note
Remember that ConfigMgr is an application installation solution in addition
to its job in deploying OSs. Thus, it can install applications on top of managed
systems once those applications have been packaged. That packaging process
is similar to what was discussed in Chapter 3.
You’ll notice that there is a step titled Install Software, which is one
mechanism that can be used to install packaged software during an OS
deployment.
You’re now ready to deploy an OS. Start that process by right‐clicking the Task Sequence,
and choosing Advertise. Doing so will bring forward the New Advertisement Wizard,
similar to Figure 7.18. In this wizard you’ll schedule the Task Sequence you want to deploy
and connect it to a collection of computers that will be upgraded.
That collection of computers is seen in Figure 7.18. The actual process to create and
populate collections is out of scope for this chapter; however, notice that I have created a
collection called XPtoW7 Computer that contains only my test computer.
116

Figure 7.18: New Advertisement Wizard.
All advertisements run on a schedule. Notice in Figure 7.19 that the advertisement has a
start time but is also configured with a mandatory assignment to begin as soon as possible.
In ConfigMgr parlance, “as soon as possible” can sometimes involve a large amount of time,
so be prepared for a short delay even after the advertisement is created.

Figure 7.19: Scheduling the advertisement.
117

This is a test environment, so you will also want to select the Ignore maintenance windows
when running program and Allow system restart outside maintenance windows check boxes.
Lastly, because you may rerun this package later, consider setting the Program rerun
behavior to Always rerun program. Click Next to continue.
Next up is the Distribution Points page (see Figure 7.20) with only a few settings. Set the
bottom radio button to instruct the client to gather its data directly from a distribution
point rather than downloading the content. An OS deployment will wipe a system disk; this
setting prevents the situation where downloaded data is deleted by the Task Sequence. You
may also select the two bottom check boxes to ensure that any available distribution point
is used.

Figure 7.20: Specifying distribution point settings.
The next five screens of the New Advertisement Wizard are not shown, as most
deployments use their defaults. Continue through the wizard to create the advertisement.
If you’ve done everything correctly, a balloon notice will appear on desktops after a few
minutes (but sometimes as much as an hour later) after the advertisement is created.
Clicking that balloon notice will bring forward the Program Countdown Status message
that Figure 7.21 shows. This notice alerts the users that their computers are about to be
upgraded, and provides a 5‐minute countdown timer prior to beginning the OS
deployment.
118

Figure 7.21: The Program Countdown Status balloon.
As with the MDT, a set of pre‐installation activities must occur on the client before it boots
into WinPE for the actual OS installation. Figure 7.22 shows the Installation Progress bar
that shows which steps in the Task Sequence are in progress.

Figure 7.22: The Installation Progress bar.
Once the pre‐installation activities are complete, the computer will reboot directly into
WinPE to begin the installation. ConfigMgr uses a different background screen to denote its
version of WinPE. You can see an example of that screen in Figure 7.23. If you’ve done
everything correctly, the OS will install and eventually return control back to the user with
the new OS. Viola! You’ve completed your first zero‐touch deployment of an OS!
119

Figure 7.23: The WinPE Phase.
Stepping Back: What Haven’t You Seen? What’s Left?
Getting this far with the zero‐touch deployment approach is an accomplishment all by
itself. The multitude of components required to get this far requires no small effort in
designing and integrating a range of technologies. Congratulations!
In fact, this simple example is only a small portion of what ConfigMgr brings to the table in
terms of OS deployment. This walk‐through represents barely the simplest of installation
use cases, and it is written to get you started down the path of even greater automation.
Once you understand the basics, you become well‐prepared for adding to that knowledge
with additional automations, many of which you only gain through your ConfigMgr
infrastructure.
ConfigMgr itself comes equipped with a significantly‐greater level of intelligence about the
software that is deployed and managed in your environment. However, most of its
functionality works best only when your IT processes subscribe to using it for pretty much
everything. That means coordinating the packaging efforts of your deployed software,
updates, OSs, and even desired configurations. By centralizing all facets of Windows
configuration control within a ConfigMgr infrastructure, you gain a configuration
management database that becomes useful for even greater levels of automation.
120

Consider additional capabilities that might come through centralizing control in this
manner. For example, software installation can be slipstreamed into OS deployments. As
ConfigMgr is as much a software installation solution as an OS deployment solution, it
stands to reason that any software package created for installation can be automatically
added to an image as well. Adding a bit of extra intelligence to your Task Sequences, it
becomes possible for your deployment sequences to query computers for installed
application packages with the goal of automatically reinstalling those packages after an
upgrade.
ConfigMgr also includes support for PXE booting desktops for image deployment, similar to
how WDS and MDT use the same technology. ConfigMgr includes a PXE service point role
that can handle deployment of WinPE to PXE clients for a streamlined LTI experience.
A third deployment approach is also possible with ConfigMgr that transfers control to users
entirely. The UDI approach gives individual users the ability to refresh their computers on
their own and without IT involvement. With instrumentation for reinstalling appropriate
applications and migrating user data, the UDI approach enables users to fix their own
problems without requiring intervention by IT.
The Automations Virtually Never Stop
This chapter has intended to serve as the capstone for this book’s discovery on automating
Windows deployment. However, the conversation isn’t done. The title of this book asserts
that it is a definitive guide for desktop and VDI environments, but we haven’t gotten to the
virtual world just yet—I purposely decided to hold on that discussion, giving you the
opportunity first to understand fully the Windows deployment process. With that
information firmly in hand, this book’s final chapter concludes with a look at how this
information can be directly translated into the desktop virtualization world. In the next
chapter, I’ll show you how the information you’ve learned so far will bring a significant
assist should you take the road of virtualizing your desktops.
You’ll be happy you’ve stuck around this long. The information in the last chapter is not to
be missed.
121

Chapter 8: Integrating Automated
Windows 7 Installation into VDI
Environments
When is a desktop not really a desktop? When it’s a virtual desktop, of course!
From the user’s perspective, a virtual instance of Windows 7 might look the same as a
physical instance. But you’re an IT professional. You’re aware of all the extra forces
working behind the scenes that are required to make that virtual instance happen.
Virtualization, presentation, transport protocols, automated deployment, and snapshotting
all comprise the virtual desktop administrator’s toolkit for deploying even the most basic
Windows 7 instance.
Complicating this process even more is the multitude of desktop virtualization solutions on
the market today. VMware View, Citrix XenDesktop, and Microsoft Remote Desktop
Virtualization Host represent three of the major players. They’re not the only ones.
“Smaller” alternatives like Quest, Wanova, MokaFive, NComputing, and others now release
their own solutions that create a Virtual Desktop Infrastructure or VDI.
When it comes to Windows 7 itself, however, there is good news. What you’ve learned so
far in this guide directly assists in creating virtual machines inside a VDI infrastructure,
notwithstanding which vendor writes the software. No matter whose technology connects
your users to VMs, the processes you now know for configuring Windows remain relatively
the same. That knowledge makes my life easier as this book’s author. It also makes your life
easier if you’ve been following along throughout its pages.
That’s why this chapter won’t delve too deeply into the specifics behind each VDI platform.
The exact clicks required to build a desktop template in Citrix XenDesktop are quite
different than those inside VMware View. That same series of clicks will surely change
within each product as they evolve over time. So, I’ll leave the specifics to the vendor
documentation.
Rather than focusing on the VDI products, this final chapter focuses on Windows itself. The
reason? Windows 7, as you know, is designed to be an “everything for everyone” operating
system (OS). Far from a single‐purpose OS, Windows 7 can just as easily be a home desktop
for one individual as a virtual business desktop for another. The difference is in the tuning.
122

In this chapter, I’ll share with you the high‐level process you’ll use in preparing Windows 7
for VDI deployment. As you can imagine, many of these tuning suggestions remove the
“extra” bits of Windows that contribute to its resource use. With VDI, many copies of
Windows operate simultaneously on the same server. Thus, the task of eliminating
unnecessary services and processes must be done to guarantee overall performance.
Finally, going down the virtual route adds the potential for a big win. Namely, VDI rewards
smart administration. The smarter you are in tuning your Windows instances, the better
they will perform in aggregate. The more resources you conserve inside each individual
desktop leaves more available for others. Smarter administration in VDI means squeezing
more desktops on fewer servers while still preserving each user’s experience. In the end,
with greater density, you’ll get more out of less.
Step Fifteen: Integrating MDT into VDI Deployment
With that introduction, let’s step back into Windows 7 deployment, but this time focus on
virtual deployment. We begin by bouncing back to our old friend the MDT. You might at
this point be thinking, “Wait a minute. We’re moving backwards from ConfigMgr to MDT?”
Absolutely. Although the extra functionality delivered by ConfigMgr was necessary in the
previous chapter’s zero‐touch installation scenario, you can use MDT (at no cost!) as your
customization platform for VDI deployment.
One of VDI’s biggest differences is in how the resulting WIM image ultimately gets
deployed. Thus far, the WIM files we’ve created were designed to be deployed to physical
desktops. Deploying to virtual desktops uses a different set of steps. Replacing the physical
desktop’s hard disk is a virtual hard disk. For VMware VDI, that virtual disk file is a VMDK.
Microsoft and Citrix use a VHD file. Combined with that VMDK or VHD file are others that
describe the configuration of the virtual machine itself, such as its memory configuration or
number of processors. All are necessary to describe the characteristics of the virtual
machine.
Creating a Virtual Machine and Deploying an OS
I mentioned earlier that different VDI platforms use different mechanisms for managing
their virtual machines. This chapter will attempt to stay as product‐neutral as possible, so
I’ll keep things simple by sticking with Microsoft’s Hyper‐V R2 platform. If you’re familiar
with how to create and work with virtual machines, you should be able to easily translate
what you see here into your platform of choice.
Creating a new virtual machine with Hyper‐V starts in the Hyper‐V Manager by clicking
New | Virtual Machine (see Figure 8.1). In the resulting wizard, follow through its steps to
create a new virtual machine somewhere on the Hyper‐V server. Although most VDI
deployments leverage SANs for production deployments, our interest at this point is only in
learning to deploy a WIM file’s contents to a virtual disk.
123

Figure 8.1: Creating a new virtual machine.
Windows 7 virtual machines tend not to require as much RAM as is commonly installed to
physical machines. Although Windows 7 can operate in as little as 512MB of RAM, real‐
world best practices suggest a starting point of 1536MB of RAM. One great fact about
virtual machines is that you can always adjust that quantity up or down later if you see
performance problems or unused resources.
Connect the virtual machine to an existing virtual network and create a virtual hard disk
when prompted. The final screen in the wizard (see Figure 8.2) discusses the options
available for deploying an OS to this newly‐created virtual machine. Take a look at the
radio button at the bottom of the screen that you may not have noticed before. That radio
button enables you to install an OS from a network‐based installation server.
124

Figure 8.2: Installation options.
Recall that our entire series of activities to this point has created the very network‐based
installation server this radio button references. By selecting this radio button, you are
effectively PXE booting the virtual desktop and connecting it to your WDS server to receive
an OS image.
Before booting the virtual machine, however, right‐click the powered‐down computer and
view its settings. Look for its BIOS settings, similar to what you see in Figure 8.3. You’ll see
that the virtual machine has been configured to boot from its legacy network adapter. This
legacy network adapter is a special network adapter that’s used by Hyper‐V just to get the
machine started during its initial configuration. Being “legacy,” it is by no means high
performance; however, it does include the necessary code to integrate with your WDS
server.
125

Figure 8.3: Boot from legacy network adapter.
Note
Microsoft recommends the use of the network adapter and not the legacy
network adapter when a machine (server or desktop) is in production. The
reason is that the network adapter enjoys a set of performance and other
optimizations not available on the legacy network adapter. You’ll eventually
switch to the “regular” adapter after installing Hyper‐V’s Integration
Components.
Other hypervisors use a similar series of virtual adapters and drivers. For
example, VMware View requires virtual machines to use VMware’s e1000
network card driver to connect to a WDS server, but suggests later switching
to their VMXNET3 driver once provisioned.
Connect to the virtual machine, and power it on. You should quickly spot a familiar screen
(see Figure 8.4) if the Hyper‐V host’s virtual network successfully communicates with the
WDS server. In that screen, you’ll see that the virtual machine is ready for a network
service boot. Hitting the F12 button at this point will connect the virtual machine to the
WDS server for an OS deployment.
126

Figure 8.4: PXE booting the virtual machine.
Injecting Drivers and Virtual Tools
Voila! You’re successfully deploying a Windows 7 image to a virtual machine! Not much to
it, eh? In reality, this book’s previous chapters have led you through most of the work in
automating this deployment process. If you do nothing else at this point, you have, at the
very least, created your first Windows 7 virtual machine atop Hyper‐V.
Yet, as you know, there’s always more to the story. You will need to add Hyper‐V’s drivers
and virtual machine tools to your MDT driver store. You’ve done this before with the
VMware Workstation drivers in Chapter 2. Hyper‐V’s drivers and tools are called the
Hyper‐V Integration Components and are located on any Hyper‐V server in the ISO file at
C:\Windows\System32\vmguest.ISO. Mount this ISO to a drive letter to get at its contents,
then unpack the drivers from their installation files within. Add them to MDT’s driver store
once you’ve gained access to the drivers themselves.
Note
Another common tactic to install a VDI platform’s virtual tools to desktops
uses an MDT application. You learned how to do this in Chapter 4 by creating
and deploying a silenced installation during the OS deployment process. The
only difference here is that the application being deployed is a collection of
drivers (among other software). Using an MDT application replaces some of
the need for driver injection by directly automating the installation of the VDI
platform’s virtual tools.
127

Tuning the Virtual Machine
With drivers ready to go, your next step will be to tune Windows 7 for use with VDI. These
tuning activities typically involve shutting down unnecessary services and processes with
the goal of streamlining Windows for best performance as a virtual machine.
In the early days of VDI, this process involved quite a bit of guess‐and‐check work. Today,
however, most VDI vendors have developed a set of guidance documents to assist.
Although each vendor releases its own documentation, you’ll find a fairly significant
overlap in what they suggest you should do. I’ll introduce you to three of these documents
that are available as of the time of this writing, then summarize some of what they suggest
in what remains of this chapter. Those three documents are:
• VMware View Optimization Guide for Windows 7
• Deploying Microsoft Windows 7 Virtual Desktops with VMware View
• Citrix Windows 7 Optimization Guide for Desktop Virtualization
Note
Tuning guidance is always a moving target as our industry learns new tips
and tricks. Thus, I am purposely not providing direct links to these
documents, as they will evolve over time and potentially change locations.
You should be able to search for their titles using your favorite Web browser.
Guidance for Services
Your first step in tuning Windows 7 starts by disabling the services that don’t make sense
within a VDI deployment. Unlike Windows XP, where nearly every service was enabled by
default, Windows 7 does a better job of turning on only those services that it absolutely
needs. That said, the default installation of Windows 7 still enables services that can be
safely disabled when they aren’t absolutely necessary.
Disabling these services also stops any associated processing, which has an effect on
overall VDI environment performance. Collected from the three documents listed earlier,
consider the following services as a starting list for those you might want to disable on your
VDI virtual machines:
• Background Intelligent Transfer Service (BITS). Some applications and services
require BITS for functionality; test before removing
• BitLocker Drive Encryption Service. BitLocker is not recommended for use within
many VDI architectures
• Block Level Backup Engine Service, Microsoft Software Shadow Copy Provider,
System Restore, Volume Shadow Copy Service, Windows Backup. Used for
protecting local data, which is unnecessary in a layered environment where data is
stored off the desktop and issues are most often resolved by recreating the desktop
• Desktop Window Manager Session Manager. Enables Windows Aero, which will
improve performance if disabled
128

• Disk Defragmenter. Disk defragmentation will have a significant impact on
performance; pooled desktops are typically destroyed and re‐created often enough
that fragmentation does not create significant performance issues
• Diagnostic Policy Service, Windows Error Reporting Service. Used for
troubleshooting and problem detection; less useful in a VDI environment where a
common solution is to destroy and re‐create the provisioned desktop
• Function Discovery Resource Publication. Publishes computer information on
the network, which may not be necessary for enterprise deployments
• Home Group Listener, Home Group Provider. Home groups are unnecessary in
enterprise deployments
• Indexing Service. Used for indexing local data, which is unnecessary in a layered
environment where data is stored off the desktop
• IP Helper. Disable when IPv6 is not used
• Microsoft iSCSI Initiator Service. VDI desktops typically do not use local iSCSI
disks
• Offline Files. Used for storing copies of network files, which is a use case not found
in most online VDI deployments
• Secure Socket Tunneling Protocol Service. Used for VPN connectivity, which is
not commonly a part of a VDI architecture
• Security Center. This service notifies users when security‐related configurations
are modified, which may be unnecessary in a fully‐managed VDI architecture
• SSDP Discovery, UPnP Host Service. UPnP devices are not commonly attached to
VDI virtual machines
• Superfetch. Used for caching commonly‐used applications; less useful in a VDI
environment where provisioned desktops are routinely destroyed and re‐created
• Tablet PC Input Service. Tablet PCs are not commonly attached to VDI virtual
machines
• Themes. This service adds personalization to the desktop experience but at the cost
of added resource utilization
• Windows Defender, Windows Firewall. Some environments elect not to install
anti‐malware or host‐based firewall software to VDI desktops due to their
extremely short lifespan
• Windows Media Center Receiver Service, Windows Media Center Scheduler
Service, Windows Media Player Sharing Service. Windows Media Center and
Windows Media Player are not commonly used on VDI virtual machines
• Windows Search. Used in searching for data, which is unnecessary in a layered
environment where data is stored off the desktop
129

• Windows Update. Virtual machine images are typically based on clones of a core
image; when updates are ready for deployment, typically the core image is updated
with clones regenerated thereafter; updates are typically not installed directly to
cloned images
• WLAN AutoConfig, WWAN AutoConfig. Used for wireless LAN and mobile
broadband configuration; not a common configuration with VDI virtual machines
Disabling these services can be accomplished via many mechanisms. Both Group Policy and
Local Policies are two mechanisms to control configuration while desktops are in
operation. Services can also be configured during OS installation by adding custom tasks to
an MDT task sequence. These custom tasks, in this case the Run Command Line task,
configures services by invoking the Windows sc command with appropriate options.
Service configuration obviously requires a functioning OS, thus they are typically disabled
late in the task sequence after the core installation is complete. Figure 8.5 shows how the
Run Command Line task might be added to a standard client task sequence in the MDT.
There, the task has been added to the Custom Tasks step, which itself is a component of the
State Restore step, by selecting Add | General | Run Command Line and entering the
following text into the Command line field:
sc config wuauserv start= disabled

Figure 8.5: A custom task to disable a service.
130

The contents of the Command line field in Figure 8.5 show that the sc command has been
configured to set the startup value to disabled for the wuauserv (Windows Update) service.
Similarly‐structured command lines can be used to modify the configuration of other
services.
Guidance for Additional Configurations and Scripting
Services aren’t the only configurations that require tuning. The guides noted earlier suggest
other configurations in which resource‐intensive activities such as full window dragging,
font smoothing, and cursor blink are disabled. These other configurations can be set
through registry manipulations, the use of native commands, or even Group Policy or Local
Policies. Often, Loopback Policy Processing is used to apply user‐specific settings to
organizational units (OUs) that contain the VDI desktops’ computer objects.
In the interests of space, I’ll direct you to each document rather than reprinting their
guidance here. That said, implementing some of these configurations at the time of
installation is another area where the MDT’s task sequences can assist. One way to invoke a
series of changes all at once is through the use of scripts.
Recall that the MDT’s Run Command Line task can invoke any executable or script that is
natively supported by Windows 7. This support means that batch files, VBScripts, and (with
a little extra effort) even PowerShell scripts can be used to make configuration changes.
Figure 8.6 shows a second Run Command Line task that’s been added to the Custom Scripts
step. That task runs a custom VBScript script named DisableCursorBlink.wsf by invoking
the cscript.exe script host. The contents of the VBScript itself are unimportant for this
discussion. As long as those contents correctly accomplish the task without generating an
error or prompting the user, the script will execute correctly.
131

Figure 8.6: Incorporating a script into a task sequence.
More important for this discussion is where you’ll store those scripts once created. For
scripts to be delivered and invoked on desktops during installation, they need to be stored
in the %SCRIPTROOT% folder. This folder is found on the MDT server, typically in the
\Scripts subfolder of your deployment share.
A view of the Options tab can be seen in Figure 8.7. For particularly complex scripting
needs, this tab provides a location to determine the success codes for a script as well as set
conditions for when a script must be run. The success codes 0 and 3010 are inserted by
default. A success code of 0 generally means that the script executed successfully, with a
success code of 3010 generally representing a successful execution with the need for a
reboot. Additional codes can be added in the field if your custom script is configured to
supply them as it exits.
132

Figure 8.7: Adding success codes and conditionals.
Also seen in the lower‐right of Figure 8.7 is an area where conditional statements can be
added to determine whether a script should be run. Scripts are only run when conditionals
in this box resolve to True.
Tuning Personal Desktops vs. Pooled Desktops
It is worth stating again that this configuration tuning process is important for Windows 7
to function best within your selected VDI platform. You’ll find, however, that which
configurations you’ll want to tune are impacted heavily by the methods in which Windows
7 will be deployed to users. Two common methods are through the use of what are
generally called personal desktops and pooled desktops.
Different vendors refer to personal and pooled desktops by different names. From a
general perspective, however, the personal desktops approach refers to delivering the
exact same desktop instance to each user each time. That desktop is considered the user’s
personal one with no other user having access to it. This approach is most similar to
physical desktop deployment, where a one‐to‐one mapping exists between each user and
their assigned desktop.
133

Pooled desktops are quite different. A pooled desktop is one that has been generalized and
added to a pool with others that are similarly configured. As a user logs in, that user is
assigned the next available desktop in the pool. As a result, they are never guaranteed to
get the same desktop every time, and in fact rarely do. When well‐engineered, this practice
adds a significant amount of flexibility to VDI deployments, as desktops can be easily
destroyed and re‐created when problems occur.
To enable this flexibility, pooled desktops are typically configured using a layered
approach. They also commonly make use of desktop clones, which are low‐volume
snapshots from a central, core image that contain only changes. Their core OS is installed
with very basic settings and core configurations. Applications and user state information is
then layered over the top as the desktop is provisioned to the user.
When well‐engineered and well‐optimized, pooled desktops tend to enjoy a much lower
cost of ownership than do personal desktops. Pooled desktops tend to enjoy a higher
density than personal desktops. They can be much more easily destroyed and re‐created
because they are based on clones from a core image. These tactics can significantly reduce
the storage costs associated with VDI while increasing its user density. As a result, many of
the tuning suggestions you will find tend to relate to the pooled desktop architecture. If you
intend to deploy personal desktops, you might want to enable more personalization
elements. Doing so will mean leaving a greater number of services and processes enabled.
Preparing and Templatizing the Deployed Virtual Machine
Desktops that will be used for VDI deployments are generally cloned (in pooled
environments) or directly copied (in personal environments) from the reference virtual
machine. Most VDI solutions first require converting the virtual machine into a template
prior to deployment. This conversion process is a protective measure that restricts the
virtual machine to be used only as a source for replication.
No matter which desktop approach you plan to use, reference virtual machines must be
generalized prior to replication. Depending on your VDI solution, the generalization
process will use the native SysPrep utility or a vendor‐supplied utility. Notwithstanding,
both SysPrep and the vendor‐supplied tools achieve the same goal of removing system
personality elements such as name, IP address, and SID, among others. Vendor‐supplied
tools will typically add configurations that prepare the virtual machine for VDI distribution.
134

Automating Windows 7 Installation: Start to Finish
And now we finally navigate to the end of this story. Starting with the very basics of OS
installation, you’ve now experienced the vast majority of tools and techniques that layer on
top of each other to create full automation. Yet even as this story concludes, it merely
scratches the surface of the in‐the‐field tips and tricks that other deployment pros have
learned. Regardless of whether they are specialized task sequences, scripts to add to them,
or other nifty tips and tricks, all of these further automate this process while making your
life easier.
Best of luck with your Windows 7 deployment project. With the foundations firmly
grasped, you’re well prepared to be successful in upgrading your environment to
Microsoft’s newest desktop OS.
Download Additional eBooks from Realtime Nexus!
Realtime Nexus—The Digital Library provides world‐class expert resources that IT
professionals depend on to learn about the newest technologies. If you found this eBook to
be informative, we encourage you to download more of our industry‐leading technology
eBooks and video guides at Realtime Nexus. Please visit
http://nexus.realtimepublishers.com.
135

Automating Windows 7 Installation For Desktop and VDI Environments

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Automating Windows 7 Installation For Desktop and VDI Environments

Uploaded by

Copyright:

Available Formats

Automating

amd64_Microsoft‐Windows‐ InputLocale = en‐us This item configures the

amd64_Microsoft‐Windows‐ Domain Enter the domain, username,

amd64_Microsoft‐Windows‐ DiskID = 0 This item begins working with

amd64_Microsoft‐Windows‐ Extend = true This item creates a single

amd64_Microsoft‐Windows‐ Active = true This item modifies that

amd64_Microsoft‐Windows‐ DiskID = 0 This item installs Windows to

amd64_Microsoft‐Windows‐ Filename See the note below.

amd64_Microsoft‐Windows‐Shell‐ ComputerName = Setting ComputerName to

amd64_Microsoft‐Windows‐ InputLocale = en‐us This item configures the

amd64_Microsoft‐Windows‐Shell‐ HideEULAPage = true Hides the EULA and

amd64_Microsoft‐Windows‐Shell‐ DisplayName = LocalAdmin This item adds a local

amd64_Microsoft‐Windows‐Shell‐ Value = {Password} This item configures the

You might also like