Deploying Windows 7 With MDT 2010

Aidan Finn
02 September 2009
http://joeelway.spaces.live.com
How to use Microsoft Deployment Toolkit to Deploy Operating Systems
This document and parts thereof are the sole property of Aidan Finn and may not be copied, reproduced, shared or
distributed in any shape or form, physical or digital, without the sole and express permission of Aidan Finn.
Table of Contents
Introduction ............................................................................................................................................ 4
My Lab Environment ............................................................................................................................... 6
Pre-Requisites ......................................................................................................................................... 7
How Windows Installation Works........................................................................................................... 8
Installing MDT 2010 ................................................................................................................................ 9
Have a Look Around .............................................................................................................................. 12
Create the First Deployment Share....................................................................................................... 14
Default Installation of Windows 7 ........................................................................................................ 21
Import the Operating System Image ................................................................................................ 21
Import the Drivers............................................................................................................................. 26
Import Packages................................................................................................................................ 29
Set Up the Task Sequence................................................................................................................. 32
Customise the Task Sequence........................................................................................................... 38
Final Steps for Deployment............................................................................................................... 45
Perform a Clean Installation of Windows 7 ...................................................................................... 50
Wrapping Up the Clean Installation .................................................................................................. 55
Creating a Custom Image ...................................................................................................................... 56
Deploy the Template Operating System ........................................................................................... 56
Create a Capture Task Sequence ...................................................................................................... 56
Prepare the Template Machine ........................................................................................................ 59
Run the Capture Task Sequence ....................................................................................................... 60
Deploying a Complete Image in Production ......................................................................................... 65
Create a Dedicated OS Deployment Share ....................................................................................... 65
Add the Image(s) To Deploy.............................................................................................................. 66
Add the Drivers ................................................................................................................................. 68
Create a Deployment Task ................................................................................................................ 68
The Deployment Share Rules ............................................................................................................ 69
Configure a User State Share ............................................................................................................ 70
Update the Deployment Share ......................................................................................................... 71
Run the Task Sequence to Upgrade an XP PC ................................................................................... 71
WDS: An Alternative Way to Access Boot Images ................................................................................ 75
Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 2

Summary ............................................................................................................................................... 76

Introduction
I’ve been doing operating system deployment of one form of another since 1998 when I first started
using Ghost to clone NT 4.0 workstations. I’ve used a variety of tools since then including a custom
routine to deploy NT 4.0 using Novadigm EDM, Windows 2000/2003 Remote Installation Services
(RIS), ImageX from Windows Automated Installation Kit and Windows Deployment Services (WDS).
As time has gone by there have been some changes.
Operating System (OS) deployment had always been a form of IT black magic. I can’t be certain why.
I know that documentation used to be non-existent or incomprehensible. If you downloaded
Microsoft Business Desktop Deployment accelerator you installed it, ran it, tried to use it, scratched
your head wondering what you were doing wrong, followed a rats nest of hyperlinks and quickly
gave up. Microsoft just seemed to be unable to clearly communicate how to efficiently deploy
operating systems. Most organisations only create a new standard operating system build once
every few years. There are plenty of organisations that deployed XP back in 2002-2003 and have no
plans to change their standard soon. That means their engineers never develop OS deployment
skills. If a change is needed then consultants or contractors are brought in and they do the
engineering, leaving a set of operations guides behind. There’s a set of people out there who either
don’t have time to learn the skills (I can sympathise!). But worse, I think there’s also a set of people
who really don’t care; they’ll do the sneaker-net thing quite “happily” or continue to (probably)
illegally use Ghost to deploy operating systems – Hey! You actually need to buy a Ghost license for
each machine built with Ghost and an auditor really can detect a fingerprint on the hard disk of
“ghosted” workstations.
Microsoft did attempt to simplify things. Documentation has improved but it’s still not there yet as
can be seen in the MDT documentation where there are gaps and misleading instructions. The tools
have gotten better too. Adding drivers to the pre-installation phase of RIS was a nightmare to figure
out. It got better with the “Panther” based installation tools that were released with Vista and
Server 2008. That involved using Microsoft’s WAIK to build a Windows PE image (your boot up
media) and add drivers into that using command line tools. The current generation of tools allow
you to build libraries of drivers and add them via a GUI.
This document is going to focus on Microsoft Deployment Toolkit (MDT) 2010. I’ll be looking at
deploying Windows 7 seeing as that’s the new desktop operating system from Microsoft. Everything
we look at here will be possible with Windows Vista, Windows Server 2008 and Windows Server
2008 R2. They all share the same basic installation functionality. MDT is going to be the tool you’ll
be most often recommended to use for deploying Windows 7. Why? There are a lot of reasons:
 It’s 100% free.

 It allows you to do light-touch clean installations of and upgrades to Windows 7.
 It uses task sequences to perform the installs. These are a sequence of instructions that can
include other tasks.
 Using task sequences you can add drivers, patches and applications to you Windows 7 PC’s,
enable BitLocker, etc.

 The task sequences are 100% customisable. You can do anything that you can do from
command line or from a script. Many of the default actions are VBS scripts.
 You cannot upgrade from XP to Windows 7. That’ll be a problem for those who have data
on their PC’s. Using task sequences and the User Migration Toolkit you can capture the user
state of the PC, put a clean install of Windows 7 on the machine and restore the user state,
effectively performing an upgrade.
 It’s very lightweight, e.g. my labs have been machines with 512MB of RAM. MDT is really a
glorified file share/set of file shares. Consultants/contractors could create a virtual machine
and transport their VHD/VMDK to customer sites to do their work. The great thing about
VHD/VMDK is that it can be copied. Over time you’ll build up a library of drivers and task
sequences that you can reuse again and again.
Here’s what I’m going to try cover in this document. We’ll install MDT 2010. We’ll get to the point
where we can deploy a standard installation of Windows 7, capture a customised template image
and be able to deploy an “upgrade” from Windows XP using a user state capture/restore. I’ll add in
a few tricks to make things easier. I’ll show you how to create a light touch installation requiring
minimal interaction and how to dispense with the need to create bootable USB/DVD media to boot
up machines for the deployment process. My lab will be running on VMware Workstation so you’ll
see how I added drivers for it. The process is pretty similar on Hyper-V (which I have also done
previously).
Disclaimer: I won’t claim to be a deployment guru. There’s other people out there who know this
stuff better than I do. But I can show you how to get started with MDT and how to deploy Windows
7 with it.
I’m using the current (at the time of writing) release candidate (RC) of MDT 2010 so some things may
change by the time you read this.

My Lab Environment
I’m using 4 machines in my lab.
Domain Controller
DNS
DHCP MDT Server
PC1 PC2
Blank Windows XP
I’m using VMware Workstation 6.5.3 on a Windows 7 laptop. Using virtualisation is great for
test/development because you can snapshot the virtual machine (VM) and return to that snapshot
whenever you want. Each of the VM’s is configured with 512MB RAM and a 40GB C drive,
dynamically expanding. Here’s the custom information for each machine:
 The domain controller is running Windows Server 2008 R2. It’s also configured to run DNS
