Throughout the years, driver management for operating system deployment in ConfigMgr have been a daunting task that administrators have had to deal with on a regular basis. New computer models are occasionally introduced in the environment, which we can’t deny.

Administrators have previously been manually downloading all required drivers, importing them into ConfigMgr, distributing them to Distribution Points and updating task sequences to include the new driver package for the new computer model. This process can be really time consuming and error prone. In the past, great guys like Johan Arwidmark has come up with great solutions like “Total Control” when it comes to driver management. Recently, Kim Oppalfens posted an article of how to enhance the previous known methods by leveraging the undocumented task sequence variable called OSDDownloadDownloadPackages.

In this post, we intend to cover an automated driver management process that provides a whole new dynamic process upon the idea from Kim Oppalfens, but leveraging both our ConfigMgr Web Service and the Driver Download Tool. This process consists of a set of steps that has significantly been improved and automated to provide an end to end solution for driver management. We want to thank Mattias Benninge for coming up with the idea of using the ConfigMgr WebService in this solution.

Solutions mentioned in this post are not all brand new, however the final piece of the puzzle, allowing for an automated and dynamic way to select the proper driver package for a specific computer model ties it all together in a single script.

Overview

We call this modern driver management (not to be confused with MDM, mobile device management), not because it’s driven by the cloud (however some parts could probably be), but it combines new methods for driver management that has not been shown before. What this solution does, simply put, is to automate the download of driver package, creating packages in ConfigMgr, content distribution, dynamic driver package selection during operating system deployment and finally installation of drivers contained in the selected package. All this with only a few clicks in the Driver Download Tool, the ConfigMgr WebService and three simple steps in your task sequence.

Below are the required steps that you need to take in order to leverage this automated solution for driver management.

Step 1 – Download and prepare driver packages

For our this approach to modern driver management we need to populate ConfigMgr with driver packages for your client machines. If you are running Dell, HP or Lenovo hardware then you can use our Driver Automation Tool to do exactly that. Simply download the script from the following link (note that the minimum required version is 2.7 due to changes in the handling of packages):

https://gallery.technet.microsoft.com/scriptcenter/Driver-Tool-Automate-9ddcc010

  • Launch the Driver Tool and connect the GUI to your ConfigMgr environment by entering the name of your Site Server and hitting the Connect To SCCM button
  • We now need to select the Deployment Platform as “SCCM – Standard Pkg“, then pick “Drivers” as the Download Type and pick your OS/Architecture
  • On the Manufacturer Tab select the vendors you wish to display models for and then hit the “Find Models” button
  • Select the models from the list you wish to download packages for and hit the “Add to Import List” button
  • On the Driver Storage Locations tab enter in UNC paths for the Repository and Package paths
  • Click on the Start Download and Import Process to kick off the driver downloads

Once downloaded you should end up with something like this in your ConfigMgr console:

Distribute the driver packages to your DP’s as needed and you are now set for Step 2.

Note: If you wish to download your own driver packages then all you need to do is ensure your driver package name starts with “Drivers -” and you use the WMI manufacturer name for the manufacturer.

Note: If you are already using the Download Tool 2.6 or lower and Standard Packages for drivers, you will need to prefix the package names with “Drivers -” also.

Step 2 – Install ConfigMgr WebService

Modern driver management solution requires the ConfigMgr WebService to be installed in your environment, with the minimum of version 1.2.1. Detailed installation steps can be found in the documentation included in the package, downloadable from the following link:

https://gallery.technet.microsoft.com/ConfigMgr-WebService-100-572825b2

Before we release version 1.3.0 of the web service, you’re required to patch (simply just replace the ConfigMgrWebService.dll file) from version 1.2.0 to version 1.2.1. Download version 1.2.1 from below:

ConfigMgr WebService 1.2.1 (179 downloads)

The web service is a key function to this process as it will be used during the task sequence to query the available packages from ConfigMgr (using the GetCMPackage function) and through logic in a PowerShell script, match available driver packages to the model and manufacturer of the machine being deployed.

Step 3 – Prepare Task Sequence with dynamic selection

Adding the steps for Modern Driver Management could not be simpler. Download the script required from the following link:

https://github.com/NickolajA/PowerShell/blob/master/ConfigMgr/OS%20Deployment/Invoke-CMDownloadDriverPackage.ps1

Update 2017-05-04 – Script has been updated with new functionality supporting multiple operating systems packages in addition to some small fixes. See script version history for more details.

This script will automatically detect the computer model and manufacturer, calling the ConfigMgr WebService for driver packages (read legacy Packages, not Driver Packages) matching those values. In the case of multiple packages that match the criteria, the most current package will be selected based upon the SourceDate property of the package object. If there’s no matches at all, the script will exit with a return code of 1, causing the deployment to fail. In terms of logging, the script is writing to a separate log file called DriverPackageDownload.log located in the same directory as the smsts.log file at the time of operation.

Follow this four step process to implement the script referenced above:

  • Package the “Invoke-CMDownloadDriverPackage” PowerShell script and distribute it
  • Add a Run PowerShell Script command after the Apply Operating System phase, calling the “Invoke-CMDownloadDriverPackage.ps1” script with parameters for the following:
    • URI – URL of the ConfigMgrWeb service – example: http://configmgr01.scconfigmgr.com/ConfigMgrWebService/ConfigMgr.asmx”
    • SecretKey – The secret key used to connect to the ConfigMgrWebService site
    • Filter – In this instance enter the term “Drivers”

  • The next step is to add a Download Package Content step. We recommend that you select a small package here, a determined value contained within the OSDDownloadDownloadPackages hidden task sequence variable is used to add the Driver Package to this list. The package selected here in the UI can be considered a dummy package, and will not be downloaded.

  • The final step is to use DISM to apply the downloaded drivers

See Modern Driver Management in action

Below is a capture of the Modern Driver Management process running on a Dell Latitude E5470:

Summary

The real “secret sauce” to our approach to Modern Driver Management is the ability to automate the download and packaging process via our Driver Download Tool and query ConfigMgr during the task sequence using our ConfigMgr WebService. Working hand in hand with each other we’re sure you will agree that this process really takes a lot of the pain out of driver management in ConfigMgr, leaving you free to drink some more coffee.

In testing we have used Dell hardware, however the same logic should work with HP and Lenovo as the driver packages are already catered for here.  That’s it for now… and if you have feedback we would be glad to hear it!

Nickolaj Andersen & Maurice Daly

Maurice Daly

Maurice has been working in the IT industry since 1999. Technology focus includes Active Directory, Group Policy, Hyper-V, Windows Deployment (SCCM & MDT) and Office 365.

Maurice is a Microsoft MVP since 2017 in the area of Enterprise Mobility

Nickolaj Andersen
Principal Consultant and Enterprise Mobility MVP. Nickolaj has been in the IT industry for the past 10 years specializing in Enterprise Mobility and Security, Windows deployments and Automation. In 2015 Nickolaj was awarded as PowerShell Hero by the community for his script and tools contributions. Author of ConfigMgr Prerequisites Tool, ConfigMgr OSD FrontEnd, ConfigMgr WebService and a frequent speaker at user groups.

(9283)

