Vista VMWare Release SysPrep/Activation Best Practice?

I'd like to have dev environments 'baselined' with certain software installed along with component packages. From time to time, a new software piece may be desired which I'd like to install in a clean VM until confidence is obtained that it's desirable to be on the production dev box.

I have been playing around with a test system trying to 'versionize' it by naming it like DevUsr0105 (major version 01, sub version 05, DevUsr is username) but this gets difficult with activation.

I can imagine a time frame from release of the next version before deprecating the previous version so at some times there may be two DevUsr type VMs in use. (New dev happening on the latest dev release, and completing previous work on the existing VM before retiring it.) There's obviously no problem paying for two OS licenses per Dev but I don't want the hassle of calling in to migrate an activation. (Also - isn't there a limit on the # of migrations per license?)

Each developer would grab the latest production developer VM whenever a new release is available. Any of their local customizations would be versionized in their SVN repository to ensure a clean migration without a lot of manual work.

So is the latest release sysprep'ed and ready for final activation by the developer? Do we really need to transfer the activation or re-activate the OS on every dev VM release?

VM's are not actively being utilized yet by developers and I'm just looking for feedback on how something like this is being handled by others before wasting a lot time going down the wrong path.

Solution 1:

I actually just created 3 XP VMs for a group of developers. One for IE6, IE7, and IE8.

Sysprep requires you to re-activate the windows on each deployment. Rather than giving each developer their own test VM. Why not deploy three or four, and tell them that every friday these will be reset from an earlier snapshot?

Developers tend to leave a lot of litter wherever they work. Leaving services and ports open to the world. And using services bound to admin accounts. This is doubly true in a test environment.

Last week I shut off a web server thinking that since the website was no longer maintained, we didn't need the server anymore. Wrong. A small group of devs had been using the server to store source code and run scheduled tasks.

Setting a limit, once every week or two, on the time a dev system can be used may help keep your network clean.

The hard part for your system will be the licensing. Next time someone is fired, don't open your door to anyone from the BSA. ;-)