May 2011 Archives

Please note, this is not perfect.  I'll take comments on how we can get this polished up and improved Smile

But my hope here is that there are enough "nuggets" that almost any tech could at least pick up MDT and get themselves running for at minimal an LTI installation or a NEAR ZTI install

It's in my own words, I'm not a writer, I'm just an Energized Tech who loves to help out.  If this is any way helpful to you?  Pass it along.  "Share and enjoy"

Just don't go near any "Nutrimatic Dispensers" when you "Share and Enjoy"


Part 1 - Installing MDT 2010 on your computer

Part 2 - Creating A Deployment Share

Part 3 - Importing an Operating System

Part 4 - Importing Applications

Part 5 - Silent Install of Applications - tips and tricks

Part 6 - Creating a Silent Office Installation

Part 7 - Importing Updates and Packages

Part 8 - Importing Drivers and staying organized

Part 9 - Creating Dependencies in Applications and Updates

Part 10 - Creating a Task Sequence

Part 11 - Creating Selection Profiles

Part 12 - Creating Deployment Media

Part 13 - Beginning to Skip Screens and Auto answer questions

Part 14 - A quick look at the Task Sequence and Unattend.xml

Part 15 - Using WDS with MDT to create a network based PXE install

So all the fun stuff is over and we’re done…

No wait.  We’re not.  I was mumbling something out using “WDS” or “Windows Deployment Services”

This is simply a Role you add in Server 2008 or Server 2008R2.  This is free to use so flip it on Smile

Just go into the Server Manager, right click on “Roles”, choose “Add Roles”, click next and choose “Windows Deployment Services”


We’re not going to go TOO deep into it’s setup.  Yes you can have multiple servers across many environments, blah blah blah.  Today we’re going to stick with the basics.  So just take all the default settings and move along (“These are not the Droids you’re looking for ….”)

You’ll find “Windows Deployment Services” as a new entry in your Administrative Tools.  Clicking on it you’ll see the name of your server under “Servers” with a Yellow Exclamation mark


So Right click on your server name in the WDS console and choose Configure Server.  This will present a nice simple step by step Wizard to get you going.  It’s going to ask to create a new folder structure for just WDS.  If this is the same server as MDT, LET IT DO THIS.  Remember to treat MDT and WDS as two separate entities.  One CREATES the images, the other is a tool to enable DEPLOYMENT of images.  Just like with another Role or Application.  Give them their own Sandbox.  Perhaps some Chocolate Chip cookies (Or are they no longer on the HCL for Server 2008R2?)

It will create a folder called C:\RemoteInstall for it’s stuff and then ask you how you want to respond to PXE requests.  If you need 100% control use “Respond only to known client computers” otherwise just choose “Respond to All” (Don’t worry, you can always turn this on or off as you need it)

When it asks you if you want to add images to Windows Deployment  Server now, clear the box and don’t for the moment.

To make this all work we need three things, a Boot Image, DHCP and a DeploymentShare created by MDT.

Right click on “Boot Images” in the Left hand console in Windows Deployment Services and browse to one of the LiteTouch.wim files that were created earlier in your C:\MyMedia folder. They will typically be under \Content\Deploy\Boot . In our case you may find two (One is a 64bit bootable WIM file and one is a 32bit bootable WIM file) You can add in each one, it won’t hurt.

Just browse to each one of these files, follow the step by step simply wizard and you’ll have two new bootable images within WDS

If nothing else is done, your environment should now (as long PXE boot is enabled on a network card) be able to now choose to boot from the WDS server from one of these two WIM files.

Now we haven’t configured them so to make it install from the DeploymentShare you’ll actually have to provide credentials and the UNC pathname of the share.  From this point it will at least be an LTI install if you haven’t configured it otherwise for the DeploymentShare itself.

But like everything in MDT, this can be tweaked even further.

So if you would like to have that bootable file have the USERID and PASSWORD and UNC pathname already known (so this becomes even simpler) just go to the Properties of the C:\MyMedia folder, Click on the “Rules” and add in the following lines to your configuration


You’ll have to right click on the MyMedia in MDT and choose “Update” to rebuild the WIM files.   Once this is done just right click on each entry in WDS for the Boot files and choose “Replace Image” and just follow the same procedure as last time to browse to those files in the C:\MyMedia folder.

Well it’s now officially the Long Weekend.  My fingers are numb.  My brain is empty and I want to go play with some more Powershell Smile

I’ll post a single posting tomorrow with the entire series and links so you could just access that if you like.   If you have any comments, add them in as this is something I’d like to see the community join in with.  MDT is fantastically amazing and Powerful tool.  If there is any way I can help YOU get off the ground with it, ping me.   Because we all need shorter days and more time to relax

MDT 2010 gives us just that Smile

Thanks Michael Niehaus for creating such a Kick Ass tool! YOU ROCK!

So now we’ve MDT 2010 to a level where we could actually make a seamless install.

No we haven’t.  I lied again.

What we’ve done is bring a lot of automation but there are things that can and should happen even further.

What about Windows Updates?   What about things that can happen WITHIN that installation as it’s installing?  Perhaps you’d like to NOT join to the Domain and leave the password in clear text?

That’s the power contained within your Task Sequence.  Remember when I said it was a “Predefined Template” but you COULD go into it deeper?  We’re about to open the hood.  Let’s pull up the properties of the Task Sequence created before.


We’re going to click on “Task Sequence” which is (Are you ready folks?) the “SEQUENCE” your task is going to run in.

Taking a quick look at our Task Sequence it’s really almost a workflow more than code.   Stating what we’re planning on doing.  If you look near the bottom you’ll see two sections marked “Windows Update (Pre-Application Installation)” and “Windows Update (Post-Application Installation)”


Presently they are greyed out.  You can see this if you click on one of them and choose the “options” tab on the right hand side.   If you were to enable this feature you will now have enabled Windows Updates to occur BEFORE applications install.   Have done more than a few I recommend looking into getting as many patches into the system upon install.  But if you have WSUS server local to your install this is not a bad option to enable.  This is off be default to leave HOW you want Windows Updates to apply up to you.

With Windows 7 you may want to enable this to avoid disturbing the application Install.  Once it’s live on the Network, Windows 7 will IMMEDIATELY want to download updates.    However now we’re going to look into editing UNATTEND.XML in order to control this and other features on a finer level.

Click the “OS Info” tab next.  This will give you a very simplistic screen.  We’re concerned with one option “Edit Unattend.XML”


Fortunately for the ITPro this will NOT bring up a souped up version of NOTEPAD and force you to learn XML.  Microsoft has provided us with a proper editor to navigate and work with the content it contains in a very sensible fashion including encryption of passwords.   We get THIS to work with Smile


Looking here under “Unattend” on the right hand side are the various stages of your Deployment.  From WindowsPE all the way down to oobesystem (Out Of Box Experience, what happens JUST BEFORE  YOU GIVE IT TO THE USER TO BREAK!)

I’ll be honest and I haven’t mastered even half of this but I’ll show you some things I learned and maybe that will help you along. 

The part I’ve with the most is under “Specialize” and “oobeSystem”.   Specialize (from what I can tell you) is various changes you’re making to the O/S from it’s stock configuration.  Like the local Administrator password you’re assigning and the scripts that are running automatically upon each successive reboot of the O/S until of course that part is complete.

The neat part I found out, is that the commands are just DOS commands.  so if you need to disable a service JUST for the install (IE, say Windows Update is stepping on your toes) you simply find out the command in Console to alter the state of a service and add it to the list of “FirstLogonCommands” When you see “Synchronous” that means nothing else can happen until it’s predecessor is complete and the command order is exactly that.   This process works the same way under “Specialize” and “oobeSystem” – Just remember everthing done under “oobeSystem” is your “Out Of Box Experience”, what get’s left behind for the user


To add a new Command to the list simply right Click on “FirstLogonCommands” and choose “Insert New Synchronous Command”.  In the provided line you will need to specify the Script or Console command you are running, Give a vague description and specify the order it happens in.  (1,2,3,4,5) – Keep in mind if you want to make this happen before OTHERS you will have to go and edit the “Order number” on the FOLLOWING synchronous commands first.


