# Driver Automation Tool does the boring half of OEM driver packaging for ConfigMgr and Intune

> DriverAutomationTool is a portable PowerShell WPF application that discovers, downloads, extracts and packages HP, Dell, Lenovo, Surface and Acer driver and BIOS updates into WIM files for Configuration Manager or Intune. It automates a workflow that is otherwise a great deal of clicking.

**maurice-daly/DriverAutomationTool** — Home of the Driver Automation Tool

- Repository: https://github.com/maurice-daly/DriverAutomationTool
- Website: https://www.driverautomationtool.com
- Stars: 592 · Forks: 140
- Language: PowerShell
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/maurice-daly-driverautomationtool

## Packaging OEM drivers is the boring half of endpoint management

DriverAutomationTool is described as enterprise-grade automation for downloading, extracting and packaging OEM driver and BIOS update packages for ConfigMgr and Intune, and it is a free community tool created by Maurice Daly. The homepage is driverautomationtool.com.

The problem it takes on is specific. If you manage a mixed Windows fleet through Configuration Manager or Intune, you need driver packages for the hardware, and the vendor does not hand you a ConfigMgr package. You go to a support page, find a driver bundle, download it, extract it, work out which files belong in the WIM, build the WIM, create the package, distribute the content, and create the detection and remediation logic. For a handful of models that is a day of work. For a catalogue spanning several vendors it is a week, repeated every time a new BIOS revision lands.

This tool does that chain. The Overview section describes it as a PowerShell WPF desktop application that automates the full lifecycle of OEM driver and BIOS package management, from catalog discovery and download through extraction, WIM packaging, and deployment to Configuration Manager or Microsoft Intune.

Two things are worth noting about the framing. It is a desktop application with a graphical interface, not a script or a service, so it runs in the hands of the person who does the packaging. And the deployment target is Intune or ConfigMgr specifically, not a generic software distribution tool.

## Five vendors, and BIOS only where it exists

The supported OEM table is short and specific, and the shape of it matters more than the count.

| OEM | Drivers | BIOS Updates |
|-----|---------|--------------|
| HP | yes | yes |
| Dell | yes | yes |
| Lenovo | yes | yes |
| Microsoft Surface | yes | no |
| Acer | yes | yes |

So HP, Dell, Lenovo and Acer are supported for both drivers and BIOS updates, and Microsoft Surface is supported for drivers only. That is the exception, and it is a reasonable one, since Surface is a first party Microsoft device and its firmware updates follow a different path from the OEM catalogue.

The catalogue discovery is automatic, which is the part that makes multi-vendor support practical. The Core Features section lists multi-OEM support with automatic catalog discovery as a headline item, so the tool queries each vendor's catalogue for the models you care about rather than requiring you to browse support pages by hand.

Note the scope limit. This is a driver and BIOS tool, not a software packaging tool. If you need to wrap and deploy a third party application package for Intune, that is a different problem, and the WIM part of this tool is aimed at driver payloads rather than general application deployment.

## Downloads with resume, retries and hash verification

The download mechanics are described in more detail than most tools bother with, and for a tool whose output ends up on thousands of machines, that is the right place to spend detail.

The README says downloads are accelerated via curl.exe, with HTTP resume support, configurable retry logic of 10 retries and a 60 second delay, and automatic hash verification. Resume matters because vendor download servers are frequently slow or flaky, and a driver bundle is often several gigabytes. Retry with a delay covers the case where the server rejects a burst of requests. Hash verification covers the case where you get a corrupt file and do not notice until deployment.

BIOS update management is described with similar care: version comparison, release classification as Recommended or Critical, minimum version validation, and hash verification. Minimum version validation is the piece that catches the common failure, where a BIOS update is offered as applicable to a model but the fleet already runs a newer revision, and pushing it anyway is a support incident.

The combination of version comparison, release classification and hash checking is what makes the BIOS half more than a downloader. A driver catalogue is a firehose of files, and the tool has to decide which of them belong in a package for a given model.

## WIM packaging with three different tools, and why that matters

