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



  • Scenario:
    -We want to build a universal Windows 7 Image that can be used on all systems we service in our School Division. (Dell Optiplex, Latitude, and some Vostro systems.)

    Challenges:
    -Machines must be sysprepped to obtain unique UUID’s to prevent issues with KMS.
    -Using a gigantic driver store on the image from audit mode increases image size, and some drivers are incompatible between models (Ie: The touch screen driver for the 2100/2110 is not compatible with the 2120, yet the 2120 detects the 2100 driver as the correct one. This also happens with some audio drivers.)
    -To update drivers, or add another model to the Image, you need to rebuild the image.
    -If you create a network driver store, it’s difficult to integrate into the sysprep process, and if the NIC drivers are missing, the network store can’t be accessed.

    Solution:
    -Have FOG identify the model based on the WIM information, and copy a Model specific driver folder to C:\drivers.
    -Build the sysprepped image specifying C:\drivers as an additional driver search path.

    I’m going to add content to the fog script in the init.gz to, if it’s a Windows 7 image, grab the Machine model, look for a matching folder on /images/drivers/MachineType, and if it exists, mount the NTFS partition, and copy that folder to C:\drivers. Then, when the sysprep drivers stage runs, it will pull the correct drivers.

    I looked through the scripts, and I couldn’t find anything like this that had been done. I want to do this in a way that will be easily brought into FOG for everyone. Does anyone see any problems with what I’m proposing?



  • Somewhat like that, but organized in such a way that FOG can automatically inject the correct drivers into the firstboot process. If I were to use the Driverpacks, I’d need to build a database linking device IDs to folder structure, and that complicates the script significantly.


  • Developer

    [quote=“Andrew Single, post: 38543, member: 1006”]Additionally, people could collaborate & build beautiful driver repositories together.[/quote]

    something like [url]http://driverpacks.net/[/url] ?



  • Heads up: I’ve got an updated version of this script written for the new FOG using the postdownloadscripts folder.

    We’re also changing the method for things from being model specific, to actually checking the PCI & USB device ID’s & pulling the exact driver required. That way, when we get a new model, most of the drivers are already there, and it’s just a matter of adding one or 2 new devices.

    Additionally, people could collaborate & build beautiful driver repositories together. Someone new to FOG can come in, sync a driver folder via public rsync, and BAM, sexy driver auto installs.



  • Good stuff. I do a similar thing, but I implemented the logic outside of FOG. Basically, I have scripts run post image that determine which software/drivers need to be run.

    I think I like the way you have FOG doing it better, though. Probably requires way fewer lines of code, haha. Sadly, I have to deal with specific installations based off of AD queries, so it made sense to wrap all that up in vbs instead.



  • Nice work guys. I haven’t been by the forums in a while, and I noticed this thread was resurrected. The other thing we’re doing now with the auto driver install is addressing drivers that are installables, but not windows drivers in the technical sense. For example, a touchscreen calibration tool. It’s something you need on certain models, but don’t want on everything. Certain Dell models have an internal speaker that doesn’t work without a helper system tray program installed, etc.

    We have the auto driver install also copy a script for each model that launches those types of programs post setup. That way you install those machine specific programs without having to make a specific image.

    [url]http://technet.microsoft.com/en-us/library/dd744268(v=ws.10).aspx[/url]

    You can add [FONT=Segoe UI][COLOR=#000000]%WINDIR%\Setup\Scripts\SetupComplete.cmd to your image, and windows 7 sysprep will launch that at the end of the setup process. Just add a copy command that sends your model specific setupcomplete.cmd to the C: drive to the location above.[/COLOR][/FONT]



  • Oh, I suppose I should also note that I use the Dell Driver cabs, but I also run them through Microsoft’s deployment workbench from the MDT by importing them as out-of-box drivers to my non-functional deployment share, and then I copy them from the folder structure (\DeploymentShare$\Out-Of-Box Drivers*.*) to the FOG server.

    I wonder if that would resolve the unsigned driver issue. It seems to format the structure of the files in the cab to a structure that looks similar to \Windows\System32\DriverStore\FileRepository

    As a side note, if you have to use a computer that doesn’t have a nice manufacturer that wraps all the drivers up in a cab like Dell does, you can use the MDT to pull drivers directly from the FileRepository from a computer that has already been set up.



  • Yeah, a lot of people I talk to are starting to move away from the unattend.xml approach, since it’s [I]technically[/I] not necessary. I prefer to have as clean of an image as I can though, so I still use it. That <DriverPaths> code is embedded in the <settings pass=“windowsPE”> by the way.

    Ah, yeah that would make sense. We get all laptops, and our oldest model floating around is in the Latitude E6400 series, which really isn’t that old. We also only deploy Windows 7 - not sure how Windows XP would handle using the unattend.xml.



  • That is nice, I like the unattend.xml approach better than modifying the registry.

    (Taking notes for next FOG hacking session.)

    I actually had a lot of unsigned drivers from Dell, using their [URL=‘http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-driver-cab-files-for-enterprise-client-os-deployment.aspx’]system cabs[/URL], but that might be because we have a lot of older models.



  • Ahh okay. I haven’t run into any issues with unsigned drivers. I found that adding this to my unattend.xml was enough (I have the script copying the relevant drivers to c:\drivers and then some vbs down along the line cleaning it up) –

    <DriverPaths>
    <PathAndCredentials wcm:action=“add” wcm:keyValue=“1”>
    <Path>C:\Drivers</Path>
    </PathAndCredentials>
    </DriverPaths>

    But the only machines I have to deploy to are Dells. I suspect all of the relevant drivers are signed.



  • [quote=“dvlsg, post: 4971, member: 1186”]Oh that reg bit is interesting too. I like that.
    [/quote]

    I feel that I should tell you I am not really using the same exact approach for driver installation anymore. I do copy the drivers as described in my posts in this thread, and modify the registry to make Windows able to find the new drivers when my generalized sysprepped image start installing devices.

    However, since Windows skips unsigned drivers in this process, it didn’t completely fill my needs. So in addition, I also modify or create a [URL=‘http://technet.microsoft.com/en-us/library/cc766314(v=ws.10).aspx’]SetupComplete.cmd[/URL] script, that amongst other things run dism.exe with the /Add-Driver and /ForceUnsigned switch, for the drivers that are unsigned.



  • I’ve done that quite a few times myself, actually, haha. I’m still not sure what exactly determines whether or not the end of a line requires a semicolon in linux scripting.


  • Developer

    actually, it wasn’t the way i had mounted the ntfs, it was actually because i was adding a ; at the end of these lines when i obviously shouldn’t of!..
    machine="${machine%"${machine##[![:space:]]}"}" #Remove trailing spaces
    ln -s “/images/Drivers/WinXP/${machine}/” /root/mydrivers
    cp -r /root/mydrivers/
    /ntfs/testmachine

    so actually dvlsg you have helped ALOT! thanks for all your help :-D



  • Ahhh okay. Good! I’m glad you got it all worked out. Sorry I couldn’t have been more help, haha.



  • Hmm… Here’s something else I noticed (probably should’ve noticed this earlier… it’s been a long Monday already – trying to do a lot of IT work with some FOG stuff on the side):

    cp -r /images/Drivers/WinXP/[B]"[/B]{$machine}[B]"[/B]/* /ntfs/WINDOWS/TestDrivers;

    I noticed that you sometimes have quotes around {$machine} in your code, but in the code I got to work, the quotes went around the whole directory, like this:

    cp -r [B]"[/B]/images/Drivers/WinXP/{$machine}/*[B]"[/B] /ntfs/WINDOWS/TestDrivers;

    Maybe that’s the cause of the problem, if they’re still there?


  • Developer

    t’s worked! it’s worked!!! i hadn’t upload the change fog but thankyou! it was the way i was mounting ntfs by the looks of things because where i was putting the code ntfs was already mounted but i had it mounted as: [B]mount.ntfs-3g $part /ntfs [/B]but should of been: [B]ntfs-3g -o force,rw $part /ntfs[/B]



  • Ah. I think I have it figured out – one more check quick, just to verify (I’ll get back to you as soon as I get a chance).

    [I]Edit:[/I] Sort of good to go on my end… It actually ends up creating a file named “machinetest” instead of a folder. Maybe I didn’t have my file structure quite right on the server. Maybe someone else has more insight. But it seems to be finding $machine, since it’s not erroring out and saying the “Latitude E6510” folder doesn’t exist. Here’s all the relevant code:

    Note: I don’t know much about links, but I believe the bolded part of the code below is important: my suggestion would be try to copy it that way if you haven’t already.

    Other notes: Testing with a Latitude E6510, relevant folder on the FOG server is /images/Latitude E6510. Permissions are 777 and root:root. c:\machinetest does [I]not[/I] exist on the test computer, but is created through this script. /root/mydrivers also does [I]not[/I] exist pre-function, but is a

    [FONT=Calibri] machine=dmidecode -s system-product-name;[/FONT]
    [FONT=Calibri] machine="${machine%"${machine##[![:space:]]}"}" #Remove trailing spaces[/FONT]
    [FONT=Calibri] echo " “;[/FONT]
    [FONT=Calibri] echo " * FOG Scripts Copy for $machine”;[/FONT]
    [FONT=Calibri] echo " ";[/FONT]
    [FONT=Calibri] mkdir /ntfs &>/dev/null[/FONT]
    [FONT=Calibri] if [ “$osid” = “5” ][/FONT]
    [FONT=Calibri] then[/FONT]
    [FONT=Calibri] ntfs-3g -o force,rw $win7sys /ntfs[/FONT]
    [FONT=Calibri] elif [ “$osid” = “1” ][/FONT]
    [FONT=Calibri] then[/FONT]
    [FONT=Calibri] ntfs-3g -o force,rw $part /ntfs[/FONT]
    [FONT=Calibri] fi[/FONT]
    [FONT=Calibri] [B]ln -s “/images/${machine}/” /root/mydrivers[/B][/FONT]
    [FONT=Calibri] cp -r /root/mydrivers/
    /ntfs/machinetest[/FONT]

    [I]Edit #2: [/I]Ah. The only file I had in /images/Latitude E6510 was a file called test.txt that only said “TEST”. I opened c:\machinetest with a text editor and it said “TEST”. FOG must’ve copied the test.txt over and converted it to machinetest. I’m guessing if I had a legitimate folder structure/set of files in my drivers location it would’ve worked fine.



  • I’m running another upload - just got my init changed (work’s been busy). I’ll let you know if I can get it working for me.

    I do have a question for you though (for my own problem): are you by chance using a single partition image, or a multi partition non-resizable?


  • Developer

    anyone who has this working in their funcs.sh/fog could i get a copy just so i can see what’s different to mine?


  • Developer

    Just to rule it out, i got the script to create a new folder and also changed the permission on the drivers folder on the server/node but still no go :-(


Log in to reply
 

361
Online

38982
Users

10712
Topics

101678
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.