Ghost Solution Suite

Hello everyone,

I am using GSS 2.5 (11.5.1.2266) running on a Server 2003 SP2 machine. Our images are built mostly on Lenovo hardware running Win XP Sp3. I still use PCDOS with my Ghosting tasks.

The problem I'm having is this: I tried to push an image onto a new/old computer that I received from one of our other locations. I used a thumb drive and GC Server to image the machine. We already have many of this model on hand, so I had a custom thumb built just for this machine (we usually use the Uni driver, but it doesn't work for the BMC 57xx NIC in my experience).

Every session would begin correctly, but would stop at :19 seconds precisely each time. Eventually I would get a time out error:

"Application Error 502

Connection reset by server with Ghostcode 19922

Batch file missing"

I thought the cause was the machine, but I ruled that out by testing its HD for errors (found none). Ran a diagnostic on the machine, which it passed. I replaced the HD just to be sure, but got the same error. I also checked the patch cable and network: no problems. Next I tried pushing a different image onto the machine, but got the same result (although it consistently timed out at :24 seconds with this image). I checked the image with Image File Check, and it passed that test as well.  I also tried imaging with both uni- and multi- casting. No change.

Suspecting a problem with GSS, I moved on to trying to image a known good machine with known good config, known good image, but using a Task. This never made it to the session, but timed out at the point where the server "talks" back and forth with the client. The error log from this session is attached as "M55 fail log.txt".

The only change I know of that was made to the Ghost Server was that my colleague installed Cisco VPN on the server (reason unknown). To troubleshoot the problem, he uninstalled VPN. After backing up the console, we tried repairing the installation of Ghost using our enterprise install disk, but the Repair failed. The Repair prompted me to browse to an .msi file, called something like "Symantec Ghost" I believe (if it matters, I can add this info later). I browsed to and found the .msi in question, but when I pointed to it, GSS repair gave me this message:

The one thing about all this that I can note is that I didn't install GSS on our server originally. The person who did set it up this way: they partitioned the C: drive, and put GSS into the usual spot in Programs. We keep our images, scripts and other Ghost stuff on another partition (E:) of the same drive; when Repair prompted me to browse to the .msi, I found it on E:. It is possible that the first time I tried to Repair, the rights were not adequate on E: for Repair to /write to the files under my rights on the machine. I've since fixed this oversight, but it hasn't changed the outcome of Repair, which always failed. Screesnhots of the messages from this failure are attached as "Repair and backup messages.zip". This also includes an error that I got when running backupdb.vbs. Despite the error from backupdb, it appears to have created successful backups.

I say this because we uninstalled GSS and re-installed it to try and correct this issue, and I used the backup to restore my console. Despite all this, I'm still having the same time out problem.

Does anyone have any idea of why this is happening?

Thanks very much.

-Chris

Attachment(s)

M55 fail log.txt   22 KB 1 version

Repair and backup messages.zip   17 KB 1 version

Does your Lenovo hardware have SATA hard disks?  If so, are you remembering to set the BIOS to compatibility mode, so that DOS can see the hard disk?  SATA is not supported by DOS, so given that all new hardware now features SATA hard disk technology, a move to WinPE as your boot environment is well overdue.

The other factor could be the size of the hard disk. PCDOS is 16 bit and has severe limitations when it comes to handling the large disk capacities that are routine these days. The LBA count was originally based on a 32 bit word, which limited the hard disk size to 132Gb. This limitation was tackled by XP in one of the service packs by upping the LBA count to a 48 bit word.

If there remain any doubts about your Ghost server install, I would recommend grabbing a copy of MSIZAP (google for it) and using it to remove any traces of the Ghost install from your server, before reinstalling from scratch.

Thanks very much for your feedback. I'm familiar with some of the topics you mentioned, and unfamiliar with others. We've dealt with the compatibility issue before on our machines, re: SATA, and have chnage the BIOS's appropriately.

The thing I have to emphasize is that I am not trying anything new here ...I've been using this system for 4 years ...and this configuration (as installed, with these versions and this hardware, both clients and server) for one year. The images which I am pushing out have been successfully deployed many times before. Why should it stop working now?

Hard disks used are between 40 and 160 GB. Images, when deployed, are +/- 30 GB.

Thanks for the tips. I'll try MSIZAP and see if that helps. I WAS thinking of doing a fresh install of server as well.

OK, it looks like Symantec Endpoint Protection may also be a contributing factor. We didn't change the clinet's config, at least not intentionally. But when we disable it, we are able to push out an image to machines on the same VLAN as the server. Still cannot push to machines on another VLAN.

You have this error in your M55 log.

>> Found Mass storage & network controller hard wire-ord together !!

This is in referance to the IRQ that they are using.   Dos doesn't do a very good job of dealing with shared IRQs.  

