Drivers are a big part of getting Windows to work properly. Anyone who has ever had to troubleshoot a piece of hardware on Windows knows this. When generalizing an installation of Windows for capture with sysprep, all but the most basic drivers are removed. This makes the captured image applicable to many different types of hardware. During a task sequence, MDT runs a plug and play check, for hardware at a couple of different points to determine what drivers, if any, are needed. When a matching driver is found, it is injected into the image before it is applied to the computer’s hard drive. To do this, MDT has a folder/section in the deployment share that is dedicated to organizing and storing drivers. It is called “Out-of-Box-Drivers” (OOBD).
The basic INF files are what MDT needs for driver injection. Many drivers are distributed as packages, which come in the form of an executable. This is not what we need. If an executable is the only way a driver is available, it must be imported as an application into MDT, and installed via task sequence. Fortunately, OEMs like Dell, Lenovo, HP, and even Microsoft make bulk downloads of model-specific drivers available from their sites. Dell hardware drivers come in the form of a CAB file, which can be opened with the expand command, or with a compression/decompression utility like 7-zip.
I need to delete all of our Drivers we have in MDT because we have a lot of duplicate drivers which is really slowing down our imaging process. With our current setup it would take at least 36 hours or more to completely regenerate the deployment share. And I found out that on some drivers we had about 60 or 90 duplicates. One of the earliest hurdles an MDT administrator will come across is the management of device drivers, specifically networking drivers. With most other drivers, like Audio, printer, and video drivers, a quick call to Windows Update or install over the network will resolve the Installation.
Bulk-driver Download Sites for Dell, Lenovo, HP, and Microsoft (Surface)
I create a folder structure on the MDT server similar to “DriversWindows ##VendorModel.” For example: D:DriversWindows 7DellOptiPlex 990
I do not delineate between x86 and x64 versions of drivers in my folder path because nearly all of my OS deployments are 64-bit. Dell combines x86 and x64 drivers in the same download. Many Dell drivers can be used on both platforms. Lenovo drivers will try to extract to their own, specified path, but that can be changed at runtime. Complete, downloaded driver packs can be between 300MB and 1,000MB in size, except for WinPE driver packs which are very small.
Using the expand command, I’ll extract the drivers to my folder structure.
expand C:UsersjasonrwDownloads990-OptiPlex-ABCDE.cab -f:* “D:DriversWindows 7DellOptiPlex 990”
The command prompt window will scroll really quickly and end with the prompt returning. Now, we can import them into MDT. MDT is able to handle drivers in different manners. The basic default option is to throw all drivers into the same folder at the root OOBD directory. With that, a deployment task will search the entire OOBD store for the right drivers. This increases the chance of the wrong driver being selected. WMI is great, but it is not perfect. Another option is to break down the OOBD store by manufacturer/vendor or by operating system version. Creating folders for Windows 7 and Windows 10, respectively can help minimize the chance of a wrong driver being installed. I take it one step further, actually a couple of steps further. I still use MDT’s WMI hardware-querying capabilities, but I tell it exactly where to look.
I create a specific folder structure under OOBD that matches a specific WMI query I pass on to the deployment task. For example, Windows 7: Out-of-box-driversWindows 7Dell Inc.OptiPlex 990
The bottom two folder tiers each correspond to variable in a WMI query, Make and Model. To find the make or manufacturer of an OEM PC, run the following command from a command prompt.
wmic computersystem get manufacturer
The returns for Dell and Lenovo are “Dell Inc.” and “Lenovo”
To get the model, run the same command as above, but replace “manufacturer” with “model” Top that off with a folder for OS version and platform, and you have something to use. In the task sequence, a task variable can be inserted into the PreInstall phase, before the inject drivers step to tell the task sequence exactly where to look. The variable is “DriverGroup001”, and the value is “Windows 7 x64%Make%%Model%” This will allow a task sequence to correctly use a WMI query to find the drivers for the exact make and model being imaged.
The Inject Drivers step has its own settings that needs to be configured. For our purpose, the selection profile has to be set to “Nothing” with all drivers from the selection profile being used.
Selection profiles are the ultimate step toward driver control. They are a pre-defined selection of drivers that may encompass and individual model, or manufacturer. MDT ships with a few pre-defined selection profiles, but more can be created to suit any need. Given the exact control this approach provides, there is one detraction, it limits task versatility. Since a selection profile tells a task sequence exactly which drivers to use, MDT doesn’t query for them. The default setting for Inject Drivers is to query the entire OOBD store, but when “Nothing” is set, they querying is off. If it is desired that a task sequence only serve one or two makes of computers, this might be a good approach. I support about a dozen different models from two manufacturers, and I’d like my task sequences to be applicable to all.
I do use a selection profile to organize the drivers I use for my MDT Windows PE ISO/WIM files. Dell and Lenovo make drivers just for Windows PE available as a download too. I use the same approach as above to download, extract, and import the Windows PE drivers into MDT. Then, I create a selection profile for the Windows PE drivers and use that for my ISO/WIM file drivers.
To import drivers into OOBD, make your folders as desired, right-click the folder for the computer model, and choose “Import drivers.” A wizard will open, walking you through the process of importing the drivers from where they were extracted. It is real easy.
After the driver import, the deployment share must be updated. By default, MDT uses the all network and system drivers it has in the OOBD store for the Windows PE ISO/WIM file. This can be changed, as I described above, with a custom selection profile, but it is not mandatory. Still, note, that each time drivers are added and removed, the deployment share should be updated for those new drivers to be used. Some drivers are clearly depicted whether or not they are x86 or x64. In reality, many single drivers can be used on both platforms, but the descriptor files do not always indicate that to MDT. Thus, MDT will import the driver and override the specified platform. This is noted after all of the drivers have been imported for that operation.
I, personally, write down the name of each driver with a warning, and disable them after the wizard ends. Disabling/deleting a driver is easy, just right-click it in the MDT workbench and choose the appropriate option. Drivers must be disabled from their property sheet. Disabling a driver is a safe approach before it is determined that deletion is necessary. Only ever delete a driver from the MDT workbench. DO NOT go into the driver store via the file system and delete it that way.
Again, when disabling or deleting a driver, you must update the deployment share to take it out of Windows PE.
Finding, downloading, extracting, and importing drivers into MDT is a big part of MDT configuration, which takes a great deal of time. If it is done with forethought and planning, it can minimize the driver problems a deployment share might have, and need only be done once. I note the name and date of the driver files that I download and import into MDT. Then, I can periodically check for updates from the vendor’s web-sites. The older a model is with the manufacturer, the less-frequent they tend to update the drivers packs for that model. If the manufacturer does not make a driver pack available for your model, it is possible, though very tedious, to download each driver, and extract them individually. I try to avoid doing that.
Came across this great post by Keith Garner (http://ow.ly/JeHHD) on Microsoft Social forum
Micron usb devices driver download windows 10. Its the most thorough debugging guide I’ve seen on drivers in MDT
How to debug Network Driver Problems
One of the earliest hurdles an MDT administrator will come across is the management of device drivers, specifically networking drivers. With most other drivers, like Audio, printer, and video drivers, a quick call to Windows Update or install over the network will resolve the Installation. However unless the Network (and storage) Drivers are installed into Windows from the start, it will be much more difficult to install the rest of the system.
Drivers Medical Unit
This post should help you get started if you find a machine that did not install a device driver properly, and you want to know how to find and import the correct drivers.
Installing network drivers in the full OS
- Step 1 – Try network connection again
It’s possible that you might get a DHCP error from MDT, but when you try again later to connect the Deployment Share it works! This may be caused by a slow or malfunctioning DHCP server in your network. Re-check your DHCP servers, ensure that PortFast is enabled on your routers. If all else fails get your network administrators to document the DHCP delay. A long delay in modern networks is unnecessary.
- Step 2 – Verify connectivity
You may not have a driver problem but a network problem. Check the physical connection on the computer (Network installs on MDT *REQUIRE* a wired network connection, no Wi-Fi). Open a web browser. Check the IP Address (ipconfig.exe /all). Ping the Deployment Server, manually connect to the Deployment Share. IF you can’t connect to the Deployment Share, neither can MDT.
- Step 3 – Find the Correct Driver Package
Before you load the driver into MDT, first verify that you have the correct driver. There are scenarios where you may *think* you have the correct driver, but the driver will never run because the package is designed for a different OS/SKU/Platform/whatever. Install the driver package by:
○ Open the Device Manager (devmgmt.msc).
○ Find the network device in the list (ensure this is the wired device, not the wireless device)
○ Right click on “Properties” and click on the “Details” tab.
○ From the “Details” tab, select the property “Hardware Ids” select all the values, and copy to the clipboard, it would be a good idea to save for later. Should look something like:
○ From the “Driver” tab, click on “Update Driver…”, click on “Browse my computer for driver software” locate the driver package on the local machine or USB Drive, and install the package.
○ You should get a confirmation that the driver package was installed.
○ IF you do not get confirmation, MDT driver installation may not work.
Windows will install the driver starting with the *.inf install package, and will typically include a *.sys (binary) and a *.cat (digital Signature). If the driver package has been re-packaged into a *.cab, *.zip, or other compressed *.exe file, the package must be extracted first. This is a hard requirement for any driver used by MDT and/or SCCM. All driver packages that are signed by Microsoft (WHQL) will be installed from the *.inf file, and you should only use devices that have the Microsoft WHQL Logo as a sign of quality.
If you need a help on where to find driver packages for your devices, the 3 largest Computer OEM manufacturers supply drivers grouped by Make and Model that are easily imported into MDT and SCCM. See: http://deploymentbunny.com/2014/07/08/back-to-basicwhere-to-find-drivers-for-servers-and-clients/
- Step 4 – Load driver into MDT
If you have more than 20 driver packages, or if you anticipate you will have more than 20 drivers, you should start grouping your drivers in sub-folders for organization. One popular method is to group by Computer Make and Model. Ensure that you are using the correct Driver Selection Profile in your task sequence. If you are unsure, disable any selection profile(s) to ensure the driver is installed correctly.
- Step 5 – Run the full MDT installation
During installation MDT will perform the following:
○ Run the PNPEnum.exe utility and capture output to PnPEnum.xml. The VEN_Xxxx and DEV_Yyyy from the “HardwareIDs” property above must be present in this list. Otherwise we won’t have a match.
○ Search through the %DeployRoot%controldrivers.xml file looking for a match for the HardwareID. MDT may filter the search based on the folder search type.
○ MDT will copy each matching driver to the local c:drivers directory using the xcopy.exe command. You can search (grep) for the string “xcopy” in the ZTIDrivers.log file, that will get you list of all driver packages matched by MDT.
○ MDT will allow the machine to boot into the NEW OS, and Driver Installation will begin in the OS. IF there are multiple drivers found and copied locally, the Windows (not MDT) will determine the best one. The c:windowsinfSetupAPI.*.log files will detail which drivers copied locally were installed (or *not* installed).
Installing Network Drivers in WinPE
- Step 6 – Try the network connection again
- Step 7 – Verify Connectivity from within WinPE
Verifying network connectivity will be a bit more difficult in WinPE, since we have a limited User Interface, so all investigation must be done in the debugging mode (Press F8) cmd.exe
○ Try connecting to the Deployment Share:
c:> net use * MDTDeploymentShare$ /u:UserDomainUserName *
○ Try pinging the Deployment Server:
c:> Ping.exe MDT.Corp.contoso.com
○ Verify that you have an IP address ( ipconfig /all ) If you have an AutoConfiguration address – Driver OK – WinPE can’t reach the DHCP server. If you have “Media Disconnected” – Driver OK – Physical adapter not plugged to network. If no devices are listed – Driver bad – Driver not installed.
○ Check the x:windowssystem32WpeInit.log – This log will show the network driver (if found) being installed.
- Step 8 – Verify driver packages are getting included into WinPE
Firstly, verify the correct driver package from within the full OS above. By default MDT will import *all* Storage and Networking drivers into your WinPE image. However it is possible to change the subset of files copied via “Selection Profile” or other method. Cross check your WinPE Driver Settings.
○ From within the MDT console, right click on the root of your Deployment Share and select properties.
○ Click on the “Windows PE” tab, and the “Drivers and Patches” sub tab for both x86 and x64.
○ Your Network Drivers package must be in the “Selection Profile” if enabled.Finally verify that the correct Network Driver package is being copied to WinPE. If necessary this may include setting up a debugger to watch the MDT Provider build the WinPE Image from scratch. My preference is to use the SysInternals http://live.sysinternals.com/Dbgview.exe tool.
○ Open up the MDT console.
○ Download and run the DbgView.exe tool.
○ Update the deployment share in question.
○ The DbgView tool should show what drivers were copied to each WinPE Image.
- Whenever you add a driver into the MDT console, you must update the deployment share for that drivers to be added to your WinPE Image. If you are unsure, select “Completely regenerate the boot images.” to ensure the drivers is imported. Additionally, you must copy the updated LitetouchPE_x??.wim and *.iso files to the other consumers of the WinPE image like WDS/PXE and or any USB offline media.
- Note that some Broadcom NetXtreme class of drivers have a multi-function driver architecture that may have difficulty loading in WinPE. Ensure that you load the “RIS” class of drivers from Broadcom in your MDT environment.
- Note that by default MDT does *NOT* support the installation of Windows over Wireless network devices (Wi-Fi). The MDT installation sources must either be available through wired networking, or offline (USB Flash) media.
- This post does not discuss origination of drivers within MDT ( Chaos vs. Total Control ), that is a different topic. http://www.deploymentresearch.com/Research/tabid/62/EntryId/112/MDT-2013-Lite-Touch-Driver-Management.aspx
If you are still having problems with drivers in via MDT, ask the experts in the MDT Technet Forum:
- Include a short description of the problem. Including the Make/Mode if necessary.
- Include the HardwareIDs from the Device Manager (Devmgmt.msc) into the post (from above).
- Copy your known good driver package (step 3 above) to OneDrive.
- Copy the following log files to a public site like OneDrive and include the link:
○ PnpEnum.xml (from Client)
○ Bdd.log (From Client) – or at least the ZTIDrivers.log file.
○ c:windowsinfSetupAPI.*.log (from client)
○ %DeployRoot%controlsettings.xml (if problems in WinPE)
○ x:windowsSystem32WpeInit.log (if problems in WinPE)
○ If the MDT server is not including your driver package in WinPE include the DBGView log.