Error finding Windows installation location

[Migration User]

I get "Error finding Windows installation location" randomly during our nightly imaging to 8 computers.  The client successfully does a Clone and SID change, but fails during the Configuration step.  Sometimes 1-3 ghost clients will get the error, and sometimes they all image successfully.  We recently upgraded from GSS 1 to GSS 2 with the latest updates.  Clients are running the latest 11. version as well.  The problems seems to be described in this previous forum message without resolution:

https://forums.symantec.com/syment/board/message?board.id=109&thread.id=7882

Ctrl-x on the client automatically reboots it into XP, without a unique hostname.

Any help would be greatly appreciated.

[Migration User]

Hi,

This error comes up when GHConfig cannot determine the Windows folder in the target drive to edit the registry.

When you say randomly, does it mean that the same image works for some machines in the same task but not for others?

If you run 'ghconfig windows' command when it fails, what do you get?

Krish

[Migration User]

> When you say randomly, does it mean that the same image works for some machines
> in the same task but not for others?

Yes, the same image works for some machines in the same task, but not others.  One machine may have the issue one night, and not another night with the same image.  Last night, all clients completed successfully.  The night before, 1 client failed.  Night before that, 4 machines failed to complete.  This has been ongoing for 3 weeks.  Our image doesn't get updated often, and I don't think it is related.

> If you run 'ghconfig windows' command when it fails, what do you get?

When I ctrl-X out of the ghost session that is polling the server, the client reboots into windows, and doesn't return to a DOS prompt.  Isn't this where I should retry the ghconfig?  I found that if I don't ctrl-X the ghost session on the failed client, and let the remaining clients reconfigure themselves, I can retry the task manually, and some of the previously failed clients will complete successfully.

Thank you for you help, Krish.

[Migration User]

Hi,

It could be related to your image, but I would expect it to behave in the same way for all the machines if it is related to image.

We may be able to get some info by running ghconfig manually. Ctrl+X should not reboot to Windows, but just go to DOS prompt. Ctrl+C will boot the client back to Windows.

When you press Ctrl+X, it may not respond immedietly, but may take some time (around 20 seconds). Could you try if it is going to work if you press it once and wait?

One common issue for GHConfig not to find Windows installation is changes to the disk drive index. By any chance, do you have USB disks connected in the failed machines?

Krish

[Migration User]

Hi,

 

as we have the same problem, I would like to know if anyone has found a solution by now.

 

Some details regarding our configuration:

- Clients: 65 Computers (FSC ESPRIMO P5925) running W2k Professional SP4

- Server: FSC ESPRIMO P5925 running W2k Server SP4

- Ghost-Ver.: 11.0.2.1573

 

Short description of our scenario:

The Ghost Image-files are located on a second partition on the client computers.

The task seems to run perfectly OK until the Image was written to the destination-partition.

After the image was written the clients split up in three groups:

- Some clients finish without problems.

- Some clients remain in the virtual partiton polling for the server.

- Some clients hang up in the virtual parition and respond to nothing but pressing the powerbutton.

 

 

What we found out as we tried to narrow the problem down:

- Message from "GHCONFER.TXT":  Error finding Windows installation location

 

- Result from the command "ghconfig windows" :

   --------------------------------------------------------------

   Available Windows Installations

   --------------------------------------------------------------

   1.1:\WINNT "Microsoft Windows 2000 Professional" /fastdetect

   1.1:\WINNT default

 

- So we tried to run the configuration manually using "ghconfig /w=1.1:\WINNT"

  The resulting message from "GHCONFER.TXT" was:

   No parameters detected

 

- We checked the file "GHREGUPD.REG" and found out it was completely

  filled up with blanks (4 kB of them)

 

- So we exported the configuration on the server to a file and manually replaced

  the "GHREGUPD.REG" with it.

 

- After running "ghconfig /w=1.1:\WINNT" again and rebooting using "ghreboot" the

  installation finished correctly using the right computername.

 

