How to use FOG to supply machine specific drivers for Windows 7 Sysprepped machines
-
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]
-
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?
-
Ahhh okay. Good! I’m glad you got it all worked out. Sorry I couldn’t have been more help, haha.
-
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/testmachineso actually dvlsg you have helped ALOT! thanks for all your help
-
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.
-
[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.
-
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.
-
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.
-
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.
-
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.
-
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
drive to the location above.[/COLOR][/FONT] -
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.
-
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.
-
[quote=“Andrew Single, post: 38543, member: 1006”]Additionally, people could collaborate & build beautiful driver repositories together.[/quote]
something like [url]http://driverpacks.net/[/url] ?
-
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.
