Note 1: I posted this same message on the MSFN forum at http://www.msfn.org/board/Request-Scrip … 43413.html , which is the thread from spring 2005 hosting the original HWIDS.CMD script. I posted it there at the request of IcemanND, the author of the INF scanning engine in this script. Thanks for the original, IcemanND!

Note 2: If someone knows how to change IcemanND's script to filter out the tab characters that sometimes got through the original script, then the dependency on SED.EXE will go away.

---
I have taken the HWIDS script and improved it by solving several weaknesses in the original.  The main caveat is it now requires SED.EXE, a free/GPL tool from http://gnuwin32.sourceforge.net/packages/sed.htm , to be somewhere on the system path.  I used SED to remove the tab characters that Skillz reported in an earlier post. The list of improvements is in the code below.

On the todo list would be automating the following:
1.) running sysprep -bmsd to insert the official MassStorage drivers into sysprep.inf (easy to do in a batch file)
2.) inserting of the output of this HWIDS script into the correct section of sysprep.inf, after the official drivers list, while verifying duplicate entries are not created in case a driver has been added on a previous insertion. (If someone has a good way of doing this, I'd love to hear it.)

HWIDS.CMD (Inf Scanner)

@echo off
:: Core INF scanning and processing engine created by IcemanND and posted on MSFN Forums
:: at http://www.msfn.org/board/lofiversion/index.php/t43413.html
::
:: Note: I (HK) contacted IcemanND on MSFN on 4/7/2008 and asked him if it would be okay to
:: release this modified version under both the GPL and Creative Commons Attribution licenses.
:: His response was 'Feel free.'
::
:: Reposted by Skillz on Driverpacks.net Forums at http://forum.driverpacks.net/viewtopic.php?pid=11604
:: Modified and expanded by Haudy Kazemi:
:: -improved handling of paths with spaces in them (added quotes around '%cd%' in SET STDOUT line)
:: -added error messages rather than silently exiting
:: -added ability to configure filename of output file
:: -added a check to see whether the output file name already exists to prevent accidental overwriting
:: -cleaned up output and added status and progress information
:: -Skillz reported that tab characters are not removed by the script.  I worked around this problem
::  with this command: sed -T -e "s/	//" hwids.txt > hwids-tabsremoved.txt
::  (tested and found to work correctly using 'GNU sed version 4.1.5' on Windows XP)

IF "%1"=="" GOTO INFO
IF NOT EXIST %1 GOTO FOLDERNOTFOUND
IF "%2"=="" GOTO NOOUTPUTFILE
IF "%3"=="overwrite" GOTO SKIPOUTPUTFILECHECK
IF EXIST "%2" GOTO OUTPUTFILEEXISTS
:SKIPOUTPUTFILECHECK

:: Check for SED.EXE on path (derived from sample code in viewpath.cmd on http://www.ss64.com/nt/path.html )
:: I (HK) contacted Simon Sheppard of ss64.com on 4/7/2008 about using a derivation of his code and
:: releasing it under both the GPL and Creative Commons Attribution licenses.  His response was 'Sure, no problem'.
:: Note: I (HK) have put together a related script called ProgramPath that exposes this search-the-path-for-a-file
:: ability directly on the command line.
::echo the path one line at a time
for %%G in ("%path:;=" "%") do (
 ::echo %%G\sed.exe
 IF EXIST %%G\sed.exe GOTO SEDEXEFOUND
)
GOTO SEDEXENOTFOUND
:SEDEXEFOUND

echo Beginning scan...this may take a few minutes...

SETLOCAL ENABLEDELAYEDEXPANSION
SET STDOUT="%cd%"\%2
SET OUTPUTFILE=%2
TYPE>%STDOUT% 2>NUL

::traverse drivers path
CALL :TRAVERSAL %1

::Use sed to find and remove any tab characters in the output file
::This is a workaround for the problem reported by Skillz
echo Running SED.EXE on %OUTPUTFILE%
sed -T -e "s/	//" %OUTPUTFILE% > %OUTPUTFILE%-tabsremoved.txt
del %OUTPUTFILE% 
ren %OUTPUTFILE%-tabsremoved.txt %OUTPUTFILE%
echo Job completed.
GOTO EOF

:TRAVERSAL
echo Processing %1
PUSHD %1
for /f %%f in ('dir /b *.inf') do (
 echo Processing %1\%%f
 for /f "eol=- tokens=2 delims=," %%i in ('find /i "pci\ven" %%f') do (
  for /f "tokens=*" %%j in ("%%i") do (
    for /f "tokens=1* delims=_" %%k in ("%%j") do (
      if /i "%%k" EQU "PCI\VEN" (
        for /f "usebackq tokens=1* delims=; " %%a in ('%%j') do (
          echo %%a=%cd%\%%f>>%STDOUT%
        )
      )
    )
  )
)
)

FOR /F %%I IN ('DIR /AD /OGN /B') DO (
CALL :TRAVERSAL %CD%\%%I
)
POPD
GOTO EOF

:INFO
echo Inf Scanner 20080407 by Haudy Kazemi
echo Credit is due to IcemanND for the core INF scanning engine, and
echo to Simon Sheppard for his system path parsing example.
echo Dual licensed under the GPL and Creative Commons Attribution License
echo.
echo This script is designed to scan a directory tree containing MassStorage device
echo INFs to find their HWIDs and output them to a file that can then be added into
echo a SYSPREP.INF.  This script should work on any INFs, in case you want to
echo gather a collection of HWIDs for other types of hardware.
echo.
echo HWIDS %%1 %%2 %%3
echo %%1 is the path to folder/tree containing DriverPack MassStorage or other INFs
echo    (e.g. C:\D\M ).
echo %%2 is the name of an output file to store the HWIDS in (e.g. hwids.txt)
echo %%3 should be the word 'overwrite' if you want to replace an existing output
echo    file of the same name
echo.
echo Messages of 'File Not Found' are normal.  They are caused by the script's use
echo of 'dir /b *.inf' coming across folders with no INF files in them.  These can
echo safely be ignored.
goto EOF

:FOLDERNOTFOUND
echo ERROR: The specified folder was not found.
echo Please specify another folder location.
GOTO EOF

:NOOUTPUTFILE
echo ERROR: No output file specified.
echo Please specify the name of an output file to store the HWIDS in (e.g. hwids.txt).
GOTO EOF

:OUTPUTFILEEXISTS
echo ERROR: File overwrite prevented.
echo You chose an output filename that already exists.  Please delete that file,
echo enable overwriting, or choose a different filename.
GOTO EOF

:SEDEXENOTFOUND
echo ERROR: SED.EXE was not found anywhere in the system path.
echo Please make it available on the system path.  It is needed to remove
echo extra tabs in the output file.
echo Note: GNU sed version 4.1.5 is known to work correctly on Windows XP
echo and can be obtained from http://gnuwin32.sourceforge.net/packages/sed.htm
GOTO EOF

:EOF

I call HWIDS.CMD with another script named hwidscan.bat.  This specifies the folder to scan, the name of the output file, and to force an overwrite of the output file if it already exists:
HWIDSCAN.BAT

:: Put together by Haudy Kazemi on 4/7/2008 to automate the HWIDS.CMD scan and update
hwids.cmd c:\drivers\dp\D\M hwids.txt overwrite

In the process of creating the improvements to HWIDS.CMD, I wrote code to verify that SED was available.  Here is that code in a standalone form, called ProgramPath.  It's job is to check to see if a program or file is available somewhere on the system path, and report back any locations it finds.

PROGRAMPATH.CMD

@echo off
if "%1"=="" goto INFO

::echo the path one line at a time
for %%G in ("%path:;=" "%") do (
 ::echo %%G\%1
 IF EXIST %%G\%1 echo %%G\%1
)

goto END

:INFO
:: I (HK) contacted Simon Sheppard of ss64.com on 4/7/2008 about using a derivation of his code and
:: releasing it under both the GPL and Creative Commons Attribution licenses.  His response was 'Sure, no problem'.
:: Based on Simon Sheppard's viewpath.cmd
:: at http://www.ss64.com/nt/path.html
:: and http://www.ss64.org/dl1/ss64win.zip

echo ProgramPath 20080407 by Haudy Kazemi
echo Credit is due to Simon Sheppard for his system path parsing example.
echo Dual licensed under the GPL and Creative Commons Attribution License
echo.
echo Checks to see if a program or file is available on the system path:
echo   PROGRAMPATH %%1
echo where %%1 is the name of the file you want to check for
echo.

:END

OverFlow, I was not and am not trying to insult your intelligence.  I was trying to ask an honest question whether I was unclear.  I realize what I posted was for Windows XP, but a lot of XP techniques work on 2003 and vice versa.  My process involves using Sysprep and Ghost 7.5 for DOS to create a Sysprep-ed Windows XP image that works across many hardware types and is self-contained on a bootable DVD.

My interpretation of the original poster's message (self-proclaimed as 'My English is comparatively bad') is s/he is trying to transfer an already installed copy of Windows 2003 from one machine to another via a Ghost image.  This is basically the same thing that I do in my process, except that I do it with XP not 2003.  I read the 'Be an ghost image , be not a bootable CD' to mean s/he doesn't want to create a slipstreamed clean-slate installation CD.

My process is not a clean-slate install method.  Your linked to method of unattended XP install plus apps via Windows Post-Install Wizard (WPI) is a clean-slate install method.  My process will work for someone who has an existing image they want to transfer to new hardware without recreating the image or re-implementing it under the clean-slate unattended XP+WPI process.  My process will also work for applications that need to be heavily, manually customized during or after installation, rather than using the default silent install options for the application.  Some of the apps I install in my image are, as far as I know, only tweakable after being installed, and I don't know how to automatically change those settings if I were to use the unattended XP+WPI process.  (Maybe AutoHotKey could help me out here, but I have not tried that possibility.)  My process will also work for programs that require a serial/registration key to be entered during the install, rather than being scripted, to be installed.  (Granted, this is only useful for apps that you have a site-license for, but that require a key upon install anyway.)

If one were to ask Microsoft the correct way to do this, they'd probably also point to an unattended clean-slate install.  However, that's not the only way to make it work, and in situations where you want to migrate an existing installation from physical-to-physical hardware or between physical and virtual hardware, my process for XP may have a chance for working with 2003.

Note: here's another description similar to the process I describe, http://www.novell.com/coolsolutions/trench/11664.html .  I think that was one of the original documents I saw on making this technique work.

Again, OverFlow, I'm not trying to aggravate you.  I simply think we are interpreting the OP's message differently, and are both presenting reasonable solutions.  The solution you pointed out is probably the better route if one were to start from scratch, but that's not my starting point right now.

OverFlow wrote:

I think you just reinforced my point...

if you must modify the image in order / before to use it
then you can't have one image for all of them can you...

sysprep is an option too... but then its not a JUST a ghost image anymore is it?
its a unified installation.

and it will take a LOT more time to do as you suggest than to make two or three images that will be much cleaner in the end.

Perhaps you didn't understand what I was trying to explain?  Once you've made a master image (or converted an existing image) to use the ACPI PC HAL type, that HAL type remains in place.  I have a single image that has worked on machines Pentium 3's to Core 2 Duos, both laptops and desktops.  My master Ghost image does use Sysprep, with the last command being 'sysprep -reseal -mini -forceshutdown'.  When I want to update the image, I load it on compatible hardware, make the changes, set the pagefile to zero, delete pagefile.sys, and then re-Sysprep the machine.  I create the Ghost image using a DOS version of Ghost.  For standalone deployment, I create a bootable DVD containing DOS Ghost, and the Ghost image.  (Sysprep doesn't actually create the image, it just prepares the machine for imaging.  I'm using DOS Ghost to take an image of the machine after Sysprep has done its work.  I think that Ghost4Linux might also work for this purpose.)

The two main keys for a universal image are to use the ACPI PC HAL type, and to have the proper entries in the MassStorage section of sysprep.inf.

OverFlow wrote:

Ghost images are made after windows install is finished.

Driverpacks are applied during windows installation by setup.

You would need to have a ghost image for each HAL and Primary HDD (boot partition) controler type that you have.
If all of your machines are the same type (HAL and mass storage) you can use ghost.
Otherwise you must have one ghost image per machine type.

RIS is an option that may work for you. If you wish to use DriverPacks with RIS I suggest RogueSpear's AutoImage

It is possible to have a unified image, even across different HAL types. (In particular, I know that switching HALs works between the various ACPI HAL types of ACPI PC/ACPI Uniprocessor/ACPI Multiprocessor, however going back and forth to the old Standard PC and MPS PC HAL types may not work.)  I discovered this technique in the summer of 2006 while attempting to create a unified Windows XP Ghost image that would work on many hardware types (laptops, desktops of various makes and models, all using ATA drives or SATA drives in ATA mode (not AHCI mode).  The commercial software package Universal Imaging Utility (UIU) from Binary Research has similar capability (http://binaryresearch.net/products/the_universal_imaging_utility/features ).

Recently I have been evaluating using DriverPacks to enhance the unified Ghost image to add additional mass storage controller support beyond those built into Windows XP SP2, especially Intel AHCI support.

The key to unifying the HAL is to have your master image be a ACPI PC, and then after deploying it changing the HAL type to ACPI Uni or ACPI Multiprocessor.  To re-enable the ability to make this change using the Device Manager, edit these sections of HAL.INF to read as follows:

[GENDEV_SYS]
%E_ISA_UP.DeviceDesc%     = E_ISA_UP_HAL, E_ISA_UP, MPS_UP, MPS_MP, ACPIPIC_UP, ACPIAPIC_UP, ACPIAPIC_MP   ; Standard PC
%ACPIPIC_UP.DeviceDesc%   = ACPIPIC_UP_HAL, ACPIPIC_UP, ACPIAPIC_UP, ACPIAPIC_MP                           ; ACPI PIC-based PC
%ACPIAPIC_UP.DeviceDesc%  = ACPIAPIC_UP_HAL, ACPIPIC_UP, ACPIAPIC_UP, ACPIAPIC_MP              ; ACPI APIC-based PC (UP)
%ACPIAPIC_MP.DeviceDesc%  = ACPIAPIC_MP_HAL, ACPIPIC_UP, ACPIAPIC_UP, ACPIAPIC_MP              ; ACPI APIC-based PC (MP)
%MPS_UP.DeviceDesc%       = MPS_UP_HAL, MPS_UP, MPS_MP, ACPIPIC_UP, ACPIAPIC_UP, ACPIAPIC_MP   ; MPS UP PC
%MPS_MP.DeviceDesc%       = MPS_MP_HAL, MPS_UP, MPS_MP, ACPIPIC_UP, ACPIAPIC_UP, ACPIAPIC_MP   ; MPS MP PC

[COMPAQ_SYS]
%SYSPRO_MP.DeviceDesc%    = SYSPRO_MP_HAL, SYSPRO_MP, E_ISA_UP, MPS_UP, MPS_MP, ACPIPIC_UP, ACPIAPIC_UP, ACPIAPIC_MP

As one of my post-imaging configuration steps, I have a batch file based Mike Laverick's http://www.rtfm-ed.co.uk/downloads/HAL_Update.txt and DEVCON.EXE from http://support.microsoft.com/kb/311272/ that changes the HAL to ACPI Uni or ACPI Multi.  This is the first post-imaging manual step, where I must know whether the machine can handle the HAL change before I try it, because if it is incompatible Windows will not boot afterwards.  I generally only use the batch file to enable ACPI Multi, and I know to use it whenever I'm on a machine with dual CPUs, dual core CPUs, or HyperThread-enabled CPUs.

I have not explored whether it is possible to move between mass storage types (IDE to SCSI or vice versa), but if it is possible, it will probably involve editing the boot.ini file after deploying an image but before it first boots up.  I've read of this kind of editing being done using a BartPE Windows XP bootable live CD where the goal was to change the HAL type.