Ghost console client reimage problem
I've been using the Ghost Console for several years to reimage 22 machines in our test lab. Currently, I'm running the Console version 11.5.0.2113 on Windows Server 2003, Service Pack 2. The client machines are Lenovo ThinkCentre M57 (9071/A18) desktop machines. The client machines are running Windows XP, Service Pack 3. The hard disks on the client machines are set up with a 15MB Ghost boot partition (which is normally hidden). The remainder of the hard disk contains an NTFS partition which occupies the remainder of the disk. Windows XP is loaded on the NTFS partition. The current setup has been running well since December of 2008. Within the last two weeks, some of the client machines have been failing to reboot into Windows XP Professional after Ghost has finished loading the image. They end up at a command prompt with a file named NGCTDOS.ERR in the Ghost subdirectory. The contents of the file are as follows:
Exception code: 0000000e Page fault Error: 0004 Registers: EAX=001075c8 EBX=001740ac ECX=00000000 EDX=00000000 ESI=00071560 EDI=001740ac EBP=00107600 ESP=001075c8 EIP=0006af4a FLG=00013206 CS: sel=00af base=10000000 limit=001bffff DS: sel=00b7 base=10000000 limit=ffffffff ES: sel=00b7 base=10000000 limit=ffffffff FS: sel=00a7 base=0002d530 limit=0000ffff GS: sel=00bf base=00000000 limit=0010ffff SS: sel=00b7 base=10000000 limit=ffffffff Call frame traceback EIPs: 0x0006af4a 0x0004f236 0x0004f5ed 0x0004f753 0x0004a847 0x000095bf 0x00009bc6 0x0000fd5d 0x0001050f 0x00008e6b 0x00009225 0x000063d4 0x00006f55 0x00056938
At present, I'm reimaging 12 machines each afternoon. Six of them reimage and reboot into Windows XP without any errors. Of the remaining six, four to six of them fail regularly.
I'm hoping that Nigel (or one of the other Symantec employees) can help me resolve this problem.
Boot track
Jim,
Was the image you are deploying created with the -IB switch? The boot track on IBM/Lenovo machines is structured differently, and this can be a factor. If it was, nevermind that.
Try using CTRL+C, then typing ghreboot and clicking Enter. This can break out of the virtual partition, if that is the issue.
I hope one of those work!
This is a DNS processing error in the 2113 DOS client
The process that the GSS client goes through to contact the server it is securely bound to is to use a multicast query for the fingerprint of the public-key parameters stored in the server's unique certificate, which the client has a copy of in the PUBKEY.CRT file. If that query fails, it then goes into various fallbacks and this fault is in one of those.
Specifically, if the client does not locate the server normally by multicast but the certificate has the full DNS name of the server, it will attempt to resolve that name by DNS; in the 2113 release of NGCTDOS.EXE there appears to be a circumstance where the code to process the DNS reply fails in this way, although the specifics of that aren't particularly clear since it hasn't been reproduced here.
If this has not been happening before, the trigger is most likely a change in your network environment, which is why the clients are doing this when they normally would not.
I made a code change to resolve this and this will have been included in the second GSS2.5 LiveUpdate (which contains build 2145 of the client components; check the file version properties on the file C:\Program Files\Symantec\Ghost\update.exe to be sure - that file was definitely updated by LU2, and it is a mini-updater for the NGCTW32 and NGCTDOS executables.
If that file is still at build 2113, you should make sure to update your GSS server to get a more recent client which should not have this, and it would be a good idea to re-make a new GBP at that point with that updated client contained it in. If the problem is inconsistent then you shouldn't have to replace the GBP's outright as updating the server should eventually get the GBP client code updated, since after you have the updated client on your GSS server, once the GBP-based clients do contact it they'll be rolled forward to the current client version the server has.
Thanks Nigel!
I've just returned to the office after being on vacation Wednesday through Friday of last week. I'll follow your suggestions and let you know what I find out!
Follow up...
Thanks again Nigel! I updated the Console (using Live Update), re-created the boot partition and replaced the boot partition on the "problem" machines. Doing so has corrected the problem with the "problem" machines not being able to boot back into Windows XP after the DOS client has reimaged the second partition.
There still seems to be an issue with network communication between the "problem" machines and the Console. The "problem" machines take a longer time the reestablish communication with the Console after they have been re-imaged. The "Task Status Window", in the Console, shows that the jobs have "failed" on most of the "problem" machines, even though they were re-imaged successfully. Evidently this is because these particular "problem" machines took too long to reestablish communication with the Console.
Also, the Windows XP image that I'm using still has version 2113 of the client in it. The Console automatically updates the client software to version 2141 on all of the "good" machines, but only one of the "problem" machines. The remaining 5 "problem" machines stay at version 2113. They show the exclamation mark on the icon.
I've contacted one of our network support folks and he is willing to help me. I assume that he will "sniff" the traffic between one of the "good" machines and the Console, then "sniff" the traffic between one of the "problem" machines and the Console, then compare the two traces. Can you tell me what network traffic he should look at?
Thank you, in advance, for all of your continued support!
Communications
The traffic between the GSS client and server is documented at this KB article. Exactly what the normal communications will look like depend somewhat on whether IGMP snooping is enabled on your switches and whether they and the server are on separate subnets (and if so, whether IPv4 multicast routing between those subnets is enabled).
If you don't want to remaster your image, one thing you can still do is use Ghost Explorer to edit it and replace the original build 2113 version of ngctw32.exe with the newer one; the console will still run the MSI upgrade, but that way you won't run into any problems which the older code may be causing you.
Nigel to the rescue!
Thank you for suggesting that I use Ghost Explorer to replace NGCTW32.EXE in my images. I keep forgetting that we now have the capability to manipulate files in an NTFS partition! Doing so kept me from having to rebuild my images and has cleared up any lingering issues that we were seeing. Many thanks for your help!
Would you like to reply?
Login or Register to post your comment.