FOG Post install script for Win Driver injection

[george1421]

@agray Ok you can ignore that section. It is in there to remove the unattend.xml file if its found in the setup directory. There should be only one unattend.xml file and it should be in c:\windows\panther directory.

What the fog.ad script does, it dynamically update the unattend.xml file with fog run time parameters. If you are not using an unattend.xml file or using the FOG client to connect the computer to AD and give it its name then you don’t need the fog.ad script at all.

If you look at the fog.postdownload script in this section

        debugPause
        # . ${postdownpath}fog.log
        . ${postdownpath}fog.drivers
        # . ${postdownpath}fog.ad
        umount /ntfs

You will see that the call to those scripts are commented out. The only script that is required is fog.drivers the others provide functionality beyond driver injection.

As for the 2017 ed why are they different? Because we’ve learned things since this thread was published. I would look at the 2017 version if you are doing a new install. This thread gives the background behind why the 2017 is the way it is.

[agray]

@george1421 From what I’m getting from all the threads, the unattend.xml file is required with win10 now. Is that no longer the case?
If it is, is that required to be edited in the master image before cloned?
Later in your 2017 ed thread you gave an update on the 1703+ Win, saying “add the following lines to your setupcomplete.cmd batch file.” That batch file already created, if not, where can i find code for it, or it that it in the code box?

[george1421]

@agray The unattend.xml file is required if you want an unattended windows setup. You can use an online unattend.xml generator to create this file: http://www.windowsafg.com/ or craft one by hand with your site specific configuration.

The setupcomplete.cmd file is run by windows setup at the end of the OOBE process and just before the first windows logon is displayed. You place batch commands in there to be executed before the user’s first login. Google “setupcomplete.cmd” to find out its location and structure.

[agray]

@george1421 Thank you! all is appreciated! I’m sorry for the bombardment of questions.

[lwafflard]

Hello,

Thanks a lot for all this stuff ! We used it since year start (HP/Dell, a dozen of differents models, 300 computers). We made some minor update on this script, if it can be reused :

# lowercase machine name and remove all spaces
machine=$(echo $machine | tr A-Z a-z | tr -d ' ')

So, our drivers directory looks like :

/images/drivers
├── forAll
├── hpelitedesk800g3twr
├── hpz230towerworkstation
├── optiplex7040
├── optiplex7050
├── optiplex7060
├── optiplex9010
├── optiplex9020
├── optiplex9030aio

Another one concern the drivers download (unicast/NFS) by each client. By default, all unicast rsync start after the last multicast session. To make «subgroups» of rsync based on last IP number:

dots "Calculate IP (wait4sync)"
MY_IP=$(ip route get 9.9.9.9 | awk '{print $7}')
IP_LAST=$(echo ${MY_IP} | cut -f 4 -d '.')

# IP OK ?
if ! [[ ${IP_LAST} =~ ^[0-9]{1,3}$ ]]
then
  IP_LAST=4
  echo -n " bad IP..., use ${IP_LAST},"
fi
# Want each to wait ((IP_LAST % 5) ) * 3mn
## w.x.y.zz0|5|10|... => no wait
## w.x.y.zz1|6|11|... => wait 3mn
## w.x.y.zz2|7|12|... => wait 6mn
WAIT=$((${IP_LAST} % 5 * 3))m
echo " IP: ${MY_IP} => wait ${WAIT}"
sleep ${WAIT}

dots "Preparing Drivers"
...

the last one concern the «forAll» directory, used for all common drivers like «pci simplified communication»:

remotecommondriverpath="/images/drivers/forAll"
[[ ! -d "${clientdriverpath}" ]] && mkdir -p "${clientdriverpath}" >/dev/null 2>&1
dots "Common drivers In Progress"
rsync -aq "$remotecommondriverpath" "$clientdriverpath" >/dev/null 2>&1
[[ ! $? -eq 0 ]] && handleWarning "Failed to download common drivers"
echo "Finish"

[fry_p]

I hate to admit it took me a full day to realize there should be no space in the directory structure for the driver folders when I (poorly) read George’s instructions in the 2017 thread (lmao)

I also have a question that is related to the driver injection concept, but it is after the post download scripts.

