Reinstalling apps in MDT 2013 the easy way

Haven’t been this excited about finding a new trick in MDT for a while, so bear with me, this is going to be a long post. I really like this as it adds a whole new level of automation to a strictly MDT lite touch environment that’s minus Config Manager, which is perfect since this is after all, an MDT blog.

MDT is great in bare metal scenarios. That is to say, “Here’s an order of 500 brand new computers, get them ready!” MDT can do that easily. Now, what most deployment pros also know is that where MDT really shines is in refresh scenarios. That is to say, “Here’s an entire organization that needs to be moved to a new version of windows” or even just standardized to a newer image. MDT can detect and reinstall apps dynamically as well.

So, in this hypothetical refresh scenario everyone’s getting an image with windows, office, the core line of business apps, and that’s all in the image, but only half of the users use Adobe Acrobat Pro and there’s a mix of users who use other one-off applications. Now, one could go about using the lite touch option to select these additional supplemental applications in the lite touch menus prior to deployment, but do you want to inventory every device?

Now, I’ve known for a while that in theory one could go about using complicated scripts, bundles or the MDT database, but yesterday I stumbled across this gem and a lightbulb went off. While I had looked into this before in the past, it involved manually creating GUID lists or writing queries and the amount of work needed didn’t look like it would be worth the hassle, but this method is really the easiest as long as we’re talking about an MSI, because while you could in theory also use a WMIC query, who’s got time for that?

So, here’s the quick rundown:

  • Some (not all) users have an application like Adobe Acrobat Pro installed
  • You’ll need to have the MSI that’s installed on the user’s PCs to show MDT
  • Create a step in the State Capture phase that sets a TS variable called AcrobatInstalled to true
  • Use a this to only set if it detects the GUID for the MSI that’s used to install Acrobat
  • During the State Restore, if the task sequence variable is set to true it will run the install for Acrobat.

Of course, this may not work during ‘offline’ migrations from PXE, or USB, so I’ll have to most likely go over refresh scenarios where we’re running from within windows.

Lots of people use MDT almost exclusively from PXE or ISO, but you really almost never need to do it that way, MDT can be run from the UNC path from within windows itself. (PXE is criminally over-rated and really only necessary when you’re imaging bare metal or a crashed PC that wont boot)

Browsing to the \\MDTSERVERNAME\ShareName$\Scripts folder, you’ll see litetouch.vbs, kick that off and you’ll get the wizard to run. This is how I kick off 99% of my refreshes. You can even pass switches to this vbs via shortcuts to include or exclude prompts in the wizard. More on that in a later post.

STEP BY STEP: How to get MDT to detect an app and reinstall it during a refresh:

Step One:
Add a step to the task sequence that detects for product in the Capture State
Step Two:
This step creates a task sequence variable and sets it to true if application is detected
Step Three:
Add a step to the task sequence that installs product in the State Restore
Step Four:
This step runs only if it detects the variable as set as true

This could be used to call not just one app, but a bundle if you wanted, however you wouldn’t want to do this for every single app, as this trick is best for something that’s on 20-45% range of your user base (like acrobat pro). This wouldn’t replace Desktop or Laptop bundles either, but it will however allow you to bring a whole new level of automation to the supplemental applications installed in your environment.

Questions? Comments? Hit me up in the Contact Me page.


Importing a Custom Wim From Your Build Share to Your MDT 2013 Production Share

Last night I was working with a client, when he asked a really simple (but good) question, I knew I should write this one up.

So, you’ve built an image, and you’ve captured it using a standard client task sequence, now what? How do I take a captured image and move into a production share?

 In production, import the image by right clicking Operating Systems.
 Select a Custom Wim file
 Image should be in the Captures folder. Make sure to select Move
 Setup files won’t be needed.
 Set Directory Name
 Once everything looks good, select next.
 Once it’s imported, rename the file to something reasonable, in this case, I cut the first half.
 Simply update the image in the task sequence.

Now, if you don’t have a task sequence, you’ll be asked which image to use when you create one.

Automating Image Name in Your BuildShares

I build images a lot, like three a month. No, I’m not building images for each make and model, but I re-build my Win7x86, Win7x64, and Win8x64 images every month. It takes me only 20min. Don’t believe me? I use MDT to build my images for me. I have a fully automated build process for my current images. I have a dedicated VM I have just for building images, and a fully dedicated MDT 2013 deployment share that builds, configures, patches, and then captures reference images for me.

Overkill? Not at all. I’ve seen task sequences that once took 28 minutes to run slow to over two hours in just over a year because updates to Office, DotNet, Visual C++ Runtimes, and just ‘ol plain Windows have slowed the deployment of a standard client task sequence task sequence to close to three hours.

To get away from this, I just kick off a task sequence every Thursday after patch Tuesday. I now jokingly refer to each of these days as “image Thursday”. This way I never have an image that is more than a month old. Because its the same fully automated task sequence creating these images, I know June’s image is just as good as April’s since the only difference is one’s more up to


