Unused Drivers -> Driver Cache (Driver Store) of Target System

bseklecki_ge

bseklecki_ge

Member
Messages
136
Reaction score
20
Question about Windows Installer (not necessarily an NTLite Question)

I've always assumed that all the drivers that NTLite lets me put into an image (setup.wim, boot.wim) were just automatically copied to the target system by Windows Setup, even if they were not used [ on the target system on which the install initially occurs], that they would somehow magically come-to reside within in the unused driver cache (C:\Windows\System32\DriverStore\) for use later.

I can see now from poking around with dism.exe, and after a few failed V2P attempts, that is not the case.

I have a situation where I'm:

* Building a golden image ISO with NTLite that contains drivers for PMs and VMs target environments
* Sometimes install ISO onto BareMetal
* Most frequently install ISO onto a VM environment, where I perform additional "2nd stage" customizations, and from there, I either make:
** An Acronis SnapDeploy TIB (BareMetal)
** An OVA/OVF (for the civilized world)

For those BareMetaltargets, I have a situation where, having first done the ISO installation onto a VM, Microsoft Windows Setup has stripped out all of drivers. V2P of this resulting VM image will fail on BareMetal.

The question is: How to get the drivers re-integrated, from within the VM environment, before I sysprep the VM image for use by V2P / V-2-P ?

I was thinking to upgrade to NTLite Business, but, even then, it doesn't allow online image addition of drivers.

Quite a few drivers, even if you find the secret way to extract the .inf/.sys file from the executable, will often refuse to install if they fail to detect the corresponding hardware.

DISM does not let one add drivers online.

( If I am feeling truly diabolical, I can use a WinPE bootable image, boot the VM, and then use dism.exe to add all of the drivers from my NTLite Preset XML by hand, or by batch file)

Anyone else been stuck in this situation?
 
Last edited:
I hope other members help you. Anyway, this is exactly what ChatGPT-4o replied:

Your situation presents an interesting challenge, especially in workflows involving virtualization-to-physical (V2P) migrations. Here's a structured approach to resolve your driver integration dilemma:

1. Prepare Drivers Offline​

Ensure you have extracted drivers in .inf format for all potential target hardware. Tools like Double Driver or manually extracting drivers using pnputil can help here.

2. Automating Driver Injection in VM (Offline Mode)​

Since you cannot add drivers directly to an online system, use the following steps:

Option A: DISM in WinPE​

  1. Create a Bootable WinPE Image:
  2. Mount the Target Disk in WinPE:
    • Boot into WinPE on the VM and mount the virtual disk where Windows is installed.
  3. Inject Drivers with DISM:
    • Use the following DISM command:
      cmd
      Copy code
      dism /image:C:\ /add-driver /driver:D:\Drivers /recurse<br>
      Replace C:\ with the path to the mounted image and D:\Drivers with the folder containing all your drivers.
  4. Sysprep and Capture:
    • Once the drivers are injected, return to your VM, finalize your customizations, and sysprep.

Option B: Mount the VM VHDX or VMDK in Host​

  1. Mount the Virtual Disk:
    • Mount the VHDX or VMDK file on your host machine using tools like Hyper-V Manager, Disk Management, or third-party software.
  2. Use DISM to Inject Drivers:
    • Inject the drivers offline by specifying the mounted disk path.
      cmd
      Copy code
      dism /image:&lt;PathToMountedDisk&gt; /add-driver /driver:&lt;PathToDriverFolder&gt; /recurse<br>

3. Automate Driver Integration with Scripts​

To simplify this process for repeated use:

  1. Batch Script for DISM: Create a script to add all drivers from a specified folder:
    cmd
    Copy code
    @echo off<br>set driverPath=D:\Drivers<br>set targetPath=C:\<br><br>dism /image:%targetPath% /add-driver /driver:%driverPath% /recurse<br>echo Drivers added successfully!<br>
  2. Integrate into VM Workflow:
    • Embed this script into your deployment tools for ease of use.

4. Future-Proof with NTLite​

While NTLite cannot add drivers to an online image, the Business Edition offers more flexible presets and automation. If you upgrade:

  1. Add all necessary drivers to your image upfront (boot.wim, install.wim, and post-install drivers).
  2. Ensure the ISO handles most bare-metal targets, reducing dependency on post-installation customization.

5. Advanced: Sysprep with Drivers​

