Ghost Solution Suite

Hi Everyone,

 

We've been using GSS since version 1.0, and had 1.1 working flawlessly for at least a year. Recently we upgraded to 2.0 (and 2.0.1) and have had nothing but problems. At this point 75% of Ghost functionality is not working for us and I'm an extremely unhappy Symantec customer.

 

Basically, after the upgrade, many of our tasks/images will no longer work. Generally, our tasks clone, SID change and join the machine to the domain. After the upgrade, many tasks/images will clone, SID change and then fail to boot into Windows. The PC will continue to boot into the ghost partition. When we investigate further it seems Ghost is not properly setting the active partition.

 

In other cases, the active partition is being set properly however boot.ini is pointing to the wrong partition. We are doing disk restores (not partition) so supposedly Ghost should not change boot.ini, however I cannot explain why these images worked in 1.1. Same image, same hardware, only variable is the version of Ghost invovled.

 

In some cases, chosing to overwrite the Ghost boot partition will allow things to function properly. In other cases it makes no change.

 

Part of what is making this so difficult to troubleshoot is there is very little consistency. The same task, running with the same image to the same PC, will fail with different behavior. Sometimes the active partition is the problem, other times it's the boot.ini setting. I have tried to edit boot.ini within the image but everytime I try to push out an edited image the task fails with yet another series of errors that leads me to believe the image is getting corrupted.

 

I am working with Symantec support but have thus far gotten nowhere after nearly two weeks. What's most frustrating is I continue to be told I am the only customer experiencing these problems yet when I look at this forum there are a number of posts of people with invalid partition tables, wrong partitions booting, etc. So it doesn't seem to just be me.

 

1.1 continues to work fine, so there is no question on my part that the issue is 2.0.1.

 

Any help would be greatly appreciated. I'm stuck, and out of ideas.

 

Thanks,
James

Hi,

 

I too am having the exact same problem, it does not seem to be setting the Windows boot partition as active so after crating an image the machine just sits in the Ghost virtual partition sending status to the Server and recieving an acknowledgment.

 

I didnt have this problem in Ghost 8.

 

Please help.

I too am having a variety of issues with 2.0.1 and am daily contact with L2 tech support. I agree with your assessment of the incorrect Active partition being marked, as I'm experiencing the same issue, and if I manually mark the correct partition active (using Fdisk) then Windows XP boots fine.

 

Currently my situation involves cloning/configuration task. The Cloning and Ghostwalk seem to work ok, but Configuration fails with an error along the lines of "unable to locate the windows installation".  When the client restarts it boots to Ghost CBP and starts awaiting a task from the server. However, if I then reboot with a DOS disk and run Fdisk only the CBP (and in my case a small FAT16 partition) show up in Fdisk. Initially I thought the clone must've actually no occured or had some issue, but this wasn't the case.

 

Actually I found that if I let the CBP boot, and execute another Configuration task, it would fail again but this time the Ghost CBP would no longer boot, instead for some reason the 2nd partition (blank FAT16) would be marked active. Now the disk says the typical no OS found etc. But now I can boot with a DOS disk, run Fdisk, and mark the now appearing NTFS/Windows partition Active and Windows then proceeds to boot fine.  In fact I've now just tested a couple systems, that once I go through that seem to execute a Configuration task properly.

Sorry for not replying sooner. So much for being the "only person experiencing this problem" per Symantec.

 

Anyway, after three techs and the third tech forwarding my info to a dev, Symantec has acknowledged that this is a bug and is supposedly working on a fix. I wasn't given an ETA.

 

Symantec apparently is trying to get people to stop using physical ghost partitions, which would be fine if there was a way to image a bare metal machine without using a physical partition. Ghostcasting is not an option because I don't want to manually SID change and join a bunch of machines to the domain. Maybe I'm missing something but the physical partition seems to be the only way to actually run a task that images a bare metal machine and makes it fully functional.

 

Thanks for the replies, it's nice to know this isn't just me,

 

 

I'm getting the distinct impression this is a low priority fix, which doesn't exactly make me happy. IMO it's a pretty major bug.

Thanks,
Endaar