Ghost Solution Suite

Hello friends, this is my first post and obviously, I'm in a hurry :)

I'm working for a NGO, we have several HP7700/7800/7900, etc desktops ultraslim and we use DVD's with bart-pe + Ghost to load the images, it works perfect. We have now developed a 32GB USB so we can put all the images from all the desktops in just one USB.

The problem is: Sometimes Ghost assigns the number 1 to the local harddrive (DST=1) and sometimes the number 2 (DST=2). This is preventing us from doing a proper menu for the USB. I would like to kindly ask you if anyone knows if it's possible to FIX the number that Ghost assigns to the harddrive, so instead of changing (1 or 2) is always 1

As I told you, even with the same model of computer (for exemple hp 7800) in one computers Ghost assigns the local harddrive with DST=1 and some times it assigns DST=2 (and put the USB as DST=1).

I appreciate greatly any help!

Best regards

It is not Ghost that assigns the local hard disk order, as a moment's thought would tell you. The boot process sets drive letter assignments, and this may be affected by whether the local hard disk in the machine is "visible" to BartPE or not. This in turn may be affected by whether the machine bios is set to emulate the local hard disk as a PATA device rather than a SATA device. SATA drives often need specific driver support in WinPE and thus BartPE if they are not set to emulate PATA devices which PE supports natively.  Equally, if the boot order is not set consistently in the bios, or the internal hard disk is not bootable for some reason, then the USB key will become the primary boot device.

The simplest solution is to use a batch file to detect which device your USB key mounts as, and adjust the Ghost command accordingly.

Thank you very much for your kind support. So I'm going to enter in the Bios and configure the local Hard Disk as the first one in the Boot order. After configuring the Bios and restarting the computer I will need to press F12 button to select the USB to load Bart-PE, I hope this will not "change again" the boot order and therefore Ghost will assign the local hard disk as dst=1

I will let you know later.

Thank you so  much!

I have just tried to put the Hard Disk as the first in the boot order in the Bios, then I restarted, press F12 to boot with the USB and Ghost still assigns Hard Disk as DST=2.

I'm usign Auto Play Menu Builder 6.1 to define the icons of the menu and its actions. I don't know if you could (if this is not complex for you) you pass me the batch file / script to detect wich device my USB key mounts as.

Anyway, Thank you a lot!

I don't have the batch file handy, but the principal is dead easy.

Just stick a text file in the root of your USB device and make sure it has a unique name - eg xxflagxx.txt

Then in your batch file you run code something like this:

If exist c:\xxflagxx.txt goto label1
If exist d:\xxflagxx.txt goto label2
If exist e:\xxflagxx.txt goto label3

:label1
REM  This means that the USB device is the first boot device, so run Ghost accordingly
<Insert Ghost command line here>

goto exit

:label2
REM  This means that the USB device is the second device, so run Ghost accordingly
<Insert Ghost command line here>

goto exit

:label3
REM  This means that the USB device is the third device, so run Ghost accordingly (eg two hard disks in the PC)
<Insert Ghost command line here>

goto exit

:exit

Note that this code is written from memory so I give no guarantees that the syntax is entirely correct but you can google basic dos commands if the above throws any errors. It's basically trying to find what drive letter the USB device boots as, and then running the appropriate Ghost command from the USB device, taking into account both the source location that the Ghost executable is on, and the target location of the hard disk.  If you are partitioning and formatting the hard disk as part of your process then of course these steps can precede the Ghost command in each scenario. This should also avoid any risk of accidentally reformatting your USB key.

Thank you so much for your time. I will try and I will let you know ;)

Take care

The order in which devices are enumerated depends on a number of criteria, but in essence it is built on how all computers look for devices; they enumerate the various attachment buses, and then on each bus enumerate the attached devices.

The older bus types come first in the enumeration process (and most especially, those legacy bus types which predate the now-universal model of device enumeration present in modern attachment buses such as PCI, USB, Firewire and the like). When new bus types are added to computers, they are added at the end of the bus enumeration process in order to avoid disturbing existing processes which rely on such things.

This means that whether any particular device inside a computer chassis is, for instance, an IDE or SATA device can completely change the device order. This is something that can vary even within model lines, as modern computer manufacturers (most notably Dell, but increasingly others) no longer manufacture identical machines within a model series and instead substitute an incredibly wide range of components for their own supply-chain management reasons.

