How I stand up a new MDT environment, Part 7

Ok, break time is over yo….

Step 5 The Task Sequence magic

So lets do another properties on our Task Sequence and go to the “OS Info” tab, which will look like this:


Click “Edit Unattend.xml”

Now this is why I (we, you are following along right?) selected an x86 version of 7 to do the console in…

x64 imagex.exe can’t catalog a x86 WIM.  No really, its documented here.

The important bit:

Different binary versions of Windows SIM cannot create catalog files for some Windows images of different architecture types. We recommend using the 32-bit version of Windows SIM to create catalog files because this version can create catalogs for all Windows image architecture types. The following list describes the Windows SIM architecture types and catalogs that can be created for each Windows image architecture type.

  • x86 Image Manager. Can create catalogs for x86, x64, and Itanium-based Windows images.
  • x64 Image Manager.Can create catalogs only for x64 Windows images.
  • Itanium-based Image Manager.Can create catalogs only for Itanium-based Windows images.

So, the take-away here is always use a x86 host and you don’t have to worry about not being able to catalog a WIM.

That brings us to this screen:


So lets do some fun stuff…

My kids will likely want all games, so lets make them available at install.  (you may want the reverse, that’s just as easy)


And then search for games (you didn’t think I had all this memorized did you?)


Double click “InboxGames” and then voila, it adds the setting to the unattend.xml for you:


Ah, already enabled….why?  It’s Home Premium not Professional.  You probably are seeing it a little different.  But that’s the basics of how to do stuff in unattend.xml.  Do a find, find the setting, add it and set it.

ONE TRICK, if you have a pesky video driver that can’t figure out his resolution and you end up with a widescreen laptop without a widescreen resolution at deploy, you can set the resolution to 0 and force it to AutoDetect at the driver level, just an fyi.

So once we’re done with the unattend.xml, we’re ready to fire up a task sequence in a VM and do a capture, applying updates and whatnot!

How I stand up a new MDT environment, Part 6

Step 4.1 The Task Sequence magic

Now that the Task Sequences are created, its important to note you are NOT done here yet.  It is not yet soup…

Before we proceed any further, I typically implement the changes the Deployment Guys recommend to add your own custom actions to the Task Sequence editor, documented here.  I implement the stock change they document.  After that I restart my workbench so I can see the changes.

(Before and After)

image  image

So lets Right Click one of those Task Sequences you’ve created and select Properties, then the Task Sequence Tab, which should get you to where I am in the pictures above.

A couple key things you should probably be doing in a reference build, enabling Windows Update (pre and post application install).


Also, disable “Enable Bitlocker”, no need to try to Bitlocker our VM for the reference capture…

Also, on “Install Applications” I specify my bundle:


This is so in the Capture Task Sequence I don’t get prompted on what applications I want to install, I just breeze through that part of the deployment wizard.

Next thing I do is modify my customsettings.ini aka Rules for the Reference share.

So hit ok on that Task Sequence properties window and go to right click on the Reference Share root and select properties.


And click on “Rules”

Here are some things I add to my Reference Share properties:

(All of these are referenced in the Toolkit Reference.doc in the optional print ready docs)


_SMSTSOrgName=Jeffs Capture Machine
TimeZoneName=Eastern Standard Time

My bootstrap.ini gets modified as well:


DeployRoot=\\mdt-share\Reference Share

I then Right Click my reference share and select “Update Deployment Share” so my changes to the bootstrap.ini get written to the WinPE.

How I stand up a new MDT environment, Part 5

Step 4.  Task Sequences

So now with Operating Systems and Applications added to the console, it’s time to add a Task Sequence or three…


I always give my Task Sequences an ID of a number.  You can use anything, but I like the numeric relevance, and its easier to type if you end up specifying a TS later…

Anyway, fill in the wizard already!  Smile


This is a “Standard Client Task Sequence”


Pick an Operating System…


No point in specifying a product key, we’re going to sysprep this image…


None of these fields really matter, this is for the reference image, and our specifications on the Deploy side will overwrite this stuff…