and DHCP for the subnet. DHCP is required for the subnet when you will be booting up
machines to do a clean installation. I’ve called this machine DC1.
 The MDT server is also running Windows Server 2008 R2. It is set up with a D: drive to store
all of my data on. That’s 60GB in size. It’s a member of the domain. The computer name is
MDT1.
 I have a blank PC, all ready to do some testing on.
 Finally I have a XP machine set up. It has data on the desktop and in My Documents as well
as a collection of IE favourites. I have made a snapshot of this VM in this state.
You can build up something similar using your favoured virtualisation system of choice. I’ve happily
done this on Windows Server 2008 R2 Hyper-V and Virtual Machine Manager 2008 R2 using the lab
server at work. I used a free ISO creation tool to get installers into my private VM lab on the Hyper-V
host. However I’m using VMware Workstation for this document because it’s suitable for my laptop,
has superior networking/snapshots to MS Virtual PC and because I can easily access the host hard
disk using shared folders.

Pre-Requisites
These are pretty simple.
 You will need DHCP on any network that you will do clean installations on.
 You need to download and install the mammoth Windows Automated Installation Kit (WAIK)
on the MDT server. I won’t put a URL here because it’s frequently updated. Beware
because it is around 1.6GB now.
 The media for deploying your operating system. I’m deploying Windows 7 Professional x86.
 The drivers for your target machines.
Get all of those and have the installers ready for your MDT server. Speaking of which, what are its
requirements? During the release candidate stage of MDT 2010 we only have the MDT 2008
requirements:
 Processor running at 1.4 gigahertz (GHz) or faster.

 512 megabytes (MB) or greater physical memory.
 One disk partition that has 15 gigabytes (GB) or more available disk space and that will
become the drive C partition.
 One CD-ROM or DVD-ROM drive that will be assigned the drive letter D.
 If using an x64 operating system then you should use an x64 edition of MDT 2010.

How Windows Installation Works
The old SETUP.EXE and CAB/compressed file approach to Windows installation is long dead. It’s
consigned to the legacy operating systems like NT, 2000 and XP. For a comparison, go install
Windows XP side-by-side with Windows Vista/7. XP started up with a DOS interface. Once you
formatted the disk it went through a file copy. Vista introduced us to codename Panther. Microsoft
started using an image stored in a WIM file. Yes, an image like Ghost uses images. But instead of
being sector (bits’n’bytes) based like Ghost, Microsoft’s WIM images are much cleverer:
 Being file based allows them to have single instance storage. That means when multiple
identical files are to be stored in the image they are stored once and multiple references are
made to that single stored file.
 Multiple images can be stored in a single WIM file. You’d think the image could get huge but
single instance storage sorts that out. For example, how much difference is there really
between Windows 7 Home and Windows 7 Professional? Not much really and that’s why
you’ll find both of them in the same WIM file.
An installation of Windows no longer boots up into DOS. It boots up into a specialised, trimmed
down version of Windows. This is called Windows PE (Pre-installation Environment). This extracts
the required image and copies the files to the hard disk. You can use Microsoft’s tools to sysprep a
configure PC and create your own WIM file. SYSPREP.EXE is a tool that is used to generalise or strip
the Security Identifier (SID) related security/identitiy information from a PC to make it suitable for
cloning. It is the only MS supported way to clone a machine. Using NewSID or other 3rd party tools
is not supported in production.
If you start looking at using WAIK’s Windows System Image Manager (WSIM) then you should learn
about the 7 passes of a Windows Installation.

Installing MDT 2010
This is a pretty simple process but we’ll go through it anyway. I’m assuming you have already
installed WAIK on the server. I’m not documenting WAIK here. The only tip I have is install it into
C:\WAIK instead of the default folder. Advanced usage of WAIK requires command prompt work
and the shorter path will come in handy!
During the RC stage of MDT 2010 we have an MSI for the installation. I’ve double clicked on that to
start the install.
This one is simple enough. Click on <Next> to get going.
Read through the End User License Agreement. If you’re OK with it then select “I accept ...” and click
on <Next>. Otherwise click on <Cancel> and abort the installation. You’ll want to stop reading now
if that’s what you decided!

Select where you want to install WAIK. The default location seems logical enough to me.
Clicking on <Install> will start the installation. This is your last chance to abort.
The install will progress. It’s a tiny package and only takes a few seconds; blink and you’ll miss it.

That’s it. MDT is installed. You can verify this by checking the Start Menu.
That’s where you’ll find the Deployment Workbench or Workbench from now on. There are
shortcuts to documentation there too.

Have a Look Around
Start up the Workbench. That’s the main management tool for MDT 2010. You’ll be getting to know
this tool pretty well.
You probably already know this but here are the basics of an MMC 3.0 console. The left pane is used
for navigation. The centre pane shows the contents of the selected navigation point. The right pane
displays context sensitive actions for the contents pane or whatever item is selected. The menu at
the top left allows you to perform certain actions too.
A few years ago Microsoft got bad feedback on their documentation for their deployment solutions.
In my opinion it was justified. You can see here that they’ve responded. Open up the Information
Center in the navigation pane.

You can see that there are 4 shortcuts to various types of documentation here. Clicking on
<Documentation> will open up a help file. It contains a lot of instructions for using MDT 2010.
Much of what I’ll show you here comes from that help file.
MDT uses Deployment Shares to share/capture images, scripts, applications, drivers and task
sequences. It’s a pretty simple way to do things. All the configurations you do within a deployment
share are stored within XML files. It’s a self-contained store, easy to backup and configure, maybe
even replicate?
I haven’t tried this yet but I’m wondering if it might be possible to replicate these deployment shares
between sites using DFS Replication. Then you could manage your build process in a central site and
efficiently replicate that to all locations in the organisation.

Create the First Deployment Share
We need to create our first deployment share. Yes, “first” because a MDT server can have many
deployment shares. Select <Deployment Shares> and click on <New Deployment Share> in the
Actions pane.
As I said earlier, I’m using a D drive on my MDT server for my data. I’ve created the above folder in
Windows Explorer and changed the default drive from C:\ to D:\.
The MDT wizard will share the folder for us. That’s handy. Notice that it’s a hidden share? I
recommend leaving it that way.
Note that you should modify the permissions of this share if you don’t want ordinary users on the
network to access it. By default, Authenticated Users from the domain will be granted permissions.
This could be bad if you’re doing test and development work on this share.

The description is “MDT Deployment Share” by default. I’m changing that to match the names
we’ve used up to now. You’ll see why when we move on to creating a Light Touch installation near
the end of the document.
We now move on to configuring how this deployment share will behave. Each deployment share
you create has its own rules. These are stored in a file called CUSTOMSETTINGS.INI and are
accessible via the MMC console. The rules are specific to the share.
The description associated with this question doesn’t really explain the implication of your answer.
Do you want users to be asked if an image should be captured? When I first installed MDT I thought
“No I don’t. Why should users capture an image of their PC?” The downside to that answer was
that I could no longer use this deployment share to create template images. The rule prevented me

