Ghost Solution Suite

Greetings

I have used GSS to clone Windows XP computers for a good while, but I am now facing cloning Windows 7 computers for the first time. I have googled on the subject and discovered many tips (Windows 7 needs two partitions to boot, how to enable local admin account after sysprep and so on) but sysprep has left me confused even after reading several articles and blog posts on the subject. I should mention that we do not use Active Directory.

I have not used sysprep with Windows XP. With Windows XP I have created a complete image with applications, drivers and customized user profile settings and then cloned that image to computers that are identical in hardware and function. With Windows 7 I must use sysprep. I have installed a KMS-server that has the necessary Windows 7 activation key.

I would like continue using my old routine: create a complete image with applications, device drivers and customized user profile settings, but some articles on sysprep suggest that it is not possible, that some settings are lost in the sysprep /generalize process that is required for KMS to work.

1) Is it possible to install drivers, applications and customize per user profile settings for the master image, or will sysprepr /generalize screw them over?

2) Windows activation, KMS and sysprep. I have read about rearm/skiprearm, but have not understood them completely. With KMS the activation limit (3 per installation) is apparently eliminated. Do i need to use skiprearm when creating my master image and/or when cloning the clients? If so, how exactly?

3) Can I install all the stuff I need (applications, drivers, user profiles and their customized settings) and then sysprep and create the master image? Some articles say one must use syprep /audit mode to install application and customize settings on the master computer before creating the image. Is this true? If so, at what stage (right after installing windows or before any third party drivers and applications are installed)?

4) Can I control the image creation process from start to finish from within Ghost Console? One user executed sysprep that ended with a shutdown command. Then he created the master image using a ghost boot cd. That sounds clumsy. I had assumed, upon starting an image create task, that the computer would first execute sysprep and then reboot into the GSS virtual partition that would create the master image

5) Does the restoration of old computer name and ip address settings after cloning work when using sysprep? Some examples have suggested that the computer name needs to be specified in sysprep settings (if left empty, random names will be generated).

6) We have some computers with Windows XP that will be upgraded to Windows 7. Can I use ghost to clone a Windows XP computer with a new Windows 7 image?

Answering these questions in any detail would require more time and space than can reasonably be expected in a forum, but I will have a stab at pointing you in the right direction.

1. and 3. Impossible to answer this accurately without knowing all about all your applications. KMS can also handle Office activation, and I see no reason why you cannot build an image with apps installed. If you have any application packagers in your company - work with them, as they should understand which apps have user profile settings that need to be handled correctly. However, that is what application packaging is all about - converting dodgy vendor installs into installs that work in an enterprise environment. Building a driver library is standard procedure for windows builds and is much easier in Windows 7 than XP as & will recurse through the driver folders looking for any driver match. If you have not already done so, download the Microsoft Windows Automated Installation Kit for windows 7 and spend some time working through the documentation.

2. Sysprep removes licensing information so that each machine will need to be reactivated/relicensed when the machine first starts up. KMS is the simplest solution for enterprise environments. When you create a new image from an old one, you will load the old image, which has been sysprepped once, make changes, and sysprep again. This works for up to 3 syspreps and then no more are allowed, unless you use the rearm switch which effectively resets the sysprep counter to 0 or 1. Googling is a good way of finding specific information on this type oif topic.

4. My personal preference is to use Ghost for imaging and the Microsoft tools for build creation. Each is optimised for those activities, and although it may appear clumsy, it reduces the number of variables that have to be explored if anything fails to work as expected.

5. Ghost should be able to do this for you, but again, there are many different solutions that users have implemented. One novel solution was to code the workstation name into the BIOS using the asset tagging option, and then retrieve this information using WMI during the first boot. The machine could then be finally configured by control scripts that run on first boot.

6. Again, impossible to answer without knowing exactly what hardware is involved.  I can generalise to the point where I can say that any machine whose hardware is capable of having Windows 7 installed on it, and for which suitable drivers can be found for all devices, can be updated from XP to Win 7 using Ghost, as long as the image has the correct drivers in the driver library and is deployed with the appropriate 32 bit or 64 bit version of Win 7.

