Driver Management

One of the nicest features of OSD in ConfigMgr is the driver catalog, which stores all applicable drivers for all identified hardware in an organization. The deployment process uses this catalog to identify which drivers to copy to a system. Entries are made to the unattended setup file in use, which effectively adds the drivers to the internal Windows driver catalog. When added to the internal driver catalog, the drivers copied to the system are available for the setup or mini-setup plug-and-play device detection, driver installation processes, and any new hardware additions made to the system in the future.

Adding drivers to the catalog is a matter of following the steps in the "Drivers" section. As you must import drivers from a UNC path, it is worthwhile to create a driver repository on your network to store all the driver files. All drivers must be stored in a driver package as described in the "Driver Packages" section, regardless of the task type used to deploy them to a target system. This is a change from ConfigMgr 2007 where a popular driver deployment technique, called the Johan Method (named after Johan Arwidmark-Windows Deployment MVP and Windows deployment master), was widely used. This method, although unsupported by Microsoft, involved directly dropping files into the source location specified by a driver package without first importing them into ConfigMgr. It was an elegant solution to a handful of issues with driver management in ConfigMgr 2007- namely duplicate drivers that were problematic to deal with. This method no longer works in ConfigMgr 2012 and is officially classified as a bug in ConfigMgr 2007.

Just because you added a driver into a deployment does not mean Windows will use it. Windows goes through its own plug-and-play process to identify devices and then uses suitable drivers from its internal catalog; the internal catalog includes drivers you injected using one of the two task types. Insiders have described the Windows plug-and-play process as a black art. OSD attempts to replicate it as closely as possible, but there are many complicating factors, including parent-child relationships that hide child devices until the parent drivers are installed. Although the Auto Apply Drivers task generally works well, there are times where it will not identify and inject the proper driver. In these cases, add the problem driver to a driver package of its own and use a separate Apply Driver Package task to inject the driver for use by Windows.

Acquiring device devices is usually a straightforward process: Visit the hardware vendor's website and download those listed for the hardware models for which you are concerned. On occasion, however, you will find that the drivers are packaged in an installation program. In these cases, there are two options:

• Extract the driver files for the installation program. This is the best option but not always available because extracting them may be an undocumented or unsupported process.
• Create a software distribution package and install the drivers using a Software Install task. If you resort to this technique to install drivers, ensure you use the proper switches to install the drivers silently. You may also want to ensure the drivers installed in this fashion are installed only on specific hardware models. To achieve this, use a WMI Query conditional on the task (described in the "Task Conditions and Groupings" section), such as
  SELECT * FROM Win32_ComputerSystem WHERE Model like "%760%"

Use the root\cimv2 WMI namespace for this query and replace the text in the quotes with the appropriate model number. Note that the percent sign is a wildcard in the WMI Query Language (WQL) and represents zero or more of any character.

To determine the model attribute quickly on any system, run the following from a command prompt: wmic computersystem get model . Cliff Hobbs maintains a fairly up-to-date list of the results of this command from many different models for many different manufacturers.