from selecting this option in the MDT wizard on a PC. Of course, I could change this afterwards by
modifying the deployment share rules. If you want to use this deployment share to create template
images then leave it ticked. If you’re following me in this example, leave it ticked. If you’re creating
a deployment share that will only ever be used to deploy operating systems then you’ll probably
want to disable this option.
Most managed networks will stick with this default answer. We don’t want our users to know the
local administrator password. We’ll configure this one for ourselves. However, unmanaged
networks will tick this option.
If you’re using a volume license key then you won’t share it with users and won’t ask them to enter
it. The default answer (un-ticked) will be sufficient. I don’t have an OEM media kit so I don’t know if

you can use it with MDT. If you could then you would need the user to enter the product key that is
on the box ... noting that you only get so many activations before you have to call the Microsoft
clearing house on the phone.
We’re at the end of the wizard. Click on <Next> to start the creation of the deployment share using
the options you have entered.
The share is created for you and the folder is populated.

This is your summary of everything that you have done.
Add-PSSnapIn Microsoft.BDD.PSSnapIn
new-PSDrive -Name "DS001" -PSProvider "MDTProvider" -Root "D:\DeploymentShare" -Description "Deployment Share" –
NetworkPath "\\MDT1\DeploymentShare$" -Verbose | add-MDTPersistentDrive -Verbose
Welcome to the world of PowerShell. Everything you just configured was done using two
PowerShell cmdlets. Clicking on <View Script> in the above dialog opens up Notepad and shows you
what was executed. You can save that for future reuse.
When you return to the Workbench you’ll see that the deployment share was created. It contains
folders. These folders all make sense when you think about the requirements of deploying an
operating system with MDT. We have locations for:
 Applications to install
 Operating systems to capture and deploy
 Drivers

 Packages or updates/patches
 Task sequences
 Advanced configuration which speaks for itself.
If you open up Windows Explorer you’ll see what the storage is like behind the scenes.
This “Control” folder inside of the deployment share contains a whole bunch of XML files. These
files contain the configuration of the deployment share and its contents. Remember those rules I
mentioned? They’re contained in CUSTOMSETTINGS.INI:

Default Installation of Windows 7
I’m going to do an installation of Windows 7 using the WIM file (INSTALL.WIM) that Microsoft
provide on their media in the \Sources folder. We can then customise that image, capture it as a
WIM file and deploy that image to our users.
Import the Operating System Image

Get your Windows 7 DVD and insert it into the drive of the MDT server. I’m using a virtual machine
so I’ll mount the ISO image. Alternatively you can have copied the entire (I stress “entire”) DVD onto
a folder on the machine. We need to import the entire DVD of the operating system we wish to
deploy.
Browse to <Operating Systems> in your deployment share in the navigation pane. Click on <New
Folder> in the actions pane.
I’m going to use this folder to store my Windows 7 x86 images from the installation media. I’ll use
the name “Windows 7 x86” for the folder.

Click on <Next> to create the folder.
The folder is created and here’s the PowerShell that was used to do it:
New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "D:\DeploymentShare"
new-item -path "DS001:\Operating Systems" -enable "True" -Name "Windows 7 x86" -Comments "" -ItemType "folder" –
Verbose
Select the new folder and follow this by clicking on <Import Operating System> in the actions pane.

You have three options here:
1. Full set of source files: This is what we’ll be doing. This will suck in an entire DVD or folder
that contains the contents of a DVD.
2. Custom image file: This is a WIM file that you have previously captured from a sysprepped
template computer.
3. Windows Deployment Services images: This allows you to connect to a WDS server and suck
in the images that it is sharing.
Pick “Full set of source files” and click on <Next>.
This dialog allows you to specify the location of the operating system media. I’ve entered the drive
letter of my DVD drive. You see that tick box? If you have copied the media onto your server
already then you can tick that box to move the files rather than copy them. This is quicker if that
folder is on the same logical volume (same drive letter) as the deployment share.

A folder will be created in our deployment share with the above name to contain the copied media.
Click on <Next> to go ahead with the import or <Cancel> to terminate the process before doing
anything.

I’ve gotten used to this part of OS deployment work, often referred to as “progress bar engineering”.
This is the first of several opportunities to go take a break, get some coffee, go for a walk, check your
Twitter or read your email. This import may take a wee while, around 5 minutes on my VM.
The copy eventually finishes and we can see the produced PowerShell cmdlets:
import-mdtoperatingsystem -path "DS001:\Operating Systems\Windows 7 x86" -SourcePath "E:\" -DestinationFolder

"Windows 7 x86" -Verbose

And there are our operating system editions. This is proof of Microsoft keeping many images in a
single WIM file. You can see all 5 editions that are available to volume licensing/retail without
Software Assurance.
Finally, here’s where the files were copied to in the deployment share.
Import the Drivers

MDT makes things pretty easy when it comes to importing drivers for your PC’s or servers that your
going to deploy operating systems to or capture images from. Previous generations of deployment
tools required you to get to know nasty command line tools. RIS required you to modify driver INF
files! MDT allows you to import your drivers and it will then inject them where necessary. That is
very cool.
What you need to do is extract those files. So that means if your driver comes in the form of a
SETUP.EXE you need to extract it so you have the INF, and SYS files (and whatever else). In the case
of a virtualisation solution like those from VMware or Microsoft you need to mount the “Additions”
or “Integration Components” ISO images and take the drivers out. In the case of Hyper-V it’s a CAB

file containing a bunch of drivers most important being one for networking. In the case of VMware
Workstation it was also a CAB file for the storage driver.
Networking drivers are the most important ones here. The OS deployment process will be booting
up into a Windows PE boot image. This requires network access to access the shared folder, i.e. the
deployment share, on the MDR server with the scripts, drivers, task sequences, images, etc. That’s
also why we need DHCP: the Windows PE image needs to be supplied with an IP address.
I like to keep these things pretty organised. The driver for a Broadcom NIC from HP will be slightly
different to the driver for an apparently identical NIC used by Dell. But sometimes the OEM’s tweak
the chipsets and the drivers. So it seems to me that it makes sense to organise your driver library
using folders. I have gone ahead and created a folder for my VMware Workstation 6.5.3 drivers.
Now I will import the drivers by clicking on <Import Drivers> while being inside that folder.
I’ve entered the path to the folder containing my drivers. You can force the drivers to be copied
even if duplicated already exist.

Click on <Next> to continue or <Cancel> to abort.
The drivers are imported and this is the PowerShell script that used to do it:
import-mdtdriver -path "DS001:\Out-of-Box Drivers\VMware Workstation 6.5.3" -SourcePath "D:\Drivers\VMware

Workstation 6.5.3" -Verbose

I only have 1 driver to add and my VM’s won’t even use it. It’s a SCSI driver and my PC VM’s use IDE
storage. However, anyone doing this with post Windows 7 hardware or Hyper-V will see much more
in here.
This is where my driver was copied into.
Import Packages
Part of the power of MDT is the ability to drop applications into your deployed PC’s as part of the OS
installation. They don’t have to be a part of the WIM file; instead you just add them to MDT as
vendors publish them.
Windows 7 has an application compatibility solution called XP mode. It uses a new version of
Microsoft’s desktop virtualisation product called Virtual PC. I’ve talked about these on my blog at
http://tinyurl.com/afinnxpmode. The final edition not released at the time of writing this document
so I won’t put a URL here.
Many businesses will want to deploy this product for application compatibility reasons. It makes
sense then to include it with the OS deployment. We can do this thanks to MDT as long as the