Doesn’t matter what local admin is, again, we’re sysprepping this and everything will be overwritten by Deployment…


Next, Finish, and done!


But that was just creating the TS, not modifying it, which is much more interesting.  But, time to get the kids to bed first…

How I stand up a new MDT environment, Part 4

Step 3.1 App Bundles

So at this point you’ve imported/added your applications and are wondering why I created a folder named bundles…maybe?


These are groupings of applications so we can force feed a bundle of apps onto a build, rather than selecting them one at a time in a wizard….

I’ve defined a x64 and x86 bundle here.  Both are empty, but not for long.


So here I click “Add’” and start selecting applications that I want on my x86 builds.


Same for my x64


Now I’ve got my app bundles, its task sequence time.  But first, time for dinner…

How I stand up a new MDT environment, Part 3

Step 3.  Here come the apps!

Much like the Operating System area, in the Application area we want to create a logical folder structure.  These are applications we may want to cook into our reference image.

In the end, mine looks something like this (I’m building out a new MDT 2012 site here at home, so these are apps I install on my home machines).


But these are just folders!  Where are the APPS?!!?1111!bbqlazers!

Ehm, Ok, here they are, we’ll start with Office 2010:


Right click the folder and select New Application.

Select the default radio button:


Fill in the fields in the next screen:


and hit next.  For Office, mount the ISO of Office 2010 and point it to the architecture you want to install.  I’m picking x86.  For other applications, pointing to the directory with Setup or the root of the CD should work mostly.

Hit Next and note the directory its creating, make sure it makes sense.


Then hit next.  On the next screen, the command line is where you’re going to want to put in the silent and whatnot install switches. Office though, MDT will do for us, so I’m going to be lazy and just put in setup.exe.

For other apps, you can contact the vendor to get the silent switches, or use the awesome website


Next will show you the summary of what you’ve picked.  Then next and it will copy from the DVD.


Office and MDT are pretty integrated.  So you can go to the properties of it and there is an extra tab from all the other applications.  This will let you do your office customizations and whatnot.


So after yours is done, wack apply.


After hitting apply, then doing the drop down at the top to None and Apply, and then ProPlusr and apply, Details should look like this:


See, the switches are now in place.  We have an application.  Now import the rest of your applications (with silent switches if possible) and continue to the next blog post.

How I stand up a new MDT environment, Part 2


Step 2.  Import OS into the reference share

So mount an ISO of the OS you want to capture and deploy into Hyper-V as the DVD drive of the MDT-Console VM.

Then in the MDT workbench, right click the folder “Operating Systems” and create a folder for that OS.  Then right click that folder and select import.


Make sure you keep it on the “Full set of source files” and hit Next.

Then select the root of your mounted ISO as your source.


The destination directory name is NOT the name you set for the folder in MDT workbench, but is the flat file system directory.


Then we are at the Summary, which should be fairly logical and look something like this:


Then it will import:


When its done, it gives a summary and a finish button.  Click it and witness the power of this fully operational MDT Reference Share!  Muwauahahahah

Er, sorry, yeah, so note that I imported Ultimate, but look what I get:


Multiple OS’s.  Anyone know why?  That’s right, the Ultimate WIM has the previous editions in it.  Do they take up extra space?  No, not really.


So now we have an OS.  Rinse and repeat for all your OS’s you want to service in the reference area.

Then, lets Right Click the MDT Reference Share in the tree and select “Update Deployment Share” so we can create the initial WinPE isos.


Select the defaults, next next and let it run.


Once this is done, we’ll be able to craft a task sequence and do some customizations.

How I stand up a new MDT environment, Part 1

There are many MDT environment setups, this one is mine.


Step .1  Pre-Flight

I use a 2008 R2 SP1 Server as my base.  I enable the Hyper-V role on it and create 2 VMs.  Half of you reading this are going to say “But we’re a VMWare shop, we don’t run Hyper-V.”  Ok, so stand it up like this anyway.  It’ll make your life easier when you are creating your reference images to be using Hyper-V, where all the drivers are natively available instead of having to provide VMWare drivers that you are just going to strip out with a sysprep anyway…

