DISM Offline Servicing: Inject Drivers, Updates, and Features into Windows Images

What DISM does and when offline servicing applies

DISM is the command-line tool Windows uses to service its own images. It surfaces as a Windows feature, as part of the Windows ADK, and as a built-in command available in any elevated Command Prompt or PowerShell session.

Offline servicing applies when you want to modify a WIM or ESD file without booting the operating system inside it. Scenarios where this is the right approach:

• Injecting storage or RAID controller drivers so Setup can see the target disk on new hardware.
• Pre-applying cumulative updates so deployed machines are patched from day one rather than downloading updates on first boot.
• Enabling optional features (Hyper-V, OpenSSH, .NET 3.5) that would otherwise require internet access or a separate setup step.
• Copying post-setup scripts or configuration files into the image so they are present the moment Setup hands off to Windows.
• Removing inbox features (language packs, provisioned apps) that your organization does not use, to reduce image bloat.

Choosing the right image: install.wim vs boot.wim vs install.esd

A standard Windows ISO ships with at least two WIM files, each serving a different purpose. Knowing which one to service prevents hours of rework:

Step 1 — Inspect image indexes before you mount

A WIM file can contain multiple images under separate indexes. Mounting the wrong index wastes time. Always inspect first:

REM List all indexes in install.wim
DISM /Get-WimInfo /WimFile:D:\sources\install.wim

REM Typical output on a multi-edition ISO:
REM Index : 1  Name : Windows 11 Home
REM Index : 6  Name : Windows 11 Pro
REM Index : 8  Name : Windows 11 Enterprise

REM List indexes in boot.wim (usually 2: WinPE setup and Windows Setup)
DISM /Get-WimInfo /WimFile:D:\sources\boot.wim

Note the index number of the edition you intend to deploy. On boot.wim, index 2 is usually the Setup image that runs when you boot from the media — that is the one to service if you need to add a driver that Setup itself needs to see the disk.

Step 2 — Mount the image

Create a mount directory that DISM will use as a working view of the image. The mount location must be on an NTFS volume with enough free space to hold the expanded image contents (typically 8–25 GB depending on the edition).

REM Create mount directories
mkdir C:\Mount\OS
mkdir C:\Mount\Boot

REM Mount the OS image (index 6 = Windows 11 Pro in this example)
DISM /Mount-Image ^
  /ImageFile:D:\sources\install.wim ^
  /Index:6 ^
  /MountDir:C:\Mount\OS

REM Mount the Setup/WinPE image from boot.wim (index 2)
DISM /Mount-Image ^
  /ImageFile:D:\sources\boot.wim ^
  /Index:2 ^
  /MountDir:C:\Mount\Boot

After mounting, the contents of the Windows image are visible as a standard file tree under C:\Mount\OS. You can browse it in Explorer to verify you have the right edition.

Step 3 — Inject drivers

Driver injection ensures the installed OS and the Setup environment can communicate with hardware that Windows does not recognize from its inbox driver store. This is the most common reason to service a WIM before deployment.

REM Add a single driver package (.inf) to the OS image
DISM /Image:C:\Mount\OS ^
  /Add-Driver ^
  /Driver:"C:\Drivers\StorageController\iastorav.inf"

REM Add all drivers from a folder tree recursively (convenient for
REM large driver packs — DISM will skip .inf files it cannot apply)
DISM /Image:C:\Mount\OS ^
  /Add-Driver ^
  /Driver:"C:\Drivers\Pack\" ^
  /Recurse

REM Verify the drivers were added
DISM /Image:C:\Mount\OS /Get-Drivers

Injecting drivers into boot.wim

The syntax is identical but targets your Boot mount. Add storage drivers here if Setup cannot detect the target disk during installation:

DISM /Image:C:\Mount\Boot ^
  /Add-Driver ^
  /Driver:"C:\Drivers\StorageController\" ^
  /Recurse

Step 4 — Apply Windows updates (MSU packages)

Applying a cumulative update offline saves every deployed machine from having to download and install it on first boot. This is especially valuable for air-gapped or bandwidth-constrained environments.

Download the relevant MSU (Microsoft Update Standalone Package) from the Microsoft Update Catalog at catalog.update.microsoft.com and apply it like this:

REM Apply a cumulative update MSU to the mounted OS image
DISM /Image:C:\Mount\OS ^
  /Add-Package ^
  /PackagePath:"C:\Updates\windows11.0-kb5034765-x64.msu"

REM Verify the packages currently in the image
DISM /Image:C:\Mount\OS /Get-Packages

Applying multiple updates in the correct order

When applying several updates (for example, a servicing stack update followed by a cumulative update), order matters. Always apply the Servicing Stack Update (SSU) before any Cumulative Update (CU). Applying them out of order can cause DISM errors or leave the image in an inconsistent state.