application is contained within a .CAB or .MSU file. Yes, this can include service packs and
security/bug-fix patches. You need to store the files in a folder that is accessible to the MDT server.
I have created a folder called “Microsoft Virtualisation”. This is where I am going to import the MSU
file for Virtual PC. I navigated into the folder and then clicked on <Import OS Packages> in the
actions pane.
My “applications” (isn’t that a bad name and wouldn’t updates be better?) are stored in
D:\Applications. I have the MSU file for the Virtual PC client in there. This wizard will search for all
.CAB and .MSU files in the folder and import them if they are suitable.

This is your last chance to stop the process. Clicking on <Next> will start the search and import
process.
The update is discovered and imported. The PowerShell cmdlets were as follows:
import-mdtpackage -path "DS001:\Packages\Microsoft Virtualisation" -SourcePath "D:\Applications" -Verbose

Here’s the imported update:

The folder structure looks like this:
You’ll need to make sure that your rules for the deployment share will allow application installation.
By default this is what is set in CUSTOMSETTINGS.INI:
SkipAppsOnUpgrade=YES
You may need to change that to the below during upgrades, depending on your circumstances:
SkipAppsOnUpgrade=NO
In my network, upgrades from XP will likely want to take advantage of Virtual PC to use XP mode for
application compatibility.
Set Up the Task Sequence

Now we get to the fun part MDT. This is where everything is tied together and where the power is.
What you’re doing here is using a GUI to create a script of sorts. Each step will run in a specific
order. There’s even some basic decision making going on. I’m going to use one of the included
templates to deploy Windows 7 Professional. I’ll be doing the most basic of customisations. You’ll
see that there two types of step in the sequence:

 Predefined: These are specialised operations such as install an operating system or reboot.
 Command line: This is anything that can be done from the command prompt. Microsoft
uses this to run some VBS scripts from the deployment share.
You can always add your own steps, remove steps, disable steps or customise them. You can even
build your own custom task sequence. I’ll leave that advanced operation to people more
experienced than myself with the ways of MDT.
I’ve browsed into <Task Sequences> and clicked on <New Task Sequence> in the actions pane.
There’s 3 pieces of information we can add in here:
1. Task sequence ID: This is very important. Get this right. If you get it wrong it is very hard to
change. It will be what is seen by users in the MDT client wizard. This must be unique in the
deployment share.
2. Task Sequence Name: I like to give it a brief descriptive name. This is what is displayed when
choosing which task sequence to run.
3. Comments: Put as much information as you can in here. Treat it like a form of
documentation. It is not mandatory.

This drop-down list box shows the templates that Microsoft includes with MDT. You must select
one. The default “Standard Client Task Sequence” is the one we’ll use. It is really powerful. It can
be used to do both a clean installation of Windows and to do the following with an existing install:
 Capture the user state of the PC and store it on a network drive.

 Wipe the hard disk and install another operating system.
 Restore the user state as it previously was.
That’s what you’ll likely want to do with XP users who don’t have roaming profiles or redirected
folders.
The next dialog asks you to pick an operating system to install as a part of the sequence. I’ve
browsed to and selected the imported “Windows 7 Professional” image.

This is where you enter the product key that is suitable for your image. I’m using a TechNet license
for this which would be considered a retail license or a volume license. These are entered in the last
option. Anyone using MAK (LAN activated) product keys should use the second option. Getting
these wrong causes the task sequence to fail with an indecipherable error – which caused me hours
of “fun”.
You’ll understand if I don’t illustrate my product key here 
Here you enter the organisational information that the Windows installer expects. You can also
enter a default home page for Internet Explorer. I strongly recommend
http://joeelway.spaces.live.com.

This dialog will set the local administrator password. Make sure it meets the default complexity
requirements of Windows 7 or whatever OS you are deploying with this sequence. That’s the last of
the configurations in this wizard.
Here’s the last chance to go back to make changes, abort or proceed with creating the sequence.

The task sequence is created and this is the PowerShell script that was used:
import-mdttasksequence -path "DS001:\Task Sequences" -Name "Deploy Windows 7 Professional x86" -Template
"Client.xml" -Comments "This will deploy the default Microsoft image of Windows 7 Profesional x86" -ID
"DepWin7ProX86" -Version "1.0" -OperatingSystemPath "DS001:\Operating Systems\Windows 7 x86\Windows 7
PROFESSIONAL in Windows 7 x86 install.wim" -FullName "AFinn" -OrgName "AFinn" -HomePage
"http://joeelway.spaces.live.com" -ProductKey "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" -AdminPassword
"Password00" -Verbose
I have changed the product key.
In the deployment share a few things happen.

A folder is created in the “Control” folder. It is named after the Task Sequence ID. This contains two
XML files that contain the operations in the task sequence. A line is added to TASKSEQUENCES.XML
in the “Control” folder for the new task sequence.
You could go ahead and use this task sequence now but we should have a peek inside and see if we
should make some changes or not.
Customise the Task Sequence

We can open the properties of a Task Sequence to make changes. Of course, if you’re adventurous
you could just open up those XML files and edit them instead. I won’t be doing that, though 

Here you can see the task sequence ID is read only. You can modify the name and comments can be
edited. There are a few more things in here:
 Version: You should implement version control as soon as possible to keep track of changes.
 By default this task sequence can run on any client platform. You can control what
platforms it can run on if there are OS specific steps in it.
 The Deployment Wizard is what will run on the client machine. You can hide the task
sequence in the wizard.
 You can also disable/enable the task sequence.

The final tab (we’ll come back to the second one in a few seconds) gives us a little information about
the operating system we’re installing. We can also edit the UNATTEND.XML using Windows System
Image Manager from Windows Automated Installation Kit. That will open the image and allow you
to customise the installation. That’s outside the scope of this document – I’ve written a section
about it in the new Sybex book on Mastering Windows Server 2008 R2. Now on to the fun bit.
In the left pane we see groups (folders). Inside of them are the sequence steps. The run in order
from top to bottom. On the right we see the properties of what we select.
You can add/remove task steps and groups and change their order by using the controls on the top
left.

The Deployment Wizard will be asking if you want to do a clean installation (Non-Upgrade) or an
upgrade (Refresh only). You can see above that there is some decision making going on.
Check out those actions called “Capture User State” and “Capture Groups”. They will capture
information from an existing computer and save it to a network drive.
The illustrated “Refresh Only” group will run during an upgrade. It will download the Windows PE
boot image from the deployment share.
You can see that there is a “Backup” task in the “Refresh Only” group. In the case of an upgrade this
sequence wants to capture an image of the PC being upgraded and store it on the deployment
share. Normally I would disable this step. I’ve selected the step, clicked on the “Options” tab in the
properties and ticked the “Disable this step” tick box.
You know when I definitely would use this step? I’d use it for upgrading the computer of my boss
and those of the directors. That would give me a way to recover their machines if something went
wrong.

