By
Johan Arwidmark
/ April 11, 2015
When deploying machines with MDT 2013 Lite Touch or ConfigMgr 2012 R2 you eventually come across a scenario when not all drivers install, and your device manager looks something like the following screen shot. To troubleshoot the missing drivers you need to know how MDT 2013 or ConfigMgr 2012 R2 goes about injecting drivers. Their process is quite similar but it’s not identical between the solutions, so in this post you find two sections:
- Troubleshooting Drivers for MDT 2013 Lite Touch
- Troubleshooting Drivers for ConfigMgr 2012 R2
Device Manager with missing drivers.
Troubleshooting Drivers for MDT 2013 Lite Touch
MDT 2013 Lite Touch injects drivers in a three step process:
- The MDT 2013 task sequence copies the drivers from the deployment share to the C:\Drivers folder on the machine you are deploying. The files that are copied depends on your configuration, but the most common method is to use a per model approach use the DriverGroup001 variable. Anyway, to troubleshoot why the correct drivers are not copied, you can review the ZTIDrivers.log and the SMSTS.log file.
- Then MDT uses dism to apply the unattend.xml which contains information about staging the drivers that were copied to C:\Drivers into the Driver Store. To troubleshoot this step, you can review the dism.log file.
- Then the machine reboot and setup will install the drivers that are matching, and that have the best ranking if there are multiple drivers that is matching the hardware. For technical details on driver selection, check the How Windows Ranks Drivers post on MSDN. You can also check one my TechEd sessions: A Drivers Saga: Mastering Windows Deployment for more info. Anyway, to troubleshoot this step, you can review the setupapi.dev.log file if you are deploying Windows 7. For Windows 8.1 and Windows 10 deployment you need to check both setupapi.dev.log and setupapi.setup.log.
Troubleshooting Drivers for ConfigMgr 2012 R2
As with MDT, ConfigMgr 2012 R2 injects drivers in a three step process:
- The ConfigMgr task sequence copies the drivers from the deployment share to the C:\_SMSTaskSequence\Packages\–packageid– folder on the machine you are deploying. The files that are copied depends on your configuration, but the most common method is to use a per model approach using the drive package feature in ConfigMgr. Anyway, to troubleshoot why the correct drivers are not copied, you can review the SMSTS.log file.
- Then ConfigMgr generates a temporary XML file with instructions to inject the driver, and then calls dism to stage the driver into the Driver Store. To troubleshoot this step, you can review the dism.log file.
- Then the machine reboot and setup will install the drivers that are matching, and that have the best ranking if there are multiple drivers that is matching the hardware. For technical details on driver selection, check the How Windows Ranks Drivers post on MSDN. You can also check one my TechEd sessions: A Drivers Saga: Mastering Windows Deployment for more info. Anyway, to troubleshoot this step, you can review the setupapi.dev.log file if you are deploying Windows 7. For Windows 8.1 and Windows 10 deployment you need to check both setupapi.dev.log and setupapi.setup.log.
Happy Deployment
/ Johan