ConfigMgr – Installing Software Based Drivers
In addition to the driver management methods that I’ve blogged about before, I wanted to create a post showing how I typically handle “bad” drivers, or drivers that are software based. These would be drivers we can’t manage through normal PNP detection (auto-apply) or through driver groups (“forced” injection), usually they are MSI based or setup.exe based as well.
So what I’d like to do here, is show you a few common approaches to handling how to install the software, sort of a good, better, best approach. All of these methods do work, so feel free to use the approach that works best for you. I’m using a bunch of generic names and models instead of specific vendors as I don’t want to give the impression that one vendor is “better” than others.
Installing drivers on a per manufacturer and/or model basis (good)
The first method involves creating a structure in your task sequence for each manufacturer and model you might have. This gives you some very good organization, and it’s nicely laid out. However the negative here is that you could be listing the same drivers for multiple models. If you add a new model, then you would need to create new steps and match up the appropriate drivers. If you have a large organization with a lot of models and manufacturers, your task sequence could get very large.
We use a model query on the model steps to limit those to only run on a per-model basis. Anything under that step will then run on the given model.
Installing drivers on a per driver basis with model detection (better)
One way to improve upon the previous method is to create steps for the various drivers themselves, and then add queries for the models they support. This allows for more flexibility. If you add a new model that uses the same driver, you just have to add another query for it work. This method has fewer steps in your task sequence than the previous method.
On the driver package itself, we use model queries to tell it what models that step will apply to.
Installing drivers based upon the HardwareID (best)
The method I prefer for installing these types of drivers is based upon the HardwareID. Just like we do for mass storage drivers. This allows the most flexibility you don’t have to worry about new model support, as long as the HardwareID matches, the driver will install successfully on your systems. This is the cleanest method and allows for the fewest steps in your task sequence.
Then for Bad Driver 1, we’ll set a single HardwareID for an example.
For Bad Driver 2, here’s an example when the driver could apply to multiple HardwareID’s. We’ve set a “If any conditions are true”, so it’ll run as long as there is a single match.
So, just like we can use the HardwareID to detect and inject the correct mass storage driver for Windows XP, we can also use it to install “software”.
Hope that helps.