Windows 10 driver injection doesn't install during sysprep
-
Thanks everyone for the suggestions. I’ll continue testing and report back if I find a solution.
-
@jdd49 FWIW: What hardware are you using?
-
@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 -
@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.
-
Hi,
First, informations about my stuff :
Server :
FOG Version : Running Version 1.3.5-RC-8 ; SVN Revision: 6066
OS : Debian GNU/Linux 8Specifications :
- 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 …HP820G1:
- 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 -
@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. -
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. -
@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.
-
@george1421 @Wayne-Workman I am seeing this issue too on Win 1709 EDU. Sysprep isn’t looking in C:\Drivers even though unattended file is telling it to. Windows Update picks up some drivers but not all. If I go into Device Manager and manually point to C:Drivers it will load the driver for that one device.
What am I missing?
<settings pass="offlineServicing"> <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" 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"> <DriverPaths> <PathAndCredentials wcm:action="add" wcm:keyValue="1"> <Path>C:\Drivers</Path> </PathAndCredentials> </DriverPaths> </component> </settings>
-
@uwpviolator maybe this can help in general for everybody?
-
-
@uwpviolator I ran into the same issue when I was working on our 1709 image (which was put on hold for the moment). I ended up with a hack to use dism in the setupcomplete.cmd to load in all of the drivers in c:\drivers directory.
-
@tom-elliott said in Windows 10 driver injection doesn't install during sysprep:
@uwpviolator maybe this can help in general for everybody?
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-device-drivers-to-windows-during-windows-setupInteresting that one says to use WinPE instead of NonWinPE. That sounds counter intuitive, but if it works…
-
@george1421 Are you able to share that info?
-
@uwpviolator Info?
What I saw was a contradiction between my settings
<component name="Microsoft-Windows-PnpCustomizationsNonWinPE"
and what Tom found in his first link
<component name="Microsoft-Windows-PnpCustomizationsWinPE"
The microsoft document said to use Microsoft-Windows-PnpCustomizationsWinPE which is counter intuitive to Microsoft-Windows-PnpCustomizations
Non
WinPE from my guide. I have not had a chance yet to see of this location that Tom found actually works, being monday and all… -
@george1421 said in Windows 10 driver injection doesn't install during sysprep:
@uwpviolator I ran into the same issue when I was working on our 1709 image (which was put on hold for the moment). I ended up with a hack to use dism in the setupcomplete.cmd to load in all of the drivers in c:\drivers directory.
This is what I was referring to. How did you call this in the setupcomplete.cmd to pull drivers from C:\Drivers?
-
@uwpviolator Ah, sorry. I thought you were talking about my last post.
Well it sucks getting old, I didn’t use dism (after looking at the code) this is what I used to force the drivers in.
REM Inject any missing drivers for hardware discovered during oobe forfiles /p "C:\Drivers" /s /m *.inf /c "cmd /c pnputil -a @Path"
-
@george1421 Testing that now. Both of the other ways did not work for me.
-
@george1421 This seems to be working for me. I think I must be missing some drivers that I did not upload to FOG or my model doesn’t like 1709 which by a few forum post might be the case. M$ really screwed up with 1709. Its like the Vista of the Win 10 builds.
-
@uwpviolator I’ve found that I need to call that pnputil 2-3 times to find all hardware hidden behind other hardware.
I agree that 1709 did some bad things to the non SCCM image cloners.