This is a report from the “Onevinn utility research kitchen”
where we have spent a few days contemplating and testing driver distribution
during OSD. Driver distribution appears to be the talk of the town and new
solutions keep popping up at a high rate. Most of these solutions target
bandwidth utilization and involves distributing compressed drivers to be
expanded on the target machines.
We decided to see if we could contribute to this by somehow
improving the concept. The basic idea is of course brilliant and brings huge
It boiled down to two questions:
If bandwidth is an issue why use the zip-format,
it is far from optimal? We have found it has a compression ratio, when dealing
with drivers, averaging at about 50 %. Can we do better?
The implementations we have come across all uses
the PowerShell cmdlet Expand-Archive to unpack the drivers on the target
machine. This cmdlet is horribly slow and only supports zip-archives. Is there
a better way?
Both questions are aspects of the same problem and after
testing several compression methods we decided to investigate 7-Zips native
“7z”-format a bit further. It gave us a compression ratio of just under 70 %
which we considered a major improvement compared to zip. The problem is of
course that it cannot be expanded with PowerShell, so instead we created a
A self-extracting archive doesn’t need any third-party
binaries, it is itself an exe, and tests showed that it did the job in only
about one third of the time required by Expand-Archive. It looked very promising
but didn’t work. Even the 64-bit version of 7-Zip produces 32-bit
self-extractors. Bummer, hardly no one is using 32-bit boot images these days!
This didn’t look good but suddenly we remembered something;
7-Zip is open source. What if we could recompile it for the correct
architecture? This was a game changer, it turned out to be a very easy. The
project, which we immediately downloaded, is very well organized and each module
can be built separately.
In this case we needed to rebuild and replace one file in
the original 7-Zip setup folder, “7z.sfx” to be precise. Once done 7-Zip
started to produce 64-bit self-extractors, victory!
But now for the fun part, at least if you want to test this?
First you need to download an archive from the link, it contains two subfolders:
The top folder contains the 64-bit self-extractor module
mentioned earlier. The other folder holds a custom Task sequence with the steps
necessary to run this test.
Next step is to install 7-Zip 19.00 (x64 edition) and replace the “7z.sfx” file with the 64-bit version you just downloaded. You might want to save a copy of the original file?
Import the “Onevinn_Driver_Steps” custom TS from the
unzipped archive, the file “Onevinn_Driver_Steps.zip” should not be unzipped,
just make sure to keep it in the same folder as the _files folder and import it
Once imported copy the steps to your own test TS so it resembles this:
There is still some configuration to do, we will get back to
that once we have created a driver package for the test.
We are using a HP EliteBook 830 G6 and Windows 10 x64 1909 for
this article. For comparison we have already zipped the entire driver folder
structure giving us a zip-archive just under 900 MB in size (compressed from
1.98 GB). Now let’s see the result if we instead use “7z” with Ultra compression
and create a self-extractor.
If 7-Zip is properly installed you should be able to mark all driver folders, right click and chose 7-Zip “Add to archive”, then use these exact settings do not forget the password:
Make sure all settings are correct and press “Ok”.
The compression will run for a while, when finished you should expect something like this:
So far it should be safe to say that the efforts have been
Next, move the self-extractor (Driver.exe) to a new folder on your content share and create a standard package without program from it:
Be sure to make a note of thePackage ID. And do not forget to distribute it to your Distribution point(s).
Now let’s get back to the TS. We need to create and set two Task
OSDDriverPackageID – The Package ID you just “noted”.
DriverExePassword – The password for the
Since we expect to run more tests with various computer models, we use a “Set Dynamic Variables” step for the first one:
For the second variable we use a “Set Task Sequence Variable” step, make sure to not display the value:
The rest of the steps requires no configuration but make sure to distribute the new package containing the “StageDrivers.ps1” script, you will find the name and ID here:
The two variables are “set”.
The script “StageDrivers.ps1” will read the variables, download and invoke the self-extractor.
All drivers will be inflated to the target drive. (normally c:\Drivers).
The self-extractor is deleted, and password variable reset.
Dism.exe is invoked and pushes the drivers on to the newly applied image.
At the end of the TS the content folder is removed, “Cleanup Driver Staging”. This could have been done by StageDrivers.ps1 but we have a few more ideas for even more optimizations, which will require the drivers to stay on disk a little bit longer. We might get back to that in a follow up post soon.
Logging is limited in this beta edition, but you should be able to find the reason for malfunction in “..\SMSTSLog\Onevinn.StageDrivers.log”.
This solution is of course driven a little bit towards the extreme, but it certainly proves optimization is possible.