Help with Win10 Driver injection

[MotD]

@THEMCV Now i have another Question, i try to run the fog.postdownload script in Terminal.
And get a Error because i there is no Folder called “/usr/share/fog” with the called funcs.sh Script. The Folder is completly missing.

I have FOG 1.3.3 installed on a Ubuntu 14.04 LTS.
Where i get the needed Files?

[THEMCV]

@MotD You shouldn’t run it, it should go in /images/postdownloadscripts. The error I’m not sure about.

in /images/postdownloadscripts do you have fog.postdownload and fog.drivers in there from the thread?

[MotD]

@THEMCV Right, under /images/postdownloadscripts i have the fog.postdownload, the fog.log and the fog.drivers all File rights set to 755

But if the Script call the funcs.sh and this file does not exist?

[george1421]

@MotD You have to remember the post download scripts run from the perspective of the FOS engine that runs on the target compuer, not the FOG server. The paths are a bit different.

functs.sh only exists on the FOS virtual hard drive.

[george1421]

@MotD In /images/postdownloadscripts you should have the master FOG hook script called fog.postdownload that should be configured to call your fog.drivers bash shell script. That script is what should move your files.

Also FWIW the Lenovo’s hide their system name in a different place than the Dells in SMBIOS.

You may need to make a elaborate structure to pull the machine name from the Lenovo systems and the Dells if you random deploy to each.

Something like:

sysmanufact=$(dmidecode -s system-manufacturer | tr -cd '\40\60-\176')
sysmanufact="${sysmanufact%"${sysmanufact##*[![:space:]]}"}"

if [[ -z ${systemanufact} ]]; then
    #system manufacturer is blank so try to pick up name from baseboard
    # / motherboard value
    sysmanufact=$(dmidecode -s baseboard-manufacturer)
    sysmanufact="${sysmanufact%"${sysmanufact##*[![:space:]]}"}"
fi

case ${sysmanufact} in
    *[Dd][Ee][Ll][Ll]*)
        machine=$(dmidecode -s system-product-name)
        ;;
    *)
       # Do this for all other machines i.e. Intel and Lenovo
        machine=$(dmidecode -s baseboard-product-name)
        ;;
esac

To get the proper value into the machine variable.

[MotD]

@george1421 Ok, thanks i dont know that.
Sorry i am new on FOG Project and Linux.
I take all Scripts from your Post, and do not make any changes but the Drivers dont copied to the Client.

Can i see a Log File about the Image Deploy and the result of the running from the fog.postdownload and fog.drivers Scripts?

i run a Windows Version of dmidecode called dmidecode212 under the Windows Maschine and get the Result: 20F10026GE from the Lenovo ThinkPad L560. and i create the Folder Structure /images/drivers/20F10026GE/win10/x64

Under x64 i put all 64Bit Drivers from a SCCM Package for the ThinkPad L560

[george1421]

@MotD There is no log file for these scripts. If you took things just as I have defined, that is for Dell hardware. That should work as I have them listed. For Lenovo you will have to make some changes to the scripts.

[george1421]

@MotD I’m going to fork this discussion into a new thread since your issue is new and I don’t want to fill up this thread with a new issue.

We really need you to setup a debug deploy to this lenovo. The numbers you have look correct for what I remember of the Lenovo systems. So you may be spot on.

So schedule a image deploy to this computer but before you press OK, select the Debug check box. Then pxe boot the target computer. After a few enter key presses you should be dropped to the FOS engine command prompt. From there I want you to key in this command.
dmidecode -s baseboard-product-name

[MotD]

@george1421 Ok, i made it this way you say.
The result is: 20F10026GE

The same result from the Way with dmidecode212 under Windows:
dmidecode212 -s baseboard-product-name
result: 20F10026GE

[george1421]

@MotD OK good to know. Lets switch over to chat it will be faster to get an answer.

[george1421]

@george1421 After a lengthy chat session then switching to team viewer we found the issue.

Basically the fog.driver script was throwing this error:

    /images/postdownloadscripts/fog.drivers: line 2: $’\r’: command not found
    /images/postdownloadscripts/fog.drivers: line 3: $’\r’: command not found
    /images/postdownloadscripts/fog.drivers: line 4: syntax error near unexpected token $'in\r'' 'images/postdownloadscripts/fog.drivers: line 4:case $manu in

The key to me was seeing the \r that was being complained about.

