FOG Post install script for Win Driver injection

george1421

@Jamaal Just for clarity this tutorial was intended for Dells only.

With that said it can work for Lenovos or other models. I can tell you that lenovos (more precisely) Dell store the system name in a different location than other computer manufacturers. So your fog post download script will need to look in a different location that my scripts indicate (because they are Dell centric).

Since you are a Windows convert, you MUST remember that case IS important to linux. So just pay attention when creating file paths.

The built in fog.postdownload script is just a shell script (it doesn’t do anything right out of the box). It is up to you as the FOG admin to add content to that script. So in short yes you will need to update that script as indicated.

So for the Dell computers we have to use this smbios key to pick up the system name using dmidecode
dmidecode -s system-product-name

For the other manufacturer (I believe lenovo too) you have to use this key
dmidecode -s baseboard-product-name

One manufacture stores the name in the system structure and one in the baseboard structure. Both are correct just a pain if you have a mixed fleet. In out production fog script we use another dmidecode key to find the manufacturer dmidecode -s baseboard-manufacturer and then use a case statement to query the right key for the system name.

What I might do until I was comfortable with the hardware setup would be to schedule a debug capture of the new and untested hardware. A debug capture will drop you to a command prompt on the target hardware when you pxe boot it. Once at the command prompt on the FOS engine (the linux OS that boots on the target hardware) run the dmidecode command and inspect what get returned. This code returned must match exactly the driver parent folder in the /images/drivers/XXXXX

Jamaal

@george1421 Ok, I’ll try that tomorrow when I go back to work. Thanks for the info, but can you tell me about the joining of the domain? or maybe it’s best if I use a script to just join it?

george1421

@Jamaal You can join the machine to the domain by:

Have the unattend.xml file join the computer to the domain
Have the FOG Client connect the computer to the domain
Create a script that is executed by the setupcomplete.cmd file

I use the first option because based on the image used, type of computer, site deployed to, our post install script will choose the correct OU and update the unattend.xml file accordingly. That is something the fog client isn’t designed to do.

Many people use option 2.

As for why your setup is not connecting to the domain. Is the network driver being loaded so the client can reach the domain controller? If I had a system that wouldn’t connect to the domain, I would log into it and then manually connect it to the domain. Be sure you use the user ID and password you defined in fog, that user account must have computer add rights. The other thing may be that you are defining a destination OU that doesn’t exist? Also you may be able to glean some information by looking at your DC’s security log to see if its a permission issue.

Jamaal

@george1421 George, I think I got the name correct for the Lenovo, getting further than before. I remember I had the name structure as ThinkPad T560 under the drivers folder, but getting stuck at Preparing Drivers… in progress. In the task menu on the web, it only shows like 1% and not moving. Any idea on why that’s happening?

Jamaal

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

@george1421 George, I think I got the name correct for the Lenovo, getting further than before. I remember I had the name structure as ThinkPad T560 under the drivers folder, but getting stuck at Preparing Drivers… in progress. In the task menu on the web, it only shows like 1% and not moving. Any idea on why that’s happening?

I think I see what is the issue. Just that the screen moves too fast and said no such file or directory and it reboots.

Jamaal

@george1421 George, 2 more questions as I’m starting to get the hang of MDT 2013 and fog. How do I put in the task to change the registry to put c:\drivers for where Fog will drop the drivers for the Lenovo machines? And the other thing that’s giving me an issue, where else in the fog.drivers script do I edit c:\drivers?

Other than that, I’m feeling confident I’ll be able to deploy our fleet.

george1421

@Jamaal I can say for my organization, I use MDT to update the registry entry during the reference image build. That always has worked for me.

The other way people have done it was via the fog.drivers script here (look at the very bottom) https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection/4

the fog.driver script route appears to work, but I’ve never used that route. It was easier for me to just create the mdt task to update the registry key, plus I could/do validate the reference image matches the our design standard before image capture, so I need all of the bits to be in place for validation.

