Vudu Solution Could Not Connect to Server Please Try Logging in Again 5000
There's nothing more frustrating than needing to deploy an operating system to computers from your Microsoft Deployment Toolkit (MDT) server and receiving the error, "A connection to the deployment share (\\mdt\DeploymentShare) could not be made." In this article, I'll discuss several causes of this error, along with solutions to get you back up and deploying faster.
- Author
- Recent Posts
Kyle Beckman works as a systems administrator in Atlanta, GA supporting Office 365 in higher education. He has 17+ years of systems administration experience.
Unless you're creating offline media with the Microsoft Deployment Toolkit (MDT) for your operating system deployment (OSD), you'll probably run into network issues at some point because the clients you deploy have to access the MDT deployment share. This typically results in the error, "A connection to the deployment share (\\mdt\DeploymentShare) could not be made," along with something more specific to help in tracking down the error. Here are a few of the most common errors I've encountered, along with solutions to fix them.
Network drivers ^
This one may sound totally obvious, but I've wanted to beat my head against the desk a few times when dealing with getting the right drivers for a system. If your MDT server doesn't have the right drivers for a NIC, you may see, "The following networking device did not have a driver installed," followed by a hardware ID.
The following networking device did not have a driver installed.
Intel, Broadcom, and all the other network card manufacturers are really bad about making minor revisions to their hardware that require an updated version of the driver. Worse yet, some OEMs like to use the new chipset, especially in their non-Enterprise business/small business brands. The new network chipset driver is sometimes backward compatible with older revisions, and sometimes it isn't. When in doubt, I always start with the OEM's web site to see that I have the latest driver they're supporting. That tends to resolve it 90% of the time. When it doesn't, I'll usually go to the network card manufacturer's web site or do a search on the hardware ID to track down a current driver. Many times, the hardware manufacturer will have newer drivers than your OEM has.
Right drivers, wrong OS ^
Are you still deploying Windows 7? Are you using MDT 2013? If so, don't forget that MDT 2013 uses Windows PE 5.0, which uses the same drivers as Windows 8.1.
If you deploy Windows 7 with MDT 2013, the computer boots into Windows PE 5.0, lays down the WIM file, injects drivers, and then reboots into Windows 7. Windows PE 5.0 may not require network drivers for a particular network chipset, but because Windows 7 doesn't have the hardware drivers included, you'll receive the "The following networking device did not have a driver installed" error right after Windows boots and realizes it doesn't have the right driver installed.
Really fast modern hardware ^
If you're deploying an OS to very new hardware running fast SSD drives, you could run into a problem I had recently. When the system booted into Windows for the first time, I received the error, "DHCP Lease was not obtained for any Networking device! Possible Cause: Check physical connection."
DHCP Lease was not obtained for any Networking device! Possible Cause: Check physical connection.
Letting the deploy finish netted a nice yellow warning screen. I really prefer the Success screens that aren't yellow.
Deployment Summary Success – DHCP Lease was not obtained for any Networking device!
Normally, I leave systems unattended when they are deploying because there's no reason for me to sit and watch them. When I checked on this system, it had an IP address from the DHCP server. When I restarted the OS deploy and watched the system, it was receiving an IP address—just not fast enough.
As it turns out, the culprit was a combination of fast hardware and network setup. In this case, the DHCP server wasn't on the same broadcast domain and was using an IP DHCP helper address so the systems on the network could get IP addresses. This introduced a delay that, coupled with the new/fast hardware, caused problems for OSD.
To fix this, you can make a simple edit to the LiteTouch.wsf file in the Scripts folder of your deployment share. Find "Function ValidateDeployRootWithRecovery" in the file and add "wscript.sleep 5000" to the file, as shown in this screenshot:
Edit LiteTouch.wsf to add wscript.sleep 5000.
I used 5000 (5 seconds), but your mileage may vary depending on your network and computer hardware. Feel free to set that number lower or higher depending on your experience. In my case, 5000 (5 seconds) fixed it every time and wasn't enough of a delay to slow me down considerably.
DHCP issues ^
Various issues with your DHCP server can also cause the error, "DHCP Lease was not obtained for any Networking device! Possible Cause: Check physical connection." If you're using a dedicated network for OSD of new machines, check that your lease duration is set fairly low. You really don't need a three-day lease for a system that isn't going to be on that network for more than an hour or so. And, check the size of your address pool and ensure that it is large enough. If you have to deploy 75 machines and only have an address pool of 50 addresses with a lease time of three days, you're going to run into problems.
Source: https://4sysops.com/archives/resolving-a-connection-to-the-deployment-share-could-not-be-madeerrors-in-mdt/
0 Response to "Vudu Solution Could Not Connect to Server Please Try Logging in Again 5000"
Post a Comment