@
paulfoel Quote:If I then restore this image to the exact same server when it boots up it pops up a new hardware found message - generic volume found. If I OK this and then reboot it goes away.
Any ideas?
I think I've seen that before on at least one of my systems--and I'm using Ghost 2003--the most recent updated build--(which came out before Ghost 8!). I never thought much about it and just did what Windows said and re-booted--all gone, and no problems.
But, I don't think it happens under all types of Ghost procedures. So maybe only happens when a *whole disk* restore is done, and perhaps not a *single partition* restore. And, it may not happen under all versions of Windows.
So, my best guess.......
When you restore, Ghost *zeroes* the HDD's *NT-disk signature* that's located in absolute sector 0 of the Master Boot tract. If *zeroed*, then the NT-disk signature is re-created during first reboot (but, I think the number will be randomly different), so no problem there--but the way NT based Windows remembers drive letter assignments, etc., Windows will assume it's a *new* disk (i.e. *generic volume*)--and will run through its discovery routine to assign drive letters to the *new disk*.
(By the way, this is why older Ghost versions will not work properly with Vista's and Win7's boot methods--the zeroing of that NT signature screws up the boot process--unless you do *workarounds* to the Ghost process or those Windows boot procedures)!
You can probably test that *theory* easily by running Ghost with a switch added to the command line that loads Ghost--the *-fdsp* switch--which I think stands for *force disk signature preserve*!.
So, just looked it up for this next quote--and the User Guide specifies that the switch is only used when doing a *whole disk* procedure:
Quote:-fdsp
Preserves the signature bytes on the destination disk when performing a disk-to-disk or
image-to-disk cloning operation
So, adding that *-fdsp* switch to your Ghost command line that starts Ghost will prevent Ghost from *zeroing* the
destination HDD's NT signature. So, if the image was taken from that destination HDD, and is restored to the same HDD, then Windows will not see the HDD as a *new disk*--and I suspect the *generic volume found* will be absent.
(Note: the above is referring specifically to the *destination HDD* and not the *source HDD* as far as the *-fdsp* switch usage is concerned! So, you are not transferring the NT-disk signature from the original source HDD to the new destination HDD--the NT signature will be the same only if both the source and destination are the same HDD--
and you have not completely zeroed out (including the Master Boot tract) the destination HDD (that was the source HDD!) before the restore--because all that switch does is *prevents Ghost form zeroing the destination's NT signature*--so if the HDD was the source, then it will remain the same after the restore!
The only way I can think of that Ghost would *transfer* the NT disk signature so the source and destination would be the same is one of the *forensic* Ghost procedures that do a *sector-by-sector* copy of the source, including the Master Boot tract--then the restore to a different HDD would *potentially* have the identical signature (I say *potentially* because I've never tried it to confirm that!).
The other way to have the NT signatures match would be to *manually* edit the destination HDD's NT signature to be the same as the source!)
So, you may wonder *why is he going on like this about the details of the NT signature*? The reason is this:
Quote:the image is going to be rolled out to a few customers, so we need a decent clean image....
Are you *Sys-Preping* the original source system for *rolling* them out to other systems? Usually, you can not just restore an image to multiple systems and have everything work upon reboot! As far as Win-NT systems are concerned, there's no such thing as *identical* hardware systems! They are identified by unique CPU IDs, NIC IDs, HDD IDs, and possibly disk controller and motherboard IDs--if not functionality issues.
So, to transfer an image to multiple systems--you have to determine if Win-NT will function properly with the *different* hardware from the source system to the destination system--and, Windows Activation will probably be triggered. If there are functional differences, then you have to *Sys-Prep* the source system so it forces Windows to go through its *discovery* routines so appropriate drivers and settings are created on the destination system upon its first boot!
But, the bottom line is the destination HDD will not be the same as the source HDD--the NT signatures will not be the *same*--and *generic volume found* will most likely be triggered--but, I have to imagine a lot of other things will be *triggered* as well!
Does using the *-fdsp* switch alter your *generic volume found* routine?