In a nutshell the issue was how the file was copied from the web, pasted into notepad++ on windows and then copied to the FOG server using winscp. Somewhere along the way carriage returns where added to the end of each line in the script. I installed dos2unix and ran that utility on the fog.drivers script. That cleaned up all of the errors. We again single stepped through the install process. I confirmed that the source path existed as well as the files on the target computer after the fog.drivers script completed.

When I left MotD he started to reboot the target computer to start the Win10 OOBE process.

Summary: The issue was related to the Windows->Unix file migration only. The script worked as outline in the thread.

[MotD]

@george1421 all drivers was installed correct, so my unattended File works. And the FOG with the great Help from you. Many Thanks.

Next Week i test it with the HP Machines i have, some HP ProDesk 600 G1 and G2, HP ProBooks G2 and G3. The Information from DMI i got todays afternun.

[Jamaal]

@MotD Hey there Motd. So I took a break off of this for a while due to being busy with work projects.
So when you added your drivers onto the fog server for Lenovo, the product name worked compared to for example Lenovo ThinkPad T570?

[george1421]

@Jamaal If your Lenovo was inventoried by FOG, look at the fog web gui
host management -> Host (in question) -> Inventory (tab) and then what does the System Product field say? For the Dells it says ‘OptiPlex 7050’ or what ever model it is. If I remember correctly the lenovo systems put the actual system model/name in a different smbios field than Dells. That name needs to be the parent directory where the drivers are stored.

[Jamaal]

@george1421 ok, I get it now. I’ll play around with it this weekend. And thanks to you, I have a better grasp with MDT 2013 update 2. Do you do what most do like have 2 WIMS? Example, one will be a reference image with like antivirus, office 2013, VNC with up to date windows updates and the other WIM will be a little fatter with other company in house apps that are a little harder to auto install?

[george1421]

@Jamaal I don’t have WIMs per se. We use MDT to build the reference image each time. So far we have found almost all applications install using the application’s unattended install method. So our MDT reference image build is all automatic (lite touch). We do have 2 reference image, but one is bios based and the other is uefi based. Other than the firmware version they builds are exactly the same.

[Jamaal]

@george1421 Ok, my bad, I meant reference WIMs. But for example, how do you handle in house apps to install and configure automatically? We have a few apps that’s in house and we need to configure the settings after install, 1 app we need to configure to point to the G drive to a server for example and our old way we used the USB and bring down the image with Acronis, which I don’t want to do anymore, know what I mean?

[george1421]

@Jamaal The in house applications are a bit more problem since they are probably not built for unattended install. If you have the ability to create the installer for unattended mode then its possible.

1 app we need to configure to point to the G drive to a server for example

I would have to ask you where is that information stored? In the registry or an ini file? If its registry then its pretty easy, just export the registry tree where the settings have already been set, then as part of your MDT application install then just reimport the registry on the target computer.

I can tell you with MDT, once the task sequence has finished on the target computer and displays the end of sequence status panel. At that point the target computer IS still in audit mode. You may continue adding applications and adjusting settings. Just don’t reboot or sysprep until you have finished making tweaks to your reference image.

[Jamaal]

@george1421

I think they’re mostly coming from the ini files. I would need to check.
If worse comes to worse, I can boot the vm, add in the third party apps and when I’m done with everything, just run light touch to sysprep it, correct? Also if I go that route, where should I configure the unattended file? From the unattended tab in MDT? Or directly on the vm like c:\windows\panther for example? I think the unattended file I got confused with last year on where to edit and think that’s another reason why my drivers didn’t transfer over.

[george1421]

@Jamaal

1. If your configurations are coming from ini file, why not just copy the “fixed” ini files to the proper location during MDT sequence steps?
2. Lite touch is a build methodology. i.e. you launch the task sequence and then don’t touch the target computer until you sysprep. Everything is installed and configured as part of a task sequence. Its not possible to do this 100%, but you can get pretty close.
3. I have a standard unattend.xml file for our builds, I started with an online unattend xml generator [http://www.windowsafg.com/] to create a generic unattend file. Then we updated it (by hand and via WAIK) to have the features we needed in the target system. I have a task sequence in MDT that copies files to the target system that we will need later. Three of the important files are the unattend.xml, setupcomplete.cmd, and a batch file called sysprepper.cmd. We use that sysprepper.cmd batch file to copy the unattend.xml and setupcomplete.cmd files to their proper locations as well as several other config files, then call sysprep with the /shutdown option. Then we pxe boot and capture with FOG. Understand this is not the unattend.xml that is used to build the MDT image (what you would edit in MDT/WAIK), but this is the unattend.xml file that is used during sysprep and OOBE after the image has been cloned by FOG.