So for instance, some manufacturers will sometimes substitute an IDE-based optical disk for a SATA one, or vice versa, and actions like this will result in different drive-letter assignments in Windows PE even amongst machines which are identical models.

Ghost's numeric assignment process is ultimately similar to the process used by Windows PE; it attempts to be a little more regular by filtering out non-writable mass storage devices, but it's nonetheless the same process.

This means that if for some reason one instance of a model has an IDE disk instead of a SATA one or vice versa, then the notion of what collection of writable storage devices exist will still end up in a different overall order.

Thank you very much Nigel. Do you recommend also the solution (batch file) proposed by Edt?

Best regards

we have issues sometimes with media card readers that come up as lettered drives with no info (think like A: for floppy).  So on the 8 in 1 readers, the HD could be upwards of disk 8!  It sucks, i agree.  Zip drives gave the same issue for us.

Aren't these card readers mostly USB devices so mounted after the HD, or are you referring to built in hardware?  Even my laptops with built in card readers mount them after the hard disk, but perhaps this is not the case for all manufacturers.  It would be interesting to know the specific hardware you encountered this on.

im referring to the ones that tend to connect to the motherboard with the 8pin adapter.  They usually come in a 5 1/4 or 3 1/2 bay on the front on the PC.  they dont all do it, just some.  We had a ton of old gateways that did this to us

  We didn't have the problem with the hard drive being different but we ran into problems where the usb drive was a different drive letter in win pe /bart pe depending on what other usb devises were in use.   Here is the bat file that we used to scan each drive for the location of the windrivers folder and then give it a name of  BOOTDRIVE   then we could call to the usb boot disk by name rather than drive letter.    

Like Ghost32 -clone,mode=restore,src=%BOOTDRIVE%\xp\image.gho,dst=1 -batch -fx

In our ghost image we included a txt file called boot.txt and we did a scan of the drives after ghosting to identify the newly deployed image and properly run the ghost deployanywhere tools.    Take a look below and modify as needed.    You could use the same portion of the script to identify the hard drive if you know that the hard drive has a file or set of files already on all machines.   simular to the boot.txt noted later in the script. 

Eds suggestion is good to identify the usb drive also I just like the following command.  It searches drive letter C to S for a folder of WINDRIVERS  (this could be modifed for any folder or file) and then sets a windows variable name of BOOTDRIVE or any name that you like.   You can then call to %yourvariable% in your batch file.

for %%f in (C D E F G H I J K L M N O P Q R S ) do if exist %%f:\WINDRIVERS\ set BOOTDRIVE=%%f:
 

Cheers.

@EcHO OFF ClS

:: ######## BOOTDRIVE searching for the drive letter of the disk that was booted from with the windrivers folder. for %%f in (C D E F G H I J K L M N O P Q R S ) do if exist %%f:\WINDRIVERS\ set BOOTDRIVE=%%f:   :: ####################  MENU OPTIONS ################### :MENU cls COLOR 1E ECHO. ECHO   ___   ECHO _/  "\   1 To deploy XP automagically ECHO( \  ~/__ 2 This option is on back order check back soon ECHO \    \__)3 To run Ghost32 ECHO /     \  4 To join a GhostCast session #1 automatic and then reboot ECHO/      _\ 5 To quit and reboot  ECHO `"""""`` ECHO. SET /P  M=Select 1,-5 if you dare and press ENTER: IF %M%==1 GOTO XP IF %M%==2 GOTO VISTA IF %M%==3 GOTO GHOST IF %M%==4 GOTO Ghostcast IF %M%==5 GOTO REBOOT

:: ###################################################### :: ################### Option 1 Start ################### :: ###################################################### :: #  1 Deploy XP automagically :: #  2 Run Deployanywhere :: #  3 Run Ghostwalker :: #  4 Rebooot :XP @cls Echo Please Hold :: #### 1 Deploy XP from \xp\image.gho to disk 1 ####

@%BOOTDRIVE% @CD \GHOST @Ghost32 -clone,mode=restore,src=%BOOTDRIVE%\xp\image.gho,dst=1 -batch -fx

:: #### 2 Run Deployanywhere  ####

:: # OSDRIVE search for the boot.txt that must be in the root of the restored image.

@for %%f in (C D E F G H I J K L M N O P Q R S) do if exist %%f:\boot.txt set OSDRIVE=%%f: Echo Please Hold :: # Deployanywhere with the target of OSDRIVE @cls Echo Please Hold @ghdplyaw32.exe /target=%OSDRIVE%\Windows /ddb=%BOOTDRIVE%\WINDRIVERS @cls Echo Please Hold :: #### 3 Run Ghostwalker command