You can, if you so choose edit the default password being assigned to the Local Administrator account in your Deployment.



Here’s the coolest part.  If you don’t want to show your ID and password for Joining a machine to the Domain under Rules you can edit the UNATTEND.XML and put it right here under “Specialize” under the “x86_Microsoft_Windows_UnattendedJoin_neutral” category.  Under the “Identification” you can specify “JoinDomain” as true then under “Credentials” key in the required credentials


You could sit down on an entire weekend and not learn the massive power available to you in UNATTEND.XML but I’m hoping here you can see what it can do and hopefully you become comfortable to really pop open the hood.

Our next and final bit?  We’re going to drop our Images into a WDS (Windows Deployment Services) and get our environment so that we can even use a PXE network boot to install the software.

At this point we have bootable media, the ability to have an LTI install controlling our workstation deployment.   We’re down to maybe a little typing and a mouse clicks and everything will deploy.

This is a problem.  (*klunk* WHAT?!)

Really it is.   Now that you’ve eliminated MOST of the clicks and you’re constantly choosing your Time Zone and reselecting the same 5 apps each time as WELL as answering the same questions (albeit simple) you will begin to question “Well can’t I automate this more?”

In a word Yes without the caveat of “It Depends”

What MDT 2010 actually does is just lay down a TEMPLATE of vbScript, INI and XML files to automate things as much as possible.   Truth be told, this is fine for most of us.  But if you deploy on even a somewhat regular basis and hate typing as much of the rest of the IT community does, you’ll want to eliminate those few extra clicks left.

So where do you start?  You start in your Task Sequence.  Remember that word…. “SEQUENCE”.  It controls the order in which things are installed but also in what questions are or are not asked, when certain features in Windows are enabled during the install, whether can join a Domain…

The amount of things you can control with a Task Sequence is mind numbing.   Here’s the really cool part.  Just about EVERYTHING that you can do with Systems Center Configuration Manager for deployment (just about!) you can do with MDT and a little programming.

“But Why?!  Why would Microsoft let us do that?  SCCM is the King of Deployment!”

Wrong.   But not for the reason you think.   SCCM is Excellent on Deployment but look at it’s name.  “Configuration Manager” and think of how this product is meant to interact with the Enterprise.  It is MEANT to manage the CONFIGURATION of your Enterprise.   Deployment is about 5% of that.   Configuration is about controlling patches, individualized application deployment, inventory and more.

So letting you have the ability to make a Near ZTI deployment with MDT 2010 does not hurt SCCM.  It’s purpose to be is much larger.  MDT 2010 is a tool to BUILD IMAGES.   SCCM is a tool to BUILD and MANAGE Everything (INCLUDING images) from an Enterprise standpoint.

So let’s take a look at our first challenge.  Skipping some screens.  “SKIP” is the magic word.   

To get rid of our first pile of screens we much “SKIP” them.  Funny thing is if you search MDT 2010 (that big built in documentation search system) for “SKIP” you’ll find exactly what you’re looking for the first time.


Clicking on the very FIRST one for “SkipAdminPassword” is going to take you to the heart of it all.    You’ll see it refers to BootStrap.ini and CustomSettings.ini which is where this entry would go (One or the other) including a sample of how it would fit in.    Here’s the catch 22.   Just because you said “SKIP” doesn’t mean it answers the question, it just means “Don’t bother asking and I’ll go with a default answer”

If you need to know which answers to provide and to which questions you click on the link near top of the Help Window saying “Providing Properties for Skipped Windows Deployment Wizard Pages” which will provide you with what I found to be the heart to getting rid of most of my questions.


So looking here we can see that if we put in “SkipAdminPassword” if we need to provide the password we must fill in “AdminPassword”

Ok fine, then when does all this go in?

Well THAT is a case of “It Depends”.  It depends on whether you are editing a configuration for your Media (Like the C:\MyMedia folder we created before) when we built an image) or if you’re editing the master settings on the Deployment Share itself.   Editing this is the “Master field” and will also be the spot you need to edit when you are working with WDS (Windows Deployment Services) or doing a manual over the wire install.

Let’s just say, we’re going to work on just our Media share (C:\MyMedia)

