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!”

Install Java 1.8 runtime with MDT 2013

This one’s a quick and dirty post. If you need to install Java 1.8 with MDT, just use the offline executable. I used to use the MSI, but that’s proven to be less reliable as of late. So, here goes:


Obviously, install silent is what you want, Auto Update is a call you may wanna make depending on your environment and of course, letting application installers call a reboot is a no no with MDT.

Sponsors = 0 is a big deal, because nobody wants the ask toolbar, NOBODY.

Troubleshooting the mysterious MDT Error 5610 “Verify File”

Earlier today, I was working on a strange issue: When attempting to image an online 64-bit system from the LiteTouch.vbs script, we were getting a strange error:


FAILURE ( 5610 ): False: Verify File: \\MDT\ProductionShare$\Boot\LiteTouchPE_x64.wim

Notice in the picture, the 0x80004005 error? that’s MDT speak for ‘something really bad happened’

I checked the Official MDT Documentation, and all I got was ‘5610: Verify File’  which was less than helpful.

Next, I checked Neihaus’ guide here: Troubleshooting Windows Deployments and found that 5610 really means, “you haven’t yet updated the deployment share to generate this WIM file (or when that architecture isn’t enabled).”

Turns out the issue was exactly that: a missing 64bit boot wim file, and yes, indeed the architecture needed to be enabled, and the share needed to be updated. Worked like a charm.

Now this confuses a lot of people, back in the day one was pretty much required to use a 32-bit boot image to lay down a 32-bit OS, and the same went for 64bit. If you wanted to deploy 64 bit Vista or 7, you would need to be rocking a 64-bit WinPE bootable media. Eventually support’s gotten better since the MDT 2008 days, and now I can image both 32-bit and 64-bit systems from one 32-bit boot image. However, if you’re using litetouch.vbs switches and shortcuts from live systems, you’ll need to keep the 64bit systems enabaled in your share properties. Just goes to show you, when you do weird things, and get even weirder errors, keep your Troubleshooting Windows Deployments PDF handy.

Note to Self: Installing Adobe Reader MSI with patches and transforms in MDT

File this under MSI installer syntax that’s more complicated than it needs to be.

When installing Adobe Reader MSI files patches and transforms all from one commandline, remember, the patch needs a full UNC while transform does not. Go Figure.

msiexec.exe /qb- /l*vx %LogPath%\AcroRead.log REBOOT=ReallySuppress UILevel=67 ALLUSERS=2 /i AcroRead.msi PATCH="\\MDT01\Share$\Applications\Adobe Reader 10.1.4\AdbeRdrUpd10112.msp" TRANSFORMS="AcroRead.mst"

See: http://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/cmdline.html

Repent! The end is near!

Repent! The end of days are near! In less than 30 days now, Microsoft will be pulling the plug on XP support. What does that mean? Well, when you call Microsoft for XP support after April 9th, you’ll be laughed at and promptly hung up on. After that date, XP will go to sleep forever along with Windows 2000, Windows ME, and Windows 98. No more updates, no more patches, no more nothing. do not pass go, do not collect $200. Remember, XP came out back in 2001. Well, it was a pretty good run, but remember back in 2001 people still took Eminem seriously, and the first generation X-Box was the hottest new toy. Yeah, it was that long ago…

All you luddites out there were warned. Vista’s been out since 2006, Seven’s getting long in the tooth now too, that came out in 2009.

Now while some fear mongerers are predicting the worst thing since Y2K, and others suggest the holdouts will be just fine, as with most things I suspect the reality will be somewhere in the middle, it’s still not going to be pretty.

More Info:


Windows 8.1 Deployment Jump Start w/ Johan, Neihaus and Nystrom!

Johan, Mikael & Michael Neihaus all in one Event? Sign me up!
Looks like a great event, don’t miss this!

Live Event Details

March 12, 2014
9:00am-1:00pm PDT


C.T.L.S. (Check the Logs Stupid!)

Ever hear of K.I.S.S.? It’s an old acronym that means “Keep It Simple Stupid!” because it’s usually something simple causing your problem, something stupid simple like the device isn’t plugged in. Well today, I’m going to tell you about my new favorite, C.T.L.S. “Check the Logs Stupid!”

I currently manage a fleet of laptops for analysts who do a great deal of travel, so obviously they need to be connected on the road. While I have an MSI file for the Verizon Access Manager software, it hasn’t been installing during my MDT deployments for the last few weeks. It was installing fine for months, but for some reason unbeknownst to me at the time, I was getting the notorious 1618 error message which really just means “something bad happened, sorry”. I checked the BDD.log file and didn’t get much help.

Error 1618 – Not very helpful.

Well, thankfully since this package was an MSI, I was able to check the msi log file in my share (see my logging article here).

An even more confusing error.

When I checked the log for the installer I got an error 258: Failed to grab execution mutex. While at first glance this seems to be just as cryptic as the previous error, a little bit of googling led me to some forums and threads that suggested this can be caused by certain software (like antivirus) needing to reboot after instalation.

To fix this, I went in and set the antivirus to reboot after installation, a sure enough my problem went away. The problem wasn’t the wireless software, it was the application getting installed before it requiring a reboot.

Set to enable reboot on install in MDT 2012.

By setting the application installed before the problematic software to reboot after install, my problem went away, but I would have had a hard time knowing that if I hadn’t checked the logs. So the moral of the story is, enable logging and then check the BDD.log file and if that doesn’t help, hunt down the log file of the application msi install itself.