How To: Enable Monitoring in MDT

I get lots of e-mails from people that are having trouble with MDT, which I don’t mind, they’re usually pretty good questions, and lots of times I learn as much from my readers as they do from me, so I consider it a win/win. Unfortunately, it’s hard for me to help sometimes because monitoring is not enabled on their shares, which really makes it hard to find out exactly where the problem is. Some guides out there referring to MDT 2010 wont show you how to do this as this feature is only available in MDT 2012 and 2013. However, enabling monitoring is pretty easy.


Right click the share in the workbench, select properties.



Select the Monitoring Tab



Select Enable Monitoring for this share.


Now in the monitoring section in the share, you’re in business.


In that final picture you can see the name, step, overall progress, and time elapsed. If configured properly in your image and/or your domain, you could even use the Remote Desktop feature here to RDP into systems that are having trouble or need things done by hand. Pretty slick if you ask me!

Also check out my post on extending the time MDT will remember systems in the monitoring tab, by default it’s 3 days, which can be a bit short, if you’re in a smaller shop, you could get away with 14 days or maybe even longer. Its an easy tweak to one XML file in the MDT programfiles folder.


Got Apps?

I usually encourage most fellow IT Pros to skip the majority of the wizards in MDT lite touch, but skipping applications is not something I’m a huge fan of, that is unless I’m ready to cook hundreds of boxes and I’m certain they all need the same appplications. If you’re ready to go to prime time I can understand why you’d want to turn off the lite touch wizard’s prompt for apps, but I prefer to leave it on most the time. But like I said, If you’re ready to pull the trigger on a huge batch of identical systems, it makes sense to skip the prompt, and here’s three different strategies you can take from preselecting and confirming to mandating some but not all, and more…

Three ideas:

First, you can default what’s checked, and leave the option to just verify, this is easily done in the customsettings.ini file.

Just get the GUID for the app from MDT and add it to your file.

for example:


This example would just check them for you, you’d verify and just click next (allows you to change your mind at deploy time).

You could also easily just do this, and set skip to yes.

Another more extreme solution is to make them mandatory apps one by one and add SkipApplications=YES to your CustomSettings.ini file.

for example:



This example would just make the three apps mandatory, would not prompt, and you’d have no choice at deploy time.

However I prefer to simplify this, and create a bundle, make that bundle mandatory and also skip applications in the CS file. The best part of bundles is you set them once, and just update them from the workbench. However, once you’re done with the mass deployment you could roll back to just preselecting and confirming. It’s really up to you, and that’s the beauty of MDT, you have the flexibility to scale back the automation down the road if you so choose.

As always, if you have any questions, send them to me on the ASK MDT GUY page!

10 Questions About MDT You Were Too Embarassed To Ask…

What is this MDT you speak of?

The Microsoft Deployment Toolkit is pretty much the best thing since Ghost. It’s Microsoft’s free imaging, provisioning, and PC deployment software. Think of it as the missing GUI and scripts that don’t come with the  Windows Assessment and Deployment Kit (ADK). Unless you enjoy running dozens of commands by hand from the command line to image systems, it’s imperative you have both MDT and the ADK if you’re trying to deploy Windows 7 or 8 to multiple workstations.

So is this MDT stuff new or something?

No, it’s been around since Vista, but the so-called “experts” who refused to learn Vista have been left in the dust since MDT has just gotten better and better with every release since then. In fact, every major release of Windows since Vista has been accompanied with a new and improved Version of MDT. Yes, Vista’s launch was problematic for a few reasons, but half of whining about Vista was people were still trying to deploy a 21st century OS with tools developed in the Windows 95 days. Now that Windows 7 and 8 are out, lots of people are just now playing catch up.

MDT is kind of like Ghost or Clonezilla, right?

No, not even close. Not even in the same ballpark, not even in the same league. All Ghost or Clonezilla ever did was clone disks, and even Clonezilla did that poorly. MDT does so much more, because it’s more than just cloning software. This is an automation framework that sits on top of the low level tools like imagex and other commanline tools that came out with Vista back in the day. MDT can automate the backup of user data, naming of workstations, imaging, application installation, updating, user data restoration and joining to the domain in less than an hour if you know what you’re doing. Again, all Ghost ever did was clone discs.

Why is this any different? I already have and pay for [insert name of disk cloning software here].

If you’re paying for software to do any or all of the things I just listed in the previous question, you’re probally paying too much. It’s not 2001 any more. When Windows 2000 ruled the day, and Windows XP was the OS of choice for those on the “bleeding edge” you needed disk cloning software, but these days, there’s a solution that’s free and makes Clonezilla look like a bad joke, and it fully integrates with WDS which is even better.

How does WDS play into all of this?

Windows Deployment Services is an optional role that can be installed on a Windows 2008 / 2012 Server that allows you to PXE (network) boot systems and muticast deployments across the network. Unless you’re planning on deploying to hundreds of systems a day, this is optional. Sometimes people confuse this for a stand alone deployment solution, but it’s not.

This is confusing, all these acronyms make my brain hurt, can we take a break?

Yes here’s a hilarious video of a little girl.
Don’t be like her, take a deep breath and focus on the essentials before you start yelling “Go!”

How do I get started?

First off, you need ADK 8.1 and MDT 2013 installed and I recommend getting a VM up and running to accelerate initial testing. Once that’s done, all you need to do is build a what’s called a deployment share. You’ll need one for building images and another for deploying images, but for now, just play with a test share and the generic image from the installation media aptly named install.wim. Once your share is built update it, and MDT will build a boot disc for you to use. Once you feel comfortable automating a basic windows windows installation, then start adding drivers, and applications to the share.

