Windows 10 Drivers Not Copying

[george1421]

@uwpviolator Well then, I think you might want to change up your fog.drivers script a bit. Right now its working fine for win7 but not win10. So in the first script you posted modify this section of code.

#############################################
dots "Preparing Drivers"
# below creates local folder on imaged pc
# this can be anywhere you want just remember
# to make sure it matches throughout! (case IS important here)
clientdriverpath="/ntfs/Windows/inf/Drivers"
remotedriverpath="/images/drivers/$machine/$osn/$arch"

to this

#############################################
dots "Preparing Drivers"
# below creates local folder on imaged pc
# this can be anywhere you want just remember
# to make sure it matches throughout! (case IS important here)
if [ $osid -eq 9 ]
then
    clientdriverpath="/ntfs/Drivers"
else
    clientdriverpath="/ntfs/Windows/inf/Drivers"
fi
remotedriverpath="/images/drivers/$machine/$osn/$arch"

You might ask, so what will that do for you? The patch tests to see what OS you are deploying. If the OSID==9 then you are deploying a win10 image. In that case it will copy the drivers to C:\Drivers, all other OS’ the drivers will be copied to C:\Windows\Inf\Drivers.

Then in your unattend.xml file, tell oobe to look in c:\Drivers for its files.

[UWPVIOLATOR]

@george1421

So doing this will not affect Win 7 as it will only copy to C:/drivers if Win 10 correct?

[Tom Elliott]

@uwpviolator Correct.

I’m wondering, however, is the script right to begin with?

I mean, you said the C:\Drivers only had a text file in it if I remember correctly, but based on what @george1421 is showing, It looks like you were copying the files to the windows inf driver store? Sorry not familiar with default structure of windows driver, so maybe I’m off base here.

[UWPVIOLATOR]

@tom-elliott

Fog Node
/images/drivers/model name/win7/x64
/images/drivers/model name/win10/x64

Fog.drivers
Copies folder to c:/windows/inf/drivers

Works for Win 7. Not for Win 10

Run debug, stop after driver copy. cd to c:/windows/inf/drivers. x64 is there on the HD. When rebooting and going through sysprep is where it seems to be removing that folder. Thought it might be unattended file but just did it with no unattended and still nothing.

So I will make the changes but this might just be something with Win 10 1709?

[george1421]

@tom-elliott Yes, he was / we were originally promoting to just place the inf files in the inf directory and windows would automagically just see them and use then. It does work that way for Win7 and older releases of win10. It appears the win10 1709 now purges and rebuilds this inf directory when you syspre it. We tested this during debugging. we stopped the master fog script just after driver deployment and confirmed the files where there. Then he rebooted the target computer and checked after oobe and the directory was missing with the test .txt file.

[Tom Elliott]

@uwpviolator I’m going to guess. The fact that you state it works for windows 7 kind of proves this is outside of something fog is actually doing. Not that we don’t want to help (I think you’re aware of this already), but we can’t fix other people’s “mishaps”. All we can do is provide, hopeful, workarounds.

[UWPVIOLATOR]

@george1421 @Tom-Elliott

Yes, I have tested and adding the lines of code fixed it. It now dropps the files to C:/Drivers which is not wiped out. Now I need to update unattend file to reflect this change.

#############################################
dots "Preparing Drivers"
# below creates local folder on imaged pc
# this can be anywhere you want just remember
# to make sure it matches throughout! (case IS important here)
if [ $osid -eq 9 ]
then
    clientdriverpath="/ntfs/Drivers"
else
    clientdriverpath="/ntfs/Windows/inf/Drivers"
