In this the latest update for the Driver Automation Tool, we have listened to feedback from the community with requests for supporting the WIM format to allow for native compressed driver packages, along with implementing a host of improvements which should help speed up the tool.
Package Compression (WIM now available)
Having recently added ZIP and 7-ZIP support with impressive results in OSD (7-ZIP typically reducing file sizes by up to 70% and improving driver installation step time by up to 50%). Mike Marable was good enough to run some tests using 7-ZIP compression against a sample HP EliteBook Folio 1040 G3 and Microsoft Surface Book, which gave some interesting results:
|HP EliteBook Folio 1040 G3||1409923 KB||4m 20sec|
|Microsoft Surface Book||2425149 KB||5m 50sec|
|HP EliteBook Folio 1040 G3||632121 KB||2m 10sec|
|Microsoft Surface Book||1021103 KB||2m 59sec|
Mike Tyrrell, Gary Blok, Martin Bengtsson and others in the community have started a trend to move to the native Windows Imaging Format (WIM). The benefit of WIM is the fact the file type is completely native, and it plays well with data deduplication when being transferred to your distribution points. Therefore it made sense that we would also let you pick your own compression format of choice, and WIM has been added.
For your benefit, below are the expected compression values for a sample HP DragonFly model with a source with 1.97GB’s of data:
Known Model Queries
While working with a client recently with over 120k devices, I quickly was made aware of an issue within the DAT. If you are querying WMI remotely and returning the model details, it can get very large and cause a substantial delay when running the tool with the model matching enabled. In fact in that example, the DAT on average took 45 minutes to launch, which was clearly unacceptable.
Due to this, the WMI call was re-written (thanks to Ken Sweet for working with me on this) for all manufacturers, resulting in a more streamlined call. For HP in particular, the logic was changed so that the model names were no longer used and we are using the same logic as our deployment scripts, based on the baseboard product value. For Dell, the latest XML feeds also contained some anomalies, where model names were duplicated, so this has been catered for.
In order to provide clarity on matching for Dell and HP, a new identifier column has been added so you can see the values being matched against. The UI also contains icons now so you can see green checkboxes next to those models the tool finds in WMI.
Please Note: The Win32_BaseBoard hardware inventory class is required for the updated matching process. This can be added through the client settings in ConfigMgr:
Distribution Point Queries
Similar to the issue with known devices, the native PowerShell cmdlet Get-CMDistributionPoint can suffer from lengthy delays when querying environments with a lot of DP’s. Due to this, the query has been re-written to use a WMI query instead, and as you can see from the below example this saves a lot of time:
In the above example the old query took 59.5 seconds longer using the native PowerShell cmdlets than querying the distribution points from WMI directly.
Hewlett-Packard to HP
One of the issues around the naming conventions used by some manufacturers, such as HP, is with the extraction paths, you can reach an issue when you exceed the maximum character UNC path limit (https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation).
To be clear on this, my recommendation for the packages, is that they are dropped into the root of a share, i.e;
If you wish to create packages within a long folder structure on your server, that is absolutely fine, but create a share deep within to avoid the path getting too long.
So back to HP, in order to reduce the package name, and due to the fact they should be called “HP”, all pre-existing packages will be renamed automatically to “HP” from “Hewlett-Packard”, and for all new packages they will also use the shortened value for the manufacturer folder.
Something which I havent really explained to date is an option to create an “XML Logic Package”. This package contains XML files which can be consumed in methods which do not rely on the web service or the admin service, think about Intune for example. Below is sample of the contents of the Driver XML created:
Creating the XML Logic Package was intended as a method to get around some of the issues with CMG, however, the Microsoft product team back in Redmond have thankfully answered all our prayers in that respect. This feature however will become clear in an upcoming blog post on managing the devices through Intune.
As usual you can download the updated DAT from the following location – https://github.com/maurice-daly/DriverAutomationTool. Note if you are just replacing the EXE, you will need to copy in the provided Images folder for the icons to render in the tool.
One other thing is you will also need to update your deployment scripts. WIM support is ONLY available now for those using the new script which supports the Admin Service as this is the method we will be running with going forward. Scripts are available here – https://github.com/MSEndpointMgr/ModernDriverManagement
We’re currently running DAT 6.4.6, which uses the ConfigMgr WebService still.
Is there a post or instructions I haven’t come across which covers off what is required to updating DAT & using the Admin Service instead?
This is our “official” documentation, that covers how to set the solution up with the AdminService.