I’ve opened the properties of one of the “Run Command Line” tasks. You can see that it is running a
command line operation. It’s a VBS script using CSCRIPT.EXE. You can run anything that you can run
on Windows PE or is accessible on the network. Note at the bottom that you can use a use account,
e.g. “mdt-domain\administrator”, to run the operation. You might do this if the step required access
to a secure file share.
Here’s the most important of the predefined steps. This one will install your operating system. You
can change the image being deployed by clicking on <Browse>. You can change the target disk and
partition at the bottom. The default options for that are usually fine.

This task sequence has only started at this point. It doesn’t just finish up with deploying the OS.
Afterwards we can see things like the drivers being injected. Yes, the drivers in our driver store will
be downloaded and made available to Plug and Play.
A little later in the sequence there is an “Install Applications” step. That will apply the updates that
we imported into the deployment share.
I’m disabling the “Enable BitLocker” step. It’s irrelevant for a deployment that isn’t using Windows
Ultimate or Windows Enterprise editions because they’re the only editions with the BitLocker
feature. Even then you need to be sure if this is how you want to deploy BitLocker. It does you the
advanced options, e.g. where to store the recovery key and how to configure BitLocker. I think I
would deploy BitLocker this way.
Finally the task sequence will attempt to recover the captured state information that was stored on
a network drive in the upgrade scenario.
Here’s a high level flow chart of how the task sequence will now run:

Start task
sequence
Upgrade or
Upgrade
clean install?
Capture state Clean

information Installation
Wipe hard disk

and format
Install operating
system
Inject drivers
Install applications
Recover state
information
End
It can be started in one of two ways:
1. In an upgrade scenario you log into the machine to be upgraded and run the Deployment
Wizard.

2. In a clean installation scenario you boot up the machine with a boot image and then the
Deployment Wizard starts up automatically.
We’re now at a stage to wrap up our configuration.
Final Steps for Deployment

I’ve talked about the rules of the deployment share. It’s time to go look a bit more at the
deployment share. Select the deployment share in the Workbench, right-click on it and select
“Properties”.
You can see the general configuration information of the deployment share. We can control what
architectures are supported, i.e. x86 and x64, by the share. Finally, we can enable multicast for OS
deployments. This requires that the MDT server is running Windows Deployment Services (WDS),
specifically the Transport role service.
We’ll skip to the “Windows PS x86 Settings” tab and come back to “Rules” in a moment.

This dialog allows you to control how the boot image (Windows PE) will be created for deploying
your operating systems.
Near the bottom you can change the default background. You’ll use this to brand the Windows PE
image as it appears on screen. That’ll impress some people even though it’s a pretty simple thing to
do. Remember that you need to recreate the boot image after modifying this.
The x64 dialog will do the same things for managing the creation of the x64 boot image.
The “Components” tabs allow you to control what is included from your deployment share when
building the deployment share. By default it includes “All Drivers and Packages”. That’s not always
suitable. I’m changing this to “All Drivers”.

Beneath there you can include:
 All network drivers: On by default. We’ll almost (if not always) exclusively need this on.
 All mass storage drivers: On by default. We’ll almost (if not always) exclusively need this on.
 All video drivers: Off by default.
 All system class drivers: Off by default.
Those international organisations out there will want to install the optional Asian fonts for localised
interfaces.
The “Rules” tab allows you to define the rules for the deployment share. Remember that I talked
about allowing applications to install during an upgrade? I’ve highlighted where I changed “YES” to
“NO” (to stop it skipping this step).
The rules are like an unattended answer script for the Deployment Wizard. There is a syntax for the
language/commands used. There are examples in the MDT documentation.
Clicking on <Edit Bootstrap.ini> will open Notepad.
The “DeployRoot” option will configure the deployment share to use during OS deployment.

The final thing we need to do now is to update the deployment share. This will create the boot
images that we will use to boot up machines. Wrap up the properties of the deployment share,
return to the Workbench, select the share and click on <Update Deployment Share>.
Normally the process just reuses existing boot/Windows PE images. It can completely recreate them
or you can compress the existing ones. They’ll tend to bloat with wasted space if you tweak them a
lot.
This is your last chance to cancel. The process takes a few minutes so it’s a chance to take another
break. Boot images that will run Windows PE will be created for the x86 and x64 architectures.

The process took around 5 minutes on my VM. You can click on <View Script> to see the PowerShell
cmdlets that were used:
update-MDTDeploymentShare -path "DS001:" -Verbose
That process created WIM files and ISO files for your 2 boot images. You can use the ISO’s for VM’s
or burn them to DVD. Alternatively you can use the WIM files as follows:
 Load them onto a WDS server: we’ll look at that later.

 Use WAIK to make further customisations that MDT can’t.

Perform a Clean Installation of Windows 7
You’re now ready to test this out. I’m copying the x86 ISO to my host (my laptop). I’m modifying the
properties of the PC1 VM so that its DVD mounts the ISO image. I’ll boot the VM up with the DVD
drive.
Windows PE will start to boot up. You can see how similar it is to Windows 7. It is a trimmed down
version of Windows, after all.
This is the start-up screen. We’ll start the Deployment Wizard. Click on the menu item for it.
You need to log in to connect to the deployment share. I’m logging into my “mdt” domain. That will
connect to the deployment share and start up the Deployment Wizard.

The task sequences on the deployment share are listed. I have selected my task sequence. You see
how descriptive it is? That’s why I took care with the name and comments when I created the task
sequence.
This is where we specify the computer name for the new machine. I’m calling it “PC1”.
You can join the new computer to a domain. You can even specify the OU to create the computer
account in. I plan on creating an image from this machine for future deployments. Microsoft
recommends that such machines should never be domain members.

In this scenario (booting up from a boot image to do a clean install) this screen is irrelevant. I have
no user state to backup. Anyway, you must be logged into the machine to capture a user state.
This is where we can specify the regional settings of the computer. Have you non-Americans ever
noticed before that you always have “English-United States” on your unattended installs even
though you don’t want it? Microsoft, an American company, uses that region as a parent for all
other English languages by the looks of it. We must use “English (United States)” as the installation
language in the RC of MDT. I’ve seen something similar with the finished versions of WAIK. It’s very
annoying and it’s always been like that.

Now we can set the time zone. Unusually, GMT isn’t in the middle; it’s at the top.
This is another irrelevant step at this stage. We don’t have an operating system yet so we can skip it.
This is the last screen in the Deployment Wizard. Clicking on <Begin> will hopefully install an
operating system using the image we selected earlier in the MDT Workbench.
The task sequence is now running. Here the disk has been wiped and a new partition is being
created. This is all automated.

Windows 7 Professional is now being installed. It’s time to take another break. How’s your bladder
holding up with all that coffee/tea/juice/water?
This is what you’re hoping to see. I think this took around 15 minutes on my VM. You should expect
a faster installation on physical PC’s.
The only remaining question is: did my update for Virtual PC install?

Yes! 
Wrapping Up the Clean Installation

What we’ve just done is perfect for administrators. We certainly wouldn’t use this for ordinary
deployments because there was too much interaction.
What we are going to do now is create a customised image. We will capture that image and then
we’ll set up a “light touch” method for deploying that image.

