FOG Post install script for Win Driver injection


  • Moderator

    Introduction

    First I have to say this article contains the results of many brilliant people and is not my content. I’m only assembling this information into a consistent document instead of spread around buried in posts and responses. My intent is to not dig into the details behind the scripts or how to tweak them for your needs. You can read the links below to figure out why things are being done the way they are. I wanted to create a tutorial that was as close to a cut and paste to get driver injection going in your environment. Now I will primarily focus on Dell hardware for the main reason that Dell does supply driver archive files (known as .CABs) that can be downloaded and extracted quickly to create the driver structure. I’m sure that HP, Lenovo, and others have similar driver packs.

    You can download the Dell driver cabs for your hardware from here: http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment

    Reference links:
    https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins
    https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script-under-construction
    https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script
    https://forums.fogproject.org/topic/8878/fog-drivers-script-will-not-run-correctly-in-postdownloadscripts/46



  • @george1421

    Ok, thanks for the explaination George, appreciate your help.


  • Moderator

    @jamaal You have to remember the script was designed to work directly with the Dell CAB file format. I understand you are working with lenovo, but as long as you have inf file format you can adapt it easily.

    osid vs osname. In the case of FOG it knows internal osid == a certain operating system. So instead of requiring the FOG IT admin to create directories based on an integer number to represent windows 7 or windows 10, I created a map so when osid == 5 that mapped to a directory path of win7 and osid == 9 would be win10 and so on. That way when you looked at the directory path you would know the win7 drivers go into the win7 directory and not the “5” directory. That is the logic of the osid to osn name matching.


  • Moderator

    @jamaal You shouldn’t (have to) alter the script.

    osname is not the same as osid, the script uses osid.

    The folder name for windows 7 should be win7 as it mentions in a comment in the script.

    #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
    


  • @george1421

    George, ok, thanks for explaining that to me. Now I understand why I saw _x86_64 and I changed the
    folder in the osn back to x64. I guess where I’m lost is for example, I installed the Lenovo sccm drivers for a T570 laptop, right? then in each folder, I took any inf’s I can find and put it in the x64 folder. The structure I followed on your other pages and in the file is /images/Drivers/ThinkPad T570 W10DG/Windows 7/x64.

    I did Windows 7 because when I ran the fog debug, it came out osname=Windows 7. Now my question is in the fog.drivers script for example, do I change osn to osname=Windows 7? I know I tried that yesterday and it didn’t work.
    When I changed the folder back to x64, during driver deployment, it goes quickly and says done instead of failed, which is good, but the drivers never make it to the T570…

    Not sure what I’m doing wrong.


  • Moderator

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

    I did a command in the Fog OS called uname -m which gave me the architecture of x86_64. Now I thought

    The issue here is you have 2 operating systems in the mix.

    1. FOS which is a x64 bit OS.
    2. The OS on the target Operating System.

    FOG / FOS is a 64 bit OS. But you could be deploying a 32 bit OS. So knowing what Arch FOS is will not ensure you deliver the proper drivers required by the target OS.


  • Moderator

    @jamaal Correct. If you follow my instructions, you should not have to modify any of the code to make it work as long as the drivers you have on the disk are in the format outlined by the tutorial.



  • @george1421 @Quazz

    Thank you both. George, I know you said you’re still working on the driver injection-2017, but I’m testing it out right now as I’m trying to understand more about Linux commands to put under my belt, you know. Quazz/George,
    in the fog.copydrivers, I put in where it says && arch= and arch= I put x64 and removed where it had 86.


  • Moderator

    @jamaal @Quazz is spot on. I know its hard to see, but the very last post in this tread actually shows you the expected disk structure: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection/2

    I’m working on a slighly better formatted version of this tutorial here: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

    Its not complete yet. The intent is to focus on what we’ve learned since 2016 and to focus a bit more on Win10 since that is the focus of the windows community now.


  • Moderator

    @jamaal The script assumes $arch in the path, which are defined as either x86 or x64.

    x86_64 means x64

    So for it to work, change the path to x64



  • @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 update0_1512050025031_fog sample.jpg. Please tell me if I have this correct, attached the pic.



  • @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


  • Moderator

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



  • 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 OK great. Would be a nice thing to just make this part of the gui? Or built into the solution to some varying degree.


  • Moderator

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



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


  • Moderator

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



  • @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!



  • This post is deleted!

 

426
Online

41.4k
Users

11.8k
Topics

112.0k
Posts