Help with Win10 Driver injection

[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.

[MotD]

I Need some Help with this Scipts.
I have HP and Lenovo Machines, and i want to test the Driver Injection with a Lenovo ThinkPad L560.

I dont know if i had all made all required settings, my Drivers dont copied to the Client.

I have placed the fog.drivers, fog.log and fog.postdownload into /images/postdownloadscripts and set the Files to 755.
And i have create da drivers Folder into /images with Rights set to 755.

Under drivers there is a Folder named to the result from “dmidecode -s system-product-name” and the other needet Folders under it.
Looks like this:
/images/drivers/20F10026GE/win10/x64

Under x64 i put all 64Bit Drivers from a SCCM Package for the ThinkPad L560.

But i think the FOG dont start the Scripts unter /images/postdownloadscripts.
The Folder C:\Windows\DRV was not created and no Drivers copied.

Do i have any settings to make so FOG run the Scrips under /images/postdownloadscripts?

Please can someone help me?

[THEMCV]

@MotD What does your fog.postdownload and fog.drivers look like?

Any error messages?

[MotD]

@THEMCV I have taken the Files and Folder Structure from this Thread and dont change anything.
https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection/2

Where can i see a Log File or else?
The Messages on the Client System runs too fast to read it.

[THEMCV]

@MotD Check out this thread and make sure you’ve got the updated ones. This is what I’m using.

https://forums.fogproject.org/topic/8878/fog-drivers-script-will-not-run-correctly-in-postdownloadscripts/51?page=1

[MotD]

@THEMCV Many Thanks to you, i’ll read it now and then i try it

[MotD]

@THEMCV Now i have another Question, i try to run the fog.postdownload script in Terminal.
And get a Error because i there is no Folder called “/usr/share/fog” with the called funcs.sh Script. The Folder is completly missing.

I have FOG 1.3.3 installed on a Ubuntu 14.04 LTS.
Where i get the needed Files?

[THEMCV]

@MotD You shouldn’t run it, it should go in /images/postdownloadscripts. The error I’m not sure about.

in /images/postdownloadscripts do you have fog.postdownload and fog.drivers in there from the thread?