Ghost Solution Suite

Problem
Some of the clients are not communicating with the Ghost Solution Suite 1.1 console. (This is the majority of my pc's) The Clients that are communicating have static ip addresses.

Background
About 10 to 14 days ago I did a remote install of the client software to the pc's on my network. About 24 - 36 hours-ago my dhcp server released all of its leases and the pc's obtained new ip addresses. Now those pc's can not communicate properly with the console. I'm able to browse to the pc if I'm doing a remote client install and the pc will accept the username and password to access that pc, but while in the process of pushing out the files it fails and produces the error log below.
All pc's are running Windows xp and the server is Windows Server 2003 stnd.
I have tried to uninstall the client and reinstall the client.

Additional Info.
originally the console was licensed for 100 pc's. I ran out and installed an additional 50. After the install, it registred fine and was about to license additional clients.
The netbios names didn't change.

We do have multicasting enabled on our switch. We do not run a WINS server. Any help getting these client machines communicating with the console is greatly appreciated.


Error log
*************************************************************************
10/26/2006 @ 11:33:51 AM \\ITBURN

Failed to install:
\\ITBURN (31): Copy files: Copy failed for file: NGCInst.exe The specified network name is no longer available.


*************************************************************************
10/26/2006 @ 11:47:10 AM \\ITBURN

Failed to install:
\\ITBURN (31): Copy files: Copy failed for file: Client.msi The specified network name is no longer available.


*************************************************************************
10/26/2006 @ 12:07:37 PM \\ITBURN

Failed to install:
\\ITBURN (31): Copy files: Copy failed for file: NGCInst.exe The semaphore timeout period has expired.

Hi Andy,

The error "The specified network name is no longer available" in the log seems to be a windows networking error message.

Can you please describe your network setup a bit more so I can attempt to reproduce your environment and issue.

Are all of your machines on the same subnet?
Are the clients joined to workgroups or domains?
Did you have a WINS server installed on the network when the clients were first installed?
From your description, you have a collection of clients that are using static & dynamic IP, is that correct?

>About 24 - 36 hours-ago my dhcp server released all of its leases and the pc's obtained new ip addresses.
Did you change the IP lease address range on the DHCP server? ie. changed the lease range from 192.168.0.x to something like 192.157.0.x.


Regards,

Peter

Peter,

A little background on our network. All the machines are on the same subnet. 192.168.53.XXX. All the machines are in the same workgroup (workgroup). The GSS 1.1 server sits on the same subnet and workgroup (192.168.53.8) We never did have a WINS server.

I have about 10 or 15 clients that have static IP address and about 80 or 85 clients that have dynamic IP's.

I do have some additional info. I ran ethereal on the two separate types of clients.
The static client
source of 192.168.53.238 and a destination of 192.168.53.8 Protocol-UDP source port: 1346 Destination port: 1347. (This is a working client.)

Dynamic client
source 192.168.53.161 and a destination of 229.55.150.208 protocol is UDP source port: 1346 Destination port: 1345

With the Dynamic client I've done a remote install and an install from the GSS cd. I've updated the pubkey.crt on the client from the install of the CD. Also, when I installed the client from the cd, I input the ip address of the GSS 1.1 server (192.168.53.8) This has yielded the same results.

My question is where does the destination ip of 229.55.150.208 come from and how do I change that?

> All the machines are on the same subnet.

Are they all on a single switch?

> Source of 192.168.53.238 and a destination of 192.168.53.8 Protocol-UDP source port: 1346 Destination port: 1347. (This is a working client.)

This is the normal status back-and-forth chatter, 192.168.53.8 being your server. Port 1347 is the port the server uses for receiving client requests, port 1346 is the one the clients use for just about everything.

To get to this point, the client has to have discovered that 192.168.53.8 is the server's current IP somehow (generally, either by WINS - which has two modes of operation depending on whether you have a WINS server or not - or by sending a multicast query). What you see next is a machine which hasn't succeeded at that discovery.

> Dynamic client source 192.168.53.161 and a destination of 229.55.150.208 protocol is UDP source port: 1346 Destination port: 1345

In this case, port 1345 is one used on the server side for discovery requests from clients. This should not be the only discovery traffic; the clients should also be trying WINS as a fallback for situations where people deliberately configure their switches/routers/firewalls to disable IP multicast. You should also be seeing those queries being periodically emitted by the clients (WINS is also often called the NetBIOS Name Service and you might see Ethereal classify that traffic as NBNS as a result).

> We never did have a WINS server.

WINS, as I said, has two modes. If you have a server, machines wishing to register a name send their registrations to that specific server, and queries work the same way (this, having a WINS server reduces the broadcast traffic, and it also allows name registrations to be propagated between IP subnets by sharing a server.

If you don't configure one at all, WINS works by sending broadcasts; name registrations are broadcast out to look for conflicts, and queries are broadcast so that machine(s) having matching registrations can tell the querier that they have a registrations. By and large, the broadcasts used are classic non-routable IP 255.255.255.255 broadcasts.

> My question is where does the destination ip of 229.55.150.208 come from and how do I change that?

229.55.150.208 is an IP multicast group address - GSS Servers and clients use that multicast group to be able to find each other. Ghost has for many, many years made heavy use of IP multicast in order to distribute image data in a network-friendly way.

There's a nice overview of IP multicast at Cisco's site: http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/mcst_ovr.htm

There isn't currently a way of letting you change this, but then you really don't need to be able to change it. If this query isn't working, because multicasting is disabled or blocked somewhere (perhaps at a firewall), the question is why the WINS fallback isn't working either.

Have you also got local broadcasting disabled, and/or do you have NBNS traffic firewalled?

I think I have this issue figured out. The server is a HP DL 380 G4. It has dual onboard nics running a broadcom driver for the NC 7782 card. For some reason They are not playing well together. I've looked for an updated driver, but haven't had any luck. So for the time being, I've disabled one of the nics and it started working. But I'm still having issues. I believe it's either an HP issue or Broadcom issue. Thank you for the overview and the additional knowledge of the client and the inner workings of the product. It's issues like this one I usually learn the most from.