I am struggling with this one too:

https://www-secure.symantec.com/connect/forums/creating-windows-7-image-ghost-solution-suite-gss-25-11512266#comment-7444071

I will try WAIK and see, but the KMS stuff I have working. Do not enter any license key in the sysprep setup and ensure the DNS settings can find the KMS Server and that takes care of that. Also, make sure you tick Skip Rearm or you will not be able to use the machine more than 3 times.

I have commented in msassoon's link

1) put the drivers (expanded) in a folder on the drive.  Add that drive to the DRIVERPATH reg key (leave whatever is already in there alone)  this will tell sysprep to also traverse those folders looking for drivers.  Apps can be installed on the machine (like office) but any per user settings would be made by the users when using the app (customizations, etc)

2) rearm tells the computer to phone home and check its stuff.  OEMs use this with the copies of windows they send out.  with KMS volume licensing, you do not want to increment the counter since you have more licenses.  Say you want to use the same machine to keep making backups to update windows, you will quickly hit that 3 time limit.  That would be VERY bad

3) yes, you can do that.  I do not use /audit (i could never get it to do what i wanted it to do the way i wanted/expected it)

4) that user is probably me.  the reason i do that is now when the image is restored to a new machine, the first thing it does when it turns on is finish the sysprep.  This is needed when the machine you are restoring to is different then the machine you cloned

5) you can set a name in the WAIK (or tell it to leave the old name alone) but i use GSS to rename the machine with the configuration after the clone.  nice and easy

6) we did the XP -> 7 conversion, but by completely wiping the XP machine and restoring Win7 to it.  Assuming the XP machine can support Win7 and the version you want (older Pentium 4 procs using Win 7 x64, for example)

Answering these questions in any detail would require more time and space than can reasonably be expected in a forum, but I will have a stab at pointing you in the right direction.

Thank you for your effort :-)

1. and 3. Impossible to answer this accurately without knowing all about all your applications. KMS can also handle Office activation, and I see no reason why you cannot build an image with apps installed. If you have any application packagers in your company - work with them, as they should understand which apps have user profile settings that need to be handled correctly. However, that is what application packaging is all about - converting dodgy vendor installs into installs that work in an enterprise environment. Building a driver library is standard procedure for windows builds and is much easier in Windows 7 than XP as & will recurse through the driver folders looking for any driver match. If you have not already done so, download the Microsoft Windows Automated Installation Kit for windows 7 and spend some time working through the documentation.

I am a one man it-support department and I don't have the tools or the knowledge to package software for remote installation. That is why i have found the "old way" of installing drivers and software, customizing settings and then creating an image that is distributed as is without sysprep very convenient. There are many settings that need to be adjusted (network printers, filetype associations, display settings, media player settings etc.) to make life easier for our end users. If sysprep forces them to use most sofware with default settings then that will be a step in the wrong direction from their point of view.

Does sysprep really remove all the device drivers I have installed manually prior to sysprep? Not a problem with chipset drivers if the driver folder is available, but will the network printers I have configured work after sysprep?

Another driver related problem is display settings I mentioned above. If I have a computer with a monitor and a projector in clone mode, will that survive the sysprep process? GSS can restore old display settings (most of the time) with the way I currently use it (cloning without sysprep).

2. Sysprep removes licensing information so that each machine will need to be reactivated/relicensed when the machine first starts up. KMS is the simplest solution for enterprise environments. When you create a new image from an old one, you will load the old image, which has been sysprepped once, make changes, and sysprep again. This works for up to 3 syspreps and then no more are allowed, unless you use the rearm switch which effectively resets the sysprep counter to 0 or 1. Googling is a good way of finding specific information on this type oif topic.

Terry BU:s answer suggests that KMS users don't neet to rearm, so "skiprearm = 1" should be used?