Once the files are downloaded and extracted, they have to be turned into something deployable. The tool supports three ways of creating the WIM package: DISM, which the README calls built-in, wimlib for multi-threaded work, and 7-Zip, which it recommends, with configurable compression.

Having a choice of packer is not vanity. WIM creation is the slowest step in the chain for a large driver payload, and the three tools have very different characteristics. DISM is present on every Windows machine so it always works, wimlib is fast because it is built for it, and 7-Zip is the recommendation, presumably for the compression ratio that matters when the package is replicated to distribution points.

The repository layout is telling about the priorities. There is a Content/ directory holding the screenshots used in the README, a Data/ directory, a HotFix/ directory, a directory named after the application itself with a space in the name, and a LICENSE and SECURITY.md file. The HotFix/ directory suggests the tool is patched when the vendors change their catalogue formats, which is exactly the maintenance pattern you would expect for a scraper-driven tool.

The Security section of the README covers a real deployment detail. For environments requiring BIOS passwords for firmware updates, the tool encrypts passwords using DPAPI with machine-scope protection and embeds them in the detection and remediation scripts for Intune deployment. DPAPI with machine scope means the encrypted value can only be decrypted on the machine that produced it, which is the right choice for a packaging workstation but means the packaging and deployment steps are tied to that workstation.

## Four deployment targets, and the WIM-only middle ground

The deployment platforms table sets out the four modes the tool can run in, and the difference is where the pipeline stops.

Configuration Manager goes all the way: download, extract, create WIM, create the ConfigMgr package, and distribute to the distribution points. Intune goes all the way too: download, extract, create WIM, wrap it as an .intunewin, then upload and create the Win32 app.

Then there are two partial modes. WIM Package Only does download, extract and create the WIM file with no deployment. Download Only does download and extract with no WIM packaging and no deployment.

Those partial modes are not filler, they are the answer to a specific objection. A team that wants to review the payload before anything ships, or that has its own package creation process, wants the extraction and the WIM without the tool also reaching into ConfigMgr or Intune. Download Only is for teams that just want the driver files staged locally, for example to hand to a separate imaging process.

For Configuration Manager the connection is over WinRM or WMI to the site server, and the settings table lists the site server FQDN, an option to enable SSL or TLS for WinRM, known model lookup that queries hardware inventory to highlight models in your environment, replication priority set as High, Normal or Low, and binary differential replication to transmit only changed binary blocks. That last one is a bandwidth decision, and it is worth knowing about before you replicate several gigabytes of drivers to every distribution point.

## Intune authentication, Graph permissions and Entra group assignment

Intune support goes through the Microsoft Graph API, and the README lists three authentication methods. Interactive with a browser is browser-based sign-in with full MFA and Conditional Access support, and it is the recommended one. Interactive with a device code is the device code flow, intended for restricted environments. App registration uses a tenant ID, an app ID and a client secret, and is the one for automated or scheduled runs.

The required Graph API application permissions are listed explicitly, and they are the permissions to request if you use the app registration method: DeviceManagementApps.ReadWrite.All, DeviceManagementManagedDevices.Read.All and GroupMember.Read.All.

Package assignment is done to Entra ID groups from the Package Management section, by right-clicking a package to reach the assignment options, and deploying either as Required, which is automatic, or as Available, which is user-initiated from Company Portal. That distinction is the usual Intune one, and having it surfaced directly in the tool rather than in the portal is a small convenience for a workflow that happens per model.

The Intune side also lists chunked Azure Blob uploads and parallel threading, plus Win32 app packaging. Chunked uploads matter because driver payloads exceed what a single Intune upload will take, and the tooling that handles that is the difference between a workflow that runs and one that fails at the last step.

## Install, unblock, launch as administrator, accept the EULA

The tool is a portable PowerShell application with no installer required. You download the latest release from the repository, extract the ZIP to a permanent location, and the README suggests a path like this.

```
C:\DriverAutomationTool
```

There is a step that trips people up and the README calls it out separately. You have to make sure the extracted folder is not blocked by Windows, which means right-clicking the ZIP before extracting, going to Properties, and checking Unblock if it is present. A downloaded archive carries a mark that makes PowerShell refuse to run its scripts, and skipping this produces an error that looks like a broken download rather than a security feature.

