Never mind. Not only did I answer my own question, but in the same breath realized that doing it this way would require multiple images, as the driver files are transferred into the image when it is made.  I might be able to make that work by putting ALL of my driver files into the image, but I don't think that's the way I want to go. I'm going to try some different things now and see if I can make it work another way.

Thanks All,
Ryan

have you looked at deploy anywhere?  basically you make an image normally and DA uses a winPE enviroment to detect your hardware and inject only the required drivers into the image before first boot.  its not as fast to deploy this way but its way easier and makes for a smaller image

I don't know if this will help you, but here is what I've been doing.

I have a single image that is loaded via a set of DVDs and a boot script I wrote.  After the image is loaded, the script copies the appropriate drivers onto the fresh image (into C:\Drivers), then copies over a platform-specific sysprep.inf. 

I have not tried this via GhostCast, but if you're using a boot disk, you could do it after the session.

AFA using DeployAnywhere:  my current implementation does both (DA and sysprep.inf).  However, I was just working with Symantec Tech Support on another issue, but he mentioned that I shouldn't need to do both.  Apparently the DA does modify the sysprep.inf, and we were speculating that it was causing the issue I had (note:  it wasn't, because the issue didn't go away when I got rid of the DA).  The way he explained it to me was DA was created for those who did not want to get into the gory details of modifying the sysprep.inf.

Keith

Thanks for the input Keith. It's definitely an option I'll look into if this doesn't work out for me.

Last night before calling it quits for the day, I ran a restore task with DeployAnywhere and a custom Sysprep.inf. The sysprep file contained instructions for installing an audio and video driver. The process completed (though it timed out on the console) and everything worked except for one minor issue. The Microsoft Kernel System Audio Device driver (one of those normally hidden devices) was improperly detected, but a quick uninstall from the device manager seemed to fix the issue. After it was uninstalled, Windows picked it back up and reinstalled it without any problems. I'm not sure if this is related to DeployAnywhere modifying my answer file, or if it was just a fluke.  Further testing is needed.

If DA was created for avoiding modifying the sysprep.inf file, then why aren't more driver options included? I understand network and storage drivers are the absolute minimum that would be required, but there is potential for administrators to save time and hassle by installing all drivers with the imaging process.

Thanks Again,
Ryan

I agree:  I wish DA let you load all the drivers you would need.  I don't like messing around with the sysprep.inf any more than I can help it.  Perhaps a future version will have that feature.

On a side-note:  for some reason (it's been a while, so I don't remember why) I could not get the OemPnpDriversPath to work, so I had to add the drivers path to the registry using GhRegEdit32.  I am currently updating all these scripts, so I may revisit the sysprep.inf method.  The registry setting was in hex, so it was not easy to modify.

I couldn't get OemPnPDriversPath to work either, until I included the UpdateInstalledDrivers command, and after thinking about it it makes sense. Because the OS was already installed on a PC, the devices are also already "installed" even if the drivers weren't. It's a small technicality, but it seems to make all the difference.

This morning I ran the same DA with Sysprep task as last night to try and duplicate my Audio driver issue. I must say I was successful in duplicating it, even though that wasn't the desired outcome.  This time I didn't uninstall the Microsoft Kernel System Audio Device and went to work on something else.  About 5 minutes later, I heard the computer play the windows startup chime (five minutes after logging in, which is what made it really odd), and when I checked on it Windows had self-corrected the device error. The task still times out at the console though.

Keith, Here's what I have ended up using for driver setup in my sysprep.inf:

[Unattended]
;[Display]
;BitsPerPel = 16
;Vrefresh = 60
;Xresolution = 1024
;Yresolution = 768
OemSkipEula = Yes
OemPnPDriversPath = sysprep\Drivers\Audio;sysprep\Drivers\Video
DriverSigningPolicy = ignore
UpdateInstalledDrivers = yes

I've found Microsofts instructions for doing a registry edit where you create driver paths and they get installed at login, If that's what you are talking about.

Thanks,
Ryan

I was searching for some information on hardware independent imaging and came across this:

www.hardware-independent.com

It is from the Ghost people, Binary Research, and their approach to multiple platforms and drivers.

I love DA, but I don't find it very useful for some of those reasons already listed above.

Here's the "bible" for this type of work:   http://unattended.msfn.org/unattended.xp/view/web/1/

there's a lot of great info there about  what you're working on.

Spohcog, UIU is a fantastic peice of software - no question about it. ...but it's not cheap either. I chose to go w/ more of a home-brewed solution utilizing http://driverpacks.net/

everyone should checkout this project (IMO) if you havn't already.

Ryan,

I use this little utility to script my driver path. http://www.vernalex.com/tools/spdrvscn/index.shtml

e.g. c:\sysprep\spdrvscn.exe /p "c:\windows\driverpacks\" /e inf /f /a /s /q

good luck on your universal image quest- it's a challenge.
Cheers,

Thanks mrguitar.  I looked at the driver packs prior to Universal Imaging Utility and you're right about the cost issue.

For me, the driver packs got it part of the way, but I still had issues with occasional machines, chipsets and drivers - really no rhyme or reason.

It comes down to how much time you want to spend vs. getting other things done.

The investment in the UIU eliminated nagging aggravations - even my wife says so!  :-)

Cheers.

If you're still searching for a way to only have one image and one sysprep, I used information found here: http://news.support.veritas.com/connect/articles/h...

As well as a script from microsoft found here: http://technet.microsoft.com/en-us/magazine/2006.0...

I didn't want to standardize my Drivers folder paths, and I didn't want to have to keep more than one sysprep file, so I used the script found at the MS site to add in the Drivers paths into the DevicePath registry key for me after imaging.

To clarify real fast, I image the computer in WinPE environment, I run a script to detect the computer model, based on that model it will copy the drivers for that model from the server share, to C:\Drivers.  I then have the PNPPath script run to edit the DevicePath registry based on the folders in C:\drivers.

Most of the information is in that first link, really helpful.