fi
remotedriverpath="/images/drivers/$machine/$osn/$arch"```

[UWPVIOLATOR]

@Tom-Elliott @george1421 you guys can make this as resolved. Thanks

[Bob Henderson]

@uwpviolator Could you share how you got OOBE to point to the drivers folder? I’m in the same boat you are, and have yet to figure out how to edit my Unattend to look in C:\Drivers for Win10

Even better, if you could share your unattend with the critical data ripped out, I’d love to see it.

[george1421]

@bob-henderson You can find the section for the unattend.xml file here: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed/4

[Bob Henderson]

@george1421 Yep, I’ve found that before numerous times. My problem is mostly ignorance of not knowing how the Unattend.xml is built, so I don’t know where to put that. Hence asking if someone had a sanitized one they’d be willing to share, so I can see the layout and go.

I’ve used the generators, as well as my existing Win10/Win7 ones, but still don’t really know where to put it.

Thanks!

[george1421]

@bob-henderson I can’t share my (our) unattend.xml file with you because of a NDA agreement, but I can show you where the section goes.

[Bob Henderson]

@george1421 See, that’s the issue. I have that right after OOBE, as you can see below, and it still doesn’t pull. Weird huh?

[george1421]

@bob-henderson Now I can say this use to work. I have not tested it with 1709 yet. 1709 is very different (internally) than 1703. As they said, “Windows 10 will be the last version of windows you will ever need”.

[Bob Henderson]

@george1421 That’s probably it. It’s a 1709 image, as we’re always pushing the latest and greatest for whatever reason. I’m sure they’ve made it more difficult to get your drivers from anywhere but Windows Update…

[george1421]

@bob-henderson

Only thinking out loud at the moment…
We may have to go the route of installing the Dell WinPE 10 drivers cab into the reference image and then in the target computer using either dism or pnputil to force load the drivers during setupcomplete.cmd. The dell winpe drivers (even if you are not using dell hardware) will give the target system enough drivers to complete OOBE where the actual drivers can be injected during setup complete.

I simply haven’t had to time to work on our 1709 image internally so I can only guess at this time.

[UWPVIOLATOR]

@george1421 @Bob-Henderson

George, I think Bob is skipping over the editing of the FOG Scripts. Bob, if you have made the changes to unattended that still does nothing to tell FOG to drop your driver folder into C:\Drivers. See the following reply.

@george1421 said in Windows 10 Drivers Not Copying:

@uwpviolator Well then, I think you might want to change up your fog.drivers script a bit. Right now its working fine for win7 but not win10. So in the first script you posted modify this section of code.

#############################################
dots "Preparing Drivers"
# below creates local folder on imaged pc
# this can be anywhere you want just remember
# to make sure it matches throughout! (case IS important here)
clientdriverpath="/ntfs/Windows/inf/Drivers"
remotedriverpath="/images/drivers/$machine/$osn/$arch"

to this

#############################################
dots "Preparing Drivers"
# below creates local folder on imaged pc
# this can be anywhere you want just remember
# to make sure it matches throughout! (case IS important here)
if [ $osid -eq 9 ]
then
    clientdriverpath="/ntfs/Drivers"
else
    clientdriverpath="/ntfs/Windows/inf/Drivers"
fi
remotedriverpath="/images/drivers/$machine/$osn/$arch"

You might ask, so what will that do for you? The patch tests to see what OS you are deploying. If the OSID==9 then you are deploying a win10 image. In that case it will copy the drivers to C:\Drivers, all other OS’ the drivers will be copied to C:\Windows\Inf\Drivers.

Then in your unattend.xml file, tell oobe to look in c:\Drivers for its files.

[Bob Henderson]

@uwpviolator Actually, I think George is right. To test this and make sure it’s none of my scripts that are acting up, I actually dumped the drivers in the C:/Driers folder prior to capture, and then sysprepped with hte info. So eve nwith the files there 100%, windows doesn’t see them and goes on it’s own merry way.

I’m with @george1421 on this one, 1709 is doing something dumb again. Honestly, I think they are trying to push us more and more to MDT/WDS…or for them, SCCM.

[UWPVIOLATOR]

@bob-henderson I have done this with 1709 and it worked just fine. Review your unattended file or create a test one with just the driver location changed to C:\drivers.

Is everything else working in your unattended file or working at all? Are you actually calling Sysprep to use your unattended file?

[Bob Henderson]

@uwpviolator Yep, I sure am calling the unattend. I’m imaging the same way I have been for a while.

Would you be able to sanitize your unattend and provide, and I’ll do a line by line? As stated, my Unattend hasn’t really been updated since hte Win7 days, so I’d love to see a modern one that is known working…