Then you open PowerShell as Administrator and launch it.

```powershell
cd C:\DriverAutomationTool
.\Start-DriverAutomationTool.ps1

# Or launch with dark theme
.\Start-DriverAutomationTool.ps1 -Theme Dark
```

If you hit an execution policy error, the README gives the standard per-process bypass.

```powershell
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
```

On first launch you review and accept the End User License Agreement, and then you set your storage paths, select your deployment platform, and configure proxy settings if needed, with the detail in the Setup Guide on the project site.

The administrator requirement and the per-process execution policy bypass together tell you what kind of tool this is. It runs with full local privileges, it downloads and unpacks vendor archives, and it holds credentials for your ConfigMgr site server or your Intune tenant.

## The API cut-off, and what the licence actually says

The Important notice at the top of the README is the first thing to read, and it is dated. On August 17th 2026, the note says that due to a number of functional changes it is recommended that anyone running DAT builds 10.1.9.0 and lower upgrade immediately, because the API will no longer serve requests for older versions.

That is a hard cut-off, not a deprecation warning. A build that is too old stops receiving catalogue data, and the failure will look like the tool cannot find drivers rather than like an out-of-date client. Anyone who installed a build months ago and has not launched it since needs to check this before they trust the output.

The repository is not archived and the last push was on 2026-10-15, so the project is active, and there are no GitHub releases listed beyond what the project publishes, with the release artefacts distributed through the repository and the project site.

On the licence, the repository records a custom licence that GitHub cannot classify, with the terms in the LICENSE file. That matters for a tool that creates packages deployed to managed devices in an enterprise. The README also has a SECURITY.md file, which tells you there is a place to report a problem, and the DPAPI machine-scoped BIOS password handling described earlier is a security relevant behaviour worth reading the licence and any deployment guidance around before you use it.

For an evaluator, the practical check is which build you are on, and whether the version is one the API still serves.

## Conclusion

Adopt DriverAutomationTool if you run Configuration Manager or Intune and you currently build driver packages by hand from vendor download pages, especially across several OEM catalogues at once. Do not adopt it if your fleet is Apple hardware, if you need vendor software rather than drivers, or if a PowerShell GUI on a Windows workstation is not acceptable in your environment. Before you deploy it, read the Important notice about builds 10.1.9.0 and lower being cut off from the API, confirm the release you are running is current, and test the WIM output on one model before you point the tool at a production deployment.

## FAQ

### What is the Driver Automation Tool?

It is a PowerShell WPF desktop application that automates OEM driver and BIOS package management, from catalogue discovery and download through extraction, WIM packaging and deployment to Configuration Manager or Microsoft Intune. It is a free community tool created by Maurice Daly.

### Which OEMs does the Driver Automation Tool support?

HP, Dell, Lenovo, Microsoft Surface and Acer. Drivers are supported for all five, and BIOS updates for all of them except Microsoft Surface, according to the supported OEM table in the README.

### How do I run the Driver Automation Tool on Windows?

Download the latest release from the repository, extract the ZIP to a permanent folder, unblock the ZIP in its Properties if needed, then open PowerShell as Administrator and run .\Start-DriverAutomationTool.ps1, optionally with the -Theme Dark argument. If you see an execution policy error, run Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process.

### Which tool does the Driver Automation Tool use to create WIM packages?

Three options are supported: DISM, described as built-in, wimlib for multi-threaded work, and 7-Zip, which the README recommends, with configurable compression.

### What authentication does the Driver Automation Tool use for Intune?

Three methods are supported through the Microsoft Graph API: interactive browser sign-in with full MFA and Conditional Access support, which is recommended, interactive device code for restricted environments, and app registration with a tenant ID, app ID and client secret for automated or scheduled runs.

## Sources

- [Issues](https://github.com/maurice-daly/DriverAutomationTool/issues)
- [maurice-daly/DriverAutomationTool on GitHub](https://github.com/maurice-daly/DriverAutomationTool)
- [Project website](https://www.driverautomationtool.com)
- [README](https://github.com/maurice-daly/DriverAutomationTool/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/maurice-daly-driverautomationtool