passmaster16

What we are looking to do is create a *universal* Windows 7 image that could be used on any of our desktops (HP & Gateway). We would create a separate *universal* image for our laptops (HP & Dell). We would be creating the Windows 7 environment (OS + Essential Applications) on a reference machine then use Sysprep combined with an unattended file to complete the setup on target computers. Right now, this is relatively straightforward with our XP build. We created our "base build images" years ago, and now we simply update our images every few months to include the latest patches and application updates. Then we run sysprep and use Ghost to make an image of machine. With XP, we can drop the image, update, sysprep, and push the image back as many times as we want. My first concern with Win7 is if sysprep /generalize can only be run 3 times, this would seem to prevent us from updating our images on a regular basis. After the third time, I assume it will no longer allow sysprep /generalize to be run. Right now, we probably update our XP images at least 3-4 times a year. So, my question is how does a corporate customer who constantly updates images handle this situation? We really wouldn't want to have to go back and build a fresh image of Win7 for the sake of running sysprep /generalize three more times. We are a volume licensed customer and will be using Win7 Enterprise. We would be using MAK activation. According to the WAIK documentation, it mentions setting the SkipRearm setting to 1 during the generalize phase but then set it back to 0 prior to deployment. Would this mean I would need two separate images? One image that is my base image that would be used for modification would have skiprearm enabled while my "gold" production image would not have skiprearm? My second concern is related to driver installation. I know that I could inject the drivers into the WIM, but I'd rather just let Windows PNP handle the work as was done with the OEMPnpDriversPath in XP. I read a thread http://www.msfn.org/board/unattended-driver-paths-t137538-pid-880434.html/page__p__880434__hl__OEMPnpDriversPath__fromsearch__1#entry880434 here that talked about adding a drivers path to either the AuditSystem or OfflineServicing passes. Has anybody done this with success? What about issues with unsigned drivers? Would it be better to install drivers during AuditSystem or OfflineServicing? My thought was to install them during OfflineServicing because that pass runs during Windows Setup. I would assume that to do it during AuditSystem would actually require Sysprep to be run twice, once to enter Audit mode and again to exit Audit mode and to start OOBE. Is this correct? Right now, I'm more or less being proactive in learning as much about the product as possible as we do not have any immediate plans for rolling out Win7 in the near term future.

I'm using WinPE 2005 from the Windows 2003 SP1 source on a Sandisk USB flash drive. I've used this setup without issue on both desktops and laptops until recently when we received laptops with SATA controllers. I edited txtsetup.sif and successfully added the device strings for the SATA controller so that PE can see the hard disk. My issue now is that for some reason when SATA is enabled, and I boot from the USB key, the USB key gets a volume # of 1. This is problematic when I attempt to run Ghost 8 using the following command: ghost32 -clone,mode=prestore,src=image.GHO:1,dst=1:1,sze1=V -rb What happens is that even though the flash drive is assigned letter X, and my two existing NTFS partitions are C: and D:, the Ghost command is trying to restore the image to the first partition on Volume 1 which is assigned to the flash drive. So in this instance I have the following: Volume 0 - E: - CDROM Volume 1 - X: - USB Flash Drive Running PE (Removeable) Volume 2 - C: - NTFS Windows System Partition Volume 3 - D: - NTFS Data Partition Obviously I do not want this to happen. I want to restore my partition to C: regardless of the Volume #. Oddly enough, the behavior does not occur when I boot PE from a CD regardless if SATA is enabled. Also, if I turn off SATA and use ATAPI/IDE mode while booting PE from USB, I get the C: drive as Volume 1. Is there any way to either force my USB device to take Volume 1 upon bootup or is there a way to force Ghost to restore the image back to the C: partition? I was thinking I could probably use some sort of script to check the current Volume status but I'd like a simple solution as possible. Thanks

Thanks. I was under the impression that BuildMassStorageSection is used to simply populate the SysprepMassStorage section of Sysprep.inf. Since I already populated SysprepMassStorage using sysprep -bmsd, I did not think BuildMassStorageSection was required. Doesn't Sysprep see that there is a SysprepMassStorage section and parse those drivers automatically? According to the deployment guide You can run the command Sysprep -bmsd instead of including the BuildMassStorageSection entry in your Sysprep.inf file. When you run the command Sysprep -bmsd, Sysprep populates a pre-existing [sysprepMassStorage] section, but the mass-storage controllers are not installed until the next time you run Sysprep. You can then delete items from this section before running Sysprep -reseal or Sysprep -factory on this installation. Installing a smaller number of items in the critical device database reduces the time required for this image to restart into the operating system.

I just realized I should have posted this in the Unattended forum. Mods feel free move this. Thanks!

I've always noticed this odd behavior with Sysprep for XP SP2. It seems that every other time I run Sysprep on my build image, it will alternate between shutting down very quickly (usually within a minute) vs taking a long time (20-30 minutes) to shut down. The behavior is actually documented on this http://www.vernalex.com/guides/sysprep/issues.shtml#drivers website. I am pretty certain that this is due to the fact that Sysprep is not parasing the SysprepMassStorage section of the Sysprep.inf file when these quick shutdowns occur. The issue never seemed to adversely affect my machines until I added the new Intel Sata drivers for new hardware we were getting in. After adding the new drivers and running Sysprep, my build machine did a quick shutdown. Upon restart, the Sata drivers did not install on my new hardware, and the system went into a reboot loop. I proceeded to go back and run Sysprep again, this time it took about 20 minutes to shut down. This resulted in a successful load of the image on my new hardware. Is this a known issue with Sysprep? Is there any way to force it to parse the Mass Storage section every time? One of the suggestions listed on the website above mentioned keeping a "gold" image and Sysprep it to create a "final" build. This would not be ideal as I have already run Sysprep on my final images so I'd have to rebuild them from scratch to have clean, non-sysprepped images available. For now I've been simply watching the Sysprep process, and if the machine shuts down too quick, I just reboot it, log in and run Sysprep again. This usually results in the proper parsing of the Mass Storage drivers. It's a bit Inconvenient though so I'd like to know of a way to force the parsing every time. I'm running sysprep -mini -reaseal A sample of my Sysprep.inf file is below ;SetupMgrTag [unattended] OEMSkipEula=Yes UpdateInstalledDrivers=yes DriverSigningPolicy=Ignore OEMPnpDriversPath="\i386\$oem$00_chipset; removed remaining drivers" [GuiUnattended] AdminPassword="password" EncryptedAdminPassword=NO OEMSkipRegional=1 OemSkipWelcome=1 OEMDuplicatorString= [userData] ProductKey=XXXX FullName="User" OrgName="name" ComputerName= [Display] BitsPerPel=32 Xresolution=1024 YResolution=768 [GuiRunOnce] [identification] JoinWorkgroup=WINXP [Networking] InstallDefaultComponents=Yes [sysprepMassStorage] *pnp0a00=c:\windows\inf\machine.inf *pnp0a01=c:\windows\inf\machine.inf removed remaining drivers