Windows 10 driver injection doesn't install during sysprep

  • I know this isn’t directly an issue with Fog, but I wanted to see if anyone else has experienced this problem. In short, manually injecting drivers does not appear to work correctly with Windows 10. Windows 7 worked properly when modifying the devicepath in the registry but not anymore, the drivers do not get installed during Sysprep, resulting in the computer not joining the domain during the Sysprep phase. After the computer reboots to Windows then the drivers are found. I know some have recommend setting the driver path in the offline servicing section of the sysprep answer file, but that answer is not valid. That phase is never processed unless the image is applied using WinPE. You can see the workflow in the attached pic as well as more explanation here.

    I know it’s a long shot, but I was hoping someone had a workaround.

  • Moderator

    @Jonathan-Cool said in Windows 10 driver injection doesn't install during sysprep:

    So, I didn’t copy any files in my FOG Drivers folder.
    I ran a task with this computer just ONLY to see if the reg hack work.

    Not a logical test since: no files copied == no drivers loaded == reg key added but no valued added because nothing to load.

    But I understand the logic behind your test.

  • i think there is a misunderstanding.
    The HP8000 is an old computer and there is no drivers for the Win10 OS.
    So, I didn’t copy any files in my FOG Drivers folder.
    I ran a task with this computer just ONLY to see if the reg hack work.

  • Moderator

    @Jonathan-Cool said in Windows 10 driver injection doesn't install during sysprep:

    To conclude, i ask some questions to myself … this method work or this method NOT work for Win10x64 ? That’s is the question !

    I will tell you that you need to debug that HP8000 a little better, the scripts will copy the files if everything is correct.

    That is different than if windows oobe will load the drivers. Step 1 is getting the drivers onto the target computer. Step 2 is telling windows where to find the drivers.

    The registry hack will work for Win7.
    The registry hack will NOT work for Win10. For Win10 you must update the unattend.xml file to tell it where to look for the drivers.

  • Hi,

    First, informations about my stuff :

    Server :

    FOG Version : Running Version 1.3.5-RC-8 ; SVN Revision: 6066
    OS : Debian GNU/Linux 8

    Specifications :

    • all images are on a Synology NAS storage : mounted with NAS_ip:/images
    • french user :)

    I discover recently the drivers injection method with scripts fog.postdownloadscript and fog.drivers.
    With Win7x64, it’s work by using the hack registry method to add C:\Windows\DRV in the DevicePath.
    I read in this topic some people have troubles to inject drivers on a Win10x64 computer using this method.
    I just realize quick test with 3 models (Optiplex7010, 820G1, HP8000) and it’s seem to works … :
    Just after the deploy, i check if the C:\Windows\DRV contained files, check if the registry hack has been realize and i check if all drivers are installed …

    Optiplex7010 :

    • C:\Windows\DRV : OK
    • registry hack : OK
    • all drivers are installed

    HP8000 :
    i didn’t find Win10x64 drivers for this computer BUT after the deploy, i can see the registry hack has work …


    • C:\Windows\DRV : OK
    • registry hack : OK
    • some drivers are absents … maybe i forgotten some files when i created the folder drivers on NAS …

    To conclude, i ask some questions to myself … this method work or this method NOT work for Win10x64 ? That’s is the question !

    Enc : Screenshot of my Optiplex7010 results …
    link text

  • Moderator

    @falko I got pulled off because we have a sick VM host server.

    Also considering if the unattend.xml fails to use DISM /online in the setupcomplete.cmd to inject the drives that got missed (assuming there was any). One other thing that we do is inject the dell cab winpe pack into the reference image before image capture. That dell cab driver pack contains network and storage drivers. So those are “built into” our reference image from the start.

    Again I’m taking jdd49 experience that its not working and trying to come up with a plan before I touch the system.

  • Moderator

    @george1421 how did the testing go?
    I plan to start checking out windows 10 deployments myself and had seen you mentioned adding the sysprep part in your post download script post
    Hope to test this the wknd

  • Moderator

    @jdd49 FWIW: What hardware are you using?

  • Thanks everyone for the suggestions. I’ll continue testing and report back if I find a solution.

  • @Quazz Fairly certain. Domain join is being done by the sysprep answer file, not the fog client. Drivers are not installed in time for the sysprep answer file to join the domain, but on the next reboot they do get installed.

  • @jdd49 I ran into this same problem beginning with Windows 8 not recursively pulling from folders I added to “c:\windows\inf”.

    My later tests using “offlineServicing” were only partially successful. Many modern devices have devices hanging off devices, which the “offlineServicing” doesn’t seem to want to wait around for to detect and install once the parent device is fully enumerated. If there was a way to force “offlineServicing” to trip more than once that’d be great but …

    Now I’m working on my first large scale Windows 10 image deployment; we’ll see what happens.

  • Moderator

    @jdd49 Do you know for certain it’s the driver at fault here? Because I use the inf folder method on all my images and it always works for me.

    There are other things that could cause domain joining (I’m assuming done by FOG client?) not to work properly.

  • @Quazz Same location for both. Windows 7 just copy drivers to c:\windows\inf works fine. Doing the same for Windows 10 does not.

  • Moderator

    @jdd49 I will test/disprove if it is working this afternoon. I’ll grab a o7040 and rename the driver directory on the fog server which should block all drivers being installed then image with win10. Our reference image only has the winpe dell drivers installed. Let me confirm if all of the hardware is detected.

  • Moderator

    @jdd49 Correct, but it was my understanding you were using a different location to house your drivers on Windows 7?

  • Yes they are inf, if not it wouldn’t work for Windows 7 either, as far as I know.

  • Moderator

    @jdd49 That’s impossible, there’s obviously something else going on that’s causing your problems. Drivers in the inf folder are installed on first boot, before OOBE. Are they actually inf drivers? Not cab?

  • @Quazz Unfortunately I have tried that too. Still the same result. Drivers not installed in time for domain join, but upon next reboot they are installed. This all worked fine in Windows 7, I’m thinking there just might not be any workaround for Windows 10.

  • @george1421 said in Windows 10 driver injection doesn't install during sysprep:

    Yes I’ve seen this before.

    You need to add this to the unattend.xml file for Win10

        <settings pass="offlineServicing">
            <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
                    <PathAndCredentials wcm:action="add" wcm:keyValue="1">

    Or where ever your install files are kept. The registry change was last officially supported in XP, and with Win7 they did keep that function in the system for legacy reasons. With Win10 that option was removed. You MUST use the unattend.xml method now.

    #wiki worthy, should probably go here somewhere:

  • Moderator

    @jdd49 I recommend placing inf drivers in C:\Windows\inf (you can put them in a subfolder) in that case, to test it out (and just in general it’s a good idea), you can even remove it with SetupComplete since they’re installed before OOBE phase (on first boot).

    You can grab driverpacks online (so essentially almost every NIC is supported)

Log in to reply





Looks like your connection to FOG Project was lost, please wait while we try to reconnect.