• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

    How to use FOG to supply machine specific drivers for Windows 7 Sysprepped machines

    Scheduled Pinned Locked Moved
    General
    8
    56
    31.3k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      ssx4life
      last edited by

      To pile on here you can also modify the SAD2 script to push only the OEM drivers that came with the pc. I’ve done this for several models.

      Simply use method 2 for the driver installation and make a new folder called D / 3 / YOUR DRIVER FOLDER HERE.

      Simply copy the oem drivers from an untouched / factory image pc for windows 7 and drop them there. Then use SFX Maker to encapsulate the SAD2 script, and have it auto run the .cmd upon execution.

      Now simply use a the .exe as a snapin so you push windows 7 with minimal drivers, and push only the specific drivers for that model to the unit.

      It cuts down on overall windows image size, speeds up imaging and deployment, etc.

      Again, use method ONE for this. I’ve copied and pasted the readme.txt file. Let me know if you need more help. You are basically not using the pre-built driverpacks and building your own based off of your office / work setting.

      [LEFT][I]What goes where?[/I][/LEFT]
      [LEFT] [/LEFT]
      [LEFT][I]NT5\x86[/I][/LEFT]
      [LEFT][I]-Method-1: Use DriverPacks BASE to create a Method-1 SAD disc selecting the packs you want to include. By default, the folder “DriverPacks.net” will be created in C:.[/I][/LEFT]
      [LEFT][I]Copy the contents of that DriverPacks.net folder to this folder so that the folder heirarchy looks like this: \NT5\x86\D.[/I][/LEFT]
      [LEFT][I]-Method-2 (preferred): 32-bit Win XP/2000/2003 DriverPacks go here in their compressed state. An empty “Example” DriverPack is included for reference. Method 2 will fail if the \NT5\x86\D\ folder exists here, only .7z packs must be present.[/I][/LEFT]
      [LEFT] [/LEFT]
      [LEFT] [/LEFT]
      [LEFT][I]NT6\x64[/I][/LEFT]
      [LEFT][I]-Method-1: Extract the contents of all DriverPacks to the NT6\x64\D\ folder so that the folder heirarchy looks like this: \NT6\x64\D*. Method 1 will fail if the \NT6\x64\ folder contains any .7z DriverPacks.[/I][/LEFT]
      [LEFT][I]-Method-2 (preferred): 64-bit Vista/Win7 DriverPacks go here in their compressed state. An empty “Example” DriverPack is included for reference. Method 2 will fail if the \NT6\x64\D\ folder exists here, only .7z packs must be present.[/I][/LEFT]
      [LEFT] [/LEFT]
      [LEFT][I]NT6\x86[/I][/LEFT]
      [LEFT][I]-Method-1: Extract the contents of all DriverPacks to the NT6\x86\D\ folder so that the folder heirarchy looks like this: \NT6\x86\D*. Method 1 will fail if the \NT6\x86\ folder contains any .7z DriverPacks.[/I][/LEFT]
      [LEFT][I]-Method-2 (preferred): 32-bit Vista/Win7 DriverPacks go here in their compressed state. An empty “Example” DriverPack is included for reference. Method 2 will fail if the \NT6\x86\D\ folder exists here, only .7z packs must be present.[/I][/LEFT]

      1 Reply Last reply Reply Quote 0
      • A
        Andrew Single
        last edited by

        Hey SSX, long time no chat. I wanted to avoid this approach. The problems are this:
        -You must include the NIC drivers for any systems that Win 7 doesn’t natively have. That means when a new model of computer comes in, if it doesn’t have the NIC driver, you need to build a new image.
        -If you include the driverpacks on the image itself, you’re increasing image size, and you have to update your image to update drivers.

        I’ve done up a proof of concept script, and it’s working. I’ve cleaned it up, and added it as a function on funcs.sh. I’m doing some more testing, then I’ll post it here. My goal is to build a mechanism in FOG to simply create a giant driver repository, with a GUI to manage it, maybe even tie it in to driverpacks now that I’ve seen that. Then, as part of the post imaging process, after it extends the NTFS partition, it copies over the machine specific drivers before first boot.

        1 Reply Last reply Reply Quote 0
        • S
          ssx4life
          last edited by

          My above statement doesn’t include any drivers into the windows installation, my suggestion was to build a snapin for post imaging that is pushed to the client computer after it has gone through the preboot / sysprep process.

          you are correct on the NIC drivers and future models however. There is no quick and easy solution to this, other than have your windows 7 images be built in a VM that you can quickly snapshot to, and re-upload to the fog server.

          1 Reply Last reply Reply Quote 0
          • F
            Fernando Gietz Developer
            last edited by

            Really, I don’t understand very well. Both methods of deployment are unicast.
            If you use a snapin to deploy or inject the drivers, the deploy time increases.

            • deployment + sysprep process + FOG client connects with the server (~5 minutes) + deploy snapin [unicast process] + run SAD
              If you use a Andrew’s method
              *deployment + deploy driverPack (mount a temp folder, mount NFS , download uncompressed model’s drivers [unicast process]) + sysprep

            If you put the driverPack into the image, the driverPack’s deployment is multicast process.

            • deployment + sysprep process + run SAD
              My driverPack’s size is 84 MB for HP7700, HP7800,HP7900, HP8200, DELL GX620, DELL Optiplex 745, DELL Optiplex 755, DELL Optiplex 760 and DELL Optiplex 780.
            1 Reply Last reply Reply Quote 0
            • S
              ssx4life
              last edited by

              I’m using a modified snapinclient.dll so it checks in after 20 seconds. [url]http://fogproject.org/forum/threads/how-to-modify-your-snapinclient-dll-file-to-check-in-more-quickly-on-a-reboot.613/[/url]

              The real benefit of having the drivers be OUTSIDE of the base image, and why I mentioned it is because Andrew is running into issues with some model computers getting the wrong drivers due to them having similar hardware.

              If you separate the drivers from the base OS it gives you the flexibility to add new driver models quickly, the only issue comes in again if you have a NIC that isn’t supported. This would require you to either rebuild your OS image or manually install the driver and continue on with the standard imaging process.

              As far as storage size it also cuts down on it due to only pushing the drivers specifically needed for that model. It’s not the best solution, but again I’m trying to find a solution for him based off of his issues with the wrong model getting the wrong driver, this alleviates that.

              I was just trying to think outside the box for a solution on this one.

              I personally am using this method for Windows XP, but for Windows 7 we have the drivers as part of the image.

              The benefit of having them be part of the image again is that they are all auto run and found during installation. I just need to make sure my windows 7 images are built virtually so I can go back into auto mode and add / modify the drivers based off of future hardware.

              1 Reply Last reply Reply Quote 0
              • A
                Andrew Single
                last edited by

                Added function copyDrivers() to funcs.sh:

                copyDrivers()
                {
                machine=dmidecode -s system-product-name;
                machine2=${machine// /};
                echo " “;
                echo " * FOG Driver copy for $machine”;
                echo " ";

                mkdir /ntfs 2>/dev/null

                echo -n " * Mounting Windows File System…“;
                mount.ntfs-3g $win7sys /ntfs 2>/tmp/mntfail
                mntRet=”$?";
                if [ ! “$mntRet” = “0” ]
                then
                echo “Failed to mount C:”;
                echo " ";
                echo -n " * ";
                cat /tmp/mntfail
                echo “”;
                sleep 5;
                else #Mount successful
                echo “Done.”;

                mkdir /ntfs/Drivers 2>/dev/null
                echo " “;
                echo -n " * Copying Common Drivers…”;
                cp -r /images/drivers/Common /ntfs/Drivers
                echo “Done.”;
                echo -n " * Copying $machine Drivers…";
                cp -r /images/drivers/${machine// /} /ntfs/Drivers
                echo “Done.”;
                echo " “;
                echo " * Driver copy completed.”;
                sleep 2;
                fi
                }

                (Sorry about the formatting, the tabs got eaten)

                I have FOG triggering this function after the Disk Cleanup stage, where it does the NTFS extend. It’s then copying drivers from /images/drivers/Common, and then /images/drivers/Optiplex745 (Or whatever model it pulls)

                The real reason for doing it this way, is that you can include the network driver for a new model that’s not in Win 7 in the driver folder for that model, and just go image it without having to worry about building a new base image. There’s also no scripts running post sysprep, it’s all done via the windows sysprep process. With a GUI for driver management, and the community sharing model specific driver packs, I think this would really add to the complete usefulness of FOG.

                We’re going to setup a core FOG server with the drivers folder, then rsync to each of our 42 schools. A big benefit for us, is that because we won’t be building a new base image very often now, it’s easier to keep all our school images up to date. New drivers popping in from rsync will happen automatically & quickly, even on some of our slow links. We’d only rarely have to pull down a new 10-15 gig image

                1 Reply Last reply Reply Quote 0
                • A
                  Andrew Single
                  last edited by

                  Fernando: You don’t run into issues with Dell Optiplex pulling the wrong audio driver?

                  1 Reply Last reply Reply Quote 0
                  • F
                    Fernando Gietz Developer
                    last edited by

                    [quote=“Andrew Single, post: 3131, member: 1006”]Fernando: You don’t run into issues with Dell Optiplex pulling the wrong audio driver?[/quote]
                    No. At least we have not had any problems with Optiplex. No one has reported anything 🙂 , and we use these models for years.
                    But we don’t use sysprep to deploy this model’s images. I have test the SAD method and my 3rd party DrivePack, and works fine, but in laboratory, not in producction environment.

                    Which are your issues?

                    1 Reply Last reply Reply Quote 0
                    • F
                      Fernando Gietz Developer
                      last edited by

                      Andrew: We tested a similar solution. The script is saved in the database (you write it in the WEBUI in a text area, and fog saved it via form), and the fog script accesses it from a web service after deploy process, before restart PC.

                      If you want to test the driverPack, I can share it.

                      1 Reply Last reply Reply Quote 0
                      • B
                        boon
                        last edited by

                        F[quote=“Fernando Gietz, post: 3144, member: 13”]Andrew: We tested a similar solution. The script is saved in the database (you write it in the WEBUI in a text area, and fog saved it via form), and the fog script accesses it from a web service after deploy process, before restart PC.

                        If you want to test the driverPack, I can share it.[/quote]
                        Fernando, I’d love to test your driverpack/script. I deal with many of the same model workstations in our environment.

                        1 Reply Last reply Reply Quote 0
                        • F
                          Fernando Gietz Developer
                          last edited by

                          [quote=“boon, post: 3244, member: 833”]F
                          Fernando, I’d love to test your driverpack/script. I deal with many of the same model workstations in our environment.[/quote]
                          You can download the driverpack from [URL=‘http://www.ehu.es/fogenehu/download/driverpack/softpack.7z’]here[/URL].
                          I call to DP_Tools from runonce.cmd script. You must uncompress the .7z file in c:\drivers folder, and post-sysprep call to runonce.cmd script.

                          1 Reply Last reply Reply Quote 0
                          • B
                            boon
                            last edited by

                            [quote=“Fernando Gietz, post: 3253, member: 13”]You can download the driverpack from [URL=‘http://www.ehu.es/fogenehu/download/driverpack/softpack.7z’]here[/URL].
                            I call to DP_Tools from runonce.cmd script. You must uncompress the .7z file in c:\drivers folder, and post-sysprep call to runonce.cmd script.[/quote]
                            How do you avoid the Found New Hardware Wizard? It seems this causes the DPInst process to hang until all New Hardware Detected windows are closed.

                            Thanks again for all of your help.

                            1 Reply Last reply Reply Quote 0
                            • F
                              Fernando Gietz Developer
                              last edited by

                              You are right. You need suppress the Found New Hardware Wizard.
                              To do it, in XP 32 bits:
                              [QUOTE]
                              [I]To fix the issue in Windows XP 32-bit versions, add a DWORD value that is named “SuppressNewHWUI” to the following registry subkey: [/I]
                              [I] HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceInstall\Settings [/I]
                              [I] To configure this registry setting, follow these steps: [/I]
                              [LIST=1]
                              [][I]Click [B]Start[/B], click [B]Run[/B], type regedit, and then click [B]OK[/B].[/I]
                              [
                              ][I]Locate the following subkey in the registry, and then click it: [/I]
                              [I] HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceInstall\Settings [/I]
                              [][I]On the [B]Edit[/B] menu, point to [B]New[/B], and then click [B]DWORD Value[/B]. [/I]
                              [
                              ][I]Type SuppressNewHWUI for the name of the DWORD entry, and then press [B]ENTER[/B].[/I]
                              [][I]Right-click [B]SuppressNewHWUI[/B], and then click [B]Modify[/B]. [/I]
                              [
                              ][I]Do one of the following: [/I]
                              [LIST]
                              [][I]To suppress messages, type 1 in the [B]Value data[/B] box, and then click [B]OK[/B].[/I]
                              [
                              ][I]To stop suppressing messages, type 0 in the [B]Value data[/B] box, and then click [B]OK[/B].[/I]
                              [/LIST]
                              [*][I]Exit Registry Editor, and then restart the computer. [/I]

                              [I][B]Note[/B] The setting does not take effect until the computer is restarted.[/I][/LIST][/QUOTE][LIST=1]
                              [/LIST]
                              To see all microsoft article, [URL=‘http://support.microsoft.com/kb/938596/en-us’]here[/URL]

                              1 Reply Last reply Reply Quote 0
                              • B
                                Bjorn Jentoft
                                last edited by

                                I really liked Andrew’s idea of copying machine specific drivers.

                                I changed his script slightly and incorporated it with some other changes I have done to funcs.sh

                                [quote=“Andrew Single, post: 3130, member: 1006”]

                                machine=dmidecode -s system-product-name;
                                machine2=${machine// /};
                                …
                                echo -n " * Copying $machine Drivers…";
                                cp -r /images/drivers/${machine// /} /ntfs/Drivers

                                [/quote]

                                Became

                                [CODE]machine=dmidecode -s system-product-name;
                                machine=“${machine%”${machine##[![:space:]]}“}” # Remove trailing whitespace
                                ln -s “/images/drivers/${machine}/” /root/mydrivers
                                …
                                echo -n " * Copying $machine Drivers…";
                                cp -r /root/mydrivers/
                                /ntfs/Drivers
                                [/CODE]

                                The symbolic link is just a simple way to overcome the space-in-path-names problem, so I can have folder names just as they appear under “System Product” in the FOG hardware inventory.

                                Bjorn

                                1 Reply Last reply Reply Quote 0
                                • D
                                  dvlsg
                                  last edited by

                                  Solid solution. I like it.

                                  [quote=“Andrew Single, post: 3130, member: 1006”]
                                  I have FOG triggering this function after the Disk Cleanup stage, where it does the NTFS extend. It’s then copying drivers from /images/drivers/Common, and then /images/drivers/Optiplex745 (Or whatever model it pulls)
                                  [/quote]

                                  I know this is a bit of a thread resurrection, but if you still check this thread, could you quickly walk us through how to set up the script so FOG automatically kicks it off? I’m sure I could figure out the syntax, but I’m not sure where to look.

                                  1 Reply Last reply Reply Quote 0
                                  • B
                                    Bjorn Jentoft
                                    last edited by

                                    In order to make use of Andrew’s modification, you start by [URL=‘http://www.fogproject.org/wiki/index.php/Modifying_the_Init_Image’]modifying the init image[/URL]. The modifications you want to do is as follows:

                                    Edit the file initmountdir/bin/fog (path as in wiki link above), and add a call to the new function. I added it just before the call to changeHostname() around line 606, like this:
                                    [CODE]…
                                    if [ “$capone” != “1” ]; then

                                                    copyDrivers    #Copy machine specific drivers
                                                    changeHostname
                                    

                                    …[/CODE]

                                    Then, you add the function to the file initmountdir/usr/share/fog/lib/funcs.sh, somewhere in the file, i put it at the very end:
                                    [CODE]copyDrivers()
                                    {
                                    machine=dmidecode -s system-product-name;
                                    machine=“${machine%”${machine##[![:space:]]}“}” #Remove trailing spaces
                                    echo " “;
                                    echo " * FOG Driver copy for $machine”;
                                    echo " “;
                                    mkdir /ntfs &>/dev/null
                                    if [ “$osid” = “5” ]
                                    then
                                    ntfs-3g -o force,rw $win7sys /ntfs
                                    elif [ “$osid” = “1” ]
                                    then
                                    ntfs-3g -o force,rw $part /ntfs
                                    fi
                                    ln -s “/images/drivers/${machine}/” /root/mydrivers
                                    mkdir /ntfs/Drivers >/dev/null
                                    echo -n " * Copying Common Drivers…”;
                                    cp -r /images/drivers/Common/
                                    /ntfs/Drivers
                                    echo “Done.”;
                                    echo -n " * Copying $machine Drivers…";
                                    cp -r /root/mydrivers/* /ntfs/Drivers
                                    umount /ntfs
                                    echo “Done.”;
                                    echo " “;
                                    echo " * Driver copy completed.”;
                                    sleep 2;
                                    }[/CODE]

                                    Follow the wiki link on how to save the modified init back into place.

                                    Then you add your drivers to your fog server, placing them under /images/drivers/<product name>, and modify your Windows 7 image, so that it [URL=‘http://support.microsoft.com/kb/254078’]looks for new drivers[/URL] under C:\Drivers (use the registry mod, adding the path to
                                    [LEFT][FONT=Segoe UI][COLOR=#333333]HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\DevicePath.)[/COLOR][/FONT][/LEFT]

                                    1 Reply Last reply Reply Quote 0
                                    • B
                                      Bjorn Jentoft
                                      last edited by

                                      This post is deleted!
                                      1 Reply Last reply Reply Quote 0
                                      • B
                                        Bjorn Jentoft
                                        last edited by

                                        If you are lazy, like me, you can let FOG change the registry setting in your images, so you don’t have to create new ones. Then the function should look like this:

                                        [CODE]copyDrivers()
                                        {
                                        machine=dmidecode -s system-product-name;
                                        machine=“${machine%”${machine##[![:space:]]}“}” #Remove trailing spaces
                                        echo " “;
                                        echo " * FOG Driver copy for $machine”;
                                        echo " “;
                                        mkdir /ntfs &>/dev/null
                                        if [ “$osid” = “5” ]
                                        then
                                        ntfs-3g -o force,rw $win7sys /ntfs
                                        elif [ “$osid” = “1” ]
                                        then
                                        ntfs-3g -o force,rw $part /ntfs
                                        fi
                                        ln -s “/images/drivers/${machine}/” /root/mydrivers
                                        mkdir /ntfs/Drivers >/dev/null
                                        echo -n " * Copying Common Drivers…”;
                                        cp -r /images/drivers/Common/
                                        /ntfs/Drivers
                                        echo “Done.”;
                                        echo -n " * Copying $machine Drivers…";
                                        cp -r /root/mydrivers/* /ntfs/Drivers

                                        regfile="/ntfs/Windows/System32/config/SOFTWARE"
                                        key1="\Microsoft\Windows\CurrentVersion\DevicePath"
                                        devicepath="%SystemRoot%\inf;C:\Drivers"
                                        reged -e "$regfile" &>/dev/null  <<EOFREG
                                        

                                        ed $key1
                                        $devicepath
                                        q
                                        y
                                        EOFREG

                                        umount /ntfs
                                        echo "Done.";
                                        echo " ";
                                        echo " * Driver copy completed.";
                                        sleep 2;
                                        

                                        }[/CODE]

                                        1 Reply Last reply Reply Quote 0
                                        • D
                                          dvlsg
                                          last edited by

                                          Oh that reg bit is interesting too. I like that.

                                          I actually currently have all the drivers saved locally to c:\drivers on my image, and the reg pointed in the right direction. What I was really interested in was using that script, but instead of copying drivers over, copying over some scripts to silently set up the computer post-image. I currently have the scripts located on the image, but it seems a bit ridiculous to take the hours to update the VM, take a snapshot of it, copy the scripts over, seal it up, and reupload it when I could just use this fantastic bit of code to push the scripts to my FOG server, have it upload them to the newly imaged computer, and be done with it.

                                          1 Reply Last reply Reply Quote 0
                                          • D
                                            dvlsg
                                            last edited by

                                            Here’s another question for you: is there a way to pull drivers/scripts/whatever off of a network drive or shared drive?

                                            My FOG server is currently in a guest VM with the host’s hard drive mounted as /media/localshare. What I would like to do is have the script also kick off this command:

                                            cp -r /media/localshare/scripts/* /images/scripts

                                            to make sure the scripts being pushed are the most recent, without having to log in to the VM and run that command by hand every time I make an update to them. Will I have to re-mount the network drive inside of the FOG script, even though the drive is always mounted on the FOG server? (my first thought was to use ln -s to make a link to the network drive, but that didn’t work for me either).

                                            1 Reply Last reply Reply Quote 0
                                            • 1
                                            • 2
                                            • 3
                                            • 1 / 3
                                            • First post
                                              Last post

                                            194

                                            Online

                                            12.0k

                                            Users

                                            17.3k

                                            Topics

                                            155.2k

                                            Posts
                                            Copyright © 2012-2024 FOG Project