Over the past two days I've been experimenting with Windows Guests and vCloud Director. If you didn't know, I updated my VM Advanced ISO with the correct syntax for vCloud cells so you can begin the guest customization process inside of a RHEL VM even faster. Please refer to KB 1026313 for installation.
After your vCloud cell is done being configured for sysprep, you are given a very limited Guest Customization option within vCloud and doesn't take advantage of vCenters Customization Specification Manager by being able to keep completed wizards. It's like having to re-build the wheel over and over. One thing to note, after you add a Windows VM to a vApp from catalog, the Enable Guest Customization checkbox will proceed by default if you don't take care of this before hand.
For instance, if I start creating a vApp, I go through the usual routine and I'm never prompted for any Sysprep or guest os customization work.
Now, I can go ahead and power on the VM, but that's probably not what you want to do. If you power on the VM, Sysprep will automatically take it's own standard course by assigning a random password to the administrator account and generating a new SID. To be able to too see what happens you need to drill down into the vApp and right click on every VM within the vApp and go to Properties.
Go to the Guest Customization tab and these are the default guest setting that will occur. As you can see, it's pretty limited compared to what you can accomplish in vCenter. You can basically get the VM to generate a new SID and by default, vCloud will assign a new administrator password such as F343#3ef. IMO, this is good for something like a public cloud service where I can pull out a credit card and just order a VM, but for any Enterprise utilizing vCloud, or for a Service Provider allowing multiple tenants to other Enterprises and connecting via site-to-site VPN, this is probably the worst way to position Sysprep. The problem occurs because users don't want to think about Sysprep, they just want a VM that already knows their credentials (domain or not):
Say, for instance, I went ahead and configured everything inside the Guest Customization tab the way I wanted, sysprep will basically erase everything. When I power on this Windows VM, sysprep will erase everything from the imported vSphere template including my CD Key. The CD Key will need to be entered and the Guest OS will need to be activated upon completion of sysprep. This is not an optimal solution because you don't want to hand out Corporate Windows Keys to anyone that plans on deploying a Windows Server.
I have talked around and there a few ways to make Sysprep work for you. The first is to generate a Sysprep answer file, which isn't that difficult after doing some research.
If you are creating Windows XP or Windows 2003 VMs, use this walkthrough: How to Build a Sysprep Answer File for Imaging
If you are creating Windows 7 or 2008 R2 VMs, use this walkthrough: How to Sysprep in Windows Server 2008 R2 and Windows 7
After you have completed your sysprep answer files, you need to configure every VM with this before the first power on by going back into the Guest Customization tab and going down to the bottom and browsing for your answer file. This answer file will need to be supplied for every VM by entering in the correct hostname and anything else you want to configure.
Once your new VM finishes the sysprep process, the CD Key will be entered from the answer file, but you will still need to activate the OS. I haven't played around with the answer files much after this initial test, but I'm sure there are plenty of tweaks you can make.
IMO, this is still not optimal because you don't want to hand out a sysprep.ini file to every single user who wants to order a VM from IT's catalog of Windows VMs. After talking to Erik Bussink, he suggested to create a template Windows 7/2008R2 VM and enter in the reg key that will allow the VM to locate the KMS server to take care of activation. Those steps can be found here Deploying KMS Activation.
I hope some developers at VMware read this because I really wish vCloud could leverage the great Sysprep abilities that are present in vCenter. With a little help of photoshop, I would love to see something like the following. This would allow you utilize the Customization Specifications Manager within vCenter to create different profiles that you can then assign to a VM during its vApp creation. This allows every Organization to have it's own set of Guest Customization Templates without Cloud Administrators needing to configure this globally. Having to go into every individual VM and doing the Guest Customization isn't the most user friendly option. If there was a way you can let Organization Administrators have the ability to define some sysprep parameters such as domain credentials, then allow Catalog Administrators to define other variables, it would be less of a headache. Perhaps, being able to tie a Guest Personalization Profile to a particular set of vApp(s)/VM(s) in the public catalog would be good too. This way, when a user deploys the vApp/VM from the public catalog, there will be a drop down list with optional Guest Personalization Profiles that can be ran against it. This alleviates the need of the user having to enter in information such as CD Keys. What do you think?
