A connection to the deployment share (\\Servername\Share$) could not be made. DHCP lease was not obtained. Retry works just fine.

I hadn’t seen this one for a good minute, and I remember why. There are several reasons you can get this error. Sometimes you just need the driver. However the error screen will almost always tell you that you’re missing a driver, and no amount of clicking retry will fix that. Other times you’re genuinely seeing some kind of delay with the assignment of a DHCP address and fancy new hardware boots quicker than the network can get the systems IPs.

I know in the past I was able to add some kind of delay to get MDT to wait and then try to resume the task sequence, but I couldn’t remember what or where, so off to the googles I went…

I found this:

Then I remembered, yes, there is a delay we can add to the main heart and soul of MDT, the script of all scripts, the holiest of holies, the LiteTouch.wsf I hate doing this, I hate the idea of editing the scripts provided by Microsoft, because you never remember what you modified and where after an upgrade or after building a new share. But then again, you know what they say, “When in Rome Do as The Vandals!” Also, I’m tired of having to walk over to computers in our training room and clicking retry, so there’s that too.

Anyway, like Kyle describes in the abovementioned article, if it is a genuine delay in the DHCP assignment of an IP, we’ll need to add a delay in the LiteTouch.wsf script.


Look around line 1268. In this case, I’m adding a whole 10 seconds because I don’t want to come back and do this again if 5 seconds doesn’t cut it so I add wscript.sleep 10000 at line 1270. Lines 1269 and 1271 are optional snark that in theory will help me find it if I ever need to again.

Your Milage May Vary and as Johan says, “Happy Deployments!”


MDT FUNdamentals: Adding Office 2016 to MDT 2013

This one’s been something I’ve meaning to post for a while now, and it’s going to hopefully be part of a fun little series I want to call MDT FUNdamentals. In this article I will outline how to add a basic Office install to your deployment share.

One of my absolute favorite things about the Microsoft Deployment Toolkit is the relative ease in which we can get it to install, configure and patch just about any version of MS Office for us. If you really wanted to, you could use this to install Office at deploy time, but for 99% of us out there, we’ll do this during the image build prior to Sysprep and capture.

This guide assumes a few things:
MDT 2013 Update 2 is installed.
ADK 10 is installed.

Now, what I won’t assume is that you have Office 2016 imported into your share. If you have an ISO, mount it, if you can’t mount it, extract it. Once that’s complete, this guide will show you how to add it.

First if you don’t already, you’ll need a share, an image, and a task sequence, don’t worry if you don’t have a custom image yet, you can use the wim in the iso. If you don’t have a share, you’ll need to create one. Remember, this is how I put Office in my image, I have MDT install it before I have MDT capture the image for me.

For this example, I’m going to add Microsoft Office Pro Plus 2016 to a share I use to build windows 10 images.

From the applications folder in your deployment share, right click and select new application. Point it to the mounted ISO or extracted ISO.

Office is easily added to MDT by importing the contents of the ISO. See below for the syntax. Once Office is imported, we’ll run the office customization tool. Create a new file, make your tweaks and save to the updates folder in the share.

Since we’re installing Pro setup.exe will need to be pointed to the proplus XML like above.

The MDT/Office integration is pretty solid. The most basic configs can be done here. Right click it once imported and select properties.

The Office Customization Tool is a powerful way to automate office install and tweak it for your needs.

The wizard also allows you to pick and choose which components. Skype? Who needs that? Not me.

The wizard’s prolly the safest way to add Office keys, well next to KMS that is.

Final trick: Use this setting to disable that first run wizard that NOBODY wants to see. Set this and thank me later.

SEE ALSO: Johan’s Guide, This and This Initials Prompt Trick

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.)

SEE: http://www.microsoft.com/en-us/download/confirmation.aspx?id=6157

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

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 DeploymentResearch.com. 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.

SEE: http://blog.coretech.dk/mip/making-file-copy-easy/

Thanks to this glorious, glorious script courtesy Mr. Michael Petersen’s brilliant site: blog.coretech.dk, 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: http://blog.coretech.dk/download/CopyFiles.zip

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: https://mdtguy.wordpress.com/2016/08/03/still-writing-scripts-to-copy-files-yeah-dont-do-that/