MDT 2010–From Zero to Deploy–The complete series

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

MDT 2010–From Zero to Deploy–Part 15

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 ContentDeployBoot . 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!

MDT 2010–From Zero to Deploy–Part 14

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.