I hadn't registered that you are using WinPE 3.0 - we get SO MANY of these "multicast doesn't work" threads here by people who don't have IGMP configured that it's always the first thing to address. In this situation it may not be the root cause, although obviously you NEED to know about IGMP and how to configure it to understand why it matters for IPv4 multicast.
There is also one other possibility if you're using your own hand-rolled Windows PE, which is that you haven't taken the normal steps to build it. Windows PE includes the same (rather buggy) firewall as present in the desktop editions of Windows, and it's enabled by default so you obviously need to turn it off; that's done through an "unattend.xml" file and if you look in the Windows PE 2.0 supplied with Ghost Solution Suite you can see that the initial STARTNET.CMD script included runs WPEINIT with reference to an unattend.xml file that explicitly disables the firewall as its main job.
Why is it that i can do a simple multicast test between one client and host, sending from winpe 3.0 to winxp and it works fine.
Those tests aren't necessarily doing multicast, or aren't necessarily doing it in ways that are meaningful as a test. GhostCast normally only uses multicast when more than one machine is involved, and so only the GhostCast server end will send multicast frames (the underlying protocol is almost completely unidirectional). In other cases, although you're using the same tools it will use unicast UDP frames to send the traffic.
And furthermore, even when networks are misconfigured, then multicast will usually work for a brief period of time - only a couple of minutes, but this is long enough that most people will run a simple test on a small image and from that incorrectly assume their networks are configured fine. They will then inevitably start seeing failures when doing larger transfers or involving more machines, and then assume that there is some fault in Ghost even though this is a classic, well-known and very common network configuration mistake that has nothing to do with Ghost.
The same issue bedevils firewalls; the built-in Windows firewall blocks incoming traffic from hosts, *except* when the client machine has recently contacted a machine first, in which case the firewall assumes the reply traffic was solicited and permits it. However, the Windows firewall is completely oblivious to multicast traffic flows. Hence, simple tests which involve unicast traffic will tend to cause the Windows firewall to implicitly permit the traffic flow, whereas using multicast if the primary flow is incoming, it will decide the incoming traffic is unsolicited and will discard it. As a result (even when specifically asked directly about it) customers will assume that they don't have a firewall present because a test in which traffic flowed outward was not blocked.
The long and the short of it is that it is never correct to assume something is configured properly without either concrete evidence, or very deliberate and very tightly controlled test scenarios which ensure that the test is measuring precisely the right aspects of the underlying configuration.
For example, one of the few ways to separate network configuration errors from host configuration errors in a Windows PE endpoint is to wrap the Windows PE endpoint inside a virtual machine with a bridged network connection, so it's possible to run Wireshark on the host physical machine and capture the incoming traffic to it. By correlating the captures at the server and client endpoints (using a technique like the above) can it definitively be proved that switch configuration is not an issue.
Is an 8 port DLink desktop switch not going to work?
Those kind of consumer-grade switches do work, but then you aren't using multicast, because consumer-grade switches work by treating multicast frames identically to broadcast frames and routing them to every switch port.
This almost inevitably causes performance problems, if not immediately then as soon as some device somewhere enters a low-power state; a machine in low-power mode will often maintain the switch link state at a 10Mbps rate, and so if any port on any switch enters such a state the results can include a catastrophic (and from the point of view of Ghost, inexplicable and unexplainable) drop in performance for the multicast session as the switch tries to stuff a gigabit-rate traffic stream into a 10Mbps link to a powered-off machine.
So again, this tends to be another place where extrapolating from small-scale tests to larger-scale environments causes problems; these kinds of problems never show up in small-scale tests because the test environments have a tendency to unwittingly eliminate all the sources of problems which actually show up in real usage.
This is one reason that, understanding how IP multicast works is crucial, because it's important for networks to use it (to avoid serious problems resulting from inappropriately causing multicast traffic to be treated as broadcast traffic) but it's also extremely common for it to be misconfigured.
Is there a practical software solution to this issue, or is my only option getting a new switch that supports IGMP Snooping and has an IGMP Querier?
No, but it's something you may well need to consider and certainly should include in your evaluation of switches.
In enviroments where there are snooping switches but nothing capable of generating queries (including the upstream routers) then there are simple software solutions such as Xorp, which although it is a very capable routing package is quite easy to configure just to generate IGMP queries (and which is readily packaged as a very light-weight VM appliance, making it easy to test and deploy).