Interesting problem, Gary. If the clients aren't reconnecting to the console, then generally we'd work on the protocol the clients use to discover the server, since generally that's where things go wrong.
Let's recap what should happen (I'll concentrate more on the multicast side):
The first thing the clients do is send out a multicast IP query for the server; this is send to a specific multicast IP that the server registers to listen to, 229.55.150.208, on UDP port 1345. If that fails, it then falls back to also try using the WINS protocol (aka NetBIOS nameservice, port 137) using either a WINS server advertised through DHCP or the fallback subnet-local WINS broadcast mode. The client starts out retrying these every 20 seconds and drops down to trying every 2 minutes or so if it never hears anything back.
The multicast query within a subnet generally "just works", unless you are using a switch that has been configured to block multicast, or has multicast support misconfigured somehow. Layer3-capable switches support efficient multicast by piggy-backing on a protocol called IGMP, which has two parts - one where the clients subscribe to a multicast group, and one where routers periodically ask the clients to refresh their interest.
Basically, the switches just recognise the IGMP subscriptions as they go past, and add them to an internal table mapping IP multicast addresses to a set of switch ports that have subscribed (IP addresses in the multicast range are numbers that can be thought of as "channels"). After seeing a subscription send out by a machine, the switch remembers it for a while (3 minutes is a typical time), and if it doesn't see a resubscription it then removes the switch port from the distribution list for that multicast address.
Above the switches, the routers do a similar job working out what subnets have subscribed to what groups - the routers exchange multicast information amongst each other, and every 30 seconds or so ask the machines in their directly-attached networks to refresh the IGMP subscriptions (which has the side-effect of keeping the switches happy, if they are snooping in on that traffic).
One of the things we often see is that GhostCast works, but clients don't find the server through multicast, which is usually a sign that the switch has multicast enabled but there are no IGMP queries being generated by anything to keep the subscriptions alive. The difference is that when a GhostCast starts, it generates a new (random) multicast group just for that specific operation, and asks the clients to register to listen to it; because those subscriptions are fresh, the GhostCast operation can complete before the switches time them out. The server registers just once, in contrast, and expects that registration to live.
In a case like yours where there are two subnets, the above can be true but the clients in the same subnet will still manage to find the server using WINS, so not having an IGMP querier would leave behind a situation like the one you are seeing. That's not the only reason; the router configuration could have been changed to stop supporting multicast, for instance.
> Any tips or articles that you could point me too that would help would be greatly appreciated
Because of the huge range of devices Cisco have produced over the years (and all the different revisions of IOS they run), there's something of a gap between the high-level overviews such as
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm and the reference documentation for individual devices. I'm not aware of any good tutorial for setting up a complete network with IP multicast support.