The default setting for Inject Drivers is to query the entire OOBD store, but when “Nothing” is set, they querying is off. Since a selection profile tells a task sequence exactly which drivers to use, MDT doesn’t query for them. Given the exact control this approach provides, there is one detraction, it limits task versatility. MDT ships with a few pre-defined selection profiles, but more can be created to suit any need. They are a pre-defined selection of drivers that may encompass and individual model, or manufacturer. Selection profiles are the ultimate step toward driver control. For our purpose, the selection profile has to be set to “Nothing” with all drivers from the selection profile being used. The Inject Drivers step has its own settings that needs to be configured. The variable is “DriverGroup001”, and the value is “Windows 7 圆4\%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. 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. 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. The returns for Dell and Lenovo are “ Dell Inc.” and “ Lenovo” To find the make or manufacturer of an OEM PC, run the following command from a command prompt. The bottom two folder tiers each correspond to variable in a WMI query, Make and Model.
For example, Windows 7: Out-of-box-drivers\Windows 7\Dell Inc.\OptiPlex 990 I create a specific folder structure under OOBD that matches a specific WMI query I pass on to the deployment task. I still use MDT’s WMI hardware-querying capabilities, but I tell it exactly where to look. I take it one step further, actually a couple of steps further.
Creating folders for Windows 7 and Windows 10, respectively can help minimize the chance of a wrong driver being installed. Another option is to break down the OOBD store by manufacturer/vendor or by operating system version. This increases the chance of the wrong driver being selected. With that, a deployment task will search the entire OOBD store for the right drivers. The basic default option is to throw all drivers into the same folder at the root OOBD directory. MDT is able to handle drivers in different manners.
The command prompt window will scroll really quickly and end with the prompt returning. Using the expand command, I’ll extract the drivers to my folder structure.Įxpand C:\Users\jasonrw\Downloads\990-OptiPlex-ABCDE.cab -f:* “D:\Drivers\Windows 7\Dell\OptiPlex 990” Complete, downloaded driver packs can be between 300MB and 1,000MB in size, except for WinPE driver packs which are very small.
Lenovo drivers will try to extract to their own, specified path, but that can be changed at runtime. Many Dell drivers can be used on both platforms. Dell combines x86 and 圆4 drivers in the same download. I do not delineate between x86 and 圆4 versions of drivers in my folder path because nearly all of my OS deployments are 64-bit. I create a folder structure on the MDT server similar to “Drivers\Windows #\Vendor\Model.” For example: D:\Drivers\Windows 7\Dell\OptiPlex 990
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.īulk-driver Download Sites for Dell, Lenovo, HP, and Microsoft (Surface) Fortunately, OEMs like Dell, Lenovo, HP, and even Microsoft make bulk downloads of model-specific drivers available from their sites. 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. Many drivers are distributed as packages, which come in the form of an executable. The basic INF files are what MDT needs for driver injection. It is called “Out-of-Box-Drivers” (OOBD). To do this, MDT has a folder/section in the deployment share that is dedicated to organizing and storing drivers. When a matching driver is found, it is injected into the image before it is applied to the computer’s hard drive. 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. This makes the captured image applicable to many different types of hardware. When generalizing an installation of Windows for capture with sysprep, all but the most basic drivers are removed. Anyone who has ever had to troubleshoot a piece of hardware on Windows knows this. Drivers are a big part of getting Windows to work properly.