Build a Corporate SOE in 5weeks - Advice.

[bluescreens]

Use Ghost and I'll guarentee you you will have problems later. I'm speaking from 15 years of experience of corporate support. I am just saying this as a lesson learned: DO NOT USE GHOST TO DEPLOY WINDOWS

I also do not wish to argue this point with the Ghost supporters. I consider them amatures, and they usually just keep making excuses and work-arounds for Ghosts (or any image deployment) shortcommings. They just like to use Ghost because it's easy and they don't have to understand how real deployments work. They don't usually support a large infrastructure. Few of them understand how link-tracking, SSIDS, Registry permissions and default profiles work - all of which are affected by image based deployment.

The problems encountered by users of Ghost deployed images are usually not recognized by the support staff. They chalk up the intermittent application crashes and slow response times to "Windows Bugs" or some such thing.

Again, I do not wish to argue this point again in these forums, you can do a search where I argued this point last year in detail. I just bring this up again because I hate to see image deployed buggy installations give XP a bad reputation because some amature admin doesn't know what the hell he's doing.

Ghost itself is only designed to copy the core image. You need to do some prep work before the core image is ready - including Sysprep and including some other (documented) steps. If you don't do this, or don't completely understand how to do this, yes, there are problems.

If you do do this, though, Sysprep+Ghost works great. You can easily deploy to all PCs no matter what drivers and hardware they have, and Sysprep will intelligently go thru your drivers and pick the right ones, every time. Builds are fast and, with a fast local network, very trouble-free.

That said, with a $3-5 per PC licensing fee and with a monolithic setup (want to update a single driver file for a single PC in your ghost image? You'll need to distribute the full Ghost file to all your sites again, not just the 200-300KB in updates, plus you'll need to rebuild the Ghost file) it's not suited for what I'd call enterprise deployment and a constantly changing enterprise environment. For the OP, though, in all honesty it would probably be good enough.

That's why I like RIS. It's a breeze to update, whether you have 10 servers or 100, and you can push 100KB changefiles out easily. It's very well supported by Microsoft, and you don't need to worry about HAL issues (if Microsoft finds out you forced the HAL on your PCs, they won't support your problems.)

[molman]

Use Ghost and I'll guarentee you you will have problems later. I'm speaking from 15 years of experience of corporate support. I am just saying this as a lesson learned: DO NOT USE GHOST TO DEPLOY WINDOWS

I also do not wish to argue this point with the Ghost supporters. I consider them amatures, and they usually just keep making excuses and work-arounds for Ghosts (or any image deployment) shortcommings. They just like to use Ghost because it's easy and they don't have to understand how real deployments work. They don't usually support a large infrastructure. Few of them understand how link-tracking, SSIDS, Registry permissions and default profiles work - all of which are affected by image based deployment.

The problems encountered by users of Ghost deployed images are usually not recognized by the support staff. They chalk up the intermittent application crashes and slow response times to "Windows Bugs" or some such thing.

Again, I do not wish to argue this point again in these forums, you can do a search where I argued this point last year in detail. I just bring this up again because I hate to see image deployed buggy installations give XP a bad reputation because some amature admin doesn't know what the hell he's doing.

Hi Nois3,

Can you please point me to the thread where you argue why not to use Ghost. I was unable to find it. I'm curious why you would so strongly discourage the use of Ghost when even Microsoft itself seems to advocate its use. What pitfalls am I getting into that I might not be aware of?

The ones I am so far are;

HAL issues

Drivers issues (Esp. for Mass Storage)

Hardware SID

Cheers.

[bluescreens]

Hi Nois3,

Can you please point me to the thread where you argue why not to use Ghost. I was unable to find it. I'm curious why you would so strongly discourage the use of Ghost when even Microsoft itself seems to advocate its use. What pitfalls am I getting into that I might not be aware of?

The ones I am so far are;

HAL issues

Drivers issues (Esp. for Mass Storage)

Hardware SID

Cheers.

Don't use Ghost alone. Use it in conjunction with Sysprep (available by searching for "deployment tools" at Microsoft, and typically in the DOCS directory on the XPSP2 and 2003 CDs you get from vendors). 2003's sysprep works great with XP.

When used correctly with Sysprep and a little bit of knowledge, Ghost is a good tool that cleanly handles driver issues (mass storage included), SIDs, and ... just about everything except HAL issues.

[IcemanND]

I'd like to see that thread also. I've been using Ghost for 8 years and never had a problem caused by ghost.

[Mordac85]

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.

[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]

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]

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.

Edited July 11, 2006 by nivlacckw

[IcemanND]

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]

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

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]

Brandon Gordon’s (AKA Notorious_bdg’s “HAL_Update.txt” Plug-in

http://www.rtfm-ed.co.uk/downloads/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]

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

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.........

B)

Edited July 12, 2006 by nivlacckw

[nivlacckw]

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

http://www.911cd.net/forums//index.php?showtopic=17752

Edited July 12, 2006 by nivlacckw

[Mordac85]

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