Book a Demo
View Categories

Drivers Overview

4 min read

Drivers Overview

Modern Windows deployment relies on the ability to supply the correct drivers at deployment time. As new hardware models are introduced and existing platforms receive Driver updates, a deployment system must be able to accommodate these changes without requiring constant rework of builds.

Maintaining an up-to-date Driver library ensures that deployed devices leave with the most appropriate drivers already installed. This reduces post-deployment remediation, improves hardware compatibility, and avoids reliance on Windows Update or manual Driver installation after deployment.

A central Driver library also allows deployments to remain future-proof. New hardware models or updated components can be supported by adding drivers once, rather than modifying or recreating existing builds. This approach differs from traditional image-based deployment systems, where Driver changes often require rebuilding or maintaining multiple images.

Why a Central Driver Library Matters

A deployment tool should allow drivers to be added, updated, or removed quickly and independently of builds.

By maintaining a shared Driver library:

  • Builds remain generic and reusable
  • New hardware support can be added in seconds
  • Existing builds automatically benefit from newly added drivers
  • There is no need to re-edit or duplicate builds for new device models

For managed service providers, this also allows hardware support to be added once and applied immediately across multiple customers or tenants.

INF-Based Drivers

INF-based drivers are the traditional Windows Driver format. These are the same drivers you would install using the “Have Disk” option in Device Manager.

An INF-based Driver consists of:

  • One or more .inf files
  • Associated .sys, .cat, and supporting files

Common Sources of INF-Based Drivers

INF-based drivers are typically obtained by:

  • Downloading Driver packages from an OEM or hardware Vendor website
  • Extracting the contents of an OEM Driver package (often provided as a ZIP or EXE)
  • Using OEM-provided deployment packs intended for tools such as OneDeploy, MDT or SCCM

Examples of INF-Based Driver Usage

INF-based drivers may represent:

  • A single hardware component

    • Example: Intel® 7th–10th Gen Processor Graphics

  • A complete set of drivers for a specific hardware model

    • Example: OEM deployment Driver packs containing all device drivers in a single folder

When added to the Driver library, these drivers are available for matching against compatible hardware during deployment.

EXE and MSI-Based Drivers (DriverApps)

Some drivers and hardware-related utilities are distributed only as EXE or MSI installers. These cannot be integrated directly as INF-based drivers.

In OneDeploy, these are handled as DriverApps.

A DriverApp is a Software Package that:

  • Installs a Driver or hardware-related utility
  • Is only installed when defined hardware criteria are met

Typical Use Cases for DriverApps

DriverApps are commonly used for:

  • OEM management or monitoring tools
  • Hardware-specific utilities that accompany a device
  • Drivers delivered exclusively as EXE or MSI installers

Example: Hardware-Specific Server Tools

A single Windows Server build may be used across multiple server models, while installing the appropriate OEM tooling based on detected hardware.

For example:

  • Dell PowerEdge servers install Dell OpenManage Server Administrator (Managed Node)

  • HPE ProLiant servers install HPE ProLiant Support Pack

This approach allows one build to support multiple server platforms without hard-coding Vendor-specific logic into the build itself.

Example DriverApps

Common examples of DriverApps include:

  • Dell OpenManage Server Administrator
  • HPE ProLiant Support Pack
  • Microsoft Surface Driver packages delivered as MSI
  • Lenovo battery or power management utilities
  • OEM firmware or hardware management utilities
  • Hardware monitoring agents supplied by server vendors
  • Touchpad or input device utilities provided as EXE installers

DriverApps are documented in a separate article.

One Build, Many Devices

Correct use of the Driver library enables a “One Build, Many Devices” deployment model.

This means:

  • Builds remain hardware-agnostic
  • Drivers are selected dynamically based on detected hardware
  • Hardware-specific requirements are handled through DriverApps instead of build logic

As a result, the same build can be deployed across different device models, manufacturers, and form factors without modification.

Where Drivers and DriverApps Are Managed

In OneDeploy:

  • INF-based drivers are added to:
    Library → Drivers

  • DriverApps are created as Software Packages in:
    Library → Software Packages
    and use filters to define the hardware they apply to

Once added, drivers are immediately available to all builds. Any future deployment will automatically use the most appropriate Driver present in the library for the target hardware.

How OneDeploy uses drivers from your library

At deployment time, OneDeploy performs an automated Driver matching process:

  1. The target device hardware is scanned
  2. The Driver library is scanned
  3. Matching drivers are identified
  4. If multiple drivers match a hardware device, the best match is selected
  5. The matched drivers are integrated into the operating system
  6. DriverApps are installed later [if selected] during the Finalise stage of Windows setup

This process ensures that each device receives the correct drivers without manual selection or build changes.

Updated on February 10, 2026

What are your Feelings