Creating a Custom Image
In the real world you’ll want to be able to deploy Windows 7 images that contain all of your
applications and configurations, e.g. Microsoft Office, Adobe Reader, etc. That way a user can be
near instantly provisioned with a PC without waiting on administrators, helpdesk or something like
Configuration Manager to install applications.
Deploy the Template Operating System

You can use the task sequence that we just created to deploy your operating system. Make sure
that it is not joined to a domain. You then want to install your required patches, security updated,
applications and configurations. Watch out for applications like anti-virus or that are sensitive to
identity change. Make sure they support SYSPREP and cloning scenarios. Some of them might have
support but only with certain predefined clean up tasks – check with your application vendors.
Create a Capture Task Sequence

What needs to be done to capture an image of an operating system? We have to run SYSPREP.EXE
to generalise the operating system. This strips anything that is unique to the PC in terms of security
and identity. I’m referring to security identifiers or SID’s. A SID is an ID that should be globally
unique to all Windows computers. SYSPREP will strip the machine of its SID. When the machine
reboots it will create a new SID. There are other tools out there such as the MS NewSID and third
party solutions. Only SYSPREP is supported by Microsoft so it’s the only generalisation solution you
should use in production environments.
We’re going to create a task sequence now that will run SYSPREP for us and then capture an image.
The flow will be:

Log into
Windows
and start
sequence
Sysprep
Reboot
Boot into Windows

PE
Capture Image
End
Enough talk; let’s go create a task sequence. I won’t show every screenshot in this because you’ve
seen them a lot of them earlier in this document. I’ve returned to the Workbench, navigated to
“Task Sequences” and clicked on <New Task Sequence>.
As I did earlier, I gave it a unique ID and a descriptive name and comments.

The choice of sequence template is pretty easy; I’ve selected the “Sysprep and Capture” task
sequence template.
I’ve selected the image I’m going to capture. I’ll be asked for more information about the
organisation, product key and admin password. I’m going to skip all of that because my deployment
task will take care of it. However, if I use a different tool to deploy the image, e.g. IMAGEX.EXE, then
I should consider putting that information in. Here’s the PowerShell script that was used to create
the task sequence:

import-mdttasksequence -path "DS001:\Task Sequences" -Name "Capture Windows 7 Professional x86" -Template
"CaptureOnly.xml" -Comments "Sysprep the machine and capture an image of it." -ID "CapWin7Prox87" -Version "1.0" -
OperatingSystemPath "DS001:\Operating Systems\Windows 7 x86\Windows 7 PROFESSIONAL in Windows 7 x86
install.wim" -FullName "BigFirm" -OrgName "BigFirm" -HomePage "about:blank" –Verbose
Prepare the Template Machine

The template machine is the one you will customise, sysprep and capture as an image. You should
ensure that the machine is in a workgroup; that’s what Microsoft recommends. I’m going to use the
Windows 7 installation that I deployed to PC1 earlier in this document.
You should prepare the machine with all of the hotfixes, security updates, applications, service packs
and configurations that you desire in your image. Set them all up just as you want them to be on
your deployed machines. You need to do all this without joining a domain and watch out for
applications that want to create some sort of unique ID on the machine. Check with the application
vendor’s support system for information on that. Typical suspects are anti-virus agents and systems
management tools.
There’s some debate about whether you should add all of your standard/universal software into an
image or not. It’s really a question for your company. There are three arguments/approaches to
this:
1. I want to deploy everything as quickly as possible. The pro is that users/administrators don’t
have to wait for manual/automated installs of applications after the OS deployment. The
con is that when you change one of those standard applications then you need to change
the image, recreating every step. Unique applications should either be deployed manually
or via some automated solution.
2. I only want to include security updates, hotfixes, the latest Windows service pack and the
software deployment agent. The pro is that there is an infrequent need to recreate the
image. You’re really only looking at doing it once or twice a year, e.g. when the Windows
service pack is updated by Microsoft or when the vendor for your software deployment
solution creates a new version of their agent. Everything else, e.g. the latest build of
Microsoft Office, is deployed by the software deployment agent, e.g. Configuration Manager
or App-V, after the OS is deployed and boots up. The pro is that the image changes very
infrequently. The second pro is that this is probably a suitable approach in larger
organisations where administration of OS deployment is separated from administration of
application deployment. The con is that it takes longer to deploy a completed machine.
3. I will include only the operating system and a software deployment agent. I wouldn’t take
this approach. After the OS is deployed the software deployment agent will have to deploy
the service pack, security updates, hotfixes and then all of the applications for that PC. With
MDT, you could even exclude the agent and deploy it as part of the task sequence after the
operating system is installed. The pro is that you’ll only ever update the image maybe once

every two years when the software update agent changes. The con (and it’s a big one) is
that a machine deployment would take a very long time.
I’m going to install two applications in my VM:
 The VMware Workstation Additions so I can access the host drive to access my application
installers.
 Office 2010 Professional CTP. This is a typical application you’ll deploy with Windows 7. This
could alternatively be Office 2007.
I’ve previously installed the XP Mode VM in a Windows 7 Professional image. Admittedly, it was
within a VM so I couldn’t start it up and I haven’t heard anything about this being a supported way
to deploy XP Mode. I’m all ready now to sysprep the machine and capture its image.
Run the Capture Task Sequence

We’ll be running the Deployment Wizard again but we will not boot the machine up with our boot
image to start it. Instead, to run this task sequence you must be logged into the machine you want
to capture. You then connect to your deployment share and run the VBS script that starts up the
client.

I have logged into PC1, my template machine, and I am running LITETOUCH.VBS. It resides in the
“Scripts” folder in the deployment share on the MDT server. So the full path in my example is
\\mdt1\deploymentshare$\Scripts\LiteTouch.vbs.
I get one of those lovely little security warnings. Yes, I do want to <Open> the file to run the script.
The deployment wizard starts up and I have selected my new capture task sequence.

This is where we tell the Deployment Wizard where to save the image and what to call it. I’m
specifying the “Captures” folder in the deployment share (\\mdt1\DeploymentShare$\Captures) and
I’m giving the image a descriptive name, “Win7ProX86StandardImage.wim”.
We next enter the credentials that will be used by the task sequence for accessing the deployment
share.
OK, this is where you need to be 100% sure that the machine is ready to be captured. After this the
machine will be sysprepped. Any reboot into the operating system will require you to enter some
information. That’s not a bad thing, just inconvenient.
When we click on <Begin> the task sequence will commence.
Once SYSPREP has run the machine will reboot into the Windows PE boot image and start to capture
the image. That takes a few minutes giving you a chance to read your email again.

Once the SYSPREP task has run you’ll see the task sequence download the Windows PE boot image
and alter the boot order of the machine to start it up with that image. The machine will boot up
with the boot image, temporarily cached on the hard disk. Eventually you’ll see the capture task
running as seen above.
Now you should check the deployment share folder, in particular the “Captures” folder and see if the
WIM image file is being created and appended. If there’s not sign of it then you’ll soon see an error
on the PC that is supposed to be captured. There are a few possible causes:
1. You booted the machine up with the boot image and started the task from there. You
instead should have logged into the template machine and started the sequence as I
specified above.
2. You specified an incorrect or failed to even specify a capture location, i.e. the deployment
share, as specified above.

