none
MDT 2013 Update 1 - Cannot deploy Windows 7 32-bit RRS feed

  • Question

  • This is an odd one, and I've spent a week on it and can't figure it out.  I have MDT 2013 Update 1 set up and configured.  I have drivers imported for all of my system models.  I can deploy Windows 7 64-bit without any issues.  However, whenever I try to deploy the 32-bit OS (using the same deployment share, same drivers, etc), I run into problems.  I can get to WinPE, run through the deployment wizard, and start the deployment.  The image lays down fine, the system reboots, then gets to a Windows desktop, and I get the "A connection to the deployment share could not be made" window, indicating that a networking device did not have a driver installed.  I have verified multiple times that I have the 32-bit Windows 7 driver for the network adapter in both my main driver store, and my WinPE drivers.  I verified that the driver is injected into the boot ISO (and wim), and I have completely regenerated the boot images multiple times.  I also have verified that the drivers needed exist under C:\Drivers.  There are no differences between the 32-bit deployment and the 64-bit other than the version of the OS.  Does anyone have any idea how to get past this issue?  I've been pulling my hair out on it for a week now.
    Tuesday, December 8, 2015 1:03 PM

Answers

  • So, I've fixed my own issue.  Basically, it boiled down to this: drivers were being put into the C:\Drivers folder, but (on the 32-bit install), never got moved to the normal driver repository (C:\Windows\System32\DriverStore\FileRepository).  Normally, this is caused by Windows setup (setup.exe) running.  For some reason, that wasn't happening.  I was able to make it work by putting in a synchronous command in unattend.xml to run dpinst.exe and move the drivers (which is the step that normally would happen automatically).  At that point, everything worked.  As a test, I reverted the change in the unattend.xml and downloaded the latest VLA media for Windows 7 Pro SP1 32-bit.  I deployed that edition, and everything worked.  So, it looks like the problem was with the media I was using.  

    The odd thing was, there wasn't anything in any of the logs I looked at that indicated a problem.  Regardless, it's resolved and if there's an issue again, I can just re-add the dpinst step to the unattend.xml again.

    • Marked as answer by jlz73 Friday, December 18, 2015 12:57 PM
    Friday, December 18, 2015 12:57 PM

All replies

  • It could be an issue/bug with the driver. Have you tried a newer or possibly previous version of the Windows 7 32bit driver?

    What method do you use for driver management? If you aren't using Johan's method, try that first. I'd recommend total control. http://deploymentresearch.com/Research/Post/325/MDT-2013-Lite-Touch-Driver-Management


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, December 8, 2015 2:40 PM
  • I plan on getting to the more controlled methods, but I'm currently on the "mass chaos" version.  I have tried multiple versions of the driver (new/old, from HP and from Intel).
    Tuesday, December 8, 2015 3:06 PM
  • I would really urge you to try switch to total control, it could be that PnP is using the wrong driver or at least one that doesn't work well with Win 7 32bit. That's an issue when you inject everything.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Wednesday, December 9, 2015 2:33 PM
  • Particularly with new hardware that has children this will be an issue and it isn't an issue with MDT.  When you do plug and play detection you only can see what you can see.  When a driver is installed that reveals another hardware device we have no way of knowing about that.  Unless you are using the total control method expect these sorts of issues.

    Logs are very important. https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/ Mention any customizations you have made.

    Wednesday, December 9, 2015 8:33 PM
    Moderator
  • So I ended up rebuilding the driver store and going with total control (thankfully, we're still testing and had only a few models set).  A 64-bit deployment on any of 3 models works fine.  However, I get the exact same problem as I initially had with the 32-bit deployment (using the same exact physical hardware).  Of course, it's a different hardware ID on different models, but every single time, it's the network driver not found.  I'm using the driver packs from HP and Dell, and I've even tried finding newer versions of the drivers for the specific hardware IDs.  I can't get it to work.  Both 32-bit and 64-bit work when deploying to a VM, but on real hardware, the 32-bit fails every time, and the 64-bit works every time.
    Thursday, December 10, 2015 12:25 PM
  • I would look for some SMBUS driver or similar that is in the 64bit driver store for that device that isn't in the 32bit driver store.

    Logs are very important. https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/ Mention any customizations you have made.

    Thursday, December 10, 2015 7:21 PM
    Moderator
  •  I can get to WinPE, run through the deployment wizard, and start the deployment.  The image lays down fine, the system reboots, then gets to a Windows desktop, and I get the "A connection to the deployment share could not be made" window, indicating that a networking device did not have a driver installed.  I have verified multiple times that I have the 32-bit Windows 7 driver for the network adapter in both my main driver store, and my WinPE drivers.  I verified that the driver is injected into the boot ISO (and wim), and I have completely regenerated the boot images multiple times.  I also have verified that the drivers needed exist under C:\Drivers.  

    #Confused

    You mention that the drivers are copied down, however I don't see anywhere where the drivers were actually loaded and tested in the full Operating System. Just because you downloaded and placed (What you *thought* were) the correct drivers on the local machine does not mean the OS will load them. I have an MSI motherboard with a on-board NIC, whose driver I can't install on Windows Server SKU's, and that's by-design!!!

    Open up devmgmt.msc, click on the device in question, and "update Drivers" pointing to your driver package. If it installs, then we should verify the copy actually took place in MDT, grep for "xcopy" in the bdd.log file, it does *not* install, then check the windows\inf\setupapi.*.log files for details (hard to parse). 

    Finally my FAQ on missing drivers: How to Debug missing Drivers in MDT Litetouch


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Thursday, December 10, 2015 10:27 PM
    Moderator
  • Let me clarify: when I get the "Connection to the deployment share could not be made..." message, I am in Windows (past PE).  If I go to C:\Drivers, there are drivers there.  If I bring up Device Manager, and do an "Update Driver" on my network adapter, and point it to C:\Drivers, it finds a driver and loads it fine (as it does for other hardware items that are missing drivers).  This also only happens with the 32-bit version of Windows 7.  The 64-bit works fine.  I have the same behavior regardless of the model computer I use, and if I do the "total control" or "mass chaos" driver method.

    I only have 32-bit network drivers are in my boot image for WinPE for 32-bit (and only 64-bit for the 64-bit boot image).  In both scenarios, WinPE loads fine and connects to the deployment share fine.  The missing driver only rears its ugly head after Windows is laid down and the system reboots.  I also have this same behavior if I put 64-bit and 32-bit drivers in the boot image.

    Friday, December 11, 2015 4:45 PM
  • So, I've fixed my own issue.  Basically, it boiled down to this: drivers were being put into the C:\Drivers folder, but (on the 32-bit install), never got moved to the normal driver repository (C:\Windows\System32\DriverStore\FileRepository).  Normally, this is caused by Windows setup (setup.exe) running.  For some reason, that wasn't happening.  I was able to make it work by putting in a synchronous command in unattend.xml to run dpinst.exe and move the drivers (which is the step that normally would happen automatically).  At that point, everything worked.  As a test, I reverted the change in the unattend.xml and downloaded the latest VLA media for Windows 7 Pro SP1 32-bit.  I deployed that edition, and everything worked.  So, it looks like the problem was with the media I was using.  

    The odd thing was, there wasn't anything in any of the logs I looked at that indicated a problem.  Regardless, it's resolved and if there's an issue again, I can just re-add the dpinst step to the unattend.xml again.

    • Marked as answer by jlz73 Friday, December 18, 2015 12:57 PM
    Friday, December 18, 2015 12:57 PM