Ghost Solution Suite

Greetings. I've been doing some testing to try and figure out a WinPE Virtual Partition PreOS behavior problem.

I have a Dell T5500 that from the Ghost Console (v. 2266) I can use a WinPE virtual partition PreOS that I created with the proper Ethernet and SATA controller drivers to take an image from. I kick off the job from the console and the T5500 reboots into the Ghost GUI and the image is taken and stored on the server.

But....

If I take that same T5500 and do a clean install of Win 7-64 then use the console with same WinPE PreOS the T5500 never reboots and the Console reports a failure saying "Failed to update unattend.xml".

I noticed that during the fresh install of Win7-64 that a 100MB partition is created automatically. I tried leaving this as default, installing again changing this partition to 400MB and also loading Win 7-64 with no extra partition being created but none of those installs will let me image the T5500 from the console using the WinPE PreOS. 

Any ideas why?

Windows 7 consists of two partitions, as you have observed. The first is usually around 100-200 Mb in size, and the second is whatever size you request during the installation process. Both partitions are required for a successful boot.

Try taking a disk image instead of a partition image and see if that solves your problem.

These imaging jobs that I am starting from the console are all disk images not partition images.

This behavior also happens with a Dell Optiplex 980 I have, disk images work fine until you try and take one with a clean Win 7-64 install.

How clean is clean?

Most vendors include a diagnostic and/or recovery partition as part of their standard builds. Have you done a complete disk wipe before installing Win 7-64 ?

Can you also clarify whether you are deploying a Sysprepped image, or running an automated install?  It is not possible to run an unattended install of Windows 7 64 bit from a 32 bit WinPE Pre-OS.

However, it is possible to create an image of a Windows 7 64 bit installation that has been sysprepped as then you are just imaging a bunch of sectors on a hard disk and the content is mostly irrelevant.

Finally, users often assume that the WinPE drivers need to be the same as the operating system being deployed. This is not the case. The version of WinPE used in Ghost, is based on the Vista kernel, and therefore additional drivers added, and selected, in Ghost Boot Wizard, need to be Vista 32 bit drivers.

Conversely, if you are using DeployAnywhere, and are adding drivers to the DeployAnywhere driver library, these DO need to be the appropriate drivers for the operating system you are imaging.

I hope some of the above has covered your issue, as I'm not entirely sure I have correctly interpreted how you are deploying or capturing your image.

Clean as in only one partition with Win 7-64 installed.

I am trying to take a non-syspreped image of this workstation, not deploy to it.

I have been using Vista 32 bit drivers for my WinPE packages.

Thank you for trying to help me figure this out.

I have read through the information provided so far, and I have found a couple of holes that it would be useful to fill in. At the same time, as the solution has not yet emerged, it makes sense to take this step by step to make sure we don't miss anything, so bear with me.

First of all, you said:

I have a Dell T5500 that from the Ghost Console (v. 2266) I can use a WinPE virtual partition PreOS that I created with the proper Ethernet and SATA controller drivers to take an image from. I kick off the job from the console and the T5500 reboots into the Ghost GUI and the image is taken and stored on the server.

I assumed that this step was undertaken with an existing installation of Win 7 64 bit, but there is nothing in the thread that confirms this, so please advise whether the working console imaging step was also imaging Win 7 64 bit, or was imaging a different operating system.  

Secondly, I would recommend reviewing other threads by searching on the string:

 "Failed to update unattend.xml"

I found this thread which may be worth reviewing in the context of your environment:

https://www-secure.symantec.com/connect/forums/error-failed-update-unattendxml-file

Let us know how you get on.

You are correct, the one working T5500 is an existing installation of Win 7-64 that came preloaded on the workstation from the factory. This T5500 was purchased maybe a year or so ago from Dell. When these workstations came in I created a working WinPE virtual partition PreOS, created a master image and cloned all 35 of them no problem.

Now to today, we receive a new T5500 with the same OS installed from the factory(Win 7-64). When I try to use my previously working WinPE virtual partition PreOS to create my master image the process fails with the above mentioned error on the server.

