Help with Win10 Driver injection

[george1421]

@kyle.heath OK, what hardware are you deploying to?

Also please show me a screen shot or directory tree of how you have your drivers installed in c:\windows\drivers. I’m interested in seeing if your have the drivers in inf format.

[kyle.heath]

@george1421 I’m deploying drivers to a Dell Latitude 3570. Here is a SS of what it looks like after the image is deployed. The drivers are there in folders, but they are not installed. I know this because I pointed a missing driver to this folder and it installed fine. It’s just not doing it during sysprep for some reason.

[Tom Elliott]

@kyle.heath I think, then, what you’re running into (possibly?) is the cart before the horse.

I ran into similar issues, where the installation would run through and install some drivers, but not all. Things like USB devices were not installing because the chipset was being installed after the usb device was installed.

Of course, there’s better ways to handle this, but my fix was to have the setup script run through the installation twice by running dpinst within the directory.

[kyle.heath]

@Tom-Elliott So in the script I would need to have it run twice using dpinst…sorry but I’ve never used dpinst so I’m not sure what it is. How would I go about doing this?

[Tom Elliott]

@kyle.heath I don’t have an example, but i had to find the dpinst binary.

I placed it in the directory where the drivers were found.

I needed a dpinst.xml file too (which just told the dpinst binary how to run without my having to intervene).

[george1421]

I’m currently deploying WIn10 to an o920 just to confirm its still working as intended. I would have been done sooner but I had a forked up FOG server this AM.

[kyle.heath]

@george1421 Ok please let me know if it still works. I’m deploying the image again, this time with sysprep in Panther. I’ll let you know if that changes the outcome.

[sudburr]

dpinst.exe is a Driver Package INSTaller that comes from the Microsoft Windows Driver Kit

Different versions of the WDK are compatible with different versions of the Windows client OS and their equivalent server OS.

Microsoft Windows Driver Kit 7.1.0 (WXP)
Microsoft Windows Driver Kit 8.0 (Vista)
Microsoft Windows Driver Kit 8.1.u1 (Win7, Win8, Win8.1)
Microsoft Windows Driver Kit 10.0.10586.0 (Win7, 8, 8.1, 10)
Microsoft Windows Driver Kit 10.0.14393.0 (Win7, 8, 8.1, 10) but doesn’t come with a new dpinst.

There are different versions for 32bit and 64bit OSes.

dpinst32.exe: installs and uninstalls driver packages.
By default, the tool searches the current directory and tries to install all driver packages found.

Usage: <path>\dpinst32.exe [/U INF-file][/S | /Q][/LM][/P][/F][/SH][/SA][/A][/PATH Path][/EL][/L LanguageID][/C][/D][/LogTitle Title][/SW][/? | /h | /help]

  /U INF-file    Uninstall a driver package (INF-file).
  /S | /Q        Silent (Quiet) mode. Suppresses the Device Installation Wizard and any dialogs popped-up by the operating system.
  /LM    Legacy mode. Accepts unsigned driver packages and packages with missing files. These packages won't install on the latest version of Windows.
  /P     Prompt if the driver package to be installed is not better than the current one.
  /F     Force install if the driver package is not better than the current one.
  /SH    Scans hardware for matching devices and only copies and installs those drivers for which a device is present. Only valid for Plug and Play drivers.
  /SA    Suppress the Add/Remove Programs entry normally created for each driver package.
  /A     Install all or none.
  /PATH Path     Search for driver packages under the given path.
  /EL    Enables all languages not explicitly listed in the XML file.
  /L LanguageID          Tries to use the given language in all UI. Useful for localization tests.
  /SE    Suppress the EULA.
  /C     Dump logging output to attached Console (Windows XP and above).
  /D     Delete driver binaries on uninstall.
  /SW    Suppresses the Device Installation Wizard, the operating system might still pop-up user dialogs.
  /? | /h | /help        Shows this help.

If a dpinst.xml is in the same path as the .exe when invoked, the dpinst.exe will use the values in that .xml. I use:

<?xml version="1.0" ?>
<dpinst> 
	<!-- equivalent to /sa -->
	<suppressAddRemovePrograms/>
	<!-- The following search and subDirectory elements direct DPInst to search all subdirectories (under the DPInst working directory) to locate driver packages. -->
	<search> 
		<subDirectory>*</subDirectory> 
	</search> 
	<!-- The following language element localizes its child elements for the English (Standard) language. The child elements customize the text that appears on the DPInst wizard pages. -->
	<language code="0x0409"> 
		<dpinstTitle>Device Driver Updater</dpinstTitle> 
		<welcomeTitle>Welcome to the Device Installer!</welcomeTitle> 
		<welcomeIntro>This wizard will walk you through updating the drivers for your device.</welcomeIntro> 
		<installHeaderTitle>Installing the software for your device...</installHeaderTitle> 
		<finishTitle>Congratulations! You finished installing your device drivers.</finishTitle> 
	</language> 
	<!-- equivalent to /sh -->
	<scanHardware/>
</dpinst>

The important bit in this .xml is that it tells dpinst to recursively scan all subdirs at the location specified for all drivers.

By using that .xml along with this command in a post-sysprep or even mid-sysprep script I can force the computer to install drivers when I want to, instead of waiting for Windows to do it at its leisure:

<path>:\dpinst.exe /path "<the path to the drivers I want to use>" /q /se

DPInst will only install those drivers needed by your hardware, provided of course the necessary driver is in your path. Once completed, the script then deletes the folder(s) that held the original drivers, thus freeing up space.

I prefer to use DPInst to install drivers coming out of sysprep, instead of injecting with dism, pnputil or other methods because with each driver you inject, whichever method you use, the registry bloats and can in extreme cases cause the OS to become unstable; yes I’ve done this while prepping a HW-agnostic image ready to drop onto any of 26 very different platforms. This is an MS documented problem with at least Windows 7. I haven’t looked back on the methodology so I don’t know if it can still be an OS killer on Windows 8.1 or 10.

Installing drivers mid- or post-sysprep means I have a large 1-3GB repository to install from that is included in the image, but it means the devices are ready on my terms.

[george1421]

@kyle.heath Yes deploying to a 9020 does work correctly all drivers were loaded correctly after the reboot. I did have to do one additional reboot after imaging was complete because the AMT drivers was not loaded.

I compared the section of the xml regarding drivers between mine and yours and they are identical.

I have my sysprep command in a batch file so we have a consistent image build every time. This is the content of that batch file.

BTW: I’m deploying Win10 Ent CBB 1607 to this target computer.

  net stop wmpnetworksvc
  c:\windows\system32\sysprep\sysprep.exe /quiet /generalize /oobe /shutdown /unattend:C:\Windows\Panther\Unattend.xml

[george1421]

Just looking for differences here.

While our unattend.xml files differ quite a bit, there is something that stands out in your unattend.xml file that isn’t in mine.

My section

    <settings pass="generalize">
        <component name="Microsoft-Windows-PnpSysprep" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <PersistAllDeviceInstalls>false</PersistAllDeviceInstalls>
        </component>
    </settings>

Your unattend file

	<settings pass="generalize">
        <component name="Microsoft-Windows-PnpSysprep" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <DoNotCleanUpNonPresentDevices>true</DoNotCleanUpNonPresentDevices>
            <PersistAllDeviceInstalls>true</PersistAllDeviceInstalls>
        </component>
        <component name="Microsoft-Windows-Security-SPP" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <SkipRearm>1</SkipRearm>
        </component>
    </settings>

Note what you are doing with the drivers. I’m not saying one is right or the other is wrong. Just my kit does as it should.

[MRCUR]

@george1421 I can’t imagine the drivers would install correctly with the persist & do not clean set to true. This is probably your issue @kyle-heath.

[kyle.heath]

@MRCUR Thanks MRCUR and George1421…I also think that this is the issue. This is a copy of a windows 7 Unattend.xml that the guy before me used to push out his images to machines and had the drivers on a flash drive. He would install the drivers to the machines after the golden image is pushed out and then re upload them with appropriate names…etc (LenovoE550, LenovoE440). I’m getting away from that and just using 1 image for all 64 bit machines. I’ll test this out and see if it works. Thanks!!

[Quazz]

I’m late, but if you’re using inf files and such to install drivers, it’s sufficient to place them in a folder under Windows\inf and windows will install them during first boot. (which means I’ll also recommend copying them over during postdownloadscript stage of imaging)

Just my two cents

[kyle.heath]

@Quazz So you think pushing them into the Windows\inf folder would work better than pushing them into a C\windows\driver folder? I may try this also and see if it works. Looks like I can approach this in multiple ways. Thanks for the input!

[Quazz]

@kyle.heath I have a folder with network drivers on all my images and that works fine. I just put all of them there from the universal driverpacks.

Cool thing is, you don’t need to specify windows to install those drivers, it does so by itself.

[kyle.heath]

@MRCUR I tested this by changing the values of those to false and it still didn’t install all the drivers. It installed a couple, but I’m missing

I’m going to try dpinst.exe to see if that works.

[kyle.heath]

@Quazz So right now I have a folder on my FOG server that pushes out a folder called Drivers onto my machines. If I push out a folder called INF into windows instead of Drivers that should push them into the correct area for Microsoft installation. It’s installing some of my drivers but not all. SMBus and some USB drivers don’t install.

[george1421]

@kyle.heath Its installing the same number of drivers as when you place them in c:\windows\drivers?

If that is the case you need to check the drivers to see if they are unpacked.

I do have to ask the question where did you get all of these drivers from? Were they on the Dell Deployment CAB for your hardware model or did you download them individually from the Dell site.?

Also note as a Moderator I’m going to fork this section of the thread since its a bit off topic of the original tutorial. I’ll clean it up after the issue has been resolved or come to an end.

[kyle.heath]

@george1421 It’s not installing the same number because when i point the missing drivers to the C:\Windows\Drivers folder it installs them. I got them from the Dell website and they were on the Dell Deployment CAB. It installs certain ones like the networks ones, but SMBUS and USB ones it does not.

[sudburr]

@kyle.heath In Windows 7, some drivers for newer devices must be installed after drivers for older devices are installed with a reboot in between and vice versa.

And as @Quazz said, you can quite simply dump your entire library of drivers into ‘c:\windows\inf’, but you will still be limited by Windows 7’s ability, or inability to prioritize driver installation order.