I really just want to build a super slick image, How do I do that?

Easy there young grasshopper, it’s good to have that kind of enthusiasm, but it’s important to not put the cart before the horse here and that you learn to WALK before you RUN. If you’re really new to this “automated installation” thing, do yourself a favour, and just rock the image that comes on the Windows Vista / 7 / 8.x media. Furthermore, its important to learn driver management and how to push applications after imaging, because those two skills will allow you to have “one image to rule them all”.

So I don’t put drivers or applications in my images?

If you like building lots of images and maintaining them, go for it. If you enjoy having one image for every make and model you support, keep applications like Java, Flash, and Firefox out of your image. No drivers either, build the image in a virtual machine, and let MDT install apps and drivers at deploy time. It’s easier than you think. This method helps keeps your total image count down. This is important, reducing your image count to one or two saves you and everybody you work with lots of pain down the road. Having one image that runs on laptops and desktops, Dells and HPs, is a thing of beauty, and the elusive goal of many windows engineers who do this kind of stuff for a living for many years. If you have more than two images, one for 32 bit and one for 64 bit, you may just be making your life more complicated than it needs to be.

Sounds pretty neat, are there free videos or books I can check out?

Yes, there’s tons of stuff out there, I highly recommend checking out the following resources:

If you have some money to burn, I can’t recommend enough “Deployment Fundamentals Vol. 1”

MDT Monitoring Tips & Tricks

Both Johan Arwidmark and Mikael Nystrom have been writing extensively as of late regarding Monitoring in MDT, one of the coolest features added in the 2012 release. Monitoring allows IT admins to keep an eye on deployments from not just a centralized location, but any system with MDT installed and an active connection to the deployment share. More importantly, one of the neatest features on top of just monitoring is that we can then start remote desktop sessions of these deployed systems after the deployment is complete, but MDT by default will only show deployments from the last three days, which makes this a little hard to do after the fact once just a few days have passed. However, after reading one of Johan’s latest posts on this topic, it turns out this can be changed by making a simple modification to one configuration file.

Changing the default time MDT remembers deployed systems in the monitoring tab is quite easy.

Find and edit the following file: c:\Program Files\Microsoft Deployment Toolkit\Monitor\Microsoft.BDD.MonitorService.exe.config



Note, the database this all relies on has size limits, so if this begins to cause problems after deploying a large amount of systems, take this down a notch, but notice the default max is 1000 deploys. Just keep that in mind.

Related Reading:

Using the Office Customization Tool in MDT and Skipping the Welcome to Office Wizard

One of the coolest things you can do with MDT is use it to install and update office at deploy time. Customizing Office is easy when using the office customization tool.


Turns out even this wizard can be hidden using the Office Customization Tool. The option to do so is just hidden a little in the wizard.

Right clicking office in the workbench and selecting properties gets you here, note the extra Office Producrs tab.

The Office details window. Use the syntax above to automate your office install.

This where you set the UI level and launch the Office customization Tool.

Here you would enter the MAK key

Here you can customize office shortcuts.

Adding desktop shortcuts is pretty straight forward.

Note I didn’t go crazy here, I just added Word, Outlook and Excel, but it’s your image go crazy if you want.

Here you can disable the pesky Welcome Wizard once and for all!

Once all your customizations are complete, save the file to the updates folder in the office folder in your share. Take some time and play with it, the Office Customization Tool is very powerful, but remember, with great power comes great responsibility.

Donde Esta Make y Model?

When setting up driver repositories in the out of box drivers section in MDT, I can’t recommend enough using the “Total Control” method taught by Mr. Johan Arwidmark, because rather than playing guess and check or worse yet plug and pray, you should simply create a folder hierarcy that at least includes make and model variables as the foldernames. This allows you to then set driver groups using those same variables during the execution of the task sequence so only the folder that corresponds to the exact make and model will be used to inject drivers at deploy time. Now, none of this will work unless the names of these folders match the makes and models recorded in the hardware. Now, traditionally one could get this from ‘msinfo32’ at the run prompt, but did you know this can be done from a shell as well? Well you do now!

wmic computersystem get manufacturer
wmic computersystem get model

Here you can see the exact make and model reported from powershell.

Why is this important? Well, in a true “bare metal” scenario where you’ve been shipped hardware with no operating system, you could run this command from WinPE and save yourself lots of valuable time.

Use those names in your drivers folder in the workbench, it’ll pay off later.

DriverGroup001=Windows 7\x64\%Make%\%Model%
Using the DriverGroup variables, you can take TOTAL CONTROL over which drivers the system uses. You can thank me later.

For more information on Orgainizing Drivers, see my post aptly titled, Organizing Drivers.

Death to Bing Bar!

As some of you may know, I’m a huge fan of using MDT to automate the building of images. This automation saves time and means that I can simply rebuild my hybrid images quarterly or monthly if I need to, all with significantly reduced user error.

However, a few months back for some reason the windows update site started pushing the Bing Bar during image build and during subsequent deployments.

I know, in a perfect world, we could just block these updates via WSUS if our deployment share was configured to look at the WSUS server, but not all of us are as lucky. So check your BDD.log file, determine the KB number of the offending update, (Bing Bar 7.2 in this case) and copy the following code to the CustomSettings.ini file.


If you wanted to add another update to block you would just add another line with WUMU_ExcludeKB002= and whatever the KB is of what you’re trying to block.