[blinkdt]

My compliments to all for maintaining their composure throughout this thread. On topic, has anyone looked at Acronis True Image Enterprise Server for this task? It is a great tool and can be used to save an image file on a server for later deployment.

[nivlacckw]

Mordac85, on Jul 11 2006, 09:26 AM, said:

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.

Agree with this. Identify GUID issues for add on apps is far much more complicated than dealing with OS itself when using disk imaging approach. There could be cases that the applications vendors do not provide utility like this Trend example. In general software requires GUID are management agents (SMS client, AV clients, hardware agents etc) and client software that needs to unique indentity to present to the server.

In my company (120k users european bank), we use hybrid approach. Imaging for core OS and more static parts. At the end of imaging , calling for an unattended installation script from network for Windows hotfixs and apps that are frequently updated or having GUID issues. This may not be the fastest solution compare with imaging all apps, however it does provide certain flexibility in managing software in a modular approach within the SOE build without frequently recreate the image.

just my 2 cents

[Mordac85]

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.

[nivlacckw]

Mordac85, on Jul 12 2006, 12:29 AM, said:

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.

In fact, this is easier for beginners to debug the build process as well.

The key sucessful factor is about the design of the build process but not the imaging procduct.

PS. If we going more into details about this, we are moving towards to things like packaging and desktop management 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.

This post has been edited by nivlacckw: 11 July 2006 - 11:08 AM

[IcemanND]

Quote

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.

Mind giving a few details.

[Mordac85]

nivlacckw, on Jul 7 2006, 01:44 AM, said:

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.c.../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!

[IcemanND]

Quote

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

works great if those are the only four HALs you are going to come up against. But I have seen the Standard HAL and ACPI Compatible HALs in my environment which are not addressed by this script. And I have not found a way to modify it for those machines. Though I would really like to just toss those machines in the dumpster, it's not an option.

[nivlacckw]

Mordac85, on Jul 12 2006, 02:42 AM, said:

nivlacckw, on Jul 7 2006, 01:44 AM, said:

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.c.../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!

One of the ideal way to implement this is to write a plugin in BartPE environment to pull the drivers and inf files from the BartPE CD itself and inject to the offline installation. PEbuilder does allow adding mass storage drivers, parses and merges them during the build process. Thus push the driver management effort to the min - this is perhaps the shortcomings in the existing fixscsi plugin.

If a machine managed to boot up with BartPe based CD with disk drives then there must be a mass storage driver within.

I believe there must be some people interested in this as this should help migrating Windows installations across different hardware without reinstall.

BTW, the MS BDD 2.0/2.5 seems using on this process.........

This post has been edited by nivlacckw: 12 July 2006 - 03:15 AM

[nivlacckw]

Post in 911 CD forum to draw Pebuilder's community attention

http://www.911cd.net...showtopic=17752

This post has been edited by nivlacckw: 11 July 2006 - 09:41 PM

[Mordac85]

I started a new topic for discussion of adapting the P2V process here.