Windows 10 Drivers Not Copying

[UWPVIOLATOR]

@tom-elliott @george1421

So worked with George yesterday on this. Here is what we know and where we left of.
Ran Debug
Broke out of script after Driver Copy
Checked the HD and the x64 folder was there and in it the test .txt file
Then sysprep
Folder is gone after sysprep

So it might be an issue with unattended file. I did not make it it was from our last image which was Win 10 EDU 1609. I am going to upload a blank image with no unattended file and see if the file sticks.

[george1421]

@uwpviolator You asked yesterday about the unattend.xml file. I started with my win7 config file and it worked for win10. But our config file was very basic. If you need a good starting point you can go to this web site to create a template unattend.xml file. http://windowsafg.no-ip.org/

Just don’t put any private information into this configuration. Put generic license keys and such and then hand exit afterwards.

[UWPVIOLATOR]

@tom-elliott

This

echo "System breakpoint";
debugPause;

rsync -azP "$remotedriverpath" "$clientdriverpath"
[[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine/$osn/$arch]"

echo "End driver copy";
debugPause;```

or This

echo "System breakpoint";
debugPause;

rsync -azP "$remotedriverpath" "$clientdriverpath"

echo "End driver copy";
debugPause;

[UWPVIOLATOR]

@george1421 @Tom-Elliott

Uploaded fresh image no unattended file. Still no files on HD. See my last reply. Which one do I replace in my fog.drivers file?

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