Using ConfigMgr to keep drivers up to date

[surfincow]

Hello,

 

I believe I'm soon going to be tasked with using configmgr to keep drivers up to date on all our workstations (all are Dell Latitudes). I briefly attempted this before using the Dell Business Client Updates Catalog for SCUP. The results were not as great as I had hoped.

 

There is an agent you push to all the machines which collect what drivers are required. You also publish the meta-data from the update catalog to configmgr and then after a few days you can query to see what drivers are actually needed. The issue I ran into is that the update catalog contained numerous circular dependencies (example: To install UpdateA you must have UpdateA installed). The result of this is that even though none of these updates were deployed, they were in the updates db in configmgr which broke software updates for all configmgr clients. (they would fail due to circular dependencies).

 

To find the problem was quite involved which required referencing numerous logs, expiring the update from SCUP, republishing, re-sync the software updates and try again. Lather, Rinse, Repeat. I believe I had at least 30 of these circular dependencies which took about a day to fix. Once that was resolved, the updates themselves weren't that "up to date" either. Since then I've been turned off by the Dell Update Catalog.

 

I've worked with a few SCCM consultants (MVP's) and asked about how they handle driver updates at the places they manage (universities with 1000's of workstations), and their answer was "we don't".

 

So I'm wondering, do any of you handle the updates of drivers? and if so, whats your method?

 

 

 

 

Thanks!

[pascalvis]

You could have a look at the PS script "http://mickitblog.blogspot.nl/2016/04/using-powershell-to-control-dell.html"written by MICK PLETCHE

[spgsitsupport]

Business PCs are NOT home enthusiast PC. Once you have working drivers (that do what they need to do, and do it well), there is really NO NEED to keep tweaking & updating them.

 

If you re-image workstations then you can update drivers in SCCM (that will be used in new deployment)

 

But really there is no need to update constantly something that already works.

 

If it ain't broken...

[YPCC]

^ fully agree with the above. This is where some pushback on managements demands is neccessary.

[surfincow]

Yeah, this sounds like the process we use now. Updated driver at install time but after that they stay the same. It is good to get your feedback as if this isn't something others are doing then there's probably a reason

 

 

Thanks!

[Garrett804]

Yeah trying to keep up with every single driver update on every single model is just insane.

 

If I were to do it though I would simply just make a package for the update files and deploy it out. I wouldn't bother trying to do it via SUP. I try and keep my SUP and packages separate which is why I don't prefer to use SCUP for the exact reasons you experience with it messing up your SUP.

[wilbywilson]

While I've used SCCM and SCUP (with Shavlik integration), I've never tried to deploy driver updates in a business environment. There's just a lot that can go wrong, and the users can end up with unusable machines.

 

A few years ago, the security team brought it to our attention that a certain Radeon/NVidia driver (I don't remember which model/manufacturer, but we had a couple thousand in our environment) had a security issue. They wanted the SCCM team to mass-update the driver. We tried on a small test group, with very mixed results. In the end, it was decided that the chances of this exploit taking place were slim, and we didn't try to push out video card drivers through SCCM. If the security exploit in question is really serious, then I would suggest an SCCM package versus SCUP. The only positive experience I've had with SCUP is integrating it with Shavlik (paid service). Through that, we've deployed Adobe, Apple, and Java patches relatively successfully. I've had poor experiences with the DELL and Adobe-manufactured catalogs.

 

(I think it tells you something when a third-party company is coding/testing the updates for these manufacturers. These big companies don't have a good track record for their own SCUP catalogs.)