Now, normally I’d be tempted to write up a whole Blog post on this process, but It would be nowhere as good as Kyle Beckman’s excellent five part series on automating image build processes:

Among MDT enthusiasts, it’s widely regarded to use to MDT build images, getting this entire process full automated does take some work. What’s pretty neat is how he’s managed to automate the naming of the image that gets built using a few simple entries to his customsettings.ini. in his build share. See below.

BackupFile=%TaskSequenceID%_#month(date) & “-” & day(date) & “-” & year(date)#.wim

Now that I have this in my share, I have a fully automated build process, the hardest thing I have to do is boot a VM and go get some tacos. Three hours later, I’m still full of tacos, I have an image and the hardest thing I had to do was boot a VM.

Questions? Comments? Reach out to me via the Contact Me page.

Where’s the Any Key?

In a perfect world we’d all have WDS servers configured everywhere, just laying around ready to feed us .wim files at a moment or F12’s notice, but that’s not always the case.

Problem: When booting to an MDT boot ISO there’s not always somebody to press any key, and well, sometimes, end users really will look for the ‘any key’. So the question is: How do we disable the press any key to boot prompt on MDT ISO files?

Solution:To disable the press any key prompt in your ISOs you’ll need to rename the file that MDT uses for this ‘feature’. Just be advised this can cause problems with physical boot media and is really only for specific situations, like USB or one time PXE boot actions with third party systems.

Rename the following files accordingly.

C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\Media\Boot\bootfix.bin
C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\Boot\bootfix.bin

Once you’ve renamed your bootfix.bin files to bootfix.old. Update your share and have MDT regenerate the ISOs.


Now these ISOs will no longer prompt for the any key.

Clonezilla Still Sucks (beating a dead horse here)

Today I was discussing with a colleague of mine how I still get poorly written and inarticulate hatemail for asserting that Clonezilla is a Joke – and a bad one at that.

I first wrote that article over a year ago and I still stand by the whole premise of not running open source software in any for, non or not for profit enterprise. The free excuse doesn’t cut it anymore here kids, because yes, Microsoft’s imaging tools, ADK and MDT are “free” as in “free taco tote”. Clonezilla is free as in a free feral puppy.

Again – at the expense of beating a dead horse here, I have to unequivocally assert that clonezilla is unfit for human consumption. Understand this: Clonezilla is “free” as in “free three day old taco bueno” which es no bueno. Clonezilla doesn’t create an unattended.xml file for you, MDT does. Clonezilla won’t build an image for you, MDT will. Clonezilla won’t capture that image for you, MDT will. For the sake of berevity, I’ll stop with that but point to three final nails in the coffin of this debate.

Three reasons Clonezilla still sucks:

1 – No support as in NO SUPPORT. The unemployed electronics engineer who wrote this in his mom’s basement can’t help you now.
2 – No Task Sequencing, as in you’re joining to the domain by hand and well, everything else by hand.
3 – No Scripts, as in you’re on you’re own if you want to install drivers, or software dynamically at deploy time.

I have to beat this last point in until it’s made crystal clear; If you have the luxury of six months to write code from scratch to partition, name, join to the domain, provision, update, and reboot, you’re either a millionaire, or unemployed, or both. I am neither, and I doubt you really are, so don’t reinvent the wheel, I promise you, you’re wasting your time and mine writing to me about it.

Think I’m wrong? Write me, but please note: I don’t care if you got Clonezilla to do a 1/3 of this with the code you wrote on your poor employer’s dime.

Write Me:

Creating Custom Variables in MDT

Another excellent post from Mr. Johan Arwidmark at Check it out. Make note of the section on property definitions, I get this question from time to time, so alas, if you’re going to create a variable, make sure it’s not one that already exists.

How to Copy Folders in MDT Like a Boss (The Easy Way) !

Yeah, This script is hella cool. Ever need to get MDT to copy folders? Course you do: That’s why you’re here. Instead of writing a separate and new script every time you need a folder copied, just use this script I found last week. It really does make this part easy.


Thanks to this glorious, glorious script courtesy Mr. Michael Petersen’s brilliant site:, You Too Can Copy Folders in MDT Like a Boss! (The Easy Way).

So, since half of what makes building images a pain is that half of what you’re doing is nothing more than copying folders; make it easy. Sometimes, these folders don’t already exist (Bummer)

Here’s what you need. The greatest MDT Folder Copy Script Ever Written:

Then copy the folder to %SCRIPTROOT%\ and rename the folder to whatever, in this case, I am moving a folder of backgrounds for the UseOEMBackground Feature in a Windows 7 image building task sequence.


Copy it to your folder that needs to be copied on your Deployment Share.

Run it from your task sequence by adding a custom step or just copy any step that calls from scriptroot.

To copy an entire folder…

cscript.exe %ScriptRoot%\Folder\CopyFiles.vbs c:\TEST

Simply change C:\Test to whatever folder you need to create in the deployed system, it’s that easy.

Go get some tacos now that half of your image building process has now been automated.

SEE: 2016 Update: