Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, April 15, 2015 7:17 PM
Hi Folks,
In my environment, I handle drivers using the following approach:
Driver Source store is organised like \share\OSD\DriverSource\MAKE\MODEL\architecture
Driver Package store is organised like \share\OSD\DriverPackage\MAKE\MAKE MODEL architecture
n.b. the driver package store isn't as deep, so the lack of slashes in my post is deliberate.
I import from the store, and create a driver package per combination of make, model and architecture (e.g. a 'dell optiplex 9020 win7x86' package). I create a category for each set drivers in alignment with the package name.
In time, newer versions of existing driver packages will be released by vendors and I will want to replace the drivers I have in SCCM with newer packages. My concern, is that the SCCM import methodology means you get cross pollination of drivers.
For example, if I try to import the drivers for a certain dell model, but the driver already exists and originated from a Lenovo driver package, I'm in a situation where (I assume) if I were to say 'ok, we're no longer having Lenovos', how could I safely purge SCCM and my storage for source & packages of Lenovo and not impacting the Dell drivers (in this scenario)?
I'm unfortunately inheriting an environment where I have to support 32 different unique models and there's definite driver crossover. Whilst I can target nicely with packages I just can't seem to get my head around a process I can follow which, if followed diligently will stop the risk of cleaning out old/dud drivers.
Would like to hear your thoughts as I'm sure I'm not the first person to want to achieve this.
All replies (2)
Thursday, April 16, 2015 3:44 AM âś…Answered
I think this might help you:
With Powershell:
- Run Get-CMDriver | select LocalizedDisplayName, ContentSourcePath, CI_ID | Export-Csv $home\documents\Drivers.csv
- Replace the folder paths in the Drivers.csv you exported and save it
- Rename the folders in your source -path to match the ones you changed in the Drivers.csv
- Run Import-Csv $home\documents\drivers.csv | %{Set-CMDriver -Id $_.CI_ID -DriverSource $_.ContentSourcePath}
Thursday, April 16, 2015 9:19 AM
Thanks, this could be useful. I'm still struggling to find a process that will work overall. Let's assume I have the following scenario:
- Driver Package #1: Dell OptiPlex 9020 Win7x86
- Driver Package #2: Dell OptiPlex 9020 Win7x64
- Driver Package #3: Dell OptiPlex 9010 Win7x86
- Driver Package #4: Dell OptiPlex 9010 Win7x64
- Driver Package #5: Lenovo ThinkCentre M73 Win7x86
- Driver Package #6: Lenovo ThinkCentre M73 Win7x64
You'll see drivers like this:
Intel Display Driver 101 - Categories: "Lenovo ThinkCentre M73 Win7x86", "Dell OptiPlex 9010 Win7x86", "Dell OptiPlex 9020 Win7x86"
The Lenovo was the first driver package installed in this fake scenario. Let's assume we stopped supporting Lenovos and wanted to remove that driver completely. I could do the following:
- Delete the Lenovo ThinkCentre M73 Win7x86 driver package.
- Find all drivers with the category Lenovo ThinkCentre M73 Win7x86.
I will see a mixture of drivers where the only category is the Lenovo category, and others which have Dell categories too, because the driver has become shared and even though I have no desire to retain the Lenovo assets, I'm kind of forced to unless manually identify, of the shared Lenovo categorised drivers, which ones have a source location which is in the Lenovo driver source, and update them.
This just seems overly complex and messy. There has to be a better way? I'm the kind of person that gobbles up all the MVA, channel9, teched stuff and whilst I've watched a lot on OSD and drivers I haven't (yet) seen the 'best practice' way of handling this.
Somebody from Dell claimed in this thread "you can delete all drivers for that platform even if it is shared by another platform (SCCM 2012 automatically points to the correct source path)." but I find that hard to believe... although I'd love to :).