You have to differentiate two different things here. First, the source for a driver and the source for a driver package. Those aren't the same and should always be kept separate.
So you have your drivers at a source location and import them to ConfigMgr. ConfigMgr now iterates over all drivers at the location you selected to import. If a driver is new, it will be added to the driver store and the UNC source path will be set to the current exact path. If the driver is a duplicate, it won't be added again and the existing driver will also not be updated with a different path. Second step is adding drivers to a driver package. During this process, the driver files will be copied from the source specified for each driver to the source of the driver package. So if a single driver is part of several driver packages, a copy will exist in each driver package source location. If the driver package now gets refreshed, the content of the driver package source location will be read. If you now replace the driver at the source location for the drivers, ConfigMgr won't actually recognize this as you didn't import it (again). And if you update the driver package, it will update it based on the source location for the driver package (which has a copy of the original driver). That's why you still see the original files. There are now several problems that can (and probably will) arise. If you replaced a driver and now add this driver to a different driver package, ConfigMgr will copy it again from the driver source location to the driver package source location. However, the files have changed, so the hash will be wrong. If you removed a driver from the driver source location but did not remove it from ConfigMgr and then add it to a different driver package it will add the driver to the package in the configuration of the driver package, but it won't be able to copy the files, so the driver package will fail to refresh, as it can't find the appropriate files. I totally agree that the way ConfigMgr is handling drivers is still far away from being easy and intuitive. What I currently do to be able to update/replace/remove drivers properly is the following: I keep all drivers in a central MDT based repository. For me managing and testing those drivers is way easier to be done in MDT, but any other way will do it as well. When drivers have been tested properly, I export/copy them from the central repository to a location that acts as a source location for all drivers for ConfigMgr (we actually have several of them for different environments like test, qa, production etc.). This is structured by OS, Architecture and Model family (we combine several models in to family packages). Important part here. I always replace the whole content, so that it reflects exactly the files from the repository. This makes sure that drivers are removed properly and it's exactly the same set of drivers that was just tested. Then I run a script over the updated driver source. Which will act as following. Iterate over all drivers for a model family (Driver package will have the same name) and try to import them into ConfigMgr. If it's new, add it to the appropriate Driver package and also add a category based on the name of the model family. If it's a duplicate, check if the source location of the driver still exists and if not, update the driver source location with the path of the current driver. If all drivers from the source have been processed, compare the list of these drivers with the list of all drivers from the driver package and remove all the drivers that aren't in the source any longer from the driver package and also remove the appropriate category. If the driver now doesn't have a category anymore, remove the driver completely. Finally refresh the driver package. This method requires a bit more space as there will be duplicate drivers at the driver source location and it also does take quite an amount of time as it basically tries to re-import every single driver again. But as it is automated I really don't care about some additional processing time and it works pretty well for me so far to keep several environments in-sync, while still being able to add, update and remove drivers on a regular basis. Regards Maik From: [email protected] [mailto:[email protected]] On Behalf Of Bradley, Matt Sent: Freitag, 26. Juni 2015 21:44 To: [email protected] Subject: [mssms] Updating Driver Packages I'm trying to figure out if I have a problem or not on how I'm updating driver packages. In this case, for a SurfacePro3. How I've been doing it, is deleting the old driver files form the UNC driver path, replacing them with the new ones, and then updating the distribution points. Looking at the monitoring tab, it shows that all the DP's update successfully. However, the driver package source UNC is not changing. It still has old files, with old time stamps. Any ideas what is wrong? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information of Cameron and its Operating Divisions. Any unauthorized use or disclosure is prohibited. If you are not the intended recipient, please contact the sender by reply email and delete and destroy all copies of the original message inclusive of any attachments. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
