Deploying Windows 7 With Mdt 2010

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.

Aidan Finn

02 September 2009 http://joeelway.spaces.live.com

How to use Microsoft Deployment Toolkit to Deploy Operating Systems

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

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


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.

MDT Server

Domain Controller

DNS

DHCP

PC1

Blank

PC2

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.

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

clean install?

Capture state

information

Wipe hard disk

and format

Install operating

system

Clean

Installation

Upgrade

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:


Sysprep

Reboot

Boot into Windows

PE

Capture Image

End

Log into

Windows

and start

sequence

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.