The only references I could find were basically one liners admonishing folks to not use Ghost. The closest one is Corporate Soe, but even though it's more detailed, like his post above, it provides no details or specifics. I'll stick w/my hunch that he ran into issues trying to do too much within the image, instead of leaving it for GuiRunOnce or RunOnceEx, and got burned and/or frustrated with the limitations of an image.

@molman Always keep in mind that the image must be generic and anything that would be configured on a per user or per HW type may cause issues. Drivers and the HAL are easy enough to handle. The SID, and other machine identification items are wiped by sysprep.

Let me use TrendMicro AV as an example of the tricky issues you can run into. Using their corporate edition the client is installed, and periodically updated, from a designated server. The problem you run into is your image master (and any other client) is installed w/an identifying GUID on the Trend server. So 1,000 PC's w/the same GUID means only 1 will get the update (Hobson's choice too), remember the base is generic. Never fear, the vendors are aware of their shortcomings and, in this instance, provide a utility to run after the imaged system is online that resets it's GUID. Et Voilà! New system created from your master image w/AV already installed. QED, b/c I've already lost several hair follicles figuring that one out. But that's why these forums are so great. If there is no current solution, you move that to a GuiRunOnce/RunOnceEx item for your post configs.

The hard part is not the OS, it's the customizations and other apps that cause most of the grief, at least for me.

That's exactly what I was trying to illustrate. And you're always going to have those apps that don't handle imaging very well. Scripting the install of a few apps after an image is a small price to pay for the speed you gain over a fully unattended build, imho.

BTW, there is another way to change HAL and mass storage drivers after image has been deployed to the system and inject the HAL/Mass storage drivers to the installation prior the system bring up . So single image for all machines is possible. Reimaging is not necessary for driver updates.

MS Devcon.exe (command line device manager) can be used to check and change HAL.

Inserting mass stroage driver for offline Windows installation is possible and has been implemented in tools for server migration. (eg. Vmware P2V, leostream and helperapps)

There is a free solution which is pebuilder based from the below web.

Ultimate-P2V
http://www.rtfm-ed.co.uk/?page_id=174

Brandon Gordon’s (AKA Notorious_bdg’s “HAL_Update.txt” Plug-in
http://www.rtfm-ed.co.uk/downloads/HAL_Update.txt

Brandon Gordon’s (AKA Notorious_bdg’s “HAL_Update.txt” Plug-in
http://www.rtfm-ed.co.uk/downloads/HAL_Update.txt

I was checking these links out and I think he's talking about changing the HAL with devcon. He's also suggesting adapting the physical to virtual (P2V) change of Mass storage drivers for a newly imaged system instead of a virtual one. So it adds an extra CD change/boot step to the system build process, but it may be worth it in the long run. Pretty novel way of creating your own UIU process, if it doesn't have any latent issues/limitations.

Looks like I have more testing to do!