The WIM file will grow as time goes by. It will sometimes appear to freeze, grow rapidly and grow in
small jumps. Take some advice; don’t watch this kettle boil. There are several gigabytes of data that
have to be transferred and the capture process needs to apply single instance storage to make the
image efficient. Give it a quick look to ensure the file is created and then go do something else for
15-30 minutes, depending on the amount of content you’ve added to the template machine.
Eventually the Deployment Wizard on the template machine will tell you that the deployment has
completed. Your WIM file is in the “Captures” folder in the deployment share and is ready to use.

Deploying a Complete Image in Production
We have now created our template image. Once you have done some testing it will be time to push
the image out to your users’ PC’s. Everything we have done up to now has been suitable for test and
development. We’ll do things a little differently when it comes to pushing this image out to
hundreds or thousands of computers.
Create a Dedicated OS Deployment Share

Have a think about your existing deployment share on your MDT server. You’ve got test and
development images and task sequences up there that you don’t really want to get out into the wild.
Your test and development deployment share that you’ve been using has a default share permission
with Authenticated Users having read and execute permissions. I would replace that and instead
make sure your image administrators have full control instead.
So how do you share the production WIM file images and task sequences? I have two suggestions:
1. If you have plenty of room in your budget then you can have a dedicated MDT server for test
and development and a dedicated MDT server for deployment that only contains your data
for end user computers.
2. There’s nothing to stop you from creating a second deployment share on your existing MDT
server. You could leave it with the default permissions of Authenticated Users having read
and execute permissions. That would be where you keep the production images and task
sequences.
I’m going to go with the second option. I will create a deployment share on the MDT server on the
D: drive called “OSDeployment”. I won’t show you all the screenshots because you’ve seen this
process before.
The share will be”\\mdt1\OSDeployment$”

I will never backup a machine or use this deployment share for capturing images so I un-tick the “Ask
if an image should be captured” setting. And here’s the PowerShell cmdlets used to create this
deployment share.
new-PSDrive -Name "DS002" -PSProvider "MDTProvider" -Root "D:\OSDeployment" -Description "Standard OS

Deployment Share" -NetworkPath "\\MDT1\OSDeployment$" -Verbose | add-MDTPersistentDrive -Verbose
Add the Image(s) To Deploy

I captured a sysprepped image in the previous task. I want to share that image with the network via
this deployment share so that we can rebuild our PC’s, e.g. PC2 which is running XP. To share the
WIM image we need to import it into the “OSDeployment” deployment share. I have created a
folder in the new deployment share under “Operating Systems” called “Standard Office Images”. I
have selected that folder and clicked on <Import Operating System> in the actions pane.

This time we can to import a “Custom image file”.
I’ve selected the image in the original, test and development, deployment share. I have ticked on
the “Move ...” tick box to speed this process up. That means the original WIM file will be moved
instead of copied into the new “OSDeployment” deployment share.

We do not need to copy any additional files to use this image.
Here’s the imported image file. Note that I’ve renamed it for the sake of convenience.
Add the Drivers

Import all of the drivers for the computers you expect to deploy to using the instructions provided
earlier in this document.
Create a Deployment Task

We need to create a deployment task in this “OSDeployment” share identically to how you did it
earlier in the original deployment share. Point it at the captured OS image. I have again edited the
task sequence and disabled the “Capture” and the “Enable BitLocker” steps.

The Deployment Share Rules
Think back to when we originally deployed Windows 7. We had to enter a lot of information before
the task sequence kicked off. That might be OK for the odd occasion when we build a new image but
it’s not OK if we have to do that for each PC on the network.
We can pre-answer those questions by adding additional rules to the properties of the deployment
share. The MDT 2010 documentation has a few samples of the rules. I’m going to use one of those
samples and tweak it a bit.
[Settings]
Priority=Default
Properties=MyCustomProperty
[Default]
OSInstall=Y
ScanStateArgs=/v:5 /o /c
LoadStateArgs=/v:5 /c /lac /lae
SkipAppsOnUpgrade=NO
SkipCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipDeploymentType=YES
DeploymentType=REFRESH
SkipDomainMembership=YES
JoinDomain=mdt
DomainAdmin=Administrator
DomainAdminDomain=mdt
DomainAdminPassword=MyPassw0rd
SkipUserData=yes

UserDataLocation=AUTO
UDShare=\\mdt1\UserData
UDDir=%ComputerName%
SkipComputerBackup=YES
ComputerBackuplocation=AUTO
BackupShare=\\Servername\Backupsharename
BackupDir=%ComputerName%
SkipTaskSequence=YES
TaskSequenceID=DEPWIN7PROX86
SkipComputerName=YES
OSDComputerName=%ComputerName%
SkipPackageDisplay=YES
SkipApplications=YES
UserID=Administrator
UserDomain=mdt
UserPassword=MyPassw0rd
SkipBitLocker=YES
SkipSummary=YES
Note the TaskSequenceID is set to the ID I used to create my deployment task sequence. If you look
at the samples in the help file you’ll see how you can make this completely zero touch by predefining
the region settings and time zone. I’m assuming that my deployment will be for a multinational
organisation so I can’t set a universal configuration up for those settings.
This task sequence is also configured as an upgrade task sequence. That means my XP (or
Vista/Windows 7) users will be able to upgrade. Remember that the task sequence will backup and
restore the user state. We’ll need to start this task sequence while logged into Windows.
I have also predefined a place to store the user state temporarily as being \\mdt1\UserData.
Speaking of which ...
Configure a User State Share

I’m creating a new folder at D:\UserData and sharing it as “UserData”. You need to ensure that
Authenticated Users can write to this. The user state only stays here until it is restored. I’m pretty
sure you can do some clever permission stuff here to prevent unwanted browsing but I won’t discuss
it here. If you are doing any DFS replication then do not add this to the replication. It is only meant
to be a temporary local store.

Update the Deployment Share
You have seen this process before. Update the deployment share. This will create your boot image
WIM files and ISO files. We’re not too worried about that now because we’re doing an upgrade
which requires us to be logged into our PC’s.
Run the Task Sequence to Upgrade an XP PC

I have logged into my Windows XP machine, PC2. As you can see below, there is a user state, i.e. a
local user profile containing data such as registry information, a desktop, My Documents and
Internet Explorer favourites.
If I’m a user getting my PC upgraded then I want all this data on my new PC. If the network is
configured with Roaming profiles then I have bad news for you XP administrators. Windows Vista, 7,
Server 2008 and Server 2008 R2 use V2 (version 2) user profiles. Legacy user profiles are not
interchangeable with V2 profiles. If your XP users are using roaming profiles then they’ll need new
roaming profiles.
For example, I could have a file server called FS1. My roaming profile while logged into XP would be
“\\FS1\Profiles\AFinn”. If I logged in to Vista or Windows 7 then I would need a roaming profile
called “\\FS1\Profiles\AFinn.V2”. The new operating systems know to add the .V2 so don’t specify it
in the roaming profile attribute of the user object; doing so will cause the profile not to load.
So you will to need to migrate those files.