What is important (for the registry key) is to have the c:\drivers path first then the c:\windows\inf directory. You want OOBE to search for the model specific driver before it uses the windows built in driver (if both exist).

Jonathan Cool

Hello,
(french user, sorry for my bad english … )
Sorry for the question (the post is quite old) but i’m lost to choose the best solution for Driver Injection after image Deploy.

In my environment, we have HP, DELL, Lenevo computer (laptop, desktop).

What is the best way ? postdowloadscript included in Fog ? Or this way ? Or … it’s “depend on” ?

Many thanks
Have a nice day.

Quazz

@Jonathan-Cool Postdownloadscripts are up to the user to implement correctly, the system exists in FOG and this thread talks about using that system with a community created script.

It’s easily the most convenient if you have a lot of the same models and it doesn’t change all the time.

george1421

@Jonathan-Cool No problem on the bad english. I’m a native english speaker, and I speak it bad too…

There are a few threads for setting up driver injection using a postinstall script. The thing you must remember if you go this path is that the postinstall scripts run under linux as a bash shell script and not windows. So there are somethings you can not do like DISM injection.

There is a second requirement for this process to work. Your drivers must be in inf format and not built into a .exe installer. All of the Dell and most of the Lenovo drivers are in INF format. I can’t speak for the HP and their drivers.

The postinstall scripts can work for all models the post install script will first check the manufacturer of the hardware then check the model number of the hardware to identify what drivers are needed.

I wrote a tutorial (in addition to this thread) for this process.
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script

Also Lee wrote an excellent that takes a slightly different approach too.
https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins

Jonathan Cool

This post is deleted!

austinjt01

@quazz So in my instance, I have 4 different HP models, and 2 different kinds of Lenovo’s. I tried using DISM to install the drivers, which appears to work, but hangs up the imaging process for a long time until you physically reboot the target machine. After reboot however, it appears to be all of the drivers installed. I am struggling trying to figure out the best way to install the drivers on a per model basis. Is there an easy way to do this with FOG?

Thanks!

george1421

@austinjt01 The steps outlined here do work.

In your case, what I would do is (on a test system) don’t inject the drivers during your test imaging. Once the system has imaged, and OOBE has completed. Login with an admin account and manually run the command as you have it defined in the setupcomplete.cmd file.

My bet is that DISM or the installation of one of your drivers is asking a question. Since this is at a point in the imaging process it can’t access the desktop the question is being displayed to a hidden desktop. By running it interactively you might be able to see the question and then take counter measures. I had an issue with an into nuc and intel not signing 2 drivers with an approved certificate that caused the driver install to fail. Once I imported the certificates before installing the drivers everything went OK.

sourceminer

Hello @george1421 Just making sure this is still the recommended way to do driver injection. Its been a year, and I have seen some other documentation for this. Just making sure its good before I go down this path.

george1421

@sourceminer Its still accurate. I do think I need to create a new one that is a bit more concise and update a few things specifically for Win10, since Win7 will start its 2 year decline to unsupported soon.

There has been some discussion around using this process and then calling DISM to inject the drivers twice in the setupcomplete.cmd to install all remaining drivers not detected during OOBE. Sometimes hardware is hidden behind other hardware, behind other hardware.

sourceminer

@george1421 OK great. Would be a nice thing to just make this part of the gui? Or built into the solution to some varying degree.

sourceminer

So I have been playing with this script seems great, except when there isn’t any drivers. Is there a way to prevent it from failing if no drivers exist?

george1421

@sourceminer looking at the code (IMO it needs a bit of a clean up). But if you tested to see if the directory pointed to by remotedriverpath existed before trying to run the rsync it would not error out. You could also print the “drivers were not found” message.

Jamaal

@george1421