So, 2 VMs, setup as thus:

VM1 is a Windows 7 x86 SP1 install.

This VM I name MDT-Console, give it 2 processors and 2 GB of RAM, 50 GB of space and install WAIK and MDT.  I install Office 2010 and download the “Optional – MDT 2010 Update 1 Print-Ready” to this VM.

VM2 is a Windows 2008 R2 SP1 install.

This VM I name MDT-Share, give it 2 processors and 2 GB of RAM, 200 GB of space (1 big volume) and create 2 File System Folders and Shares, “MDT-Reference” and “MDT-Deployment”.


Step 1.  Establish our shares.

To make things simple, I domain join my 2 VMs.  I permission the account I am using on the Windows 7 VM1 to full rights on the VM2 shares.  I then open my MDT console (I pin mine to the taskbar in this VM) and create the reference and deployment shares by clicking on “Deployment Shares” in the console and selecting “New Deployment Share” which invokes a wizard.


When I do a \\MDT-Share\ it autofills…


I then select my Reference Share, cause I want to establish it first.

I name it (logically) MDT Reference Share in my console…


On the next 3 screens, I leave the “Capture” checkbox checked, because it’s a reference share, where we are going to do a lot of capturing. <next>

I leave the Administrator question checkbox blank/default. <next>

I leave the product key blank/default. <next>



Awww yeah, now we’re cooking with gas.


To create the Deployment Share, I basically do the EXACT same thing, except I select and name it Deployment instead of Reference, and I uncheck the box to “Ask if an image should be captured”…

Which leaves the console looking like this:


How to collect a netmon 3.4 and xperf kernel trace and stop when a problem occurs.

So at a customer location the following question was posed to me:

“In our VDI environment, how do we capture trace information?  How can we set a capture for the network and xperf the user can start (or logon script the start) and then give them a link to click when a random non-reproducible problem occurs?

So what do we want, data wise?  A netmon 3.4 consumable trace, and an xperf trace including stackwalking.

So I want to use the following commands:

netsh trace start scenario=LAN,RPC capture=yes report=yes tracefile=<path to file\netmon.etl> maxSize=512 fileMode=circular overwrite=yes


netsh trace start scenario=LAN,NDIS,WFP-IPsec capture=yes report=yes tracefile=<path\file.etl> maxSize=512 fileMode=circular overwrite=yes

(this will collect a network trace in ETL format (Netmon 3.4 can read this), generate an HTML report, trace to a circular logging etl file in a directory you specify and it cannot grow larger than 512 meg.  It will overwrite an existing log file to create a new one if need be)


xperf -on disk_io+dispatcher+latency -f <path to file\xperftrace.etl> -MinBuffers 1024 -MaxBuffers 1024 -MaxFile 1024 -FileMode Circular -stackwalk cswitch+readythread+threadcreate+profile

(this will collect an xperf trace to the path specified, buffering a bit of memory, restricting the file size of the xperf trace to 1GB and again it is a circular log, with stackwalking enabled)

We place these two in a batch file, have the batch file run as administrator when opened, and the user is educated to double click this at logon, we place it in the logon script, etc.  Delivery method doesn’t really matter as long as it happens before the user starts working.

When/if the problem reproduces, we run a second batch file that also runs elevated that has the following commands:

netsh trace stop

xperf -d <path to file\merged.etl> (or wpr -stop <path\filename)

Note:  There is a caveat.  If you are tracing (stackwalking in particular) on 64 bit Windows, you must set “DisablePagingExecutive” in the registry to 1.  This command will do that:

reg add “HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management” /v DisablePagingExecutive /d 0x1 /t REG_DWORD /f


WPR -disablepagingexecutive on

Either command requires a reboot to take affect though!

Then we can have the user notify us a repro of the issue occurred, collect the files that were logged and analyze Smile.