comments
  • Jakob Svarrer
    Posted at 06:24 March 30, 2017
    Jakob Svarrer
    Reply
    Author

    Hi,
    Great post(and work) and very interesting. Just a single question is it possible to manage the download of the right driver package when you have multiple OS (Windows 7, Windows 10) and different architectures (x86 and x64) for the same hardware model by using this approach?
    Kind regards
    Jakob

    • Andrew
      Posted at 07:57 April 11, 2017
      Andrew
      Reply
      Author

      Hi Jakob,
      I haven’t tried x86 and x64 yet (everything is x64 here), but for Multiple OS I have set my package names to W10Drv and W7Drv as a prefix and used that in the -filter of the TS step instead of using “Drivers” like in the guide above.
      Regards,
      Andrew

      • Jakob S.
        Posted at 22:38 April 23, 2017
        Jakob S.
        Reply
        Author

        Hi Andrew,
        Thank you for your post. I got inspired by the solution Matthew Teegarden posted recently and decided to add some code from his script to the code of Nikolaj and Maurice and made it possible to support multiple os and architecture(according to a Tweet by Maurice I Think it was,, an Update is on it’s Way supporting multiple OS etc.
        Kind Regards,
        Jakob

  • Mark
    Posted at 08:55 March 30, 2017
    Mark
    Reply
    Author

    Amazing, I look forward to testing this out. Does this mean we could also do BIOS updates in a similar way ?

    • Maurice Daly
      Posted at 09:02 March 30, 2017
      Maurice Daly
      Reply
      Author

      Hi Mark,

      It does indeed. Another blog post to come on that very subject.

      Maurice

      • Mark
        Posted at 09:06 March 30, 2017
        Mark
        Reply
        Author

        Awesome, I look forward to it.

  • Kristians
    Posted at 09:52 March 31, 2017
    Kristians
    Reply
    Author

    Hi,
    Did you think about second part of driver certification? How to automate driver download and importing that can’t be included in drivers packs, because they have only setup.exe without any INF file?

    I have some draft “PS scirpt” for automating hardware application detection, downloading, preparation and importing for HP computers. If you are interested in it, please contact with me.

    Thank you.

    • Maurice Daly
      Posted at 09:41 April 4, 2017
      Maurice Daly
      Reply
      Author

      Hi Kristians,

      If the script can do anything to help HP deployments, then by all means send over a copy to review. If any of the code is included in the tool I will provide an acknowledgement to you.

      Maurice
      Maurice@scconfigmgr.com

  • Bjørnar Dahl
    Posted at 13:05 March 31, 2017
    Bjørnar Dahl
    Reply
    Author

    Hi,

    Great post! just one question; the Download Package Content step, what package is that? Where is that created? or is it just a random package?

    -Bjørnar

    • Nickolaj Andersen
      Posted at 13:30 March 31, 2017
      Nickolaj Andersen
      Reply
      Author

      Hi,

      I can see that the part about the dummy package may not have been clearly stated, so it’s been updated now. Simply use any package of your choice, it doesn’t matter what, since it won’t be downloaded.

      Regards,
      Nickolaj

  • Mar
    Posted at 16:10 April 4, 2017
    Mar
    Reply
    Author

    Hi guys, great article. This is the way forward! One quick Q from me. I download the drivers and I seem the models in my repository share, but no packages appear in SCCM. (under Software Library > OS > Driver Packages). Have I missed a step?

    Ta

    • Maurice Daly
      Posted at 17:13 April 4, 2017
      Maurice Daly
      Reply
      Author

      Hi Mark,

      If you followed the steps on the post, then you should see the packages listed in the Software Library > Applications Management > Packages folder. Remember that using this method we are not importing the drivers into the SCCM database, simply creating a package that will be used during the TS.

      Maurice

      • Keith Morris
        Posted at 14:25 April 21, 2017
        Keith Morris
        Reply
        Author

        Why are you using the standard package instead of a driver package? It seems to me it would make more sense to use the driver package.

        • Maurice Daly
          Posted at 15:13 April 21, 2017
          Maurice Daly
          Reply
          Author

          Hi Keith,

          The main reasons we are recommending standard packages over driver packages are as follows;

          1. Improved driver package creation time, no need to wait for every driver to import
          2. Reduces the load on the SQL database as driver entries are not maintained
          3. Avoids issues with driver imports, incorrect versions etc
          4. Provides greater control over the specific drivers applied to each model as each drivers are contained within physically separate packages

          There is nothing wrong as such with using Driver Packages, but for the reasons mentioned we recommend using Standard Packages. If you are concerned about space issues on your DP’s, you can enable data-deduplication to claw back any space used by the duplicate entries.

          Maurice

  • Bjørnar
    Posted at 09:48 April 5, 2017
    Bjørnar
    Reply
    Author

    My TS failes at Dynamic Driver Package Detection step. Error in SMSTSLog: “Failed to run the action : Dynamic Driver Package Detection: Incorrect function. (Error: 00000001;Source:Windows).
    Any idea?

    • Maurice Daly
      Posted at 22:20 April 6, 2017
      Maurice Daly
      Reply
      Author

      Hi Bjørnar,

      What happens when you try running the script via a PS window in WinPE?. Also have you PowerShell enabled in the boot image and the Win 10 ADK?.

      Maurice

      • Bjørnar
        Posted at 08:05 April 7, 2017
        Bjørnar
        Reply
        Author

        Hi Maurice,

        I figured it out. It turned out to be that the account in AppPool did’t have the enough rights in SCCM. Now it’s working like a glowe! Your DynamicDriver log file helped me solve the problem.

        • ben
          Posted at 12:40 April 7, 2017
          ben
          Reply
          Author

          Hi Bjornar,

          i have exactly the same issue, PS is running in PE but is returning nothing.
          Can you let me know which rights you granted to the user?
          I’m not running it against MDT, it’s running only via SCCM.

          • Maurice Daly
            Posted at 14:30 April 7, 2017
            Maurice Daly
            Author

            Hi Ben,

            The minimum rights required is to be a member Read-Only analyst security role in SCCM. What happens if you query the web service from a normal PowerShell session using the following;

            # User Variables
            $SiteServer = “YOURSERVERNAMEHERE”
            $SecretKey = “YOURSECRETKEYHERE”

            # Connect to web service
            $URI = $SiteServer + “/ConfigMgrWebService/ConfigMgr.asmx”
            $Web = New-WebServiceProxy -Uri $URI

            # Test-Get-CMPackage
            $Web.GetCMPackage(“$SecretKey”,””)

            Maurice

          • Bjørnar
            Posted at 14:33 April 7, 2017
            Bjørnar
            Author

            It’s a lab enviroment, so i used my account, which is administrator in SCCM and on my SQL database.

          • ben
            Posted at 08:47 April 10, 2017
            ben
            Author

            Hi Maurice,

            i adjusted your script to:

            $URI = “http://” + $SiteServer + “/ConfigMgrWebService/ConfigMgr.asmx”

            then it works fine, providing an output of all packages.

            In my Task Sequence i’m using this as parameter (it’s uri not url or?)

            -URI “http://HOSTNAME.FQDN/ConfigMgrWebService/ConfigMgr.asmx” -SecretKey “5987d9fa-5fd9-48f5-8827-5d5c1c8814e1” -Filter “Drivers”

            If i start the script directly with the above parameters i get:

            WARNING: Unable to construct Microsoft.SMS.TSEnvironment object

          • Maurice Daly
            Posted at 15:51 April 10, 2017
            Maurice Daly
            Author

            Hi Ben,

            I did intend for you to put in http://YOURSERVERNAME, but glad you figured that out. The script parameter is URI not URL and running this inside of a normal PS environment will result in the warning message as it looks for a PE/TS environment. Can you reply with the model returned from the following PS command – Get-WMIObject -Class Win32_ComputerSystem so we can look at the naming used for the driver package?.

            Maurice

          • ben
            Posted at 16:00 April 10, 2017
            ben
            Author

            Hi Maurice,

            yes sure. Model Output is “HP ProBook 640 G1”
            But, i noticed that i was not using the up2date Driver Download Tool (was running 2.8)
            I’ve now adjusted the driver package names and now it’s working fine.

            But anyway, i need to test all other HP Models aswell… pain as i have a lot of different “G’s”

  • Danny
    Posted at 14:29 April 5, 2017
    Danny
    Reply
    Author

    Hi,

    I’m currently stuck getting trying to get this to work successfully. I’ve followed steps 1 – 3 in this article to download the driver packages (selecting “SCCM – Standard Pkg”) distributed my package, have installed the web service and tested that it works correctly, but in my OSD task sequence nothing happens when I try to download and apply the drivers. Here is what I’ve receiving in the “DriverPackageDownload.log”:

    – Driver download package process initiated
    – Manufacturer determined as: HP
    – Computer model determined as: HP ZBook 15 G3
    – Retrieved a total of 4 driver packages from web service
    – Empty driver package list detected, bailing out

    • ben
      Posted at 12:14 April 10, 2017
      ben
      Reply
      Author

      Hi Danny,

      because HP Naming Convention is a pain..
      Check for the correct driver package name.
      If you download the driver package for the Zbook 15 G3 the name is “HP Zbook 15/17 G3….” because it applies to both models.
      But the script is looking for a driver package with Zbook 15 g3 in the name maybe thats the issue you have. I have a similar issue with Probooks 640 G1 and EliteBook 1040…

      BR
      ben

      • Maurice Daly
        Posted at 13:25 April 10, 2017
        Maurice Daly
        Reply
        Author

        Hi Danny / Ben,

        Indeed HP model naming is causing some issues with the WMI model query, especially since the download script was updated to copy for the many models which share SoftPaq’s. We are looking at working on an update to add in logic to determine matches based on regular expressions to cater for this.

        Maurice

        • ben
          Posted at 14:25 April 10, 2017
          ben
          Reply
          Author

          Hi Maurice,

          thanks for getting back.
          I corrected the Driver Package Name for the 640 G1 and now it technically works (with W7 driver pack, because there is no W10 pack for the 640G1…)

          But as you already have written before, there are multiple models sometime that apply the same driver pack.
          A solution for this would be very appreciated

  • Steve O’Connor
    Posted at 12:29 April 6, 2017
    Steve O’Connor
    Reply
    Author

    Great post – however, I’m struggling to make it work. The TS keeps failing on the Dynamic Driver Detection step. Looking a the SMSTS.log its throwing an incorrect function error?

    • Maurice Daly
      Posted at 22:27 April 6, 2017
      Maurice Daly
      Reply
      Author

      Hi Steve,

      Have you tried opening an a command prompt in WinPE and launching PowerShell to test the script is working with the web service?. Also have you PowerShell enabled in the boot image and the Win 10 ADK?.

      Maurice

      • Steve O’Connor
        Posted at 09:14 April 7, 2017
        Steve O’Connor
        Reply
        Author

        Hi Maurice, PowerShell is enabled in the boot image. Not sure what you mean by in the ADK?

        Tested the script in PE with powershell and it seems to run the drop back to the prompt, as in there does not seem to be any output.

        Thanks,
        Steve

    • Bjørnar
      Posted at 08:08 April 7, 2017
      Bjørnar
      Reply
      Author

      Hi Steve,

      I had the same error as you, it turned out to be the account in AppPool missing rights in SCCM or MDT (depending if you use MDT database).

  • Nick
    Posted at 20:17 April 6, 2017
    Nick
    Reply
    Author

    Would LOVE to see Microsoft Surface drivers/firmware added to the tool

  • Danny
    Posted at 15:43 April 10, 2017
    Danny
    Reply
    Author

    Hi,

    Could you please let me know how you think I could troubleshoot and determine why I’m receiving “– Empty driver package list detected, bailing out” in the DriverPackageDownload.log?

    I am using the Driver Automation Tool to download a “SCCM – Standard Package”, the package is created in SCCM and distributed to my DP correctly, and is approximately 1.9 GB in size.

    When I run the following steps manually in a PowerShell session during OSD, it returns several packages (so the rights for SCCM and the Web Service appear to be fine), and I have also tried switching out the “Dummy” package, but I continue to experience the issue of “Empy driver package list detected”.

    –Here are the steps I’m following to verify that I can access packages using the WebService during OSD:

    # User Variables
    $SiteServer = “YOURSERVERNAMEHERE”
    $SecretKey = “YOURSECRETKEYHERE”

    # Connect to web service
    $URI = $SiteServer + “/ConfigMgrWebService/ConfigMgr.asmx”
    $Web = New-WebServiceProxy -Uri $URI

    # Test-Get-CMPackage
    $Web.GetCMPackage(“$SecretKey”,””)

    –When I run this, I receive several packages, including the one I created with the Driver Automation Tool:

    PackageName : Drivers – HP ZBook 15 G3 Mobile Workstation – Windows 10 x64
    PackageID : CM002D4
    PackageManufacturer : Hewlett-Packard
    PackageVersion : 4.00 A 1
    PackageCreated : 4/10/2017 9:08:35 AM

    Any help or suggestions you could provide would be most helpful.

    Thanks.

  • Ryan
    Posted at 01:15 April 11, 2017
    Ryan
    Reply
    Author

    Great tool/script. Is it possible to add a variable that gets set on failure which can be used to call a auto add drivers step? We have a large number of obscure and consumer grade computers in our environment along with your standard Optiplexes and Latitudes so this would really help.

  • Danny
    Posted at 13:53 April 14, 2017
    Danny
    Reply
    Author

    Maurice / Ben,

    Sorry, I did not see your reply to my original question before I posted my 2nd post.

    Just to provide an update, I noticed that the Driver Download Tool was created the SCCM package with the vendor listed as “Hewlett-Packard”, but when the “Invoke-CMDownloadDriverPackage.ps1” is running in the task sequence, it appears to only be looking for packages with a Vendor name of HP.

    On my package in SCCM that was created by the Driver Download Tool, I changed the vendor to “HP”, and then everything started working correctly in the task sequence. The machine was still missing some drivers after the build was complete, but at least the automation part is working correctly now.

    If not too much trouble, For HP machines it might be worth updating the script to accept Packages with a vendor listed as “Hewlett-Packard” or “HP” (since HP is not always very consistent when it comes to the vendor WMI class), and that might allow it to have better results when running in the task sequence.

    Either way, thanks again!

  • Trevor
    Posted at 17:52 April 15, 2017
    Trevor
    Reply
    Author

    This is a sweet solution, thanks for posting!

    I found that with a UDI deployment, you cannot use the %OSDisk% variable as it gets cleared by the UDI wizard (read more here https://www.fosund.com/udi-wizard-clears-the-osdisk-variable/).

    You can use %OSDTargetSystemDrive% instead, so the DISM command becomes: “DISM.exe /Image:%OSDTargetSystemDrive%\ /Add-Driver …”

    You could also just use “%_SMSTSMDataPath%\Drivers\” instead of “C:\Windows\Temp\” for the driver package, so the package will get cleaned out along with the other OSD packages before the deployment ends (unless you want to keep them on disk of course…)

  • Trevor
    Posted at 11:54 April 18, 2017
    Trevor
    Reply
    Author

    Found a small bug in the line 161 of the PowerShell script (for when multiple packages are found) – you are just missing a “1” on the end, so:

    $Package = $PackageList | Sort-Object -Property PackageCreated -Descending | Select-Object -First

    Should be:

    $Package = $PackageList | Sort-Object -Property PackageCreated -Descending | Select-Object -First 1

    Otherwise you get this error:

    An error occured while setting OSDDownloadDownloadPackages variable. Error message: Missing an argument for parameter ‘First’. Specify a parameter of type ‘System.Int32’ and try again.

    Also, the package filter will not work for the “Dell Latitude E6430” model if you also have drivers for the “Dell Latitude E6430s” (s) model. I had to add a space in the computer model variable so that the filter could correctly distinguish between the two similar model names:

    If ($ComputerModel -eq “Latitude E6430″)
    {
    $ComputerModel = $ComputerModel + ” ”
    }

  • Mark
    Posted at 19:59 April 19, 2017
    Mark
    Reply
    Author

    Thanks Maurica & Nickolaj

    We have a Robert Marshall with us at the moment working through this in our model office. Great tool.

    A slight enhancement request if possible. I have found that with two packages created for the same device one per OS so 7 and 10 in our environment. That as you would expect we get two returned values. Only problem I have is that this then lead us into the comments that Trevor left above, with the error on setting the variable OSDownloadDownloadPackage. Any chance you could find some way to detect the OS version being installed, and cross reference that so only a single package assignment is returned?

    Thanks

    • Maurice Daly
      Posted at 22:49 April 19, 2017
      Maurice Daly
      Reply
      Author

      Hi Mark,

      Thanks for the feedback, you’re also in good hands with Robert looking after your SCCM environment for you. In regards to the packages, Nickolaj and I spoke about this briefly earlier on and we are sure we can do something here to resolve this for you.

      We will follow up on email so you can test an updated script.

      Maurice

  • Damon Palm
    Posted at 17:45 April 20, 2017
    Damon Palm
    Reply
    Author

    It looks like the model names in the Microsoft DownloadLinks.xml do not match the model names in WMI. For example, the xml contains ‘SurfacePro4’, but the model name in WMI is ‘Surface Pro 4’ (with spaces). This causes Surface driver packages to not be applied during the task sequence.

  • Palm
    Posted at 03:57 April 26, 2017
    Palm
    Reply
    Author

    how does it work if we have a remote branch office to image the PC? can we setup the webservice on multiple site servers or remote DPs ?

    • Maurice Daly
      Posted at 09:56 April 26, 2017
      Maurice Daly
      Reply
      Author

      Hi,

      In a branch office environment clients can talk to a centralised web service and retrieve the driver package ID, the local DP will then be used to obtain the package from (obviously if the package is available). That said if you wish you could also house the web service on multiple site servers, however you would need to cater for this in your task sequences or via a load balancing mechanism.

      Maurice

  • Anders Rodland
    Posted at 10:48 May 4, 2017
    Anders Rodland
    Reply
    Author

    I love this solution, but is it possible for this to differentiate on OS version? Some of our customers that we manage have MDT integrated task sequence that deploy both Windows 7 and Windows 10.

    An optional parameter named -OS to the “Invoke-CMDownloadDriverPackage.ps1” would solve this, then the script would know exactly which operating system to download drivers.

    • Nickolaj Andersen
      Posted at 10:49 May 4, 2017
      Nickolaj Andersen
      Reply
      Author

      Hi Anders, stay tuned. We’re finishing up with some tests regarding exactly that. Hopefully we can have it published this week.

    • Nickolaj Andersen
      Posted at 12:07 May 5, 2017
      Nickolaj Andersen
      Reply
      Author

      Hi Anders,

      Check out the latest version of the Invoke-CMDownloadDriverPackage.ps1 on GitHub. It now supports multiple operating systems for the driver packages (and legacy packages). It does however require ConfigMgr WebService 1.2.1 that can be found in this post. However, if you’re deploying multiple OS from the same task sequence, it won’t work. I usually consider this a bad practice as well, for a number of reasons. But everything can be overcome with PowerShell and some logic.

      Regards,
      Nickolaj

  • Robert
    Posted at 22:34 May 16, 2017
    Robert
    Reply
    Author

    Hi,
    really great tool, but the WMI Name of the Driver for the Model “HP EliteOne 800 G2 23-in Non-Touch AiO” is to long for the Driver Name. Is there a way to shorten this?
    Regards,
    Robert

    • Maurice Daly
      Posted at 22:44 May 16, 2017
      Maurice Daly
      Reply
      Author

      Hi Robert,

      The model names come from HP’s XML model listings and indeed there are some very long model names. The issue with shortening these is we need to cater for model detection when using our modern driver management process so we need as much info as possible to match against WMI.

      Maurice

    • Maurice Daly
      Posted at 22:44 May 16, 2017
      Maurice Daly
      Reply
      Author

      Hi Robert,

      The model names come from HP’s XML model listings and indeed there are some very long model names. The issue with shortening these is we need to cater for model detection when using our modern driver management process so we need as much info as possible to match against WMI.

      Maurice

      • Robert
        Posted at 13:33 May 22, 2017
        Robert
        Reply
        Author

        Hi, the PackageName can be longer, if I edit it afterwards. Only in the ConfigMgr Package-Creation-Wizzard the field for the Name is limited. I don’t know if the Driver Automation Tool can create the long Names, because it doesn’t find any HP Packages so I download the Packages with the HP SDM.
        Robert

  • Morten
    Posted at 14:41 May 22, 2017
    Morten
    Reply
    Author

    Awesome work both of you

    But a minor “bug”
    When using the driver download tool for Lenovo it gets imported to sccm as “Drivers – Lenovo T460s – Windows 10 x64”
    Problem is when you use the “Invoke-CMDownloadDriverPackage.ps1” the detection spits out “Thinkpad T460s”
    So it returns no package found.
    I tested by renaming the package to “Drivers – Thinkpkad T460s – Windows 10 x64” and it worked.

  • Leave a Reply to Jakob S.
    Cancel Reply