I hope someone can help me solving this issue, cause doing all these steps manually is

no option for us.

 

Kind Regards

Rene

[Migration User]

Hi Rene,

Thanks for providing all the info.

Since all the machines are of same model, I presume that you use either the same or a very similar image for each client. Does these failures occur for the same machines all the time or for different machines?

I can't think of a obvious reason to have a empty configuration file. Do you use default configuration or a template configuration in the task? Please note that ghregupd.reg file is padded with spaced to make it 4kb. If you use type command, you may not see the data.

Most common reason for "Error finding Windows Installation" is some kind of a confusion over drive index. This could cause by USB devices when used with some BIOSs. Do you have any USB devices connected to the machines that fail?

Krish

[Migration User]

Hi Krish,

 

you are right, we use the same image for all machines. The failure shows up on
different machines. The number of failing machines varies strongly.

 

I checked the configuration file once again and it contains nothing but spaces.
I also had a look on it using a hex editor to verify that there are no other non-printable
characters.

 

There are USB-Devices in all the computers (Card-Reader, ...), but we are already
using the -NOUSB option. Before we used -NOUSB, the Ghost-Client froze up
sometimes before connecting to the session. So I hope USB should be no problem
any more.

 

Kind Regards

Rene

[Migration User]

Hi Rene,

Could you open a failed machine in Console, and check what information it gives in Client properties?

If you press EDIT, do you get the correct details? This is what is used to generate Configuration file. I assume you would be using default Config in the task, since you re-image them regularly.

Krish

[Migration User]

Hi Krish,

 

we use the "user defined" configuration with a configuration set for each computer

(I hope this are the right English terms cause our Ghost is a German language version).

I had a look at some configuration sets and they seem to be correct. I also checked

the Client properties, even though we don't use the default config, and they look

alright too.

 

I made some more tests during the last week so I can describe the two Problems

which occur on our computers more detailed:

 

Case 1:

-------

 - The Client is running in the virtual Partition, polling for the server continuously:

 - The screen looks like this:

    ...

    <Time> <Client-IP>:1346 sending status to <Server-IP>:1347

    <Time> <Client-IP>:1346 acknowledged by <Server-IP>:1347

   ...

 

 - GHREGUPD.REG is filled with nothing but blanks

 

Case 2:

-------

 - The Client is hanging and only responding to the power button:

 - The screen looks like this:

    ...

    Received message #\Configuration{ ErrorFile = "ghconfer.txt" }

    <Time> <Client-IP>:1346 sending status to <Server-IP>:1347

    Closing server connection

    <Time> <Client-IP>:1346 disconnecting from <Server-IP>:1347

 

 - GHREGUPD.REG contains the right information (looking like this):

 CONFIG_COMMANDS OVERRIDE_NETBIOS_NAME = "1" "1" COMPUTERNAME = "SOME-NAME" "SOME-NAME" DNSHOST = "SOME-NAME" "SOME-NAME" NICMACADDRESS = "0x0123456789AB" "0x0123456789AB" END_CONFIG_COMMANDS

 

 

In Case 1 the Client will get a wrong name after ghreboot unless GHREGUPD.REG

is changed manually as described earlier.

 

In Case 2 the Client will finish correctly if it is switched off and back on

while the task on the server is still running.

If the server task has already finished due to its timeout, the client will boot to

the virtual Ghost Partition instead. From there it will finish correctly after

the following steps:

 -> [Ctrl]+[X]

 -> ghconfig /a   (sometimes hangs up again -> power cycle it in that case)

 -> ghreboot

 

Kind Regards

Rene

[Migration User]

Hi Rene,

Thanks for the details, I think the word for this in English system is 'Customized configuration' it makes me to think that the ghconfig may be failing in both cases. But the failure seems to be inconsistent.