REM Correct order: SSU first, then CU
DISM /Image:C:\Mount\OS /Add-Package ^
  /PackagePath:"C:\Updates\SSU-kb5005260-x64.msu"

DISM /Image:C:\Mount\OS /Add-Package ^
  /PackagePath:"C:\Updates\CU-kb5034765-x64.msu"

Step 5 — Enable or disable Windows features

Optional Windows features can be enabled or disabled in the offline image, which removes the need for internet access or a separate post-setup configuration step on each deployed machine.

Enable features from the image's own capability store

REM Enable .NET Framework 3.5 (requires providing the source from the ISO)
DISM /Image:C:\Mount\OS ^
  /Enable-Feature ^
  /FeatureName:NetFx3 ^
  /All ^
  /Source:D:\sources\sxs

REM Enable Hyper-V (requires a Windows edition that supports it)
DISM /Image:C:\Mount\OS ^
  /Enable-Feature ^
  /FeatureName:Microsoft-Hyper-V ^
  /All

REM Enable OpenSSH Server capability
DISM /Image:C:\Mount\OS ^
  /Add-Capability ^
  /CapabilityName:OpenSSH.Server~~~~0.0.1.0

Disable or remove features to slim the image

REM List all features and their enabled/disabled state
DISM /Image:C:\Mount\OS /Get-Features /Format:Table

REM Disable a feature without removing its files (re-enable later without source)
DISM /Image:C:\Mount\OS ^
  /Disable-Feature ^
  /FeatureName:WindowsMediaPlayer

REM Remove a feature entirely — saves disk space but cannot be re-enabled
REM without source media
DISM /Image:C:\Mount\OS ^
  /Disable-Feature ^
  /FeatureName:WindowsMediaPlayer ^
  /Remove

Step 6 — Inject files and scripts into the image

Because the mounted image is a live file tree, you can copy files directly into it using standard Windows copy commands. This is the correct way to pre-place post-setup scripts referenced by your answer file:

REM Create the Setup\Scripts directory if it does not exist
mkdir "C:\Mount\OS\Windows\Setup\Scripts"

REM Copy your post-setup scripts into the image
copy "C:\Build\PostSetup.ps1"     "C:\Mount\OS\Windows\Setup\Scripts\"
copy "C:\Build\SetupComplete.cmd" "C:\Mount\OS\Windows\Setup\Scripts\"

REM Copy configuration files, certificates, or license files
copy "C:\Build\CorporateCA.cer"   "C:\Mount\OS\Windows\System32\"

Step 7 — Commit or discard your changes

When you are satisfied with the changes made to the mounted image, commit them to write the modifications back to the WIM file. If something went wrong, discard instead to roll back to the original state.

REM Commit changes and unmount (this can take several minutes for large updates)
DISM /Unmount-Image /MountDir:C:\Mount\OS /Commit
DISM /Unmount-Image /MountDir:C:\Mount\Boot /Commit

REM Discard all changes and restore the image to its pre-mount state
DISM /Unmount-Image /MountDir:C:\Mount\OS /Discard

Export the image to reduce WIM file size after servicing

After applying updates, the WIM internal free-space (superseded files from replaced packages) inflates the file size. Exporting creates a clean, compacted version:

REM Export the serviced index to a new WIM — this compacts the file
DISM /Export-Image ^
  /SourceImageFile:D:\sources\install.wim ^
  /SourceIndex:6 ^
  /DestinationImageFile:D:\sources\install_serviced.wim ^
  /Compress:max

Step 8 — Rebuild the ISO after servicing

A serviced WIM file alone is not bootable media. You must reassemble the ISO with the correct boot sector metadata intact. On Windows, the standard tool for this is oscdimg.exe from the Windows ADK:

REM Replace the original install.wim with the serviced version
REM (back up the original first)
copy D:\sources\install.wim D:\sources\install.wim.original
copy D:\sources\install_serviced.wim D:\sources\install.wim

REM Rebuild the ISO with dual UEFI/BIOS boot support
oscdimg.exe ^
  -m ^
  -o ^
  -u2 ^
  -udfver102 ^
  -bootdata:2#p0,e,bD:\boot\etfsboot.com#pEF,e,bD:\efi\Microsoft\boot\efisys.bin ^
  D:\ ^
  C:\Output\Windows11_Pro_Serviced.iso

The -bootdata flag is the critical part. It encodes both the legacy BIOS boot path (etfsboot.com) and the UEFI boot path (efisys.bin), producing a hybrid ISO that boots on both firmware types. Omitting this flag produces an ISO that mounts and browses correctly but may fail to boot on target hardware. See Bootable ISOs: El Torito, BIOS vs UEFI, and Hybrid Boot Media for a detailed explanation of why this matters.

Common DISM errors and fixes