If anyone has tried syspreping Windows Vista Beta 2 inside a VM, you may have noticed that the VM Additions are still installed but not functional afterwards (this only happens if you use the /generalize switch). This is because of the way that the new Sysprep Generalization phase works. The idea here is that the system starts with a totally clean slate, and PnP detects the "best" driver for the hardware all over again.
For some reason, the drivers included with the Additions are not detected as the "best" fit. I'm not on the setup team, so I'm not sure why, but that's what seems to be happening.
There are a few ways to work around this. The first, and most obvious way, is not to use the /generalize switch on Sysprep. While this has the pro of not breaking our Additions, there are a lot of cons involved with doing this. The big one is that the unique information about the system's identity (the system's SID, for example) aren't reset if you don't generalize, which causes a boatload of problems if you want to deploy the VM to multiple people/places.
The other - and preferred - way to do this is to provide an answer file to Sysprep when you run it. You'll need to set the PersistAllDeviceInstalls flag to "true" in the "generalize" pass. Here's a sample unattend file which contains that information:
<unattend xmlns="urn:schemas-microsoft-com:unattend" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"> <settings pass="generalize"> <component name="Microsoft-Windows-PnpSysprep" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <PersistAllDeviceInstalls>true</PersistAllDeviceInstalls> </component> </settings></unattend>
Assuming you've named this file sysprep.xml, you'd tell Sysprep to use this as an answer file with the following command:
sysprep /generalize /unattend:sysprep.xml
(of course, you can throw in any other switches that you need, too.)