Ghost Solution Suite

I'm having an issue with Ghost, mainly in that we've been forbidden from running multicasting utilities on our network. This appears to be the method, the only one, by which a Ghost Boot Partition on a client machine locates a Ghost Cast Server. Many of our machines are separated by routers which makes location of the servers impossible when using a Console Boot Partition built with Ghost's creation tool.

Surely there is a method of specifying the IP of the GC server in the boot partition, is there not? When the client machines are manually booted using disks, one of the fields is for the server IP address. When allowed to specify the server address, the software works swimmingly, so the issue is just one of initial server location. I cannot find any method of including this information in the boot partition which reduces the usefulness of GC exponentially. There's not actually much point in using GC if I'm still having to manually boot all of the client machines from floppies/CDs/etc.

Anyone have any thoughts on this matter?

At present, the only alternative method used for the management client (that runs in the boot partition) to locate the configuration server through the use of the WINS protocol set through DHCP options. If the configuration server and the client machines are part of a network with a common WINS server they will be able to locate each other automatically.

We are evaluating adding additional alternative methods for the location of the server to be specified; the main problem so far has been usability, since even if we do add code to allow hardcoded specification of the server address that would impose a fairly large burden on users (and also create exciting new failure modes that make diagnosing connectivity problems harder).

The obvious alternative would be DNS, but that is problematic for many customers for the same reason multicast is - DNS servers are considered part of the network infrastructure in control of central IT departments. Indeed, that same problem exists for fixed IP addresses: central IT departments often make it difficult or impossible for network users to even obtain fixed server IPs.

That is, essentially, the reasoning behind our support for WINS - at the time we developed that alternative, it was the only protocol that customers tended to have already deployed (to support Windows networking) which would not require the active cooperation of a central IT department.

If you had a preference for an ideal method, what would it be given the constraints imposed on you by your particular network?

At our facilities all of our servers have Static IP's. Clients on the other hand are DHCP assigned. We have had many problems with locating a Ghost cast server especially when we have multiple Ghost Servers in a given network. I was supprised that some of the clients even jumped to a different subnet to the other server.

In our facilities our ghost console servers exist only for that subnet.

Mike, thanks for explaining what behavior you've seen on your site. I also noticed that as long as machines were on the same physical subnet/switch, then there were no issues finding the server from the boot partition.

Nigel, thanks for the explanation regarding the server detection methods available to GhostCast. We're currently looking at several options to get around the issues inherent in our network. I will find out if it's possible to enable IGMP on just the routers between the server closet and the various labs we need to image. I don't think there are more than 2 or 3 router hops involved in any instance, so we wouldn't have to enable IGMP building-wide. That should solve the issue if it's allowed. We're also looking at running a restricted WINS server in the building (it's been a non-MS house here for years).

Taking all arguments into consideration, I understand why the multicasting method is the one used by GC as many end techies have no sayso in what happens on or to their networks, such as the difficulty in obtaining fixed IP addresses. Our situation here is one where we are in control of our DHCP servers, but are not allowed full control of the physical routers in the building. Hence, we have no issues on my site in setting IP reservations, although I realize this might not be a common scenario.

My preference for an ideal method of finding the GC server(s) would like be the ability to hardcode the IP address of a GC server into the partition while creating the Console Boot partition with the creation wizard. That way, anytime the machine receives a reboot command that activates the Ghost console boot partition the machine automatically looks only for the defined server. That would also eliminate the initial multicast chatter on the network that occurs when multiple clients are attempting to find a GC server. I didn't know how difficult it would be to hardcode such into the Console Boot partition, as the ability to specify a GC server IP address is functionality that's available when Ghost is booted from floppies or a CD. It seems that being able to specify GC servers by IP address would also be the most scalable method of dealing with server location issues, as it is a method that works regardless of other restrictions allowed on a multitude of different network configurations.

Thanks for the speed of your initial reply.

And Mark, sorry for calling you Mike in the previous message. :O

> Our situation here is
> one where we are in control of our DHCP servers, but
> are not allowed full control of the physical routers
> in the building. Hence, we have no issues on my site
> in setting IP reservations, although I realize this
> might not be a common scenario.

In that case, would support for a custom DHCP option be preferable to static configuration? There's an existing argument for using DHCP options to support mobile machines, although that's complicated by the fact that many wireless routers aren't very configurable.

One of the things we're also trying to achieve is creating configuration processes that work for customers who use both a static boot partition and those who prefer the dynamically built Virtual Partition - not just the technical details of the implementation, but the whole surrounding complexity of documenting how it all works and getting coverage for enough scenarios.

Since you use the boot partition and are a non-MS house, are you using the Windows management client at all, or are your machines mainly running something else and you use a system of your own devising to get back to the boot partition? This is something that we'd always considered a valid scenario, but it would be good to know if it's actually used this way; our impression is that most customers now use the Virtual Partition, making it an interesting balancing act to keep both partition types supported equally well.