Drivers in the Image

Because you want your image to be as generic as possible and include only those items existing on every system in your organization, you want to minimize additional thirdparty drivers in the image itself. Minimizing drivers limits the size of the image; however, it is completely unavoidable to include some drivers-particularly those distributed with the OS and those required for the reference system itself. This is quite acceptable; do not worry too much about additional drivers; most are relatively small, and Windows does not use or load them if they are not for a currently installed device.

There might be times when you want to force certain drivers into every image; for example, when users use locally attached devices such as printers, scanners, card readers, or biometric devices not attached to the system during its deployment. In this case, make the same decision with these drivers as you do with software. Is the device going to connect to all (or nearly all) systems? If so, include it in the image. If not, it should be layered on after the image is deployed with an Apply Driver Package task.

Another common concern is that if you do not include a driver in the image, it will not be available to systems where you deploy the image. This particularly comes up as a concern for the built-in drivers. This is a false assumption. All drivers that come with Windows are still part of the image unless you go through a lot of pain and effort to remove them.

Drivers After the Image

If any, organizations use the exact same desktop and laptop hardware for all their users. Although a desirable goal, it is unrealistic for most organizations because of many factors: the ever-changing model lineup delivered by hardware vendors, the diversity of user requirements, merges and acquisitions, hardware refresh cycles, and so on. This results in a wide range of hardware in your organization and many different drivers. As with software that is not ubiquitous throughout your organization, after deploying the image you must layer on various drivers by using one of the two driver task types, described previously in the "Drivers Category" section of this tutorial:

• Auto Apply Drivers: Uses a plug-and-play detection during the task sequence to copy only the drivers for devices detected during the task sequence.
• Apply Driver Package: Copies all drivers in a given package to the system without any detection logic.

Driver management is an oft-discussed topic in the various Internet forums, including the main Microsoft Configuration Manager forums. Many different opinions exist on this topic and can be placed on a spectrum with "control freak" at one end and "chaos" at the other. Control freaks use only the Apply Driver Package tasks in combination with the WQL conditional presented in the "Drivers" section to ensure only specific drivers are deployed to systems in a controlled manner. Subscribers to the chaos methodology use only an Auto Apply Drivers task and let chaos reign with driver deployment.

Although neither methodology is necessarily wrong, the reality is that most OSD deployments fall somewhere in the middle depending on the drivers and systems you are deploying. As long as it works and enables you to deploy your systems successfully, the methodology you adopt cannot be wrong. An excellent blog post reinforcing some of the information presented here is available at http://blogs.technet.com/deploymentguys/ archive/2008/02/15/driver-management-part-1-configuration-manager.aspx.