master image with drivers

[Bob Henderson]

@Lee-Rowlett Ah, yeah, that.

Can’t you just add them to the driver store though via PNPUtil so they’re ready to go?

[george1421]

@Bob-Henderson said in master image with drivers:

Can’t you just add them to the driver store though via PNPUtil so they’re ready to go?

You could but its much less work to just place the files in the right spot and tell OOBE where to look. You could (which I don’t like to do) just stuff the model specific drivers into the windows/inf folder using a post install script and let windows just magically find them during oobe.

[george1421]

@Lee-Rowlett said in master image with drivers:

@Bob-Henderson DevicePath Registry wont work with Windows 10 - im sure its mentioned in links george has already posted

Right its in there, for win10 you must update the unattend.xml file to tell it where to look for the drivers. Actually MS deprecated the guidance to use the registry settings for Win7 (this was a hold over from XP), but it still worked. MS recommended using the unattend.xml approach for Win7 onward.

[sudburr]

I’ve created a folder of all the drivers needed by all our platforms (just over 4 GiB worth) that sits in the image. Coming out of sysprep unattend.xml calls dpinst and installs the drivers before oobe, then deletes the folder to reclaim the space.

[Bob Henderson]

@george1421 sorry coming into this late but link to the oobe stuff?

I’ve just been doing the process here to add downriver store in one big chunk.
http://bobhenderson.org/add-multiple-drivers-win10-driverstore-one-shot/

[sudburr]

Depending on how large a cache of new drivers you are injecting by using pnputil you run the risk of bloating the registry. I’ve poisoned Windows 7 images doing this. I haven’t gone back to pnputil since; Windows 10 may be more robust.

I may be the exception with the number of different systems I deal with.

However, building drivers into the local store bloats your master image permanently. I prefer now to install on-demand coming out of sysprep with synchronous commands in the unattend.xml or a .vbs run by auto-logged on Administrator, then deleting the local store at deployment to reclaim that disk space.

Why don’t I use a network-based driver repository? Systems we deploy to may not have access to our network or even a fog server when they first power up.

[george1421]

@Bob-Henderson I’m know expert in this but I can tell you what has worked for over 500 systems we deployed with win7 and now moving on to win10 it also functions with a bit of a twist.

Ref: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection/4

With Win7 (and before) if you changed / updated HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/DevicePath with a place for the OOBE or windows installation process to look (%SystemRoot%\DRV;%SystemRoot%\inf;) and the files were in the .ini format, Windows will load them just like they were internal (MS delivered) drivers. There is nothing to inject, nothing to load, nothing extra to do. We have to remember since FOG is deploying using linux, none of the windows utilities will run for injecting the drivers during image deployment. So everything has to be done on the windows side. We do copy the drivers files to the specified location during fog image deployment so when windows “wakes up” it finds what it needs and loads them.

For Win10, the registry key mentioned above has be deprecated and to achieve the same results you need to append this section into your unattend.xml file.

    <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:\Windows\DRV</Path>
                </PathAndCredentials>
            </DriverPaths>
        </component>
    </settings>

Again no additional action is needed here. Just pace the files in the right location referenced by the setting and windows will load them.

FWIW: OOBE is what we are incorrectly calling the windows setup process before the windows user surface is displayed for the very first time.

Now for 100% transparency, when we build our master image we do inject the Dell PXE hardware drivers into our master image. This at the very least ensures that our master (reference) image includes basic network and hard drive drivers so if we need to reach out to a network share during OOBE we can.

[Bob Henderson]

@george1421 Awesome, that’s simple enough. Does the unattend option support a network location as well. i.e. \server\with\drivers ?

Our total driver store we need to add is under 4g, so it’s nothing crazy, but network based could make it easier to maintain for sure…

[george1421]

@Bob-Henderson According to this MS document they do. https://technet.microsoft.com/en-us/library/cc766485(v=ws.10).aspx Search for “Adding a device driver during auditSystem”

In our case our driver store is on the FOG server. As I said before, we use a FOG post install script to install the correct drivers onto the hardware post image push and before the first windows boot. When windows powers up for the first time everything is already on the target disk it might need.

In your case of the network file share, you must have the networking and storage drivers on the target hardware or it will never get to the network driver storage. The issue also comes when new hardware comes out you will have to update your master image to include the new network and storage drivers too.

We support 12-14 hardware models (3 new models per year for 4 years), our driver store is about 20GB but that is for Win7 and Win10 drivers over 15 supported models.

[Bob Henderson]

@george1421 Alright. I’ll have to dig through those scripts more, I guess. I’ve liked the thought of FOG handling it, but have never really went into it and I’m not sure why. Guess I like to keep my imaging and my application/driver bet seperate for some inane reason

[Quazz]

@Bob-Henderson You might enjoy Snappy Driver Installer, although this is generally more useful if you get all sorts of models accross the floor, rather than expected ones as it will have drivers for close to everything. (compressed)