This is really strange....

I've got a server which I can produce a ghost image from. All looks good. 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.

Trouble is no matter how many times I reboot and then recreate the image, the first time it boots after an image restore it finds this new hardware. I must admit I dont understand.

I know it sounds like nothing but the image is going to be rolled out to a few customers, so we need a decent clean image....

Any ideas?

Brian wrote on Mar 31^st, 2010 at 2:29pm:


Windows 2000. Ghost 8 (yeh, I know).

Interesting about the partition. I dont think so but I'll check.

paulfoel

Quote:

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:


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:

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?

paulfoel

Quote:

Well, you can use it on another machine or other replacement HDD on the same machine--but the NT-signature will not match what the OS is expecting to find if it's not a restore to the same source HDD--that may cause the OS to go through a resetting of the drive letter assignments and may trigger that same *new hardware found - generic volume* routine.

I don't work with server based OSs and I've not attempted to use that switch on a different HDD or machine--so I don't have any personal experience with what happens under those circumstances.

If you are going to be testing your deployment plans, it would be interesting to hear your results.