Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

"Error finding Windows installation location" when trying to set a config on a cloned image from a Boot CD

Created: 24 Sep 2013 | 10 comments

Hi all,

Client system : Windows 7

GSS: 11.5.1.2266

OS running GSS server: Windows 2008 R2

 

I am attempting to restore a sypreped image to a machine that has been booted from a boot CD but rather than starting Ghost32 from the 'start.bat' Batche file, I start "ngctw32 -console" in order that I can run the clone task via the console and apply a machine name configuration at the same time.

 

However, after the clone, I see the following error when the configure is attempted to be applied

Error finding Windows installation location.
After lookup:

I have stopped the ngctw32 process and ran "ghconfig32 -windows" which lists:

                          
X:\GHOST>ghconfig32 windows                                                     
----------------------------------------------------------------------          
Available Windows Installations                                                 
----------------------------------------------------------------------          
[F:] 1.3:\Windows Windows 7                                                     
                                                                                
X:\GHOST>                                                                      

This is the correct disk and partition.

 

Is this something that can be achieved - if so what am I doing wrong?

Many thanks

 

Chris

 

Operating Systems:

Comments 10 CommentsJump to latest comment

Swinster's picture

Hey all,

Well, I haven't been able to sus this as yet. I wonder, if this is even possible? Else, is it possible to apply clone and a configuration using just the ghost32 client running from the boot disk?

I did create a boot disk to automatically connecting to a pre-configured Ghost Server session, but I can't see how I would apply the configuration without the client being involved. Of course, after the image has been deployed and the remote machine starts, we end up on the Windows OOBE page asking a user to apply a user name and machine name. At the point the Ghost client service hasn't started and so I have to manually enter this info.

Maybe I could add the SkipMachineOOBE and SkipUserOOBE to the sysprep file (although I was hoping to avoid this), wait for the machine to boot fully and the Ghost client service start, then apply the configuration?

Chris

Swinster's picture

Well, I have had a few attempts but I fear this may not be possible - although I would be supprised if it can't

 

I am able to successfully connect and remote boot the PC/Laptop using the inbuilt Intel vPro/AMT technology to a CD Ghost ISO. I have added the following command to the "startup.bat" file on the Ghost Boot ISO so that the Ghost Client connects direct to the console running on the server.

start ngctw32 -console

So, I can now kick off an image restore via the Console to the remote booted machine. All good so far.

However, depending on the command line options added in the Clone tab on the Restore Image task depends on the error I end up seeing. If I run a vanilla restore with NO added command line, the clone completes successfully, but the client on the remote machine remains active and the Configuration task fails with the error seen above.

I then added the follow command line switched to the the advanced section on the Clone task:

-rb -sure

Whilst the client on the remote machine now closes when the image has been restored, it seems as though this is too quick for the console and the Clone task ends up timing-out so the console thinks that the clone doesn't complete successfully - of course the configuration task therefore does not complete.

 

In both case the clone has actually been completed succesfully, but I then need to reboot the machine/or let the machine reboot, and wai untill the machine has gone through the intial setup. I have now added the SkipMachineOOBE and SkipUserOOBE = true into the unattend.xml answer file and this does indeed allow the machine to start up fully into the administrator account and iI can then run another configuration taks to change the machine name/add it to the domain. All of this of course, adds time and manual input.

So almost there, but not quite

 

Swinster's picture

Nope - what even I have try I am unable to get this to work seamlessly

The best I have come up with using the -rb option when restore int he image form the console, meaning that the client will reboot after cloning, but the console say that the clone has failed (which it hasn't). The machine will then startup and run through the finalisation of sysprep and because SkipMachineOOBE and SkipUserOOBE = true have been set in the Unattend.xml answer file (and auto login has also been enable in the answer file), the machine will boot straight into the desktop with the Ghost client running.

I then have to run a second task to change the name the machine (which of course is randomised), and then add to the domain.

 

If anybody manages to get this to work - please let us know.

Maneesh's picture

Boot the cloned machine to Windows and take a screenshot of disk management.Post the same if possible,or atleast let us know the partitions on disk 0.

Below are the things to check,

=>OEM Recovery partitions

=>BDEB partition used by Bit Locker

=>Whether the machine is Dula boot.

Swinster's picture

Hi Manesh,

 

=>OEM Recovery partitions

Yes

=>BDEB partition used by Bit Locker

No

=>Whether the machine is Dula boot.

No

 

Ovbiosuly, Windows 7 also installs in 2 partitions as well. I had thought that there might be some issue with the way the partitions were setup, but this is why I check the command

ghconfig32 windows 

As indicatied in the first post. The show that when Ghost boots from the ISO, is understands correctly where the Windows partition is:

----------------------------------------------------------------------          
Available Windows Installations                                                 
----------------------------------------------------------------------          
[F:] 1.3:\Windows Windows 7                                                     
                                                                                
X:\GHOST>      

Of course, if may be possible that the disk in the first instance is blank.

 

Swinster's picture

Ok - but this isn't going to be practical going forward. We would required the the diagnostic partition is included with the disk image going forward.

Maneesh's picture

This is just for testing as we have seen issues with multiboot systems and diagnostic /recovery might also be considered multiboot.The 100 MB system reserve parition which Windows 7 creates should not be a concern.

Swinster's picture

Ok, I take it that this will be just a matter to opening the GHO in the Ghost Explorer, deleting the diagnostic partition and re-compiling?

However, will this affect the boot process of partition placement when applied to a new machine - or is it that because the diagnostic partition is effectively hidden from Windows, that it won't actually make any difference?

Maneesh's picture

It should not make a difference as long as the active partition is not the diagnostic(I am sure it is not).