5. Ghost should be able to do this for you, but again, there are many different solutions that users have implemented. One novel solution was to code the workstation name into the BIOS using the asset tagging option, and then retrieve this information using WMI during the first boot. The machine could then be finally configured by control scripts that run on first boot.

I hope the old way works (GSS restores old settings), guess I'll find out during testing.

6. Again, impossible to answer without knowing exactly what hardware is involved. I can generalise to the point where I can say that any machine whose hardware is capable of having Windows 7 installed on it, and for which suitable drivers can be found for all devices, can be updated from XP to Win 7 using Ghost, as long as the image has the correct drivers in the driver library and is deployed with the appropriate 32 bit or 64 bit version of Win 7.

The computers do support Windows 7, we intend to move from 32 bit Windows XP to 64 bit Windows 7. I was only worried about possible limitations in GSS that would prevent replacing Win 7 with Win XP with a normal multicast session. If the HD has to be wiped and the new image restored manually on each computer, the operation would last much longer.

I thank you for your effort :-)

1) put the drivers (expanded) in a folder on the drive. Add that drive to the DRIVERPATH reg key (leave whatever is already in there alone) this will tell sysprep to also traverse those folders looking for drivers. Apps can be installed on the machine (like office) but any per user settings would be made by the users when using the app (customizations, etc)

I take it that sysprep removes all installed drivers? 

What will happen to settings that depend on device drivers, like multimonitor cloning settings and network printers? GSS can restore display settings (most of the time) in our sysprepless way of cloning, but what about network printers for example? Will they be lost in the process?

2) rearm tells the computer to phone home and check its stuff. OEMs use this with the copies of windows they send out. with KMS volume licensing, you do not want to increment the counter since you have more licenses. Say you want to use the same machine to keep making backups to update windows, you will quickly hit that 3 time limit. That would be VERY bad

Ok, so we should use skiprearm = 1?

4) that user is probably me. the reason i do that is now when the image is restored to a new machine, the first thing it does when it turns on is finish the sysprep. This is needed when the machine you are restoring to is different then the machine you cloned

But why booting of a GSS boot cd instead of the GSS virtual partition? When you initiate the image pull operation from the GSS console, it executes the sysprep process and then (optionally) restarts. Wouldn't the computer then load the GSS client to execute the image pull operation before rebooting again and then finishing sysprep? When you push that image to other computers, they would finish the final stage of sysprep after rebooting as well.

5) you can set a name in the WAIK (or tell it to leave the old name alone) but i use GSS to rename the machine with the configuration after the clone. nice and easy

So the old way works, excellent :-)

6) we did the XP -> 7 conversion, but by completely wiping the XP machine and restoring Win7 to it. Assuming the XP machine can support Win7 and the version you want (older Pentium 4 procs using Win 7 x64, for example)

So you did not replace Win XP with Win 7 using GSS. Did you use a boot cd?

Couple of follow ups.

1. If using multicasting, make sure that IGMP snooping is configured on your switches.

2. I have never known sysprep remove drivers from an image. When a system boots, plug and play reads the Device ID of every PNP device on the computer (and there are MANY) and looks for the ID in the INF files on the system. These INF files store information about the associated driver files for the supported device IDs allowing the operating system to locate and load device drivers for all the internal devices.

Therefore, as long as you have the correct driver files in the image, you should be able to support many different models.  However, as you are no doubt aware, there are also model specific utility files, especially on laptop machines, so it is often more convenient to just build a separate image for each laptop rather than spend a lot of time scripting model detection and utility installation.

1) Sysprep will remove the drivers [from being used, but it leaves them in the image in the same place you put them] if you use the /generalize flag.  If you have that folder of drivers and that folder is also listed in the driver path reg key you should be fine.  As for video settings, i find that it just takes the recommended settings from the card.  I use displaychanger through GPOs to set some of the stuff.  *[edited for clarity]*

2) you do NOT want it increasing that counter when you sysprep your backup.  you will quickly run into a generic error if it hits that limit

3) easiest answer of the bunch!

