Ghost Solution Suite

Hello,

I am currently testing Ghost Solution Suite 2.5.1 on a windows server 2008 r2 with 40 clients, everything connected directly to one isolated cisco switch.

I got multicasting up and running, but still encounter a small problem: most of the times when I start a multicast task only 32 clients connect. And it is always exactly 32. After cancelling and restarting the task two or three times finally the rest of the clients connect, too and the multicast works quite good.

Do you have any information regarding such a behaviour or any idea where this problem could come from?

Thank you very much.

Do you have IGMP snooping enabled on the Cisco switch?

Is it the SAME 32 machines that connect each time, or is the connection of 32 machines entirely random?

If it is the same, 32, have you tried moving the network cables around?  How many ports does each card in the Cisco switch support?

Yes, IGMP snooping is enabled and the vlan ip address is set up as igmp querier.

IGMP snooping                       : Enabled
IGMPv2 immediate leave              : Disabled
Multicast router learning mode      : pim-dvmrp
CGMP interoperability mode          : IGMP_ONLY
Robustness variable                 : 2
Last member query count             : 2
Last member query interval          : 1000

The funny fact is that it is not always the same computers. They change randomly. The computers not connecting either stay on the console or open the ghost32 application, but don't completely start it (the background colors show up, but the progress bar, text, etc. don't show).

EDIT:

Any hint where I could look at to find out where this problem comes from? Or any idea what could cause this problem?

Since all the computers do work, albeit not always at the same time, I would be looking for environmental issues at the hardware level initially, as this is often overlooked.

First of all, what speed are the LAN connections?  Are they coming up at the same speed when this problem occurs?  (Does the Cisco have connection lights you can watch?)

Are the network cables within the length limits for twisted pair at the LAN speed you are using?

Are all the computers running off the same phase of the mains electricity supply?  I have seen issues caused by earth leakage currents through the mains supply due to machines being on different phases causing high currents to flow through the network cabling. This really messes with the signal to noise ratio in the cabling.

A quickish way of checking is to disconnect half the machines and see if the problem goes away. Then try with the other half.  Then try with three quarters of the machines rotating by quarters to see if a specific machine or block of machines are causing the issue.

If not hardware, it may be worth running something like Wiseshark to determine the difference in communications between a successful connection and a failed connection.

All the computers are running full duplex gigabit ethernet and the connection works, the computers all boot from pxe and show connection to the ghost server after booting.

Cable length should be fine, I don't know about the phase. I just disconnected one of the failing computers and started the task again. It successfully finished. But after starting it a second time again only 32 clients started ghost32 successfully.

The failing clients show me the following message again and again:

<TIMESTAMP> <LOCAL IP> disconnecting from <SERVER IP>
<TIMESTAMP> <LOCAL IP> TCP connecting so <SERVER IP>Received message #\Clone{ Name ="<SESSION NAME>", Short_Name = 33 }
read error = 10053

Is this a known issue? What does this error code mean?

I cannot find any reference to the 10053 error code.  Do you have sufficient spare IP addresses in the DHCP pool?  Perhaps this would be a good time to give support a call unless anyone else in the forum can suggest a different course of action.

Okay, I think I found the problem.

The error only occurs when I first start all the clients with the netboot image and THEN start the deployment task so that all clients try to establish the connection at the same time.

When I first start the task and then boot one client after another it seems to work fine.

Looking up error code 10053 shows that this is not an error by Ghost itself, but by the windows network stack. According to this page http://support.ipswitch.com/kb/WSK-19980702-EM02.htm it occurs when the queue of the network stack is full and some packages get lost and the required ACK / FIN packages won't get send out.

This makes sense in our scenario as all of the clients try to connect at exactly the same time (started by a broadcast). Is there any way in Ghost to change the buffer value of the used socket? I think this should solve the problem.

I doubt whether anyone other than a Ghost developer would be able to answer the question about the buffer size of the used socket. Check out past postings by Nigel Bree - he was a developer of Ghost and sometimes answers questions like this. You should be able to contact him via the Connect email system.