@george1421 I was intending on sharing my changes in that 2017 post on drivers and on the unattend updates by the end of this month (still making sure everything is stable and will have to universalize a bit)
Granted, the only changes I made for the drivers related to how I structure my driver packs. Like I don’t have anything other than 64 bit windows 10, so I didn’t need all the os code stuff or a structure matching that. I also have driver packs that fit multiple models, in windows/powershell I found ways to match models based on the folder name but wasn’t able to recreate that syntax in bash (I’m sure it can be done, I just didn’t want to put in the time). So instead I added a ModelList.txt file in each driver pack and have it use grep to search all of those files for the model of the machine. This also helps in handling spaces in the folder structure and model name, as I didn’t want to recreate my entire driver folder structure without spaces. So I didn’t need the bit that removes spaces from the make\model (I also change manu to make and machine to model). I also had to add bits as mentioned below for the makes that have a ‘.’ as it was seeing that as a command in some cases.
I also had some notes on how and when the drivers are added in windows, as you can use the unattend.xml to deploy them during the specialize phase before it gets to oobe. You also can do pnputil
without the /install
flag first so that all the drivers are added to the pnp store so once they are visible they will auto add in windows.
Also the unattend update example mentions putting the password in plaintext, but the fos console has access to the $adpass variable from the host information. So it can pass that to the unattend without displaying it. I would also add a note about being sure the unattend.xml files should be deleted.
I don’t know why I waited so long to play with the driver injection and other postdownload scripts, once I did I added so many improvements in speed and stability to my provisioning system.
I also added a log file for what is copied down that is visible inside of windows, basically had it pipe to said log file instead of to null.
This is what my snippet looks like for getting the model
ceol=`tput el`;
make=`dmidecode -s system-manufacturer`;
make="${make%.*}";
dots "Identifying hardware"
if [[ "${make}" == "Hewlett-Packard" ]]; then make="hp"; fi
if [[ "${make}" == "HP" ]]; then make="hp"; fi
if [[ "${make}" == "Hp" ]]; then make="hp"; fi
if [[ "${make}" == "VMware, Inc" ]]; then make="VMware"; fi
case $make in
[Ll][Ee][Nn][Oo][Vv][Oo])
model=$(dmidecode -s system-version)
;;
*[Ii][Nn][Tt][Ee][Ll]* | *[Aa][Ss][Uu][Ss]*)
# For the Intel NUC and intel mobo pick up the system type from the
# baseboard product name
model=$(dmidecode -s baseboard-product-name)
;;
*)
# Technically, we can remove the Dell entry above as it is the same as this [default]
model=$(dmidecode -s system-product-name)
;;
esac
# if the model isn't identified then no need to continue with this script, just return to caller
if [[ -z $model ]]; then
echo "Unable to identify the hardware for manufacturer ${make}";
debugPause;
return;
elif [["${model}" == "Surface Go"]]; then
echo -en "\n\nSurface Go will also match other generations of Surface Go, adding a 1\n\n"
model="Surface Go 1";
fi
echo "${model} Identified";
Then I find the driver pack to copy like this
dots "Preparing Drivers"
#folder to copy into, I create this when I setup my image and also embed a small selection of storage drivers that aren't included in the default windows install (.i.e any that require loading a driver when installing windows manually such as intel vmd/raid types or vmware paravirtual scsii) These are added during audit system phase of sysprep
clientdriverpath="/ntfs/Out-Of-Box Drivers"
#the driverstore is organized as make/model but that Model folder can apply to multiple models (i.e. hp shares a driver pack for all the form factors of hp elitedesk/prodesk 400/600/800 g#)
#define the base make path, and cd to it, helps with handling spaces in the path
makePth="/images/drivers/${make}"
cd $makePth;
#find the model in a modellist.txt using grep. I used the API to get all my hosts and then sorted the inventory to show me all the unique makes/models and used that to built the modellist.txt files so that they would match what is found here.
listFile=`grep -il "$model" ./*/*-ModelList.txt`
#set the remote driver path to the parent folder of the modellist.txt where it was found
remotedriverpath="$makePth/${listFile%/*}"
#define the log file that will be visible
injectLog="/ntfs/logs/driverInjection.log"
Then I get ready to copy
#I set up a generic/universal driver pack of network/storage/chipset drivers that I've found aren't included in the default windows install that I've found through trial and error. It probably has a bunch of duplicates (so I call it a hodgepodge) but it helps to get the machine on the network so it can find the drivers it needs when a driver pack wasn't found.
if [[ ! -d "${remotedriverpath}" ]]; then
echo "failed";
#output to console and output to log
echo " ! Driver package not found for ${model} copying hodgepodge! ";
echo " ! Driver package not found for ${make} ${model} copying hodgepodge universtal oobe drivers ! " > $injectLog;
remotedriverpath="/images/drivers/generic/universal"
debugPause;
else
# output to console and output to log
echo " Driver package for ${make} ${model} found! ${removedriverpath} will be copied to ${clientdriverpath}";
echo " Driver package for ${make} ${model} found via ${listFile}! ${removedriverpath} will be copied to ${clientdriverpath}" > $injectLog;
fi
cd /;
echo "Ready";
echo -en "Driver Injection In Progress\n\n\n"
echo -en "Driver Injection In Progress\n\n"
#I removed the -q and tried to add a progress bar to no avail, but also found that rsync displayed a message saying to use -zz instead of -z for sending with compression, since the output is piped to a log, I kept -q out of it to get more verbose logging
rsync -azz "$remotedriverpath" "$clientdriverpath" >> $injectLog;
echo -en "Drivers.cmd Injection In Progress\n\n"
#this is the drivers.cmd file used during specialize to add drivers
rsync -azz "/images/drivers/drivers.cmd" "/ntfs/drivers.cmd" >> $injectLog;
# I also copy additional files here following this same syntax
[[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$model] or other files failed to copy"
debugPause
This is the contents of drivers.cmd
echo "Adding drivers to driver store...."
start pnputil.exe /add-driver "C:\Out-Of-Box Drivers\*.inf" /subdirs
echo "Installing drivers for present devices...."
start pnputil.exe /add-driver "C:\Out-Of-Box Drivers\*.inf" /install /subdirs
This is the part of the sysprep unattend under the specialize phase I use to call it
<component name="Microsoft-Windows-Deployment" 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">
<!-- I have other settings inside this component, this is just to show the synchronous command in the component-->
<!-- commands to run in order during specialize -->
<RunSynchronous>
<!-- add and or install the injected drivers and then reboot -->
<RunSynchronousCommand wcm:action="add">
<Path>C:\drivers.cmd</Path>
<Order>1</Order>
<Description>Add Injected Drivers</Description>
<WillReboot>Always</WillReboot>
</RunSynchronousCommand>
<!-- Additional commands to run before getting to oobe, I use this for configuring built in windows features using dism powershell commands and I have a powershell function that detects nvidia drivers and attempts to install the graphics driver. This .cmd file just opens a .ps1 file -->
<RunSynchronousCommand wcm:action="add">
<Order>2</Order>
<Description>Pre-req steps</Description>
<Path>C:\step0.cmd</Path>
<WillReboot>Always</WillReboot>
</RunSynchronousCommand>
</RunSynchronous>
<!-- I have a case statement in my unattend updater to set the correct device form. This affects some UI settings in windows, I use 3 as a default as it is a normal desktop pc, there are also ones for detachable or convertible tablets, all in one machines, and many others. You can also just omit this-->
<DeviceForm>3</DeviceForm>
</component>
This above component needs to be in the specialize settings block, i.e.
<settings pass="specialize">
<!-- other specialize components-->
<component name="Microsoft-Windows-Deployment" 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">
<!-- stuff from above -->
</component>
</settings>
I recommend using windows system image manager (https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/wsim/windows-system-image-manager-technical-reference) for creating your initial unattend file.