Yes I have reviewed many other threads and tried all of the suggested solutions before I ever started this thread. None of the posted suggestions worked except for using PCDOS.

The main reason I started looking into this is that I have 215 workstations coming in that will need to be imaged and I wanted to be able to use WinPE as it images much faster than PCDOS can. I have been using Ghost to create workstations for the past 8 years going back to using a boot disk, an external USB hard drive and going around cloning one workstation at a time. I started using the GSS running on a server when the workstation count got too great to clone one at a time and have had hundreds of successes using both PCDOS, and before now, WinPE. Don't get me wrong, I have had plenty of issues during all of this but it seemed like there was always a workaround when things wouldn't work.

I have been working on this newest problem (failed to update unattend.xml) for about 2 weeks now off and on and I'll be damned if I can figure it out. The workstation has a Broadcom NetExtreme 57xx Gigabit Controller for the NIC and a Intel ICH8R/ICH9R/ICH10R/DO/5 Series/3400 Series SATA RAID Controller for the disk. I have tried using different Vista drivers for these in my WinPE virtual partition PreOS and even reordered the manifest to check drivers before trying to update the unattend.xml to get driver errors reported:

{
   name = "WinPE-512"
   type = PEx86
   size = 190
   ram  = 440
   bootonce = 1
   steps = (
     # Check that drivers are present in winpe for the devices on the client
     {what = checkDrivers, path = "{manifest}\\pci.manifest.txt"}

     # Update the unattend.xml file with any required static ip settings    
     {what = unattend, path = "{manifest}\\ghost\\unattend.xml"}

This worked to report on a incorrect Ethernet driver but no SATA errors are ever reported.

I can not think of anything else to try.

My gut instinct is that this could still be a driver issue.

Once WinPE has booted to a command prompt, you can load candidate drivers dynamically using DRVLOAD <path and filename of driver INF file>

This should allow you to quickly test the SATA drivers - if they are working then you will be able to "see" the hard disk and its contents.  With the NIC drivers, you can test if they are working by running IPCONFIG /release and IPCONFIG /renew.  

Once you have the correct drivers identified, you can integrate them into the WinPE image.

Also, have you checked the light on the NIC port? That can reveal whether the NIC is trying to connect at the wrong speed or not connecting at all.  I presume you have checked it's not a cable fault or a port down on the switch?

If I could get the workstation to reboot into WinPE, like you say, I would have this problem solved but it never gets that far along in the process.

The network seems to be fine as I can watch the WinPE and Template folders being written into the C:\Program Files (x86)\Symantec\Ghost\INCOMING folder on the workstation after I start the imaging process on the server.

Could you create a WinPE boot CD or USB stick and boot the system from that rather than using PXE boot?

It might help to narrow down the area where the problem lies.

I don't know why this works but it does.

The lab network that I have the server and workstations connected to is not using a default gateway, only the IP address, Subnet mask and Preferred DNS server. For some reason this causes Win 7 to label that connection as "Public network". With this designation I can not get the server to take an image of the workstation and it always errors with "Failed to update unattend.xml".

After I type in a Default gateway and close the IP and Network GUIs Win 7 prompts for you to set a network location. Selecting "Work network" then allows the server to be able to take an image.

If anybody knows in detail why having the network connection labeled as "Work" instead of "Private" allows the imaging process to complete I would love to hear about it.

Thank you for all the help.

This looks more like a Windows 7 security issue than something specific to Ghost. It may be that the "public network" is considered a higher security risk than a work environment, and therefore UAC may be blocking execution of processes required by the imaging software.

It is a security issue with Win 7 no doubt but I have the firewall turned off for Public, Private and Domain networks and I also have UAC turned off.

Is there any way to get Symantec to look into this to provide a detailed reason as to why this is happening?

You would need to log a support call. The Ghost development team was laid off some years ago, and thus patch maintenance is, I believe, handled out of India. There is supposed to be a future update of GSS on the cards but no real information on when and what will be included.