Hey George, hope all is good. So I’ve taken a break from this as I got busy with my job, so I’m almost there with this.
I copied and pasted the fog driver script and also ran a debug to confirm on the Lenovo laptop, it’s dmidecode -s system-version. Now my question is that for example, the version name for the machine is Lenovo T570 W10DG ( a zero by the way, not an o) how am I supposed to load the drivers? I have the structure as /images/Drivers/$machine/$osn/$arch, so /images/Drivers/Lenovo T570 W10DG/win7/x64 and I downloaded the drivers for sccm for example and let them in their folder structure, ex; network, display, etc… with all the files in it.

My assumption was that fog will look throughout the subfolders under x64 for the correct drivers, or am I wrong? I then decided to take all of the inf drivers from the subfolder an past them in the x64 folder, but I still couldn’t get the drivers to install. Please look at the fog.driver file:

#!/bin/bash
ceol=tput el;
manu=dmidecode -s system-manufacturer;
case $manu in
[Ll][Ee][Nn][Oo][Vv][Oo])
machine=$(dmidecode -s system-version)
;;
[Dd][Ee][Ll][Ll])
machine=$(dmidecode -s system-product-name) #pruduct is typo, just realized sorry
;;
)
machine=$(dmidecode -s system-product-name) # Technically, we can remove the dell one as it’s the “default”
;;
esac
[[ -z $machine ]] && return #assuming you want it to break if it is not lenovo or dell?
machine=“${machine%”${machine##[![:space:]]}“}” #Removes Trailing Spaces

#############################################

Quick hack to find out if the installed OS image is a x86 or x64

system64=“/ntfs/Windows/SysWOW64/regedit.exe” # sloppy detect if 64bit or not
[[ ! -f $system64 ]] && arch=“x86” || arch=“x64”

#############################################
#this section has been updated to bring the osn names in line

with how the Dell CABs are defined

case $osid in
5) osn=“win7” ;;
6) osn=“win8” ;;
7) osn=“win8.1” ;;
9) osn=“win10” ;;
esac

#############################################
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/DRV”
remotedriverpath=“/images/Drivers/$machine/$osn/$arch”

if [ -d $remotedriverpath ]; then

[[ ! -d $clientdriverpath ]] && mkdir -p “$clientdriverpath” >/dev/null 2>&1
echo -n “In Progress”

#there’s 3 ways you could handle this,
#driver cab file, extracted driver files or both
#so on the server put extracted driver files to match below folder tree
#i.e. Model Latitude E5410, Windows 7 x86 image would be:
#/fog/Drivers/Latitude E5410/win7/x86

rsync -aqz “$remotedriverpath” “$clientdriverpath” >/dev/null 2>&1
[[ ! $? -eq 0 ]] && handleError “Failed to download driver information for [$machine/$osn/$arch]”

#this next bit adds driver location on pc to devicepath in registry (so sysprep uses it to reference)

remember to make devicepath= match the path you’ve used locally

#also do not remove %SystemRoot%\inf
#and to add more locations just use ; in between each location

regfile=“/ntfs/Windows/System32/config/SOFTWARE”
key=“\Microsoft\Windows\CurrentVersion\DevicePath”
devpath=“%SystemRoot%\DRV;%SystemRoot%\inf;”;
reged -e “$regfile” &>/dev/null <<EOFREG
ed $key
$devpath
q
y
EOFREG
echo -e “\b\b\b\b\b\b\b\b\b\b\b${ceol}Done”; # this just removes “In Progress and replaces it with done :-)”

fi

Jamaal

@george1421 [0_1512049987850_fog sample.pdf](Uploading 100%)

I did a command in the Fog OS called uname -m which gave me the architecture of x86_64. Now I thought
under the architecture on the fog server, I’d call the folder _x86_64 instead of x64. Is that not correct? I was fighting with this yesterday, but working at it now, will post once I have an update 0_1512050025031_fog sample.jpg . Please tell me if I have this correct, attached the pic.