In the list of dos drivers there is the Universal Packet driver irqcfg version.   This was built to try and get around shared IRQs and may be worth trying.    Inorder to use this driver you will need to make sure that the bios is set to support network booting.  

Also you are using the latest public release of ghost why not use the windows PE?  Being that it is 32bit it can deal with shared IRQ's a lot better than dos.

Cheers.
 

Did you use a 11.5.1 build 2266 install disk to do your repair or the stock install of an earlier version?   This could be the cause for the repaire erros it is trying to find the 2266 install files.   It sounds like you unstall and reinstall worked,  did you get back to eht 2266 or  are you now at an eariler version? 

thanks.

Don't use Bart PE use the built in Windows PE with ghost.  I am not bashing Bart pe I have used it a lot over the years.  

You need to be at build 2266 I am not sure about live update not updateing your build but this is the version you want.     Also try with a ghost build PE disk make sure if you have to add drivers you add vista 32 bit drivers as that is the version of pe that ghost uses.

cheers.

ICHCB & others,

Thanks for your help. I've been out for the holiday, but now back to the task.

I tried the UNDI driver, but this time with the IRQ. On the load screen (black background with white text, the screen you see before the Ghost32 client opens) I did see the message you refer to, re "Found Mass storage & network controller hard wire-ord together". Anyway, I had the same result with this driver, same error message as before when trying to pish out the image.

I attached the ghosterr.txt file from this session.

I also built a boot USB drive with WinPE, but I also got the same exact failure of task and error message. Man!

I was not able to find a ghosterr.txt file from THIS session, however. Nothing on the USB drive.

At this point I am out of ideas. We are going to take a second machine, install Windows Server and make a new Ghost Console to see if this works (we want to rule out an issue with the original console, and help point to a network issue).

Per your second question, when I did the repair I used our stock copy of the GSS installer. The disk isn't branded, but is a copy. It is legit ...was made by our licensing guy, and is our OEM copy. Here's the thing: I can't really tell you what version Ghost identified itself as after we re-installed it. I grabbed a screenshot this morning, but it said 11.5.1 2226. I ran Live Update, but this didn't change the version either. So, it is possible that the version we installed from the disk last week was older than 11.5.1 build 2226, and perhaps update ran in the last few days over the holiday and brought it up to 11.5.1 build 2226 ...either that or our install disk is 11.5.1 2226 (which seems unlikely to me).

I'm still looking for suggestions. This will soon become a big problem for me...

Thanks all.

Attachment(s)

GHOSTERR_7.TXT   23 KB 1 version

Sorry, I meant WinPE. We use BARTPE to image our Macs using Ghost, but I mixed up the terms.

Also, we are at build 2266 for sure, not 2226. Typo!

So, I guess I already did try your suggestion (ie, the WinPE boot disc) and this also failed in the same way.

I appreciate the input.

We are able to successfully ghost a machine, but only if the machine is in the same room as our Ghost Server. We have to turn the firewall off, and we also had to remove Symantec EndPoint Protection and replace it with standard Symanetc Antivirus.

We have two VLAN's ...a public and a staff. Oddly enough, we still can't ghost a machine which is on the same VLAN as the Ghost server ...it MUST be in the same room as the server.

Machines which fail don't all fail the same. For example if we use GCServer, the session will start but time out after 30 seconds of imaging. If I use console, the session never starts ...it stops right at the beginning, with the Ghost32 application displaying the progress bar and the first message of the sessions (such as "uncompressing data" or something like that).

We're working on setting up another server with clean installs of Server and GSS to compare that to our standard, now problematic machine.

I have a vague recollection that your network switches need to be able to pass some sort of protocol in order for this all to work. Maybe one of the other forum members with a better memory can be specific, or have a search for past postings by Nigel Bree as I'm pretty sure it was him that commented on these protocols before. It would also be consistent with your observation that things work in the same room (therefore presumably via the same switch).

https://www-secure.symantec.com/connect/forums/gss-8-causing-problems-broadcasts-network

...I'll see what I can make of this. I have a ticket open with our IT folks to see if anything has changed network-wise that would limit our normal Ghosting.

Appreciate the help.

Hi All,

I made another server on the side (built on an old, slow computer we had lying aorund), and populated it with my Console's data. This machine worked across all subnets, no problem. I still couldn't use Console to "hit" machines because I gave this new server a different NetBios name than the "messed up" machine, but that didn't matter. I was enough to convince me to just rebuild my original machine.

Once I rebuilt the machine I found that it works fine ...I've successfully imaged machines using Console.

So, I have no idea what the problem was, but it wasn't hardware related.

Also, my colleague at another center who also uses GSS2.5 on the same base hardware told me this exact same thing happened to her. She suspected a gorked NIC in her server, but by wiping and re-installing everything was fixed, as in my case.