Archive: Some tips on exporting drivers for MDT/SCCM

It’s no secret that finding the right drivers for a Windows system can be a challenge. Importing those drivers into MDT/SCCM, deploying a system, and getting those drivers to apply correctly can be an even bigger challenge. Over several projects with some pretty diverse clients, there’s a few tools that I’ve run across that I use for every deployment now.

One of those tools is DriverMax or Double Driver. Essentially, both accomplish the same thing. They grant you the ability to export the drivers on any Windows system in a format that imports perfectly into SCCM or MDT for deployment. This sounds like a much simpler task than you’d think, but for anyone who has struggled finding the right driver before will understand. Both of these tools can identify the non-native (or non-Microsoft) drivers that don’t come down in a vanilla image deployment, export them in the correct INF format, and organize them into categories (NET, SATA, Biometric, etc) to make life simpler.

This, in my humble opinion, is a better format than what you get downloading driver packs from manufacturers’ websites. For one, those downloaded packs can literally add up to GBs, where a Double Driver/DriverMax export might be a couple hundred MB maximum, exporting only the files required for a successful driver installation. Also, the downloaded packs sometimes have a driver embedded into an application installer, which of course doesn’t import directly into MDT/SCCM. With these freeware tools, you can easily export the driver after the larger application has been installed.

These tools help a lot, but there’s some other helpful tips when using driver detection/deployment in MDT/SCCM. Firstly, only import the drivers that you absolutely need. Watch out for driver exports that contain drivers for external mice/keyboards, drivers for VPN applications, or drivers that won’t apply to every system. If you keep it clean, you will thank yourself down the road when a driver conflict doesn’t happen. Second, keep your drivers organized, and split into packages and categories if you’re using SCCM. If you differentiate your drivers when importing them, they will be much easier to troubleshoot later if needed. Thirdly, use driver packages instead of the “auto apply drivers” option. I will make a post later detailing this process- there are a few reasons for this method, but it’s much cleaner and dependable process. For more on using driver packages, check out this guide.

An even greater challenge can be finding the right drivers to inject into your boot media! Seriously, find a spot on the wall to bang your head on. Luckily, this has been greatly improved. The later your version of WinPE, the better your chances are that your model’s network or driver controller driver is already embedded into the default boot media. This means: use the Windows 8 boot media (even if installing Windows 7) that comes in the Windows Assessment and Deployment Kit (Windows ADK). If you’re using laptops with USB 3 ports, you might want to import those drivers as well if you’re using USB boot media! They are usually not supported by default in WinPE. And once again, using only the required drivers that you need, and not importing an entire pack, is a recommended practice.

Several manufacturers are releasing WinPE driver packs now, which can save you a lot of time. Even packs released for older versions of WinPE will be helpful in the current version, 5.0.

All in all, things in the driver world have greatly improved over the years, but a plan for deployment is essential! Hopefully this provides you with some guidance and will save you some testing time.


Updated on 2014/03/12 – Links were updated to reflect new WinPE 5.0 Driver Packs