If integrating drivers post-setup is unavoidable:

  1. Place drivers in a directory like C:\Drivers.
  2. Add a custom unattend.xml file with the &lt;Path&gt; element under &lt;DriverPaths&gt; for sysprep to pick them up during the specialize phase:
    xml
    Copy code
    <span>&lt;<span>Component</span> <span>name</span>=<span>"Microsoft-Windows-PnPSysprep"</span> <span>processorArchitecture</span>=<span>"x86"</span> <span>publicKeyToken</span>=<span>"31bf3856ad364e35"</span> <span>versionScope</span>=<span>"nonSxS"</span>&gt;</span><br> <span>&lt;<span>DriverPaths</span>&gt;</span><br> <span>&lt;<span>PathAndCredentials</span>&gt;</span><br> <span>&lt;<span>Path</span>&gt;</span>C:\Drivers<span>&lt;/<span>Path</span>&gt;</span><br> <span>&lt;/<span>PathAndCredentials</span>&gt;</span><br> <span>&lt;/<span>DriverPaths</span>&gt;</span><br><span>&lt;/<span>Component</span>&gt;</span><br>

Community Input​

You’re not alone—many sysadmins face similar challenges. If your workflow still feels cumbersome:

  • Explore Deployment Tools: Consider Microsoft MDT (Microsoft Deployment Toolkit) for end-to-end automation.
  • Experiment with Hybrid Approaches: Inject drivers in pre-sysprep stages within the VM.
Would you like detailed help on creating a WinPE image or crafting custom scripts?
Click to expand...
 
Cobra_Smile said:
I hope other members help you. Anyway, this is exactly what ChatGPT-4o replied:
Click to expand...
That's a pretty accurate assessment.

The other option I'm going to offer to my customer:
* Switch to FreeBSD or GNU/Linux
* Purchase matching BareMetal hardware equipment/environment on which to make BareMetal images. The same code can be used. Hard to give Laptops and Desktops 40gbps speed connectivity to the NAS/SAN >:}
 
ALSO, we would sponsor development of a feature to allow all unused drivers from [ install.wim ] to be copied into the Driver Cache (System32\Drivers\Driver Store\) of Target System.

However, I have a feeling that this is something that Microsoft has to fix; code that would run during WinPE/WinRE state of Windows Setup.

The super-inefficient way of using Bare Metal hardware to prepare bare metal images is in keeping with the Microsoft ethos. In 25 years as a UNIX system administrator, building custom OS images for embedded platforms, it is just not something that I ever encountered.

You just .... copy the kernel files from the install environment to the target...and then ..... you....are....done.
 
After some time finally allowed further research into this, I find Windows Installer is really inconsistent here.
It seems that only certain "classes" are drivers are exempted from copying into the driver cache on the target system.
* NIC Drivers = OK
* Storage Drivers = NOT COPIED
* Graphics Drivers = NOT COPIED

Mercifully, further testing also reveals that one can bundle up the filesystem hierarchy from their NTLite build environment, extract it into the target environment, and post-Sysprep have a PowerShell script simply call a recursive search & install function:

PS> Get-ChildItem "C:\Drivers_Location_Parent_Folder" -Recurse -Filter "*inf" | ForEach-Object { PNPUtil.exe /add-driver $_.FullName /install }

It is just not at all graceful, and there are big security risks.
 
Maybe you can try this trick (I dunno if it works outside of a normal sysprep):
Code: 
[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\Sysprep\Settings\sppnp]
"PersistAllDeviceInstalls"=dword:00000001
"DoNotCleanupNonPresentDevices"=dword:00000001
 
In this case, the sequence is:

[ OEM ISO from Microsoft DOC ] => [NTLite Process] => [ Custom ISO ] => [ Install in VM ] => [ 2nd Stage Customization ] => [ Sysprep ] => [ Deploy V2P as: OVA/OVF, WIM Image, or SnapDeploy TIBx]

When the Custom ISO is installed into VM Environment, 50% of the drivers (previously added to custom ISO via NTLite Process) are lost , and are therefore unavailable during V2P.

I just think it is interesting that only certain classes of drivers are missing; imagine to be a fly on the wall of the meeting room where the Microsoft engineers were discussing that design.

"Guys! I got it, we can make the system install and run faster if we optimize the image during installation."

"But, if we make the code faster, then our golf buddies at Intel will have fewer sales volume"

"Yea, you're right, so lets only half-implement it; but continue adding sleep() statements at random places in the rest of the kernel code."
 
You must log in or register to reply here.
Back
Top