Ghost Solution Suite

The scenario:
We're looking at managing large deployments through the Ghost Console using multicast.  We're using Symantec-packaged WinPE as the preinstall-environment (which weighs-in at around +100 MB).  The target workstations would be in an active windows-XP session when the multicast-task is initiated on the console.

At initiation, the pre-OS environment is sent to the target workstations, followed by a reboot of the systems into WinPE.

My Question:
Is the pre-OS virtual partition multicasted to the clients as well (while the targets are still in WinXP), or is this essentially a single-threaded copy operation to each target workstation?

The reason this is important to us:
If the pre-OS is multicasted to the targets, then it's only 100MB of network traffic - and a light-load on the server.  If it's single-threaded to 85 targets, then its essentially 8.5GB on the network and thrashes the server HD.

Your assistance / expertise is welcome - thanks for any help!
Arthur

> Is the pre-OS virtual partition multicasted to the clients

Not in normal task execution, no; the PreOS files are replicated to the clients over TCP. A master image that contained a GSS2.5 client would also end up containing the WinPE PreOS files, so the replication down of the large WinPE PreOS is usually a one-time thing.

The folder copy feature in the console shares code with the PreOS transfer (it also uses TCP and determines on the fly with each file and each client whether it needs to do the copy at all). It's only the transfer of a single individual file in the "Software and File Actions" section of task execution which can do multicast transfer, and because of the way Ghost's multicast protocol works that transfer is unconditional and every client receives the file it whether it has it already has it or not.

> is this essentially a single-threaded copy operation to each target workstation?

It's a unicast copy to each workstation that doesn't have the PreOS, but it's not single-threaded at the server end (it can serve quite a few concurrently, and should be able to use most of the available upstream link bandwidth).

> its essentially 8.5GB on the network

Yes, for that one initial copy - although how important that is depends on your network design, since modern Gigabit switched Ethernet is completely point-to-point. For a purely Ethernet network it's generally only the GSS server's outbound link and any interposing routers which would be impacted by that load, since even modern consumer-grade switches have more point-to-point switching capacity than the sum of all their links.

What might be possible if you did have some low-capacity routed links between your server and some clients that you were particularly concerned about, then you could hand-optimize this by transferring out (using the "Software and File Actions" task section) the individual WinPE .WIM file to the location the automatic transfer would use, to pre-seed the clients on the remote subnets.

> and thrashes the server HD.

In practice, that isn't what we see - it would only happen for servers with very small amounts of RAM. During multi-client operations the PreOS WIM file ends up being cached quite effectively by the server OS.

Hi Nigel -

Thanks for the detailed answer - this is what I was looking for.  Many of the locations that we'll be using this service utilize switched-LRE network (hub & spoke, effectively 3-5mbps); we're using a well-equipped desktop system as the server.

To be sure that I understand: If the virtual partition already exists on a target PC, then it does not get re-copied during an image deployment task (though I'm sure there's some validation that local copy matches the console's copy)?

We had intended to deploy the Ghost Client (not the pre-os vmdk) to the target workstations (running the old OS) prior to issuing the reimage-command task; can we also copy out the pre-OS files (via an SMS package?) and avoid the single 'big bang' deployment (is this what you meant by hand-optimizing)?  If so, which files are needed to make the pre-OS work?  I see the the VIRTPART.VMDK and the VIRTPART.DAT at the root of 'C' - are there other files that need to be included in a SMS-package for the Ghost client to 'see' this as a legitimate boot environment (and avoid the copy-down) - assuming that the client has already 'registered' against the server-console?

Thanks again - I appreciate your response!

Arthur

> If the virtual partition already exists on a target PC, then it does not get re-copied during an image deployment task

Actually, the *virtual partition* is a file containing a filesystem that is always recreated from scratch when entering the pre-OS, according to a script. That script (and the files it puts into the virtual partition, such as BOOT.WIM) are the things that don't get re-copied each time, but which live as regular files in the client OS.

The different managed PreOS files you can select in the console live in C:\Documents and Settings\All Users\Application Data\Symantec\Ghost\Template\Common - this is the same place that the Ghost Boot Wizard gets the PreOSes to make boot media. There are up to 3 managed PreOSes available, the two classic ones PCDOS and MSDOS, and the new one in GSS2.5 - WinPE. Each lives in its own subdirectory containing a file called manifest.txt which identifies the subdirectory as a console managed PreOS and that manifest.txt file is a script that is used by the managed client to build the virtual partition for that PreOS.

Depending on which PreOS you use with a client, the entire subdirectory for it is copied to the managed client into a subdirectory of the same name under the client's "Incoming" directory. So, if you use WinPE as the PreOS, the PreOS source files are checked to ensure they are the same as the server versions, and if not they are copied to C:\Program Files\Symantec\Ghost\incoming\winpe

[ The DOS PreOSes contain additional copy steps to include the relevant DOS network drivers that the server has tried to detect as a match for the client's hardware as well ]

> though I'm sure there's some validation that local copy matches the console's copy

Yes. As part of the task processsing both for the PreOS files and for folder copy task steps under the "Software and File Actions"section, the contents are checked at each end to work out what needs to be done.

>  I see the the VIRTPART.VMDK and the VIRTPART.DAT at the root of 'C'

Those are the files that hold the virtual partition, and those are re-built from scratch every time depending on what PreOS the client has chosen for it and various other settings. The files copied into it are mostly taken from the appropriate pre-OS subdirectory in C:\Program Files\Symantec\Ghost\Incoming\ - for the Windows PE PreOS, almost all the size is in one file: WinPE\Sources\BOOT.WIM, so you just need to ensure that file is copied to C:\Program Files\Symantec\Ghost\Incoming\WinPE\Sources\BOOT.WIM after the client agent is installed and that should accelerate the very first time you run a task that enters the PreOS.

Nigel -

Thanks again!  This gives us the information we need to move forward with our deployment.

Regards,
Arthur