Windows 7/2008 Deployment - KMS and MAK Keys pt. 3
I would close up what we have learned from part 1 and part 2. During my work with the VMware Support on this case, one of the questions I asked, was is it possible to to inject a parameter into the customization process, but the only option was to import a full sysprep file. This would in essence break a good deal of the automation process, such as the rename of the OS to match the deployed VM name. So this was out of the question.
Unfortunately there was not much I could do here. So I rebuilt a new VM. But I had to take some certain precautions. Once your KMS is registered in the DNS and new OS connects to the network and gets an IP, it automatically looks up for a DNS record for the KMS server and will activate - which is exactly what I did not want.
The machine was started disconnected from the external network. I applied a MAK Key to the machine and then connected it to the network. Once a machine is activated with a MAK key, it will not try to contact a KMS server, so I was set.
So just to re-cap
- Build your VM
- Customize the OS - including your default profile settings
- Do not connect it to the network
- Install a MAK Key
- Connect to the network
- Activate the MAK key
The last part of the puzzle was how to change the MAK key to KMS for all the VM’s that will be deployed from this template? This was actually the easiest part. In the Customization Spec you can enter a License Key, and yep you guessed it here you insert the MAK key.
Machine is deployed, the Customization Spec injects the xml (with the MAK key) into the VM, the vm is sysprep’ed (without a problem because you have 3 ReArms left) and when it comes back up automatically is activated with the KMS server.
A few things still puzzle me though. All of this worked - flawlessly on vCenter 4.0 - I did not have to go through this whole process with MAK and KMS and USD and BS! So did something change? Was there a change in the way the machines are customized from the previous version?
The deployment and templates were a bit icky after the upgrade. I could not edit of my previous templates in vCenter - they all had to be re-registered VMware KB…
I also had another issue of not being able to deploy any templates at all (Windows / Linux) with customization until the vCenter Server got a kick in the butt and was restarted.
Small little things that do not add up. I am happy to say that I did manage to educate VMware support a bit on how this works, and in turn I learned a decent amount in the process of how the VMware deployment process works as well. All in all it was an educating experience all around. I was told that the information learned from this case will possibly be used in a VMware KB for all of our benefit.
On to solve the next problem. Hope you enjoyed this series of posts.