-
Notifications
You must be signed in to change notification settings - Fork 57
Drivers
- General information: https://docs.microsoft.com/en-us/sccm/osd/get-started/manage-drivers
- Auto Apply Drivers: https://docs.microsoft.com/en-us/sccm/osd/understand/task-sequence-steps#BKMK_AutoApplyDrivers
- Apply Driver Package: https://docs.microsoft.com/en-us/sccm/osd/understand/task-sequence-steps#BKMK_ApplyDriverPackage
There is a lot of misinformation between Driver Packages and Auto Apply. You often hear the term "wild west" or "uncontrolled" used in reference to Auto Apply and "full control" in regards to Driver Packages. The truth is that both function very similarly, it is mostly a question of when the driver filtering happens. The driver selection in both scenarios is essentially the same. Using Auto Apply does not reduce any control you have, nor does Driver Packages give you any more control. With both methods you are fully at the mercy of the Windows driver selection logic, the only way to gain control would be to roll your own driver selection functionality and then individually inject drivers one at a time. While the bulk of the steps ideally are one or the other, the optimal solution is to use both as each one has strengths and weaknesses.
To address the key difference, when driver selection happens, for Auto Apply driver selection happens at that front, meaning it only downloads and applies the drivers you need. Note that you can instruct Auto Apply to download all applicable drivers, in which case it would function much more closely to Driver Packages. This is an unusual niche use case as all you would be doing is injecting multiple versions of the same driver into the database. Apply Driver Packages downloads and injects all drivers in the package into the driver repository, then during Windows setup drivers are selected and installed. In both scenarios, drivers aren't actually installed until Windows setup runs and actually installs the drivers. So it really comes down to when the filtering happens, before drivers are injected into the repository or after they are injected (but still before they're installed).
In either case the filtering logic is essentially the same, we use the VEN and DEV ID to identify drivers, and then sort by date and version. Date always wins over version, this is purposefully done so MS can publish their compatability drivers with very old dates, but a manufacturer driver wins even if it is a much older version.
Here's a quick pro/con list for the two approaches:
- Significantly faster than Driver Packages as less content is downloaded and injected. (Time savings goes up as driver package size goes up, thank you very much HP.)
- Can be scaled to be more responsive and dynamic (open ended auto apply) or more controlled by selecting specific categories. If the categories match your driver packages, the end functionality is essentially identical.
- Can catch models that are not known/expected/supported in the environment by using an open auto apply.
- Can catch drivers from the vendor supplied packages that are missing or intentionally left out (thanks Lenovo!).
- Quicker and easier to add missing drivers or disabling a bad driver as the driver package does not need to be re-distributed. (Note: Content still needs to be on the Distribution Point, it just doesn't care how it got there and there's no need to redistribute packages if the driver is already there.)
- For single vendor environments it's often very viable to have a single open auto apply, limit them by family, or even desktop vs laptop. This reduces TS size and complexity and makes management drastically easier.
- Drivers that are not found by PnP or are not currently connected won't be installed. Mitigate this by using a driver package with all your docks/dongles/USB/etc drivers. It is good practice to do this regardless if you are using Auto Apply or Driver Packages.
- Open Auto Apply (not category limited) can apply a driver that doesn't play well with the hardware. HP drivers/hardware is often incompatible with Dell/Lenovo (going in both directions). If running a mixed environment, it is recommended to put some limitations in place to prevent drivers from being cross installed between vendors. (YMMV. Dell and Lenovo for example generally play nice.)
- Does not work for offline media. ( :protip: don't use offline media. )
- All drivers in the package are stored locally, which can be useful for devices that are not plugged in when OSD occurs.
- Arguably slightly easier to build and understand, this is largely mitigated by using a tool to automate the import and creation of drivers, packages, and categories.
- Works for offline media. ( :protip: don't use offline media. )
- Uses more disk space on the endpoint.
- Increases imaging time as more files have to be downloaded and then injected.
- Disabling a driver in the driver database doesn't do anything. At all. Sorry-not-sorry for all the times that you used driver packages and disabled a driver to "fix" the issue you were having.
- Any changes to the Driver Package requires that it be re-distributed out in order for changes to take effect.
- Apply Driver Package step in the task sequence takes a LOT longer to load than Auto Apply. (Don't ask me why, it shouldn't, it's just pointing to a package.) This is incredibly painful if you have to change a large number of steps, and is exponentially more painful as your connection to the primary from the console gets slower/worse.
While selecting Apply Driver Packages vs Auto Apply is not a hill you should choose to die on, given a preference Auto Apply will provide for a better experience to the techs (faster imaging time) and better experience to the end user (not eating up disk space). If more granular control is desired (as it often is) then using individual steps gated by WMI or TSVars and categories fills this need nicely.
Regardless of the solutions is chosen for the "main" part of the driver installation (individual models), a few steps should always be included which will reduce issues, reduce missing drivers, and provide a better tech and end user experience.
Often docks, dongles, USB devices, network printers (or just printers in general), and similar devices are not present when OSD happens. These are also often not present in the vendor supplied driver package. It is recommended that these be collated into a single driver package and this package be installed on every device (regardless of manufacturer or laptop vs desktop). This ensures that an end users will always have support for these devices, even if they take their HP laptop and sit down at Janice's desk to use her Dell dock, or if a clever user decides to use a dock to add additional monitors to their desktop.
What happens if we get to the end of the drivers and we haven't found a matching model? Or perhaps this is a new model that's coming in and you forgot to download and import that package (shame on you!)? Or it's a BYOD device (because that never happens 🙄 )? Or someone refused to put a driver into their driver package out of petty spite (Lenovo!)?
An open ended Auto Apply will find all these scenarios and have your back. Regardless if you use packages or Auto Apply for the bulk of you models, having an open ended Auto Apply is a good way to CYA and give better support to all those scenarios that otherwise the imaging would fail on (meaning you have to do more work troubleshooting) or end with poor hardware support.