The script generates a PowerShell GUI to automate the processes of downloading, extracting and importing driver packages for all three of the previous vendors and I hope to add more with time. The initial version is labelled v2.0 as many of the features that people requested as additional extras were built into the Dell version, so it made sense to build upon that release.
Looks great, with regards to the HP Driver packages does the modern driver management method eliminate the need to install the drivers that only come in setup.exe format (Hotkey drivers, ISS driver etc) seperatley or do you still have to add these drivers in to run silently after using WMIC filters
Depending on the product life cycle it is up to the manufacturer to guage support in their XML feed. However you can always create a custom package using the tool for consistency with support in our modern driver management solution.
In the instructions on the Modern Driver Management page, you recommend importing the drivers into a Standard Package, as opposed to a Driver Package, and then using a custom script Invoke-CMApplyDriverPackage.ps1 to install the drivers. I can see where this would be useful installing drivers on machines in the field, but is there any advantage to using this method to install drivers during OSD (vs using Driver packages and the Auto Apply Drivers task sequence step)
Essentially the underlying process of injecting the drivers is very similar in both methods. Where we differentiate from using driver packages is for several reasons, that are not really to do with OSD as such, but avoid adding the driver information to the SQL DB, the lengthy import process, avoiding the knock on performance impact on the console associated with doing so, and avoiding the total chaos method if people selecting to apply compatible drivers which could be from multiple models. During the detection process used by the Invoke-CMApplyDriverPackage script, only the latest driver package for that model is matched every time, so the results are always going to be consistent with how the manufacturer has delivered the drivers for that model.
Thanks for the explanation. You make some interesting points. Combine that with the fact that the same script and packages can be used both to install drivers during OSD and to update drivers on existing systems already deployed in the field definitely makes it interesting.
======== Latitude 7480 BIOS PROCESSING STARTED ========1/1/1601 12:00:00 AM0 (0x0000)Info: Found BIOS URL 1/1/1601 12:00:00 AM0 (0x0000)Info: Latest available BIOS version is 1.6.5 1.7.31/1/1601 12:00:00 AM0 (0x0000)Info: New BIOS download available1/1/1601 12:00:00 AM0 (0x0000)Info: BIOS Download URL Found: _7x80_1.6.5.exe FOLDER04651314M/1/Latitude_7x80_1.7.3.exe1/1/1601 12:00:00 AM0 (0x0000)Info: Downloading Latitude_7x80_1.6.5.exe Latitude_7x80_1.7.3.exe BIOS update file1/1/1601 12:00:00 AM0 (0x0000)Info: Copying Dell Flash64Bit EXE To \\\\ITGC2W000208.VFCORP.VFC.COM\\SOURCE$\\OSD\\DRIVERS_TMP\\Dell\\Latitude 7480\\BIOS\\1-6-5 1-7-3\\1/1/1601 12:00:00 AM0 (0x0000)======== Latitude 7480 BIOS PROCESSING FINISHED ========1/1/1601 12:00:00 AM0 (0x0000)Info: Updating existing BIOS package descriptions for deployment purposes1/1/1601 12:00:00 AM0 (0x0000)Info: Remaining models to process: 01/1/1601 12:00:00 AM0 (0x0000)======== Clean Up Driver Option Processing ========1/1/1601 12:00:00 AM0 (0x0000)ConfigMgr: Removing downloaded driver files from \\\\ITGC2W000208.VFCORP.VFC.COM\\SOURCE$\\OSD\\DRIVERS_TMP. Extracted drivers will remain1/1/1601 12:00:00 AM0 (0x0000)======== Finished Processing ========1/1/1601 12:00:00 AM0 (0x0000)
Unfortunately as Alienware is seen as a consumer brand, Dell do not publish SCCM driver packages for those models. If you are looking to use these downloads through our MDM process, the only alternative is to create a custom driver package based on extracted drivers.
It really depends on the model and its life cycle stage. If the model is new then they tend to keep the driver packages as up to date as possible, having said that though there will be times when individual drivers are released separate to their package refresh times. So to answer the question, if you want to keep the most up to date driver packages possible go with the custom package. Note that you could simply replace driver folders within the manufacturer package as an alternative also, i.e remove the video folder and replace it with your own, then re-distribute.
The driver packages are the responsibility of the vendor to keep up to date and you will find that as each new product comes out, support for older models like the T460 will begin to decline. This is why I have added in the ability to create custom packages in the latest version, of course there is nothing to stop you simply replacing the old drivers within the package source and re-distributing. As for duplicate drivers, personally I would just enable data dedupe on the distribution points to let it take care of any duplication issues but its a personal choice.
Congrats on this amazing tool. Unfortunately I am experiencing an unusual behavior running it to get Lenovo drivers.Everything seems to have run successfully, the folders are created and the drivers/packages downloaded but nothing is created on the SCCM side, although the logs show that the packages were created:
The model list and subsequent supported operating systems are fed through in an XML from Dell, so I have no direct control over the listings. Dell ship updates to the XML on the second Tuesday of the month ( -client/w/wiki/3588.driver-pack-release-schedule) so it might be a case that the link will appear in the next release. At present manually interrogating the XML only results in the following;
When the drivers are attempted to be added, the script attempts to add the directory as a driver package. To solve the problem change line 900 to include the -File filter so only files are included in the list and the directory object themselves are excluded.
If you wanted to apply hypervisor drivers from either Microsoft or VMWare, you could simply create a custom driver package. You would need to extend the driver matching within the matching script, see the code for examples, as it is just a matter of having a matching value for the content to download and apply.
Hello, I am sure I overlooked something in the documentation so I apologize up front. I have implemented this in my environment and the problem I am having is the driver packages are pulling from the main site server and not from the local DP. I have one location that has very limited bandwidth and because of this it went from a 40 minute image process to a 4 +hour imaging process because the driver package download was so slow. Any suggestions on were I should look or check on Thank you.
We currently have issues with Driver Package for the Models Dell Latitude 7400V and 7200 2 in 1.For the 7400V package the download link is wrong so it will fail.In the 7200 2 in 1 package a driver is missing so that the touch screen will not work. It is the driver Intel(R) Serial IO I2C Host Controller.Is there anyone with the same issue
We have noticed that it takes quite a long time for the driver package to download because it is downloading a single unpacked file at a time. Has there been thought to making the package the driver CAB and extracting the contents after it has been downloaded In one example, the packed version is a single 850MB file, where the unpacked drivers are 1.7GB with over 1000 files!
The dell 980 package was originially a windows 7 package but as there are no 10 drivers available from dell for this model I changed the package name from 7 to 10 .. should it still work applydriverpackage.log here:
3. All Drivers in the Fallback package are installed in \"DriverUpdate\" Mode. I would prefer also only to insert the drivers and let windows choose, which are the best on reboot. Otherwise i can only insert really standard drivers and thats seems to be useless. Therefore its is easier to catch a missing driver package in the task sequence with \"continue on error\".4. Could you include Fujitus drivers
Is there a good method for updating drivers in the field We have a very large environment and currently we manually script \\ create packages delivered by SCCM to update drivers \\ firmware in the field. Any automation is desperately needed.
1. Once the package is made you can indeed remove the package path used for the driver package. BIOS packages are created in the package path. There is an automated method of doing this via the GUI itself also if you wish.1a. The hierarchy is %Make%\\%Model%\\%OS%-%Version2. It is a manual delete unless you are superseding the previous version, in which case there is an option in the GUI.3. The service will indeed still find them as it looks for the package name, which does not rely on the folder structure within ConfigMgr.
Driver download package process initiated1/1/1601 12:00:00 AM0 (0x0000)Manufacturer determined as: HP1/1/1601 12:00:00 AM0 (0x0000)Computer model determined as: HP EliteBook 840 G31/1/1601 12:00:00 AM0 (0x0000)Retrieved a total of 0 driver packages from web service1/1/1601 12:00:00 AM0 (0x0000)Retrieved OS Image version from web service: 1/1/1601 12:00:00 AM0 (0x0000)Determined OS name from version: 1/1/1601 12:00:00 AM0 (0x0000)Unable to detect current operating system name from task sequence reference, bailing out1/1/1601 12:00:00 AM0 (0x0000) 1e1e36bf2d