In case 1, could you ctrl+x and check if there is a file ghconferr.txt in ghost directory? If ghconfig failed, it would have created this error file.

Usually client stays in this mode, when the task failed and it thinks that restarting is not safe. What does the tasklog say for this task (after it getting in to this mode)? Do you have any other steps in the task such as command executions or file transfers in Ghost partition?

In case 2, could you check if this file is there after the restart? In this case having a file is unlikely, since it seems to be getting stuck.

In this case, client receives the command to run ghconfig, then disconnects from the server and start ghconfig but never comes out of it.

Krish

[Migration User]

Hi Krish,

 

because of other tasks I hadn't much time left for our ghost problems during the

last few weeks.

 

By the way, we found out that the error discribed as case 1 is not coming up

when WakeOnLAN (WOL) is disabled in the ghost-task! I don't know why WOL

which takes place at the beginning of the task affects the configuration-step.

 

So here are the answers to your questions.

 

Case 1:

 - GHCONFER.TXT: Error finding Windows installation location

 

 - The Tasklog:

    ...  Remote-aktivierung über LAN                           <some date> 00:00:03    Erfolg

    ...  Client-Datei fehlt Datei wird vom Server kopiert   <some date> 00:00:04    Erfolg

    ...  Auswertung des lokalen Pfads                          <some date> 00:00:05    Erfolg

    ...  Client-Datei fehlt Datei wird vom Server kopiert   <some date> 00:00:20    Erfolg

    ...  DOS-Netzwerktreiber aktualisieren                     <some date> 00:00:21    Erfolg

    ...  DOS-Systemdateien                                        <some date> 00:00:21    Erfolg

    ...  Konfiguration vorbereiten                                 <some date> 00:00:21    Erfolg

    ...  Auf virtuelle Partition                                      <some date> 00:01:49    Erfolg

    ...  Duplizieren                                                    <some date> 00:14:02    Erfolg

    ...  Konfiguration                                                 <some date> 00:14:09    Fehler

 

 - There is only the Imaging and the Configuration task nothing else.

 

Case 2:

 - GHCONFER.TXT is not existent.

 

Kind Regards

Rene

[Migration User]

Hi Rene,

Sorry for the delay since I was out of office. 

 

I can't see any reason for it to work if WOL is removed. All it does is sending the WOL packet before starting the task. If you have WOL enabled, but if the machine is turned ON already, does it fail?

One possibility is the boot order could be different when boot from WOL (in most of new machines, you can set a different boot order for WOL). Could it be booting from a different device? For example, some users set to boot to PXE client when start from WOL.

 

In a earlier post you said -NOUSB option was used with Ghost. Did Ghost hangup if this was not specified? In case #2, if you do not use -NOUSB switch what happen?

 

Krish

 

 

 

[Migration User]

Hi Krish,

usually the machines are already ON, I just enabled WOL to play it safe.

I didn't check if switched-OFF machines behave different.

The boot order is set to be the same for WOL and normal boot. Our machines

are booting from PXE in both cases. The PXE-Server tells them to boot from the

local hard disk. Anyway, if the machines would boot from a wrong device the

task would not even get to the transfer of the image.

Before we used -NOUSB, the Ghost-Client froze up sometimes before connecting

to the session. The Effect is the same as described in a post by Eric_K:

"... when the ghost GUI loads, it freezes before the About Ghost screen comes up (Ghost 11.0.1).  

 It just displays the grey background with the blue textured border and sits there. ..."