For one of the machine types, the .cab comes with an unknown amount unsigned driver for some stupid reason. This complicates things because a prompt to “install the unverified driver(s)” during the setupcomplete.cmd. I can’t find a method to force/silently say yes to this with pnputil.

Most fixes involve an extra reboot to turn off driver integrity checks. I am trying a really roundabout method:

Setupcomplete.cmd

BCDEDIT /set nointegritychecks ON
shutdown -t 0 -r

Then, a script that lives in the startup folder found at C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup does the following, then deletes itself after it runs once.

pnputil.exe /add-driver "C:\Drivers\*.inf" /subdirs /install
pnputil.exe /add-driver "C:\Drivers\*.inf" /subdirs /install
pnputil.exe /add-driver "C:\Drivers\*.inf" /subdirs /install
rmdir /Q /S C:\drivers
BCDEDIT /set nointegritychecks OFF
(goto) 2>nul & del "%~f0"

Finally, I have a scheduled task built into the image that takes care of the commands usually in the typical setupcomplete.cmd, then deletes itself as well. The reboot should theoretically take care of the client service config and turning the integrity check back on.

sc config FOGService start= delayed-auto 
shutdown -t 0 -r

I got to the point of being ready to test this yesterday, but the workday ended. I will test in a few hours when I am in. I am open to suggestions of how to make this less clunky (if it even works).

[Sebastian Roth]

@fry_p said in FOG Post install script for Win Driver injection:

sc config FOGService start= auto

Why do you set it to auto instead of delayed?

[fry_p]

@Sebastian-Roth Whoops, I did not know that was the norm now. It is in the wiki article as auto. My bad, I can certainly change that before I try again.

EDIT: fixed my first post with the delay and a missing space just in case it works and someone uses it later

[Sebastian Roth]

@fry_p said in FOG Post install script for Win Driver injection:

It is in the wiki article as auto.

Which wiki article is this?

[fry_p]

@Sebastian-Roth

https://wiki.fogproject.org/wiki/index.php/FOG_Client#FOG_Client_with_Sysprep

"Place these lines within the file, and then save.

sc config FOGService start= auto
shutdown -t 0 -r

As the filename indicates, the script is called by windows after an image is deployed and post-sysprep operations are complete. It will re-enable the FOGService and then reboot the computer gracefully. After the computer reboots, the FOGService will start automatically and rename the computer if necessary, reboot if necessary, join the domain and reboot if necessary, and then perform any associated snapins. "

[Sebastian Roth]

@fry_p Thanks, fixed.

[george1421]

@fry_p said in FOG Post install script for Win Driver injection:

BCDEDIT /set nointegritychecks ON

Right this needs to be put into your golden image. Its a bad hack. But its VERY strange that Dell would release unsigned drivers, that’s so 2015. Are they not signed, or are they signed but have an unidentified certificate?

[fry_p]

@george1421 said in FOG Post install script for Win Driver injection:

@fry_p said in FOG Post install script for Win Driver injection:

BCDEDIT /set nointegritychecks ON

Right this needs to be put into your golden image. Its a bad hack. But its VERY strange that Dell would release unsigned drivers, that’s so 2015. Are they not signed, or are they signed but have an unidentified certificate?

I legitimately want to ask, is it really dangerous to have that off for that short period of time? I turn it back on after the next automated reboot. I suppose if something failed, it would be stuck in that state… I need to not be lazy and find which one(s) is(are) unverified. Sadly, the message does not specify in sysprep.

This may be a fluke because I am testing and found this issue on an OptiPlex 7020 .cab. It is not the newest gen by any means.

[george1421]

@fry_p said in FOG Post install script for Win Driver injection:

I am testing and found this issue on an OptiPlex 7020 .cab.

Someone else on the forum was building a 7070 and had the same results where setupcomplete.cmd never finished. What we found is it was hanging injecting the drivers because of an unsigned driver and the continue message was on a hidden desktop.
I wonder if this will be an issue with those using SCCM or MDT to build their images? MS may just turn it off to avoid failure then turn it back on when done, I don’t know. But its very bad when a hardware manufacturer releases unsigned drivers. I had an issue with Intel NUCs a few years ago where the driver was signed, but it was signed with a MFG certificate. I had to import the certificate into the cert store on the reference image to get the drivers to load correctly on a post deploy driver injection.

