locked
Win10 MDT copying but not loading drivers RRS feed

  • Question

  • I've got a weird issue that I haven't been able to find posted by other admins on the internet. I have a WDS server running MDT and a single Window 10 1809 image. I have been able to successfully image three out of the four hardware models I have tried, but am running into a confusing issue with my organizations newest Dell micro tower, OptiPlex 5060.

    I have downloaded and imported the driver cab for the model from dells support site.
    I have a driver injection task in my task sequence tied to the WMI model name.
    The driver task executes during the task sequence, but at the end of the preboot environment reboot when windows says "Getting Ready" it does not actually install the drivers it copied over. When the machine finally gets to the desktop it has an error message about unable to access the DeploymentShare and in device manager I have eight devices without drivers.

    In my trouble shooting I have tried...
    Feeding the machine JUST the network driver
    Giving the machine EVERY driver in my "out-of-box" driver folder
    Verified that the drivers in the CAB file work with the hardware by manually installing them after getting to the windows desktop

    Hopefully someone out there has seen something like this before and can give me some guidance. I can post whatever logs might be helpful if someone knows a good place to look for indicators.

    Thanks!

    Friday, May 31, 2019 3:23 PM

All replies

  • Couple things, first I am not 100% sure how exactly you are injecting the drivers into the image my first guess is there is something wrong with that bit so please make sure you configure the task sequence as specified in this video EXACTLY:

    https://www.youtube.com/watch?v=MK2mlqIxtGM&t=3s

    second, when the inject drive task runs, do you actually see each individual driver file name being processed by MDT? You should see each name appear under the MDT progress bar it usually takes a while 5-10 minuets bit less sometimes. If it goes quickly and does not display the driver names then it is NOT actually injecting the drivers. 

    Third, if you have verified that all the drivers are actually being injected then the next thing that comes to mind is possibly something messing with your connection with the MDT server possible causes could be GPO that involves how the NIC or firewall functions, or maybe a windows update processing a new NIC driver causing you to lose connection for a second. To verify that nothing external is interrupting your connection you can block all connections except for the one with MDT by doing the following:

    1. Go to a computer that is working and configure it's firewall so that it can ONLY communicate with your MDT server, your AD server, DNS server, and DHCP server with SMB enabled. 
    2. Export the firewall rules and use the newly generated file to create a task in your task sequence to import those rules into the computer being imaged
    3. generate another firewall rules file with the rules you normally use in your environment and create a task to import those at the end of your task sequence

    Personally for the tasks I created an "application" in MDT for deployment and it looks like this:

    My suspicion is that there is an issue with the way you are injecting the drivers, it's possible that certain models would work well enough to image with Microsoft built in drivers  and models with specialized hardware like an M.2 or Msata drive might not work with microsofts built in drivers causing the issue you are experiencing. 



    Friday, March 20, 2020 9:35 AM