ASK MDT Guy: Adding Scripts as Applications to MDT

Just received a great question this morning from Paul who’s asking about adding scripts as applications to MDT shares to be selected as needed at deploy time.

It is possible to add a really small/simple .bat file I created as a Standard application that users can just click on the checkbox to add the application at deploy time?
The .bat file is really simple: just displays a few lines in the command prompt and does one other thing, and at the end, there is EXIT, where it closes the command prompt.
I right-click Applications in the Deployment Workbench and choose “Application with source files.” The main question I got is, what would I put in the Quiet Install Command?


The short answer to this question is yes. You can very easily add batch scripts as applications in a share to allow helpdesk staff to install them “as needed” at deploy time. I would only do one bat per application, nesting them like that may be half the problem right there.

I however, prefer to use VBScripting (vbs) or windows script files (wsf) whenever possible for a number of reasons, the least of which is the numerous limitations of bat files regarding UNC paths and logging.

If you’re in a crunch, and you know your batch script works, go ahead and use cmd.exe /c script.bat as your quiet install command.

The /c tells the command prompt to close when it’s done.

As for importing the applications…

You could do it one of two ways, import it as an application with source files, and point to a folder that has the batch or vbs script in it.


Sometimes, I’ll also import it without source files and use the %SCRIPTROOT% variable and just throw it in the script root directory, which I’m trying to not do anymore, as the advantage of the first method is that if I need to move this application to another share down the road, it’s a simple drag and drop operation.


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.

Why would Microsoft make such a simple thing so complicated?

Today I got an e-mail from a reader Blake, who was wondering why Microsoft would make imaging more complicated with MDT as opposed to the “simplicity” of basic disk cloning tools that were ubquitious over a decade ago.

Question: Why would Microsoft make such a simple thing that has been used for so many years so complicated?

Answer: Agreed, the complexity of MDT is quite intimidating, I must admit, the first time I opened MDT I had no idea where to even begin.

I’ve been using MDT for over two years here now and there’s no way I would go back to the nightmare of managing a single image for every single make and model. That wasn’t simple. That was hell. I would never go back to having to run windows updates by hand on a six month old image. That was not easy, that was a pain in the ass. I wouldn’t go back to installing one off applications by hand, that wasn’t simple, that was a chore. The dynamic driver injection, the windows updates, and the dynamic provisioning is really hard to beat. When I worked for Xerox I reduced their image count from over twelve to two, one for 32bit and one for 64 bit, it was beautiful, long gone are the days when you’re maintaining dozens and dozens of images. Again, today I have one 32bit win7 image, and one 64 bit image, that’s beautiful.

Understand, that back in the early days of Windows XP there were no Microsoft tools, there was sysprep, and that’s as far as Microsoft would take you, but that all changed with the release of Vista, which was released with the first version of the AIK. MDT was still called the Business Desktop Deployment Kit (BDD), but by the release of Vista SP1, it was rebranded as MDT.

Now, for the Thick vs. Thin image debate… Fans of thick images say that they’re faster, and fans of thin images say they’re more flexible at the expense of speed. I honestly don’t like either. I’m a big fan of the “hybrid” image.

Seriously, take what’s good about thick images (speed) and what’s good about thin images (flexibility) and you can have your cake and it too. Build the image in a VM with MDT and the cost of maintaining your images is cut exponentially.

Here’s what I recommend to lots of people; Put Office, C++ runtimes, and DotNetFramework in your image, along with the windows and office updates, but keep Java and Flash out (they’re easy to add back in as they get updated which is weekly.)


I also suspect that you’re missing the real benefit of using hybrid images with MDT and that is the flexibility. I personally have to support a call center, accounting, marketing, sales, lending, human resources and an accounting department. I don’t have the time to build ten different images for all the departments I support, so I build a pretty generic image that has office, c++ runtimes, silverlight, etc… and then I use MDT’s wizard to let me customize what apps I install at deploy time, and that my friend is what separates a tool like MDT from a toy like clonezilla.

For more questions and answers: See the Ask MDT Guy Page

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:

ASK MDT Guy: A tale of Two WSUS Servers

Yesterday I received a really good question from a reader Winston.


I have multiple sites that I have been able to connect together using DFSR. Servers are 2012 R2 using MDT 2013. I have a WSUS server on one server but I would like to be able to have a WSUS server on the second server. The WAN link between the two sites is fairly fast but I would like to have two WSUS servers but having one sync to the other but the second site will get it’s updates from the second WSUS server. I know how to sync the two WSUS servers just not how to have my two MDT servers recognize which one should be used for their respective site.


Getting clients deploying at site A to get one WSUS server and clients deploying at site B to get another is actually pretty easy. In fact, we can do lots of fun stuff this way, we could set names based on sites, and even specify which applications get installed.

The solution is brilliant in it’s simplicity. Tweak your customsettings.ini file.

MDT allows us to set different variables based on the default gateway detected at deploy time.

See the Example Below.


Using the Default Gateway, we can configure site specific settings at deployment time.

In this example, we have two sites, Chicago and Atlanta. Devices at each site will detect different Gateways when the NICs initialize, and then will get different names, different WSUS servers, and different application bundles. There is almost no limit of what could be done with these

See Also: