Professional Documents
Culture Documents
02 September 2009
http://joeelway.spaces.live.com
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
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:
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.
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.
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:
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.
During the RC stage of MDT 2010 we have an MSI for the installation. I’ve double clicked on that to
start the install.
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!
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 where you’ll find the Deployment Workbench or Workbench from now on. There are
shortcuts to documentation there too.
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.
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.
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.
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
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
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.
Add-PSSnapIn Microsoft.BDD.PSSnapIn
new-PSDrive -Name "DS001" -PSProvider "MDTProvider" -Root "D:\DeploymentShare" -Description "Deployment Share" –
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
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:
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.
The folder is created and here’s the PowerShell that was used to do it:
Add-PSSnapIn Microsoft.BDD.PSSnapIn
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.
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.
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.
Click on <Next> to go ahead with the import or <Cancel> to terminate the process before doing
anything.
The copy eventually finishes and we can see the produced PowerShell cmdlets:
Add-PSSnapIn Microsoft.BDD.PSSnapIn
Finally, here’s where the files were copied to in the deployment share.
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
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.
The drivers are imported and this is the PowerShell script that used to do it:
Add-PSSnapIn Microsoft.BDD.PSSnapIn
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
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.
The update is discovered and imported. The PowerShell cmdlets were as follows:
Add-PSSnapIn Microsoft.BDD.PSSnapIn
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.
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.
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.
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.
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.
Here’s the last chance to go back to make changes, abort or proceed with creating the sequence.
Add-PSSnapIn Microsoft.BDD.PSSnapIn
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.
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.
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.
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.
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.
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.
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:
Upgrade or
Upgrade
clean install?
Install operating
system
Inject drivers
Install applications
Recover state
information
End
1. In an upgrade scenario you log into the machine to be upgraded and run the Deployment
Wizard.
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.
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”.
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.
The “DeployRoot” option will configure the deployment share to use during OS deployment.
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.
Add-PSSnapIn Microsoft.BDD.PSSnapIn
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:
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.
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.
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.
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.
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?
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.
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
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>.
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
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
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.
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.
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.
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.
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.
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.
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.
Add-PSSnapIn Microsoft.BDD.PSSnapIn
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.
Here’s the imported image file. Note that I’ve renamed it for the sake of convenience.
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
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 ...
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.
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.
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.
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.
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:
Now when you boot up a PC on the network (PXE boot) then it will download that image and boot
up from it.
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.
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.