(https://forums.symantec.com/syment/board/message?board.id=109&message.id=8954)

The usage of -NOUSB made no difference concerning the problems described as case1 and

case2 in an earlier post.

Kind Regards

Rene

[Migration User]

Hi Rene,

 

Thanks for info.

 

I was wondering if you use PXE client to connect to the Console for some of the tasks. From your reply, it seems you use VP all the time.

 

I will have a look at the behavior of Case 1 to see if there is any problem around that area. After removing WOL, did you see the behavior described as Case 1 at all?

 

In the behaviour described as Case 2, ghconfig seems to be hanging up. I'm wondering if the HW made Ghost to hang when not using -NOUSB makes GHConfig to hang-up too.  Is it possible to do a test after disabling USB to see if that's the problem?

 

Krish

 

 

[Migration User]

Hi Krish,

 

most of the time we are not using PXE to connect to the Ghost-Console. Usually the PXE-Server tells the computers to boot locally. We use PXE if we want to boot some tools, or for Ghost-Installations of computers with a blank harddisks.

 

Up to now I have not seen any "case 1"-errors when WOL was disabled.

 

I updated the BIOS on 34 computers and disabled USB. After that I made 4 test runs with Ghost and there were no Problems at all. Then I enabled USB again in the BIOS, and during the next Ghost-Task 2 computers showed the "case 2"-behavior. So your guess seems to be correct.

 

So what can we do now? Is there any option to tell ghconfig to ignore USB?

 

Rene

 

 

[Migration User]

Hi,

I can't understand the relation ship with WOL and configuration. All WOL does is sending the magic packet to the address, and there is no error handling it that situation since there won't be any response for WOL packets. I will keep an eye on this. There was a one issue with Dell machines when WOL wakes the machine, it keeps the same boot order till you power off the machine. That's the only issue I have seen around this area.

Regarding the second case, I assume that there were no USB devices connected during the test. Usually, when there is this incompatibility, it used to behave in the same way all the time. But in this case it appears to be random.

What kind of BIOS settings do you have in these machines for USB? Do you get legacy settings etc.?

Krish

[Migration User]

Hi Krish,

 

"Case 1":
I don't think that the magic packet is the problem, because we use our own WOL tool to restart the computers. We run it in regular intervals and there are no known problems with that. We also deactivated our WOL tool for some time to check if it was interfering with Ghost, but nothing changed.
And the interesting thing is, that the affected machines were not switched off. So they haven't even been
started by WOL.

 

"Case 2":
I left the hardware setup unchanged for the test. That means all computers have the following USB-devices:
mouse, keyboard, smartcard-reader, multi-card-reader (SD, CF, ...)
And two of the computers have an USB-scanner attached to them.

 

USB-Settings from the BIOS:

 

 USB Host Controller: [Enabled]
   USB Speed: [USB 1.1 And USB 2.0]
   USB Devices: [Keyboard And Mouse Only] --> legacy support for keyboard and mouse
   USB Ports: [Enable All]
   USB BIOS Hot-Plug: [Enabled]

 

 USB At Power-off: [Always On]
   USB Keyboard: [Enabled]

 

 

Rene

[Migration User]

Hi Rene,

Case 1: - No, I didn't mean to say it is due to magic packet, but from Console side only difference should be sending it when WOL is used. I believe that even with WOL this does not happen all the time (correct me if I'm wrong). That was the reason I am confused what can happen.


From the BIOS settings you mention, BIOS Hot-plug is not something I have seen a lot (unless they use different words). Could you try disabling it? This is a long shot, but enabling this probably means that BIOS keeps polling the USB ports all the time.

Krish

[Migration User]

Hi Krish,

 

your assumption concerning the "USB BIOS Hot-Plug" seems to be a direct hit :-).

A few tests showed that disabling "USB BIOS Hot-Plug" leads to ghconfig working

without problems. And I don't need the "-nousb" option any more, cause ghost

doesn't freeze up any more when the GUI comes up.

 

I will now reactivate our scheduled Ghost-Tasks, and keep an eye on them for a few

weeks. For now I want to thank you very much for your help!

 

Rene

[Migration User]

Hi Rene,

I was really lucky - should buy a lottery today :-)

Good to hear that it is working now. Please let me know if it is working OK in the long run.

I was trying WOL issue but no luck yet.

Krish