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:
https://4sysops.com/archives/resolving-a-connection-to-the-deployment-share-could-not-be-madeerrors-in-mdt/

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.

dhcpdelayfix

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