4) Let me back this up a bit to try to clarify what i do.  When we are creating an image BACKUP, we boot to that CD and back it up so the sysprep doesnt finish the part after the restart.  Our image master computer is different hardware then most machines we have on campus.  We do not use the sysprep in the console, only the sysprep built into Win7.  You want that part running on the machine that is restored with the image.  Now, if we hot restore a machine, we just do it through the console and let it reboot into the virtual partition, restore it, and THEN it picks up the sysprep from the backup file.  I will only use the CD for the RESTORE if the machine cannot boot into Windows

5) yay!

6) we did.  We just WOLed the machine, and rammed the Win7 image down.  We do not back up user profiles on the machines i support, since we use redirected profiles to a network drive.  No boot CD (unless the restore botched into an infinite reboot because someone shut the machine off in the middle....grr)

right.  The drivers stay on the drive, but they might not be loaded.  Sysprep will look for the drivers it needs (this is why that driver path key is so useful) and if it finds it then it will load it.  This is so useful when the 1 image supports (like mine) 6 different desktops and about 6 different laptop models too in one image

1) Sysprep will remove the drivers [from being used, but it leaves them in the image in the same place you put them] if you use the /generalize flag. If you have that folder of drivers and that folder is also listed in the driver path reg key you should be fine. As for video settings, i find that it just takes the recommended settings from the card. I use displaychanger through GPOs to set some of the stuff. *[edited for clarity]*

So, sysprep removes driver files that have been installed into operating system directories? Having extracted driver files available somewhere else (with the path specified) is compulsory in that case.

2) you do NOT want it increasing that counter when you sysprep your backup. you will quickly run into a generic error if it hits that limit

Agreed, but is using skiprearm = 1 the correct way to avoid incrementing the counter?

4) Let me back this up a bit to try to clarify what i do. When we are creating an image BACKUP, we boot to that CD and back it up so the sysprep doesnt finish the part after the restart. Our image master computer is different hardware then most machines we have on campus. We do not use the sysprep in the console, only the sysprep built into Win7. You want that part running on the machine that is restored with the image. Now, if we hot restore a machine, we just do it through the console and let it reboot into the virtual partition, restore it, and THEN it picks up the sysprep from the backup file. I will only use the CD for the RESTORE if the machine cannot boot into Windows

Ok, so the reason you use a boot cd to make an image backup is that you don't initiate the backup from the GSS console. I thought that GSS could initiate Win 7 sysprep if pointed to the correct files, am I wrong? If it does work, you wouldn't need to use a boot cd for backup.

6) we did. We just WOLed the machine, and rammed the Win7 image down. We do not back up user profiles on the machines i support, since we use redirected profiles to a network drive. No boot CD (unless the restore botched into an infinite reboot because someone shut the machine off in the middle....grr)

Ok, I misunderstood. Good to hear that GSS can be used for the upgrade.

Thank you for your help!

1) right, we have a DRIVERS folder in the root of C:, set up all nice with subdirectories like NETWORK, VIDEO, etc

2) my XML file has skiprearm=1.  From the WAIK:

4) the convienence of doing it this way is that if you want to use imagex to make the backup you can do that too.  GSS really doesnt allow that

i hope this all helps!

1) Ok

2) Ok. I  now recalled having read that if one uses skiprearm = 1 then it should be removed later. I now found this quote from Microsoft: "We recommend that KMS clients use the sysprep /generalize command where the value of the SkipRearm setting is equal to 1. After capturing this image, use the sysprep /generalize command, where the value of the SkipRearm setting is equal to 0."

Do you execute skiprearm = 0 on clients after an image push?

4) I have never used imagex. What advantage does is offer if GSS is already used to create and distribute images?

i usually dont change the skiprearm.  My computers are all on campus, and they dont leave.  It isnt necessary for me to do it.

ImageX is the tool that makes WIM files from HDs.  I have messed around with WIMs trying to get our copy of SCCM to do OS install, but i really prefer GSS in the OS restore area.