When Does Driver Injection Make Sense?

Over the years I've generally stayed with a specific piece of advice when performing driver injection when deploying Windows images using Microsoft Deployment Toolkit or System Center Configuration Manager. You start with the expanded driver files and import them while removing drivers that are not relevant to the platform you are deploying. Then you deploy the operating system with driver injection to see which drivers successfully install then remediate the remaining by installing them manually and using a tool such as Driver Magician to export the drivers for import into Configuration Manager. Or you might need to make silent installations of the OEM driver installers that get installed as packages via the task sequence after the Windows operating system has been applied.

All of these techniques generally works well with the exception of storage and network drivers because if Windows PE does not have network or more importantly storage drivers that work with your hardware you won't be able to image the machine. If you look deeper you might realize that there is even more that needs to be considered when deploying drivers with your Windows operating system. For example the most obvious issue is the front end software a driver might have to perform tasks such as further configuring the behavior of the device to updating the device software on a regular basis. For example some of my users using a high end display setup may want the advanced configuration control panel for their device that would not be offered if we did simple driver injection. A perfect example would be the NVIDIA control panel below.

Of course automatic updates might not be desireable in an enterprise but the advanced features may be something to consider. Off the top of my head I've seen the following types of devices use additional software to enhance the driver experience.

• Mouse / Pointer
• Keyboard 
• Display
• Printer / Scanner / Multifunction Printer
• Trusted Platform Module Chip
• Network Adapters
• Bluetooth
• Sound Devices

Further to that there are some installers that expose more information about the device via WMI and the driver installer creates the related classes. The reason this might be of importance is if you are using client management software such as System Center Configuration Manager to collect hardware inventory data of your deployed systems.

What I am trying to recommend is that you take a closer look at how you build your systems and determine if deploying the driver itself gives the user the experience they need and satisfies the system administrator's requirements rather than just injecting as much as possible. The network and storage drivers will need to be initially injected if Windows PE cannot communicate with the devices out of the box but where you go from there should be done with some care rather than following some hard and fast rules.