Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We run an office full of laptops that are all different ages/configurations with lots of different hardware. Basically we want to upgrade every laptop to windows 7, the classic ghost deployment wouldn't work as far as I am aware, as the varying hardware would cause a range of issues. I have been investigating sysprep and also the possibility that you can simply ghost the images across to new hardware with no issues since vista was deployed. Can anyone confirm/deny this? or provide some insight on how to copy a windows 7 image to new hardware with minimal issues?

share|improve this question

The recommended way is to use the WAIK, but at the very least you should be using sysprep on the "master" image before capturing the image and deploying it.

share|improve this answer

Maybe just easier to upgrade all of the machines to one standard brand, model and configuration and which comes preinstalled with the version of Windows that you're looking for. Once you do that, you can just create an image of the installation, and when a replacement is needed, take the new machine and just re-image it with the master image.

Good luck and hope this helps some.

share|improve this answer

As of Ghost Solution Suite 2.5 (the product which actually contains Ghost, since the "Norton Ghost" product is a consumer tool based on different code these days) Ghost deployment actually can work across diverse hardware, even without using Sysprep.

In GSS 2.5 an extra tool is included called "Deploy Anywhere" which can help install certain critical types of driver into a recently-deployed Windows install (this tool itself runs from Windows PE rather than DOS; Ghost Solution Suite 2.5 changes the default OS from which managed Ghost operations run to Windows PE largely as a consequence of this, although the Ghost Boot Wizard can also build DOS or Linux boot media for you for traditional styles of Ghost deployment without DeployAnywhere).

In the main, what running Sysprep does on a machine is two things; arrange to trigger Windows Setup the next time the machine is rebooted, and change the mass storage driver loaded for the next boot to be a reasonably generic one rather than a hardware-specific one. This is done by Sysprep before the image is taken, so that the image is generic. Lots of other options in Sysprep do exist, which mainly revolve around scripting what the Windows Setup wizard ends up doing on that next boot aside from re-detecting all the installed hardware.

DeployAnywhere in GSS 2.5 works somewhat similarly, except that you don't need to run Sysprep ahead of time to generalise the image; it can adjust the target Windows install after deployment to trigger the hardware redetection, and can also adjust the storage driver to ensure that the next boot succeeds. It arranges to directly install a replacement hardware-specific driver in the newly deployed OS rather than a generic one, and so for this it works with a library of storage and network drivers (which the Ghost Boot Wizard maintains) to which you can add additional ones.

Whichever toolchain you use, you should be able to get things to work; the choice between DeployAnywhere and Sysprep really depends on what kind of overall process you want to set up. The main thing that the GSS toolchain (particularly the managed deployment in the GSS console) is set up to let you do is get away with making arbitrary adjustments to what happens after you've captured your baseline image without requiring too much up-front preparation, whereas what Sysprep does is driven by scripting the Windows Setup system via XML files - but once you've got those scripts right, you're not dependent on any third-party toolchain.

share|improve this answer

Windows Vista and 7 overcame the major issue with deployment on different hardware by removing the need for the chipset and disk controller to be identical (or compatible) between source and destination; this allows them to properly boot when moved to different hardware, and then do what Windows has always been doing since '98: do some plug&play and discover what hardware it's actually running on.

This doesn't mean you won't have to provide drivers if needed: there could still be some device on the new system which your image doesn't have drivers for. But it will not crash with INACCESSIBLE_BOOT_DEVICE anymore.

Also, SYSPREP is still a must, otherwise you'll end up with a bunch of computer with the same SID, which will wreak havoc on your network.

If you want more control on your deployment, you should definitely have a look at the Windows Automated Installation Kit and the Microsoft Deployment Toolkit.

share|improve this answer
Actually according to sysinternals having multiple computers with the same sid is not a problem.… – devSpeed Feb 23 '10 at 22:23
But it still can cause troubles, and not doing it is plainly and simply not supported. – Massimo Feb 23 '10 at 22:49
true Sysprep is needed for mass deploys, but not for the SID issue you mentioned. It also does other things which do make a difference. The SID issue just isn't one of them. – Goyuix Feb 24 '10 at 2:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.