Ghost Solution Suite

Hi,

Have just upgraded to ghost solution suite 2.0 from 1.1 and after running a refresh configuration on some clients they now show up disconnected on the console. I have waited a few days but still not showing up. Other machines work as expected.

The nctw32.log on a machine that is not showing in the console has the following repeated over and over: (Our ghost server is on 10.58.24.17)

11:12:45 AM 10.58.24.111:1346 sending status to 10.58.24.17:1347
11:12:45 AM 10.58.24.111:1346 acknowledged by 10.58.24.17:1347
11:13:05 AM 10.58.24.111:1346 sending status to 10.58.24.17:1347
11:13:05 AM 10.58.24.111:1346 acknowledged by 10.58.24.17:1347
11:13:25 AM 10.58.24.111:1346 sending status to 10.58.24.17:1347
11:13:25 AM 10.58.24.111:1346 acknowledged by 10.58.24.17:1347

If i delete a the client from the console server it does not reappear.

Also if i attempt to perform a client install form the consoele on the machine it appears to work but the client install log shows the following:

Successfully installed:
\\ENGA505(51):
(0): \\ENGA505

Any help in solving this would be appreciated.

Something I'd appreciate seeing to help diagnose the cause is a copy of the ngserver.log file on your server, and ideally the ngctw32.log from an affected client so I can match up the communication from each.

If you could zip them up and e-mail them to me at nigel dot bree at gmail dot com I'd appreciate it.

The requested log files have been sent.

Thanks a bunch, although they haven't shown up yet which is odd (gmail is normally pretty quick). It might pay to drop me a plain e-mail and I can send you instructions on how to upload them to one of our file servers instead.

Just to explain what's going on here, in GSS2 the primary machine identifier we prefer to use is the SMBIOS UUID (or the PXE UUID), if available. There's a small mistake in the GSS2 client and server which means that some BIOSes are detected as having a UUID of all zeroes - you can see if this is happening to you by searching the ngserver.log file for the UUID values the clients are reporting.

C:\Program Files\Symantec\Ghost> findstr /i /c:"Uuid = #[0x00 0x00 0x00" ngserver.log

The above will print any clients reporting a UUID that starts with four zeros, for instance. If the UUID is all zeroes, that's bad and you need a fixed ngserver.exe which knows that it makes no sense. I've sent Craig a development build to test out, and there will be a proper numbered build available through technical support as soon as we can (given that we need to QA it).

Nigel,

I have this same problem. Is it possible to get the updated ngserver.exe?

Thanks,

-Brian

It's possible if you e-mail me to the address above, for now; getting a fully QA'd, digitally signed numbered build takes time, especially with arranging for problems like this to be reproduced n QA so we can verify that any proposed fix does in fact work.

So, I'm happy to send a test build to anyone with the problem, since you're the best people to tell us whether we actually have fixed it or not, but it's also good to keep track of who gets anything experimental.

I e-mailed you earlier this morning. Please let me know if you do not receive.

Nigel,

We are having a similar issue. The computers which have the latest BIOS version are not seen in the ghost console (Dell Optiplex Gx270 Bios : A07). Also, we do not see the UUID as being 0's for these workstations in the ngserver.log.

If you like I can send you the ngserver.log file. We would like to try out the development build. Could you let me know how we can obtain that?

Thank you,

Ashwin

Brian, got your e-mail and I've just sent you some download info.

Ashwin, the GX270 is a slightly different issue.

Customer Support have been working on the GX270 with us and it transpires that a large number of these machines have been manufactured with incorrect SMBIOS data that includes identical machine serial numbers and identical (but seemingly valid) UUIDs. Which, since they are supposed to be unique, comes as an unpleasant surprise.

I have devised a workaround that you are welcome to help us test out though, so drop me an email if you'd like to pick up the development code for this situation.

Nigel,

We would definitely like to test the development code. Please let us know how we can access it.

Do you know if there is a way to update the SMBIOS data on the Dell GX270's?

Thank you,

Ashwin

> We would definitely like to test the development code. Please let us know how we can access it.

E-mail me at nigel dot bree at gmail dot com and I can send you the information.

I'm experiencing a similar problem with ghost 7.5. A client with UUID 0000006013BB can not be seen. Does there exist a better version of ngserver.exe here, too (I can't see any ngserver.log, maybe there is none in ghost 7.5)

Actually, 00-00-00-60-13-BB isn't a UUID, it's a network adapter MAC address, and it's not really a valid one of those either. UUIDs are 16 bytes long, and that length means that generating a "random" number pretty much suffices for it to be a unique ID. MAC addresses are assigned to IEEE 802 network adapters, and have two parts; the first three bytes are assigned to specific manufacturing organizations (you can look up the ID assignements at http://standards.ieee.org/regauth/oui/index.shtml). The 00-00-00 OUI prefix was assigned to Xerox - where Ethernet was first designed - for instance.

With 7.5, it is the MAC address of the network adapters that is used by the server to identify clients; using the SMBIOS UUID of a system was not supported until GSS2. SImilarly, the ngserver.log file is new in GSS2 (there's a procedure for bringing up a similar diagnostic display, which I'm managed to forget - holding down the Control key and moving the mouse to the top-left corner of the dispay, or something like that - it works on the clients and the server to bring up a tray icon which has opening a debug window as an option).

With a 7.5 client, the reasons for not showing up are slightly different; if the client thinks it's in contact and isn't showing up, it's probably a similar kind of problem to the one discussed in this thread, but the details are different. Some software network adapters claimi to have valid-looking MAC address assignments, and these can cause the clients to be misidentified (the Microsoft loopback adapter is one such - we've tried to filter out the more common problematic IDs, but that one managed to slip through).

If the client thinks it isn't connected, then it's generally a matter of exploring the network.