Anyway, let’s get back on topic. I’ve logged into my XP machine. I will start things up by running
“LITETOUCH.VBS” from the deployment share scripts folder, e.g.
\\mdt1\OSDeployment$\Scripts\LiteTouch.vbs.
The first screen to popup asks me to configure the regional settings. I’m using an Irish laptop so I
configure it appropriately.
I then set the time zone of the machine. Clicking on <Next> will kick of the pre-defined task
sequence. If nothing happens then check to see if the task sequence ID defined in the deployment
share rules is a valid one for that deployment share.

The task sequence runs. It will capture the user state, download and apply the boot image and then
reboot. At that point the task sequence will format the hard disk and deploy the new operating
system.
After a while and a few reboots the machine will automatically log in as the administrator account
your specified in the deployment share rules (so DONT use the domain admin account like I have in
this demo) and will complete the post-install steps of the task sequence, including restoring the user
state.

As you can see above, the machine that was running XP has had the following happen to it:
 It has been upgraded to our Windows 7 image.

 Office 2010 and Virtual PC are a part of that image and installed on the PC.
 The machine is a part of the domain.
 The user state, i.e. all the files owned by users of the PC, has been restored.
The user(s) of this PC have a freshly built PC with all the benefits associated with that along with
keeping all of their old settings and data. So who really cares if you can’t upgrade from XP to
Windows 7? We’ve just used a free OS deployment solution to get the same effect but with a
healthier PC network.

WDS: An Alternative Way to Access Boot Images
Windows Deployment Services (WDS) is another way to create and deploy operating system images.
It uses the same basic tools as MDT: boot images, OS images, WIM files, WAIK, etc. The big
difference is that it works by using PXE technology. That’s a BOOTP protocol, similar to DHCP. When
you boot up a machine you have an option to boot from the network, often by pressing <F12>
depending on your hardware and BIOS. This will start a PXE client in the hardware. It will send out
a request for a DHCP address and for an address for a PXE server, e.g. a WDS server.
It will then download a client from that machine. In the case of WDS that client allows you to log in
using some Windows credentials. If you are authorised you will then be presented with a set of boot
images. They then allow you to do things like capture OS images and deploy OS images that are
stored on the WDS server.
We’re interested in the boot image part of this. It uses a WIM file. We happen to have some WIM
files too. Remember that when we update the deployment share we create ISO images and WIM
files. We can share those WIM file boot images with the network without having to create bootable
media. That’ll be a time saver. When you want to deploy your OS images to new PC’s you can
simply boot up from the network, log into WDS and select a boot image. You won’t need to muck
around with USB sticks or DVD writers.
To do this:
1. Install the WDS role on a server, e.g. your MDT server.

2. Make sure that the PC’s can use the MDT as a DHCP server – it is not configured with DHCP
but you must ensure that any VLAN with PC’s can forward BOOTP to the IP address of your
MDT server.
3. Launch the WDS console and navigate into boot images.
4. Add a boot image – choose the boot image WIM file from your deployment share.
Now when you boot up a PC on the network (PXE boot) then it will download that image and boot
up from it.

Summary
You cannot upgrade from Windows XP to Windows 7. At first that sounds like a big deal but it isn’t
really. Using the free MDT 2010 you can quickly refresh the PC’s on your network so that they run
Windows 7 and retain any user data and settings that are stored locally. In a virtual lab, I can get this
up and running in less than 2 hours, including just about all of the steps required.
MDT 2010 is more than just some simple OS deployment solution for desktops. You can also use it
to deploy Server operating systems. MDT uses Task Sequences which are an ordered set of steps.
This allows you to SYSPREP a machine and capture an image of it. You can capture the user state of
a machine, deploy a new operating system and restore the user state. Task sequences are pretty
powerful. You can customise them to do other things before and after the installation.
In this document you’ve been shown how to install, configure and use MDT 2010 to deploy Windows
7. I’ve shown how to upgrade your XP network to Windows 7. That’s the most difficult part of
making the upgrade.
There are a few other things you should read about to supplement this document.
 Using Windows System Image Manager, a part of Windows Automated Installation Kit for
Windows 7 and Windows Server 2008 R2: This will allow you to further customise the
installation phase of the MDT process.
 Windows Deployment Services: You can use it to boot up your boot images over the
network and to enable multicast.
 The MDT help files: There’s much more you can do to customise the rules and create task
sequences.
 Get to grips with scripting: This is how you will make the most of MDT 2010. For example, I
haven’t talked about how to use MDT 2010 to create custom USB or DVD installation media.
I can recommend the online materials of Johan Arwidmark, a deployment MVP, at

http://www.deployvista.com/. And watch out for presentations and material by Rhonda Layfield,
another deployment MVP. Both of them know this stuff much more than I do and will be able to
offer advanced techniques that I probably have never even heard of. Both can be found helping
people out on the Minasi forum at http://www.minasi.com/forum.
Spend a night going through this stuff in a virtual lab and you’ll be able to go into work the following
morning and impress your boss with your new found OS deployment skills.

Deploying Windows 7 With MDT 2010

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Deploying Windows 7 With MDT 2010

Enviado por

Direitos autorais:

Formatos disponíveis

Aidan Finn

How to use Microsoft Deployment Toolkit to Deploy Operating Systems

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 2

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 3

 It’s 100% free.

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 4

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 5

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 6

 Processor running at 1.4 gigahertz (GHz) or faster.

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 7

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 8

This one is simple enough. Click on <Next> to get going.

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 9

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 10

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 11

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 12

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 13

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 14

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 15

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 16

The share is created for you and the folder is populated.

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 17

NetworkPath "\\MDT1\DeploymentShare$" -Verbose | add-MDTPersistentDrive -Verbose

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 18

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 19

Import the Operating System Image

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 21

New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "D:\DeploymentShare"

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 22

Pick “Full set of source files” and click on <Next>.

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 23

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 24

New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "D:\DeploymentShare"

import-mdtoperatingsystem -path "DS001:\Operating Systems\Windows 7 x86" -SourcePath "E:\" -DestinationFolder

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 25

Import the Drivers

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 26

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 27

New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "D:\DeploymentShare"

import-mdtdriver -path "DS001:\Out-of-Box Drivers\VMware Workstation 6.5.3" -SourcePath "D:\Drivers\VMware

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 28

This is where my driver was copied into.

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 29

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 30

New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "D:\DeploymentShare"

import-mdtpackage -path "DS001:\Packages\Microsoft Virtualisation" -SourcePath "D:\Applications" -Verbose

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 31

Set Up the Task Sequence

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 32

There’s 3 pieces of information we can add in here:

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 33

 Capture the user state of the PC and store it on a network drive.

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 34

You’ll understand if I don’t illustrate my product key here 

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 35

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 36

New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "D:\DeploymentShare"

In the deployment share a few things happen.

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 37

Customise the Task Sequence

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 38

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 39

Copyright Aidan Finn 2009 http://joeelway.spaces.live.com 40