For that we go back to the properties of the MyMedia configuration we created under “Media” and click on the “Rules” tab (Remember how I said we’d look at that later?  “Later” is Now.


These are the “Rules” that say what happens or Doesn’t happen in this Deployment.   Added your SKIP entry with the appropriate variable will now SKIP that screen in your LTI and have the answer prefilled.  For the “SkipAdminPassword” we would add in these two lines



I would not recommend using that password of course, but that would set the Local Administrator password AUTOMATICALLY on all of your Deployments to everything after “AdminPassword=”

This is just one option.  The one I REALLY wanted was the ability to “Skip” the application screen since I would check the same 8 or nine applications each time.  Skipping this is easy but you need to know how to specify the Applications.

I found the line was “SkipApplications” which was sensible enough but how do you SPECIFY the applications? It turns out it was easier than I thought.

For each and every Application, Bundle and even package there is a GUID you can reference.   You may have overlooked it (I certainly did my first couple of times)

So looking up in Applications, let’s pull up the Properties for our “Adobe Flash Player 10”



In order to get this Application to install you simply need to key in to the CustomSettings.ini file (Your Rules)



If I had a series of applications to have installed I would just mark down something like this



As well, the order they will attempt to install will be the order you list them in.   But remember this (Good thing).  All those dependencies you programmed in are going to be called up here.

If you want to have the Media automatically choose which Task sequence to default to you can enter in a


But how do you know how to choose the task sequence.   Do you remember how we entered a “Task Sequence ID” ?  This is where that ID get’s used


So within our CustomSettings.ini (Rules) we would enter a



So if were to add in these entries to our Rules it would all look like this


Now would you like me to make your life REALLY easy?  Here is a sample set of Rules from a Deployment I created that would install the applications, Join the Domain and not ask ANYTHING except prompt me with the initial “Welcome Screen”.  Just read the various Skip statements and see if You can figure out what I’ve done here.  The nice thing is the variables are very sensible.  The ComputerName one is call since it takes the SerialNumber from the BIOS and gives the computer that as a default name.  For that I must personally express heartfelt thanks to Mitch Garvis for that one.  I was butting my head against a wall for 24 hours on that one!


TimeZoneName=Eastern Standard Time

But you’re not satisfied?  You want MORE? You want to skip the Welcome screen too?

The welcome screen is a part of the Windows PE boot and you must edit the Bootstrap.ini file for that.  On the same Rules tab, click on “Edit Bootstrap.ini” and add this line on the end


With these settings you can now have a Boot that won’t bug you with any silly questions and do all the dirty work for you.

Next time around?  We’ll open up the hood a bit and take a quick look at editing the UNATTEND.XML with the built in Editor in MDT 2010

Now for the best part of MDT 2010. Makin’ the Media!

The process is simple and the only thing limiting you to the amount and type of media configuration is your hard drive space.

So first thing is to Right click on on the Media folder on the left hand side and choose “New Media”.   We’ll have three fields to fill out.

Media Path

The local folder to contain the Media you are building.   The structure must exist.  You can Browse to it’s location (if the folder already exists) or you can use the same browsing interface to create said folder


Pretty much a free form field to put in details about this media.  Be creative if you need to be, but don’t get carried away.

Selection Profile

Just What information we’re going to pull down and put into this Media.  Yes, the very Selection Profile you just created (or one of the predefined ones).  This is why the Selection Profile is important since our Destination media might be a DVD or a small USB key.  The Selection Profile our method of control on content.

Fill in your details, Click on next twice more, and Finish.  (And again… poke poke poke…. Every step generates a Powershell script)

So now under our Media Link we have some raw and unprepped media.


If you like, you can rename MEDIA001 to anything you like.   Click on the name, and on the right hand right is a “rename” option.  So click it and rename the name.  Or if you’re geeky, hit F2 and rename it. Smile


Right click on the Media name and choose “Properties” which will show you the present configuration the Media including various options to work with


Let’s break this down to four tabs since the x86 and x64 configurations are identical in how they work (based on whether you’re generating an x64 or x86 Windows PE image)

Oh right, if you’re not familiar with it, Windows PE is a very light core based version of Windows 7.   So our environment will actually build a tiny version of Windows with the ability to use the same Windows 7 drivers as the main Windows 7.  It also brings forth options we didn’t have before like the ability to install Windows Vista, Server 2008, Windows XP or Server 2003 / 2003 R2 from a USB key.

Now on the General tab there’s not much to do.   By default we will have a bootable ISO file created containing a bootable x86 and x64 file.   If you don’t want the ISO media and just need the structure for a USB key you can clear the “Generate a Lite Touch bootable ISO image” checkbox

It’s up to you whether you want to have a bootable x86 and bootable x64 Windows PE environment or not is up to you.  Simply clear off the one you don’t want.  I’ve not found a drawback yet to NOT having the x64 version but that’s just me.

The Rules tab will be touched in greater detail later on.  Suffice it to say this is the part where we can have some of our questions for the image Pre Answered such as computer name, time zone, others.   We’re going to dedicate the next article to that Smile


You can edit the Image Description for the Windows PE Wim file.   If you look in the folder structure MDT 2010 is installed within you’ll see a folder called “Samples” with the very background picture.    If you have something you’d like to use instead, just place it here.  You’ll of course want reference it’s name, have it in BMP (Bitmap) format and try to keep it at a resolution of 800x600.    If you alter this your new bootable image will have this as it’s background.    This would be a way to customize the boot environment for yourself or a client for a more professional look.

There’s also the setting for “Scratch space size” – This is memory allocated from RAM for Windows PE.  By default it’s 32 meg.  It can be increased to has high as 512.  If you encounter errors (possibly if you have too many drivers loaded in the environment?) you may need to increase the Scratch space size.   By default you shouldn’t need to adjust it very often.


Under the Windows PE x86 Components tab we are specifying what drivers that we’re using in our Windows PE environment.  Typically the default settings are fine.  We only need network access and possibly the hard drive.

Click ok to get back to your Media.

Right click and choose Update.  This can take a while to build depending on just how much you’re pulling in.  What this process is actually doing is copying all the files over and building the root structure of a bootable media (like a DVD or USB).  When it’s done (if the “Generate a Lite Touch bootable ISO image” is checked off) it will then proceed to build an ISO file from this structure that you can burn afterwards to a DVD (presuming your structure fits the 4 gb or 8 gb limit of your blank media.



So after it’s all done in the folder “C:\MyMedia” you’ll see an ISO file (that hopefully is reasonable size Winking smile ) and a folder called content


You can take the LiteTouchMedia.iso file and use any standard CD/DVD burning software to produce the media

Double click inside Content and you’ll see a structure similar to this


Does this look familiar?  this is your boot media BEFORE it was dumped into the ISO file.

Making this into a bootable USB key is so easy.  You can Bing the solution if you like but just for quick refresher

INSERT USB KEY TO WIPE OUT (make sure there nothing of value on it)



Find the disk that is your USB key (just gauge by size).  If it’s the second disk








Select the files in the Content Folder, past them to the USB key.


If you don’t do anything else at this point, you have a preconfigured environment right now that is a Lite Touch install.  Simply put, it will ask some basic questions and then do all the work for you.

Next time round we’ll take a look at Customizing your MDT 2010 to start answering some of those questions and bring it to a Near ZTI install

Once we have Task Sequence we should move on to building media.   Because at this point we just have a big folder full of stuff programmed and ready to be pulled down, but nothing preconfigured to grab it.

Go into the “Advanced Configuration” and expand so that you can see


These four are placed in a very sensible order for a reason, I’ll try to give the “Instant Condensed” version of what they are.

Selection Profiles

When you create an Image, it will need to reference JUST HOW MUCH you DO and you DON’T want in that image.   Your actual Deployment point (if you have multiple images) might well be 45 gigabytes of applications, Operating Systems and Service Packs and (if you were like our hapless ITPro friend in Part 8) Drivers.

If you broke everything down into a nice compartmentalized folder structure, This (YES RIGHT HERE) is where it all pays off.    As you can see Microsoft has predefined some basic Selection profiles which (if you are working on a single deployment for a Single client site) might just meet your needs find.   The names pretty much say it all


The whole Enchilada.  The kitchen sink.   Every O/S, Driver, File, Application, Service Pack nook and cranny that is in my deployment.  RELEASE THE KRAKEN!

All Drivers

Ok just gimme the drivers and O/S to go.    This SHOULD be pretty light (Unless again, you were that silly fool in Part 8) Winking smile

All Drivers and Packages

All Service Packs under Packages, All drivers (Hmm Beefier! But hold the mayo0

All Packages

I think that guy in Part 8 may have been involved in this Deployment, just give me all the stuff imported under Packages


I’m on a Diet.  Just give me the O/S.  Perhaps a straw?

Creating a Selection Profile (like everthing in MDT 2010) is very easy.  Right click on Selection Profiles and choose (what else?) “New Selection Profile”

You’ll have to give the Profile a name.   Make it sensible as you may have to later on call it up programatically.


And now after clicking on NEXT here, HERE is why you want the organization!  When you get to your Selection Profiles, they select those folders you created (not the individual contents)

So the more granular you need your Selections, the more you should organize your folders.  It also makes troubleshooting easier as you might be wondering why a deployment on 3 machines is crashing.  If it’s a bad driver and you’ve organized your drivers VERY well you could ACTUALLY create a Selection Profile (or clear the configuration in an existing Selection Profile) and test that way


So looking at THIS particular Selection Profile It appears (because of the way I organized and named the Folders) I’m building a very specific selection of Software, Drivers and even Packages.   You can even break your Task Sequences down by folders.

Clicking next twice and Finish and we now have a new Selection Profile

Next time?  We Build MEDIA!

So we’ve spent the last while getting to know how to import an O/S, drivers, packages, Dependencies, Service Packs and keeping it all organized.  This time we get to have some fun with it.

Up until now, it’s been VERY much like you’re out in the store, gathering ingredients to cook a very special dish.   Really your Deployment point IS just that.  A well organized pile of ingredients you pull together to “Dish out” an image to install on to your workstations or servers.

Ok, enough comparing this food.  I missed lunch and this is making me Hungry.

The first part into making all of this useful is to create a Task Sequence.  A task Sequence is a predefined set of XML’s, INI’s and even vbScript to call up and control the installation of the Operating System and applications as you see fit.

But rather than throw Dominoes at you all day long until you learn vbScript, XML files and how to understand what any of the stuff an INI file contains, Microsoft uses MDT to prompt with a very simple Step by Step wizard to create modify and tweak that structure to get you up and running.   I should mention now, this is not a set of files you’re not ever allowed to modify, but of a predefined base configuration that will get you up and running pretty quickly.

You can and are most encouraged to take it beyond that level.

So to create a Task Sequence you will have to Right Click on “Task Sequences” in the Left Panel in the Deployment Workbench.  Like everything so far you can still break this down into a Subfolder structure.  I’ve found this is especially helpful here.  As were get near the in Building Media, the more organized and granular your structure, the better the final product can be.

Choosing “New Task Sequence” presents a simple Wizard prompting for 3 pieces of Information.

Task sequence ID:

This entry is UNIQUE for easy Task Sequence.  It could be a word or a series of numbers.  It is completely dependant on you.  What is very important to near (When you get into the end of all this generating  a NEAR ZTI deployment is that the name is used Programatically by MDT.  This means at one point when you get towards pure automation, you will tell MDT to launch this task by it’s Task sequence ID.   I recommend making it sensible so when you go to customize, you don’t have to think too hard about what you would have called it.

Task sequence name:

When you actually get installing, this is the Displayed name for your choice.   It can be very descriptive but I wouldn’t go about writing a 12 page novel about it.  KISS. Keep it Simple Silly.

Task sequence comments:

As you can tell by the amount of space, you can be pretty verbal here.  It could be as simple as “My First Windows 7 deployment” to “Our Corporate Windows 7 Enterprise Image that Ernie the CoOp student made and we’re all placing bets on whether it will work or somehow magically take out the entire network” – It’s up to you.

Here’s an example below


Clicking next we get to the stage where we choose the general “Predefined Behaviour” of this task.  There are (as we can see below) seven basic configurations.


Sysprep and Capture

This sequence when run is designed to do what it says, do a SYSPREP on a live operating system removing the Product key and identifying information and capture it back another location (physical USB, Network drive) as a Gold image.   ALWAYS do SYSPREP on a clean machine as there is a limit as to how many times you can “re run” Sysprep on a system. 

Standard Client Task Sequence

This is my default I work with.  It is designed to ask the basic questions to install the O/S and Applications and then take over when you say go.  If you run this sequence within a live Windows XP operating system (IE: Connecting to a network Share) it has the amazing ability to Migrate the user data on the physical machine, install a clean O/S and then migrate it back.   Most of the time you’ll probably use this one

Standard Client Replace Sequence

This has a simple task in mind.  Prepare a computer FOR replacement (Backing up data and settings, entire systems and then afterwards wiping the system clean)

Custom Task Sequence

A raw slate.   Completely customizable.   Never used it myself personally Winking smile

Litetouch OEM Task Sequence

A variant on the Client Task sequence with a few extra predefined steps added in for OEM manufactuers.  This is scenario where you need the O/S and applications installed,  tweak things up the way an OEM wants to do and and snaps it all shut for a new User.  

Standard Server Task Sequence

Similar to Standard Client Task Sequence but geared towards a server.  Typically you don’t install a pile of applications on a server so a little simpler.

Post OS Installation Task Sequence

A task to allow you to run additional changes to the O/S after install.  Yup.  Haven’t had the need for this one yet either Smile

Now to SAVE YOU TIME if I am trying to setup a Deployment point to just Automate the install of Windows 7, Vista or XP typically I am just using “Standard Client Task Sequence”.  If you’re doing a full scale upgrade across multiple systems you may well want to looking into programming a Standard Client Replace Sequence to capture settings first and blank all the machines out afterwards.   Especially if you’re changing the Physical machines on the user (*SURPRISE!*)

In our scenario I’ve chosen a “Standard Client Task Sequence” and clicked next.  Now you get to see where organization pays off.   If you have MULTIPLE operating systems installed, at this point you are going to select ONE for this task since EASY TASK SEQUENCE is tied about a Single O/S deployment.    So if you wanted one for Windows 7 Enterprise and Windows 7 Professional, you would have to create a new sequence for the second one (or the third, or the fourth or the 35th one)

Here we’ve chosen Windows 7 Enterprise


Clicking next we’ll have one of three options to fill in.   If we have Windows 7 or Windows Vista we have the option of NOT specifying the Product key at this time.   If you have an MAK key you can key it in here right now and have the product key ready installed.  If most of your workstations have OEM stickers on the side or RETAIL, you’ll want to avoid prepopulating a key.  It’s easier to key in 25 digits as you install than removing the product key from the register afterwards to change it.    If you have Windows XP or Server 2003 you will need to use a key.   If you only have an OEM key, you’ll be busy pulling it out on each machine.

So get Windows 7 and make life easier on yourself.  It’s a more cost effective deployment.

Clicking next brings up our “Description page” where we can have the Full Name, Organization and even the default website prepopulated on our systems


Next we can choose to specify the local Administrative password on our installs. No, users cannot retrieve it from a file in clear text and view it.  I know because I tried.  (I forgot a password I assigned to the local Administrator Account in one deployment image I made, It ended becoming a game for a short while of “Quick, join it to the domain or if you forget you’ll have to image it all over again)


The choice is up to you and an interesting side note.  Using Preferences in a Server 2008 or Server 2008R2 environment will allow you to manage the local Administrator account membership and passwords via Group Policy. (But that’s for another post)

Click Next twice and finish (And don’t forget your Powershell script too!)

Now at this point if you were to access your Deployment Share over the network, or have it on a portable drive of some type (maybe a USB?) from within a Live Operating system (or a Windows PE Network boot) you would have a basic deployment that ask you some questions (Like the computer name, whether you want to back up the data, which applications you want to install etc) and afterwards *IT* would do all the work

But this isn’t what we want.  We want a deployment we can pop into a WDS server or USB / DVD media.  We’d like to just Boot up and take it onto a Netbook with a blank drive

Which is where we touch on our next two parts next round,  Selection Profiles and Media

Now we're down to the last of the building blocks.   One of the more important ones to be honest.   It's called Dependencies.

Now in all fairness if you DON'T care about the order the applications go in and DON'T care if your Service Packs and updates are installed WITH the applications you can skip Dependencies.  But after having done a little Deployment I've learned to appreciate them.

Let's try a simple scenario.   You've got an application that can only install IF Outlook is already installed.  Maybe you would prefer the Antivirus is the last thing installed.   Or maybe (just maybe) you WOULD like to have the newest Service Pack for Office installed AS you deploy the operating system. 

Just cuz.

Those are Dependencies.   They're not actually difficult, they're just overlooked many times and forgotten, because to be quite honest we got over the hard part of getting things to install themselves.   "Meh!  What's a simple service Pack?   It'll only take 15 minutes to do afterwards."

That's right, only 15 minutes.  Or maybe it's only a 2 minute hotfix? 

Multiply that by even three computers and setting up a Dependency will eliminate that time already.    And remember, this is not a "one shot deal".   Because the MDT environment we're putting together is very much like a box of Legos where we can build something new by selecting different pieces; this time you spend now can be used on multiple different sites and images.

Dependencies are a part of your Applications.   So in our present environment I have download and imported into my MDT 2010 setup something as simple as the "Junk mail filter" update for Outlook 2007.  I'd like to ensure that as soon as my users get Outlook 2007 they can immediately have the best possible protection against all the "Free stuff" the internet is offering.   I'd like to offer them as few "Investment opportunities" as possible.

So in this case our Junk Mail filter "Depends" upon the install of Outlook happening first.   To ensure this occurs we establish a Dependency within the "Junk Mail Filter"


So right click on the entry for "Microsoft Outlook 2007 Junk Mail Filter April 2011" will pull up it's properties.  This should be familiar it's the same way we edited the application for a Silent Install.   We're now choosing the "Dependencies" tab which will open up and be not so impressive looking.  That's because we haven't added any yet.


So clicking on "Add" will allow me to browse my current imported Applications structure within MDT 2010 and select an application this Depends upon before it's allowed to install.

In this case I have browsed to "Microsoft Office 2007 SBE" and clicked ok.  I COULD keeping repeating this process and establish (That for whatever reason has twisted my mind) that Adobe Flash Player 10 must be loaded as well before the Junk Mail filter is applied.  Because (as well all know) "Flash" is the root of all evil and viruses.  So "Obviously" if Flash isn't installed you'll get no viruses.

No?  that's not true?  That's good because I completely made that bit up.   But we can establish MULTIPLE dependencies if so needed before an application is allowed to install.  Just be adding them to the list


Now you've done a BASIC simple Dependency.  The process is pretty simple.

But what if you need to be more complex?   Say you're installing Office 2007 and would like to have 35 updates, Service Pack 3 for Office 2007 as WELL as the most current Junk Mail filter?

Well THAT is a PERFECT example of an Application Bundle.

Do you remember back when we first imported an application we had an option to choose "Application Bundle" which had no Command line?   An "Application Bundle" is really just a predefined list of Dependencies.   If you were to import one into your list of Applications and call it "Microsoft Office 2007 - All the Bells and Whistles" , you would have with you a single Dependency list.   This list as an ENTITY is treated (when we get to Selections) as a SINGLE APPLICATION (including all the hotfixes and whatever else is in your dependency list)

Take note as well that when working dependencies you CAN move entries up and down the list to make sure a specific order happens there.

Now here's a final piece on Application Bundles.    Think of them as a template for how you'd like Application configurations (At the Service Pack level) to be applied.  Let's just say you'd like to have Service Pack 3 for Office 2007 applied for one Division, but Service Pack 2 for Office 2007 applied for another division.  (Ok, I don't know WHY you'd want to do this.  Perhaps you had some leftover been burritos last night and it SEEMED like a good idea).

If you place a dependency directly on an application itself it will ALWAYS apply.  If you place it within an Application Bundle, then it applies only when you want it to.

So all this prep work.  All this effort.   Soon we'll see where all this is taking us. 

Next up? We begin to make a real image!   We create a TASK SEQUENCE

We are about to import the last of the pieces.  Our drivers.  Because up to this point, we are building a pile of well organized bricks to assemble our image.   One of the MOST important pieces is the drivers.

Our link to choose is “Out-of-Box Drivers”.  Like other portions of MDT 2010 we can (and SHOULD) create folders to sort this into manageable piles,  I like by Driver Type, Operating system and variant (x86 / x64) but you choose what makes most sense to you.

Importing drivers is identical to importing Updates (other than the location) and has the wonderful Powershell script at the end as well.

One of the nicest parts about the Import Drivers feature is that it will dig through and pull in driver structures.  This can be very nice if you have a vendor giving a single folder for multiple drivers but you’re not quite sure which is the RIGHT one for your particular card.

“A Lesson Learned”

But here’s a tip I learned from a great Master of MDT, the one who taught me.   See what the O/S has built in and what will come down from Windows Update.   You need to keep you driver base as clean as possible.


Well let me tell you a story about an ItPro.   An ItPro who shall (for this story) remain nameless.  This nameless ItPro had built an image in MDT 2008.  They were so proud it worked the first time. 

“Muah hah haa" the ITPro cackled. “Muah ha ha haaaa.  I am the Greatest ITPro! I have MASTERED MDT in moments!”

Then the silly fool went mad and imported every Dell driver on the planet.  All of them.  Even ones for components Dell hadn’t even thought of.  For some reason, the previously working “Perfect” install of Windows Vista Enterprise just started hanging on that “oh so perfect” WDS PXE boot.

No matter what the silly fool did.

All seemed dire until the Master of MDT walked to follow up.   The install was so messed up it had to be erased.    But not before he took a good look at hit.

“Young one…” the Master shook his head “Why does your deployment point have 25 gigabytes of drivers for three types of computers?”

It was then the ItPro learned from the Master, to keep it simple.

Drivers are easy to import.   Just learn to keep your list as LEAN and CLEAN as possible.  import what you NEED not what you WANT.

Take that from someone who might just know that poor fellow.

This was a fun story that was true to give us break.   But the facts are true.  Import your drivers, organize them well, keep the list as lean and clean as possible for best results.

We’ll take a quick look into setting up Dependencies on applications next time and then dive into the fun stuff afterwards.  The TASK sequence.

So now we have the ability to Bring in an Operating System, Applications and setup silent installs.  But what’s the one thing that REALLY slows us down on installs?  It’s getting all those updates added and download and (again) manually running them.  

Well here we have a section in MDT called “Packages” and it is within this folder you can play all the .MSU and .CAB files you’ll need to update your systems.

Importing Packages is much like Applications, including the ability to create sub folders to sort them out.   Again with MDT 2010, let’s try to keep things as organized as possible since this makes the creation of our Task Sequences later far easier to be as selective as we need.


I found it is ESPECIALLY important to keep the updates organized to allow you to easily select and deselect what you / want need on your base deployments.   When you run the “Import OS Packages” it literally just points to a root folder and pulls WHATEVER is in their like a giant vacuum.    

Where do you find those darn updates?  You’ve got the O/S and applications JUST the way you like it, or there is a critical Hotfix that causes some single program to work “Just right” and need to get the hyperlink easily.  It’s all stored in the Operating system.

In Windows 7 and Windows Vista, go to your “Windows Update”.  To get the update and download it all over again go to your Windows Update, View update history on the left hand side to get the complete list.


Choose “View Details” and the corresponding box will contain two Hyperlinks.   Under “More Information” will be the Hyperlink to the Microsoft website where you should be able to get details about not only the update but where to download it.

You’ll want to make sure you have it organized since you may want to have to option of applying XPmode (as an example) on specific workstations or not.  In order to do that you’ll need to ensure it is well organized.  You’ll want those updates for XP separate from Windows 7.  The more cluttered it is with stuff it has to reject, the slower your overall install.

There are SOME updates (IE Service Pack 1) which do NOT fall into the Packages Category.   Office 2007 updates and many other Service Packs are simply executable files.  Those would be actually be imported in with the applications and would be treated as part of a “Bundle”

“But if we need to ensure certain Service Packs are applied AFTER the software is installed?  What if I want to make sure the Antivirus Agent is installed before Office, I need to make sure my Operating System Service Pack is applied before any applications are installed….”

Since these questions refer to things that “DEPEND” on each other we’ll get into that with Dependencies later.

Next time we’ll get into Importing the drivers you’ll need injected into your installation.

Now with deployment I did make a little fib.  There is a sixth Scenario.   That ‘s when you Deploying a Microsoft Office application.   It’s not that it’s hard but it’s far better in a special way.  Since it is probably one of the most common applications you may deploy, MDT 2010 has special attention paid to it for specifically Microsoft Office to allow for as seamless and as CUSTOMIZABLE install as possible.

Office 2007 / Office 2010

With Office 2007 / 2010 this is done by way of the “Office Customization Toolkit” .  Typical VL (Volume License) Media will have this preinstalled into it as will Enterprise editions.  

You can confirm if your version of Office has the kit built in (On 2007 / 2010) by checking the Root of the media for a folder called “Admin”


If it does you’re good to go.  If however it does NOT you’re still not out of the game.  It just means you have to download it via way of the “2007 Office system Administrative Template files (ADM, ADMX, ADML) and Office Customization Tool version 2.0“ for Office 2007 or the “Office 2010 Administrative Template files (ADM, ADMX/ADML) and Office Customization Tool”

Simply download the appropriate version for your version of Office, and in the case of the Office 2010 the 32bit or 64bit to match your particular media.   Double click and extract the contents to a folder.  Within these extracted contents you will find a small group of folders (Your Group Policy Templates for that particular version of Office) and the much needed Admin folder.

Simply copy the Admin folder to the root folder structure of your media.  If of course you are using DVD media, you’ll want to copy it to a folder on the hard drive FIRST and of course copy the Admin folder to THAT root folder structure.   (See Example Visio 2010 Media without and with folder added)


Once your Media is prepared, import it into MDT 2010 into an appropriate folder destination in MDT 2010 as you would any other application with Source Files.  Once it has been added in, you can right click on the properties of your Office install in MDT 2010 and see a new tab called “Office Products”


This is unique to Office 2010 / 2007 and is your one stop shop when getting that Office deployment automated.  Clicking on the tab will present us with a screen with some new options of course and a few extra buttons.  We’ll go over the screen options after.  Right now we’re interested in that big beautiful button in the lower right hand corner called “Office Customization Tool” .  Clicking on that will launch the “Office Customization Toolkit” for that particular version of Office.

Unlike most of MDT, the OCT will require local Administrative rights to run.  If you run WITHOUT the Administrative rights you’ll get a weird MMC snapin error possibly and after it pukes out, it will indicate WHY it puked out. (It’s my blog, I’m allowed to say “puked”, so nyeah nyeah)  The actual OCT interface is identical to both versions.   When you click on it you will be prompted with a message indicating where you need to save the .MSP file.  This will be within the folder structure of your Deployment Point like so….


As the OCT interface appear you will be prompted to create a new configuration file or open an existing one.  If you have already customized your Office install prior to this you can open up an existing MSP file for it.  Right now we’re creating a new one.

The Actual interface for OCT is pretty simple.  A list of options on the left and things to fill in on the right.  


There are typically a few that most of us will be interested in.

Install location and organization name

Where you do want Office to install and what Company name would you like prepopulated in the Organization field?

Licensing and User Interface (KMS and MAK license keys ONLY)

What product key do you want in this product automatically upon install?  Do you want to PRE accept the End User License Agreement so the user ISN’T prompted on install? What display level for the application?  Full (everything under the sun) Basic (A simple progress bar) or None (Voodoo magic happens in the background and nobody sees anything!)

Three additional options are.

Completion notice (Yes I do want to see a little ‘I’m done everything’ displayed on the screen) If you want a truly silent install, don’t check this off.  The user will have to click on something to continue

Suppress Modal (Don’t show me any errors, if it fails, it fails)

No Cancel (Nobody is allowed to cancel (except Administrators that are trigger happy on the Task Manager and MSIEXEC)

Remove previous installations

By default it will remove all prior versions of that particular Office product.  But you CAN customize things so that say you have Access 2003 left behind instead of behind overwritten with Access 2010.  Here is where you at least say “Don’t erase the old one or ONLY erase the following ones

Set feature installation states

Expand this and you have our old familiar “What options am I installing” Office interface upon setup.  This is EXACTLY what you think it is.  Choose what you want or don’t want (Including which Applications you don’t want)

Configure shortcuts

Administrators will love this.  I swear I don’t know how many times I’ve encountered somebody complaining that “Because there is no Shortcut to Word on their desktop it was never installed”.  If you encounter that situation, this is your chance to put that INTO the actual installation.

There are a pile of other options in the OCT but there are other articles that dedicate better time to it (or perhaps I’ll write one later).  For now, we have our “Quick and Dirty” explanation of OCT.   Now click on “File / Exit”, the “X” in the upper right hand order or even “ALT-F4” if you feeling like a Keyboard Guru.   It will ask you where to save the MSP file.  Just remember the box that popped up BEFORE you started all of this.  The OCT will NOT default to the folder containing your Install media in the Deployment point (I personally think it should).  Save the file with any name you choose in the office folder called “updates” for your version of Office.

Keep in mind that if you want MULTIPLE versions of the MSP file in the Updates folder you will have to specify them in your SETUP.EXE when calling Office up.   By default, SETUP.EXE will apply whatever MSP file it finds in the Office Updates folder.

When you click on the “Office Products” tab you’ll notice several fields I had you ignore last time.   This is because the OCT eliminates the need for them with it’s more secure MSP file format.   But as I mentioned before, copies of Office using MAK or KMS keys (Typically Enterprise / Volume License) are the only ones that can have their Product key in the MSP file.  This is a FEATURE of getting the better version (enhanced security).  

But you CAN still use this tool in a Small to Medium size business setup.  Just click on the pull down menu beside “Office product to install” and change it from “<Let Office Setup decide> .  Our new options are available under CONFIG.XML settings.

Office Languages

If your media supports more than one language, which one?  Check off the box or boxes that apply

Product Key

Your 25 digit product key.  If you are running an MAK or KMS version, DO NOT ENTER THIS HERE, use OCT to store it INSTEAD.

Customer Name

The default Company name Office should contain

Display Level

Just like in OCT.  None, Basic or Full.  Works the exact same way

Accept Eula

Pre accept the End User License Agreement for the user so they don’t get pestered with it upon install

Cache Only

An interesting option.  This allows you to store the INSTALL MEDIA on the workstation without installing Office.   Handy (I guess) if you want to spend the time dumping files on a local computer.

Always suppress reboot

Don’t let the computer reboot on Office install.  This is an important option in case something decides to make the computer reboot.  This ENSURES Office installs 100% and a reboot only happens AFTER it’s done installing

Click Ok and you’re done.  That particular Office product should now just launch if you run SETUP.EXE (No additional parameters needed by default)

Here’s a small piece I ran into as well.  If you want to leverage features of the OCT with a Retail or OEM product it will work, but just make sure you DON’T fill in anything under “Licensing and user interface”.  Also if you go to edit an existing MSP file and click on the license key field, you WILL have to rekey in that field.  That is INTENTIONAL so that people don’t try to pull out the license key if they get their hands on the .MSP file.

Now if you have an OEM or RETAIL install you have a few things to remember.   You MUST remove the license key AFTER install.   Having said that we can make this happen.  Within Office 2010 it’s incredibly easy as Microsoft has supplied a vbScript application called OSPP.VBS (By default under your Microsoft Office\Office 14\ Directory)

Double click on this file to launch the instructions on how to use it (Built in). Executing a


(Assuming of course that THAT is your 25 digit product key) will remove it from the Registry so the next time Office is installed it will prompt for the key.  But there’s also TWO cooler options


will replace an EXISTING Office Product key with a new one and better yet


Will activate your Office products with whichever predetermined activation server you have (Default internet)

With Office 2007 you have to remove the subkeys under a Registry key (HKLM\Software\Microsoft\Office\12.0\Registration) which removes ALL your License keys for Office 2007.  I’m not certain this is a supported solution either but it’s good to know if you do HAVE to change the Office 2007 Product key.   Upon the first launch of Office you will be prompted for the new Product key.

Microsoft Office 2003

If you need to deploy Office 2003 it’s a similar process but you need to download the “Office 2003 Editions Resource Kit Tools” – It provides a similar interface to customizing ANY Office 2003 install.

Once installed you’ll find it under your “Microsoft Office Tools” there will be an entry called “Microsoft Office 2003 Resource Kit”. Just select the option “Custom Installation Wizard”.  

This is a simple step by step wizard.  Click Next, Browse to the .MSI file from your Office install (typically off the root of your Office 2003 install media).  You will be asked to created a NEW MST (Windows Installer Transform) file or open an existing one.  Let’s create a new one to start.  Just give it a name you’ll remember.   At this point it’s very similar to the OCT except it’s a Step by Step prompting Wizard as opposed to a navigable menu system.  Even the options.

The biggest part will be that running setup.exe does NOT default to a silent install.  For this you must supply a command line Parameter.   When you’re done with the “Custom Installation Wizard” it will supply you a sample one based upon your present location.

setup.exe TRANSFORMS=".\CustomOfficeInstall2003.mst" /qb-

Drop this into the entry for “Quiet Install Command” and you’re on way to a silent install of Office 2003 to boot

Next time we’ll look at getting those Service Packs and Additional Packages into the MDT 2010 environment

Now that we’ve imported an application we should adjust it’s Parameters to allow for an Automated install.   If you working on a Microsoft Office Product, skip this section.   An automated Office install takes a special explanation unto it’s own.  It’s not difficult but I’d rather focus on it all by itself.

Let’s choose an application we’ve imported (in this example I imported the “Adobe Flash Player”) by Right clicking on it and choosing properties to see what the configuration looks like


This will pull up a screen with three tabs.  “General", “Details” and “Dependencies”.  We’re going to focus on the “Details” in this section since it contains the part we’re truly interested in, the “Quiet Install Command” line.


Now a word of warning for those of you who just got your hopes up.  Just by putting something there does not make MDT yell out “SHAZAAM” and make a silent install magically happen.  You will have to find what to replace this with to make this executable run in either a “SILENT”, “AUTOMATIC”, “PASSIVE” or whatever wording you think is appropriate for “Run this darn thing with no user interaction required”

For the most part we can break into five groups.

  • An Executable with a documented parameter
  • MSIEXEC.EXE based applications (.MSI file)
  • An Executable that HAS a parameter but not well documented
  • An Executable that HAS no parameter but happens to be a wrapper for an MSI file
  • Applications that must be captured on a reference workstation

The cool part is there really ISN’T too many other scenarios and once you get the knack you can easily repeat these with almost ANY application. 

Well except Microsoft BOB.  I couldn’t find the Silent install for that.

In my experience for the most part I have managed to hit the first two with great success.  Those are the easy ones.  The latter two occasionally.  The fifth situation calls for using an Application like “Wininstall LE” (or various other application packaging software solutions) to capture the application AS it installs.

If you get into this scenario you will need what is known as a  “reference workstation”.  It is ideally a physical or virtual version of a typical workstation in your environment that you can rollback.  With Virtualization this is now a very cost effective reality to most IT people.

What these particular applications really do (to over simplify it) is record where the application dumps the files, what registry changes they make and anything DLL’s that they register.   This recording is generally turned into an MSI file which now allows it to fall into the first two categories.

The advantage of a solution such as this, is it allows automated deployment of applications which were not designed for it.  The drawback (at least in my experience) is it generally does NOT cross operating systems well unless they are very close cousins (Vista/Windows 7) (2000/Windows XP)

Most executables designed to install will have some nice simple command line parameters such as /silent /quiet /install or (haven’t seen this one yet) /doitrealquietsotheuserdontwakeup

In many cases you can find out quickly be (believe it or not) running the application with a /? or /help or even just /jibberish to cause it to crash and complain you didn’t supply parameter /x /y or /z

Most of the bigger vendors will have their stuff well documented.  But in some cases they don’t.  Hey it happens.  But often I’ve found the ones that don’t document it turn out to be just running the EXE as a wrapper that extracts  an MSI file at any rate.   Most of the time taking a quick look in your personal %TEMP% folder while the application is installing for NEW folders created just about the time you started the install. 

Most of you will (just by sheer co-incidence and often a bit of luck) find the ACTUAL folder the application extracted to including it’s MSI file.  Grab all those goodies before the application finishes the install, releases you’re watching it and cleans up it’s mess.    Having that version of the installer I find makes deploying the application far easier

With an MSI file it’s actually usually quite easy to install

Simply keying in


will show you all the wonderful parameters available to you.   But rather than getting a dizzy spell I’ll give you the “Coles Notes” version.


This is the most basic line you can pass to launch a MSI file called FILENAME.MSI that will generate a non interactive session with a simple progress bar as it installs.  Is some situations you will need to pass parameters to the MSI file to have it default certain options (Like the name of a server or IP address it should point to).   If you get to this level and have support with the vendor, save time and ASK.

If you don’t grab an application like “InstEdit” or any cheap MSI editor, make a copy of the MSI and browse the contents to see the variable names.    This is a bit of an art unto itself but if you find the MSI file has an entry called WEBSERVER that has a NULL value and should the name of the Webserver your application should point to you can assign it a value externally by keying in (on the same line)


Of course if you don’t have that particular property available you’ll probably trip an error, cause the application to stare you down and wag a digital finger at you.

Now here is the easy part.  ONCE you have figured out what command line to run to make your application just putt along? You need only edit one line in the configuration for your application in MDT.  Go back to that details Window and replace the line within “Quiet Install Command” with the executable line you’ve figured out.

In the case of the Adobe Flash Player 10 it was particularly stubborn.  It wouldn’t tell me anything of use but I got my answer easily doing a Bing on “Adobe Flash Player silent install” and got the results from the best resource.  Real people who use the software. 

This is the other thing you’ll find out.  JUST BING IT!  You’ll probably find you don’t need to re-invent the wheel to make it happen and others may have solve the problem for you.

So it turns out the parameter was pretty simple.  Add a “-install” to the end of the application.


And voila.  This application (Adobe Flash Player 10) is now an available resource to MDT to be used as a silent install.

Next time we’ll look at Customizing various Office products for an Automated install

Last time we imported the O/S into MDT.  This time we’re going to Import applications.

Applications are very much like importing an Operating system with one exception.  There are minimal to NO restrictions out what qualifies as an Application.  In a nutshell if you can run it and it does something to install code on the Operating System?  That’s an applications.  Even a good old fashioned BAT or CMD file.  And that’s an important strength to know

First off the importing part.  Within the Deployment Workbench, Right Click on Applications to see “New Application” and “New Folder”.  Like the entry for Operating Systems you can Create an organizational Folder Structure.   This is one spot where Organization will REALLY pay off.  


You may find across all systems you will have some Common applications which you should have on every machine such as Acrobat Reader, Flash, Silverlight, etc and then applications would you must restrict based upon Licensing and sometimes just simple need.

Breaking THESE at least down into folders will make your life far easier in the long term as you will then be able to support multiple deployment configurations far easier in our later configurations.   For now let’s choose “New Folder” and name it “Common Applications” by following the Step by Step wizard.  It’s simply to ask you to name it, click Next twice and you’re done (Well you’re done after you hit Finish actually.  Like each section you’ll see that wonderful option “View Script” which allows you to copy that to the side into a Giant Windows Powershell script for later use.

Let’s run through the “New Folder” Wizard two more times again and Create folders off the “Applications” called “Contoso Programs” and “Fabrikam Programs”.  

This will give us a nice base structure for storing applications that may be unique to two different companies or Division but can both safely (From a licensing standpoint) leverage a common base of free software.  When you’re done it should look like this when you click on “Applications”


Now we import an Application.   When you choose “New Application” you will be presented with three different source types.

Application with Source Files

This will be any location containing the file structure to install an application.  It does NOT necessarily only need to be the folder with the application calling the install.  It should be the entire structure from the lowest folder down containing all files you WOULD or COULD deploy.   So for most programs you would just simply choose the base folder on the DVD or CD (for the simpler route). In some cases it may just be the folder containing your MSI file to start off with.  

When in doubt, for guaranteed results, take the bigger of the two.  You can always improve and refine this later.  This is one of the biggest strengths of MDT in that I can add and remove pieces without completely destroying all my work.

Application without source files or elsewhere on the network

First time I saw this I did a double take.  “What do you mean without source files? Is the code INVISIBLE?” That part still makes no sense to me but in this case we’re referring to an application where MDT is just to POINT to the installer rather than bringing it into the repository.  This is a very fast setup in an in existing network since nothing is actually copied.   If you need to make this MDT deployment point 100% portable (As in you’re storing all the data on a USB drive or External hard drive) you may not want this option.   If you’re in a large infrastructure where the applications and install media are updated centrally by another department you may want this.

Application Bundle

This is actually more of a Grouping/Depends on Mechanism.   A perfect example would be “When I am deploying for Windows 7, I will need shims for Office 97 but not when I am installing on Windows XP”.  In this scenario you would use an “Application Bundle” which simply says “Use the following Application but make sure all of this stuff is installed with it and IN a particular order”

You can add dependencies to your Application as a whole, but the change becomes more global.  This allows you to make special bundles of an Application or files.   It is up to you to leverage this how you need.

Let’s at least start right Click on the “Common Applications” folder we created and choose “New Application”.  We’ll select “Application with source files” and choose next.

The next screen will ask for some basic information on the application.  It COULD be all jibberish if you wanted but it will make far more sense if you populate the fields with sensible and useful information

Publisher (Optional)

Who made this silly thing?  Microsoft, Adobe, IBM, Symantec, or your Cousin Ernie (A simple name will be fine)

Application Name (Mandatory)

What is this cutting edge application called?  Office, Reader or Automatic Taco Cooker?

Version (Optional)

Which version ? Retail? 2010? Version 7 3/5 or just “X”.  The Details are up to you

Language (Optional)

English, French, Pig Vulcan.  Again put in what makes sense, not necessarily what is “funny”.  Deployment is not a time to test the client’s “Sense of Humor”

Click on next and Browse to the physical folder, CD, DVD, Mapped Network Drive or USB key that has the install files.   Depending on how much you have to import, how fast your hard drive is and your general perception of Space and Time, this could take from 3 microseconds to 3,000,000 years.   But in general a standard application shouldn’t take more than a few minutes.  Maybe 10 for a really big one.  

If you happen to have a 3 Petabyte application to import, at this point I’ll be honest; I have no clue on THAT one.

Click on Next, the following Window will simply display what the Application will display as based upon what YOU provided.


You next screen will show you the working folder the application will sit in as well as prompting for the actual command line to run the installer.  Now don’t worry right now if you don’t know how to perform a silent install, that can be edited or added later.  Right now just fill in the EXE, COM, MSI or even CMD to launch the Installer for this application.  You don’t have to fill in the exact path name.  If it’s it the root folder you’re done.  If it’s a folder just under then only key in that name and the Executable name



Click on Next two much times, One for the Summary screen and one more to make it go.    Click Finish and you’ve imported an Application.   (And of course don’t forget the Power hidden under the View Script button either)

Are we done?  Of course not.  Unless you like clicking “next next next ,custom type type, next next” when a program installs.

That’s next time when we’ll look at editing your Command line in the Applications folder and show you Tips and Tricks on just how to setup a Silent install on an Application

Now that we have a Deployment point to work with, we need to Import an Operating System.

With MDT 2010, although we typically may think Windows 7, It is completely perfect for deploying any Windows Operating system as far back as Windows XP.

It is not, no matter how hard you try, a very good Deployment system for Legacy setups such as Windows 2000, DOS/Windows 3.1 or even that copy of CP/M 2.2 you found in the back corner on eBay.  Really, don’t bother trying.  It’s a geeky cool thought but a wasted endeavor.   There are far better things to pursue your time with;  Like organizing your collection of slightly stale Babelfish and old pennies.

On a more serious point,on any CURRENT operating system from Microsoft, it is a beautiful thing to work with and a very simple task.


When you initially right click on “Operating Systems” to import an O/S you may be tempted to just Import it and go.  From my personal experience, I recommend you actually break it into organizational folders.   The more time you spend in getting MDT organized as you use it, the far easier it will be down the road when you get into Selections and Task Sequences.

Yes, it WILL just work if you just dump everything into one folder, but also try to plan things out in the short term and it will pay off in the long term.  Remember too, those Powershell sample scripts will allow you to EASILY replicate this. So go ahead and spend the time now.

Right clicking on “New Folder” is pretty simple and just creates a subfolder.   Since I’m pretty certain everybody here has created a file folder in Windows at least ONCE in their career, we’ll skip on that ever so challenging part Winking smile

So let’s start with Importing an O/S into a base folder.   .   Right Click on “Operating Systems” and choose “Import Operating System”.  It will bring up a Wizard prompting us for three available source types.

Full set of source files

This is standard root directory structure and current Microsoft operating system.   This will be any current CD/DVD or ISO file with Virtual CD mounting software.   Even if you have the file structure copied to a physical folder will work fine.

Custom image file

This would be an example of a .WIM file that has been captured, or possibly other variants (such as a customize WinRE environment or even the DART toolkit)

Windows Deployment Services images

This allows you to leverage existing images on a Windows Deployment Server to create physical deployment media.

For this series we’re going to deal with Windows 7 media. It is almost an identical process with Windows XP or Windows 7.  The variants will be whether a product key is required or not (you WILL require it with Windows XP).

So on our first screen after choosing “Import Operating System” we’re going to choose “Full set of source files” and simply browse to the root of a DVD drive Containing Windows 7 Professional.  One of the coolest things about the process (as seen by the screen below) is that it is smart enough to identify the Operating System and will automatically name the folder based upon that.  In our example, our example of 32bit Windows 7 will be automatically named “Windows 7 x86”.  Clicking next gives us a progress Window like previous Wizards until we get “Finish” and our “View Script” button.


When done you will see an entry under Operating Systems like our example here for Windows 7 Enterprise.   An import of non Enterprise media will show multiple available versions.


You could have something as simple as the setup we see here for the operating systems or even a Multi Tiered folder structure.   For if you were a Consultant working for multiple clients on Deployment, you could ACTUALLY build a repository of the various operating systems you deploy.

Next time we’ll look into Importing applications into MDT 2010

With MDT installed and ready to go on our system, we need to get the basics setup.   First off we should point out that before you go digging online for documentation, EVERYTHING you need is built into the system.  An incredibly detailed help system with tons of information.  Step by Steps.   So before you go ANY further make sure you click on “Documentation” on the Upper left panel


If you’re trying to figure out anything, I recommend the Quick Start Guides.   They’ll get you up and running in a very efficient manner.  Note especially for those of your deploying Systems Center Configuration Manager 2007, there is an excellent set of instructions predefined just for you.   But even if you aren’t deploying SCCM some of the details on how to do more complex deployments are in there, make excellent reading and can be applied to smaller environments.  Even if you don’t have SCCM.

The next key task is to create a Deployment Point.   All that is, is a Prebuilt folder structure populated with some predefined XML files, Vbscript files that will be the base for your image.   As you  import software, images and build configurations; this will be your Master repository for you to build on.

So to create your first Deployment point, Right click on “Deployment Shares” and select “New Deployment Share”


This will launch a simple Step by Step wizard that prompt for a physical location, Network share name and Descriptive Name

The default location is “C:\Deployment Share” but you can choose any location on the local computer.   It will also default to a Network share name on the computer with MDT as “DeploymentShare$” with a Descriptive name of “MDT Deployment Share” .  You can choose any names and descriptions you like. But I personally recommend sticking with the Hidden Share concept for (“$” on the end of the share name)the name since it means people can’t randomly browse, mess or ruin your work while you’re, well you know, WORKING on it. Smile 

There are some key questions it will prompt you for next.

“Ask if an image should be captured”

This is an opportunity to to establish that images created from this environment COULD be captured a .WIM file.   If you choose this an option, it means you could build what is referred to as a “Gold Image”.  For a simple deployment you may not want this option.   In our sample scenario we’re to going to leave this box UNCHECKED (It is enabled by default)

“Ask user to set the Local Administrator Password”

Now you in the back of the room.  STOP Laughing.  Although in a corporate environment you may not want this, remember that MDT is a TOOL that could be just as easily be used for Residential deployment.  Yes, large big corporation having the user’s set their OWN local Administrator password would not be such a smart move.  For home however, this might make sense.  But it is UNCHECKED by default

“Ask user for Product Key”

Now again, depending on your setup, you might want to exercise this option.  Computers with OEM product keys for the operating system are a perfect opportunity to leverage this.  Or if you have an environment full of FPP (Retail) copies,  Asking for the product key at Deployment time probably isn’t a bad idea.   With a Corporate setup using KMS or MAK, you may not want to worry about this.

When you’re done you’ll see a quick summary of what it’s about to do.


Click Next, let the magic happen and the work is done.  But here is the coolest part (Did you think I would miss an opportunity to NOT mention my nearest and dearest friend,  Powershell?


That’s right on the lower right hand side is a “View Script” button.  That’s because ALL of this runs through Powershell and is thus an easily scriptable repeatable task.  As you run through ALL of the Wizards in MDT 2010 you’ll find they are Windows Powershell scripts.  Click Finish and you’ll be looking at your first Deployment point.


If you were to look at the File system, you’d see it’s simply a reference point to the folder structure wherever you created it as can be seen above

You can have as many deployments as you want or need, your only restriction being physical storage space.  And the laws of physics of course Winking smile

Next time we’ll show you how to begin with the fun stuff and Import an Operating System

In this series – we’re going to present all the steps that should be required to not only setup MDT 2010 for a standard LTI, but all the techniques needed for Automated application installs  More so by the end of this you should be able to get yourself down to a near ZTI deployment on USB.

The first thing you need to know is that MDT 2010 is NOT a server application. It is a tool.

A tool that will help you tune your media from Windows XP to Server 2008R2 into a more simplified install.  It can tie in applications, specific settings, updates, drivers.  Everything you would need to get your Workstations and Servers installing with minimal effort upon the part of yourself and your staff.

So the first part you need is to get the media.   This is just a matter of doing a Search on for “MDT 2010 Update 1” which as of this writing is the most current release of the toolkit.

Click here to download MDT 2010 Update 1

Take note the only difference between the 32bit version and the 64bit version of the software is that is designed to run optimally on a those specific versions of Windows.  Functionally and feature wise they are identical.

Just download and install the application, take all the default settings, and in moments you will have a basic install of MDT 2010.   Now to access it just go to the start menu and

To start the application the first time go to “Microsoft Deployment Toolkit” off the Start Menu and choose “Deployment Workbench”


Now we’re going to “assume” you are on the internet and letting the Toolkit do all the work.   When you get into the Workbench choose “Components” on the left hand side.   The Window will now display a screen like so


Anything that says “Required” is well… REQUIRED (pretty obvious fortunately).   Click on each link and choose the “Download” button as it appears to download the required components. 

If you’re deploying MDT on a regular basis (Say you’re a consultant?) Just make sure you download the “Windows AIK for Windows 7” and store the ISO file away.   This is something you can install before MDT 2010 to save the time on downloading on a regular basis.

If you install the Windows AIK separately, like MDT; just take all default options.

Next time we will actually start into the fun stuff and create a Deployment Point.