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.


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

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:

ASK MDT Guy: Updates in MDT take forever… HELP!

Today’s Question comes from a reader named Walter, and he wants to know about updates in task sequences.

Question: When I deploy Windows 7 from the Media Install files and the task reaches the “State Restore” and begins with the Windows Update pre and post application installation. The deployment process can literally take hours to complete. If I disable the Windows Update pre and post application installation the process then is really completed in less than 10 minutes.

1. Why does it take so long?

2. Does the target machine pulls the updates from MS or does get the updates via the MDT machine?

3. Aside from building a WIM that has all the updates, is there a way to speed up this part of the process?


These are all really good questions.

This is typical, an unpatched image can take hours and hours to patch, depending on the starting point and your internet connection speed. Now, I use SP1 media and inject a hotfix rollup from last summer and there’s still over a hundred updates it still needs to run. I can only imagine if you’re missing SP1 and/or the hotfix rollup its going to take even more time, as these patches vary from anywhere to just a few Kb to over ten megs. Some take just a mere second, and some like dotnet framework updates can take several minutes, and when those updates are done, they need updates. Yes, updating your updates, fun I know.
When the State Restore phase starts the windows update, it’s calling to a script called ZTIWindowsUpdate.wsf. Unless you specify in MDT to look for a WSUS server, you’re going to be pulling from Microsoft’s Windows Update servers.
As far as speeding this up, yes, you could inject the post Win7 SP1 hotfix rollup from Microsoft or better yet, get a WSUS server setup. If you don’t have a WSUS server handy, there are a few other steps you could do. But for now, start with adding the hotfix rollup, its like 90 updates out of the way.
Info on the HotFix Rollup:
Add a step in the task sequence to install the latest version of IE BEFORE patching starts. This really helps because that way you’re not upgrading to IE 9, patching and then upgrading to 10, patching, and then upgrading to 11, and yes, then doing more patching.
Block updates you don’t need, I don’t think you really need the Bing Toolbar, so block the ones you don’t need in the customsettings.ini file.
I actually use MDT to build my images in a VM. I simply use the standard client task sequence, have it capture, use the LTISuspend.wsf script, and make my customizations then.
Info on Adding IE 11 to your image:
For more questions and answers: See the Ask MDT Guy Page

Download Slides From ‘Deployment Made Simple’

I’ve received numerous requests over the last week for my PowerPoint presentation entitled ‘Deployment Made Simple’, from my talk last week at the HDI Rio Grande Chapter meeting.

It can be downloaded here.

ASK MDT Guy: Why should I integrate MDT with SCCM?

This week’s question comes from Andrea.

Question: Why should I integrate MDT with SCCM?

Answer: Integrating MDT with SCCM really expands the capabilities of SCCM with over 200 some features. Lots of IT pros will use MDT to build the images, and then use SCCM integrated with MDT to push the image. If you’re learning, you can always just start with MDT, see if it works well and add SCCM into the mix later, it’s what I’d recommend. Learn to walk before you run, right?

The advantages of using MDT+SCCM are pretty big. SCCM by itself is pretty crude, MDT allows you to do things with much more finesse. For example, MDT allows you to leverage the LTISsuspend.wsf script to pause the image creation, customize the image, and capture the image. The copy profile setting will also let you copy tweaks made to the admin profile to the default profile for end users who will be using the image.

Regardless of what you do, make sure you build the image in MDT on a VM, it’ll save you lots and lots of trouble down the road.

MDT in and of itself is great for getting images out, SCCM is a much better tool for managing them down the road.

Again, if you’re just learning I’d really suggest starting with MDT first, and when you’re ready to move up your management, integrate the two. It’s hard to beat imaging systems without even having to touch them.

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