:: GhWalk32.exe /CN="PC<RANDOM_NUMERIC>" /batch

:: #### 4 Reboot using the Pe Reboot command @cls Please remove the USB drive. @pause @WPEUTIL Reboot

:: ###################################################### :: ################### Option 2 Start ################### :: ###################################################### :: #  2 Deploy Vista automagically :: #  3 Run Deployanywhere :: #  4 Run Ghostwalker :: #  5 Rebooot :VISTA @cls ECHO This item is still on back order please check back soon. Pause GOTO :MENU

:: ###################################################### :: ################### Option 3 Start ################### :: ###################################################### :: #  1 Start Ghost32.exe :GHOST

:: #### 1 Start Ghost32.exe #### @cls Echo Please Hold %BOOTDRIVE% CD \GHOST Ghost32.exe

:: ###################################################### :: ################### Option 4 Start ################### :: ###################################################### :: #  1 Start Ghost32.exe and join session 1 Automatic :: #  2 Reboot :GHOSTcast

:: #### 1 Start Ghost32.exe  ####

%BOOTDRIVE% @CD \GHOST @Ghost32.exe -ja=1 -sure

:: #### 2 Reboot using the Pe Reboot command #### @cls Please remove the USB drive. @pause @WPEUTIL Reboot

:: ###################################################### :: ################### Option 5 Start ################### :: ###################################################### :: #  1 Reboot :REBOOT

:: #### 1 Reboot using the Pe Reboot command #### @cls Please remove the USB drive. @pause @WPEUTIL Reboot

Nice - thanks for posting your script.!!

the use of the variables has tech cool but the silly ghost aski that I did is what people who were using it were most impressed with.   :)   In the start up bat file that is created while still in the ghost boot wizard I have it call to pcA thin host so if we needed we can connect to a machine remotely and work with it. 

I forget you can attach files here sorry for not just putting it in the orriginal post and quoting a snipit .   Just put it back to a .bat file to use it or don't.  :) 

Cheers.

Attachment(s)

auto.bat_.txt   3 KB 1 version

Thank you very much for your kind support ICHCB!  Unfortunately I think it's not exactly what I need.

Well, let me explain my situation. I am working for an NGO and we use Ghost with BartPE to make a recovery DVD. Now we are deleveloping a recovery USB and we have the problem to identify if Ghost assigns local hard drive dst=1 or dst=2.

Well I have been looking to your script and I am not able to figure out how to find if my local hard drive will be dst=1 or dst=2. The recovery USB will be use to restore computers with problems and basicaly will put again the Windows XP image  (with C and D partition) I can use your script to identify the C: and D: partition in the local hard drive (befire Ghost, old Windows XP) In C: we always have c:\windows folder and in D: we always have d:\mail, then I can assign "Cpartition" label to C: and "Dparition" label to D:, the problem emerges when I want to put the image: 

ghost32.exe -clone,mode=load,src=x:\cdr00001.gho,dst=1,szee -sure -batch -rb

The cdr00001.gho image has two partition C and D. Do you know how can I put the full gho image in Cpartition and Dparition ?

If you believe that there´s another way to find if my local hard drive is dst=1 or 2 I would really appreciate it.

Thank you so much!

It is NOT Ghost that assigns dst=1 or dst=2 - it is something YOU have to do depending on whether the hard disk on your target system ends up as the first hard disk or the second hard disk in the boot order.

So in a simplistic way, if your target drive ends up as Drive C then you need to specify dst=1 whereas if the target drive ends up as Drive D then you need to specify dst=2.

By finding out what drive letter your USB boot device ends up on, using the batch file method that both ICHCB and I have presented as a solution, you can make a deduction on what drive letter will have been assigned to your target hard disk.

Therefore if your USB device is found on C: then clearly the machine hard disk cannot also be on C: and so is most likely to be on D: as "hard disk" partitions are assigned drive letters before optical devices, and we assume that your USB device is not going to be partitioned into more than one volume.

Depending on how BartPE is built, it may also support WMI, and with WMI you can perform quite detailed analysis of connected drives. However that is overkill for this problem and so I hope that you will now see where we are trying to take you and try some practical tests with your systems before dismissing our suggestions as not appropriate to your situation as you have explained it.