If you have a service account with Dell I sure would give them a call and ask is this normal. If you rerun the pnputil command interactively with a desktop you may be able to trap which driver(s) are causing the problem and eject them from the driver pack and have solid info when calling Dell support.

[acatalepsy]

Hi everyone,

I’ve just copied scripts and getting following error while deploying image to a windows client. I cant find how to resolve it. Did anybody experience same issue before?

An error has been detected!

Failed to download driver information for [VC60/win10/x64]

[george1421]

@acatalepsy First I would follow the instructions in this post: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

I realize its 4 year old information but its still accurate and works for Win10. The thing you have to remember is that linux is case sensitive so you need to make sure your data path to the drivers is in the case format that is known and expected. You can surely debug your setup and make it work.

[DVBNL]

I’m experiencing an issue with a Dell OptiPlex 3090. In the postscript:

“/images/postdownloadscripts/fog.copydrivers: command substitution: line 14: syntax error near unexpected token ‘;;’”

manu=dmidecode -s system-manufacturer; >> is working fine since it’s returning the next line of code:

“echo “Unable to identify the hardware for manufacturer ${manu}”;”
result:
“Unable to identify the hardware for manufacturer Dell Inc.”

case $manu in
    [Ll][Ee][Nn][Oo][Vv][Oo])
        machine=$(dmidecode -s system-version)
        ;;
    *[Dd][Ee][Ll][Ll]*)
        machine=$(#)
        ;;
    *I[Nn][Tt][Ee][Ll]*)
        # For the Intel NUC and intel mobo pick up the system type from the
        # baseboard product name
        machine=$(dmidecode -s baseboard-product-name)
        ;;
    *)
        # Technically, we can remove the Dell entry above as it is the same as this [default]
        machine=$(dmidecode -s system-product-name) 
        ;;
esac

Somewhere in the above code the script is unable to retrieve the product name. I’m still debugging this but maybe someone already resolved this issue?

[DVBNL]

@dvbnl

Fixed it with the following code:

#!/bin/bash
ceol=`tput el`;
manu=`dmidecode -s system-manufacturer`;
dots "Identifying hardware"
case $manu in
    [Ll][Ee][Nn][Oo][Vv][Oo])
        machine=$(dmidecode -s system-version)
        ;;
    *I[Nn][Tt][Ee][Ll]*)
        # baseboard-product-name
        machine=$(dmidecode -s baseboard-product-name)
        ;;
    *)
        # system-product-name
        machine=$(dmidecode -s system-product-name)
        ;;
esac

[JJ Fullmer]

@dvbnl It’s the “.” in “Dell Inc.”
I was just implementing this and found an issue with “Vmware Inc.” specifically the “.” not being seen as part of the string.

I chose to remove any trailing dots in the manufacturer name.

add this second manu definition, and it should help move you forward.

manu=`dmidecode -s system-manufacturer`;
manu="${manu%.*}";

I would also add below it something like

if [[ "${manu}" == "Dell Inc" ]]; then manu="Dell"; fi

If you are structuring your folders with the name “Dell” rather then Dell Inc

[george1421]

@jj-fullmer So how would you propose to tweak this code:

#!/bin/bash
ceol=`tput el`;
manu=`dmidecode -s system-manufacturer`;
dots "Identifying hardware"
case $manu in
    [Ll][Ee][Nn][Oo][Vv][Oo])
        machine=$(dmidecode -s system-version)
        ;;
    *[Dd][Ee][Ll][Ll]*)
        machine=$(dmidecode -s system-product-name)
        ;;
    *I[Nn][Tt][Ee][Ll]*)
        # For the Intel NUC and intel mobo pick up the system type from the
        # baseboard product name
        machine=$(dmidecode -s baseboard-product-name)
        ;;
    *)

ref: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

I need to look because someone else just recently found a bug in this section of code too. Maybe I need to update/create a 2022 version of this post. The 2017 version is still accurate even in 2022 (maybe)