Before I begin I owe a debt of gratitude to Larry Blanco from the VMware Forums – when I first google’d the string”View Composer agent initialization state error (16): Failed to activate license (waited 1245 seconds)”
It was his responses that fixed this problem….
Recently I started working with fellow vExpert (Barry Combs) on upgrading my View 4.5 guide to be a View 5.0 Book. Like me you probably have a lab environment where you play around with stuff. I came across this problem, in fact I had the problem in View 4.5 with linked clones and license activation. The problem only arises in certain conditions:
IF your using Linked Clones AND QuickPrep THEN = you get an activation error. If you don’t use Linked Clones OR if you don’t use QuickPrep – you don’t have a problem.
The trouble issue won’t jump out at you and neither will the resolution. Initially, you will find that when the Client goes to connect you get an error, which is just like all the other errors you get. However, if you dig a little deeper you into the View Admin portal at +Inventory, +Desktops. You should see at in the “Status” column a number of errors…
The phrase “Activate License” is the give away. Unlike ANY of the other deployment methods, the View Agent will fail to start if Windows 7 or Vista (sic) is used. There are couple of resolutions to this problem:
1. Get a KMS server in place – Not a very always an option in a lab environment
2. Use Sysprep, instead of Quick Prep – Linked mode is all about rapid deployment, the less said about the rapidity of Sysprep the better
3. Hack the registry of the ParentVM to disable this annoying “feature” and run the non-activated setup - SUCCESS!
The registry location you need to modify is at: HKLM/System/CurrentControlSet/services/vmware-viewcomposer-ga/SkipLicenseActivation to ’1′ – as it to be found on the ParentVM – not in vCenter or where the View Composer has been installed (which for many is one and the same location).
Once you apply the registry key, and reboot the virtual desktop – it will be able to continue with its “Customizing” phase. Once the desktop has completed “customizing” phase it will reboot and then be available. If you have a lot of virtual desktops that are afflicted this way, you could export the regkey and just import it. Of course, you would want to apply this key to the ParentVM and any templates so you don’t have this pain-in-the-arse again.
Remember. If you update the Agent this will overwrite the registry change – so remember after a Agent update to correct that and then revert your template back to a VM or update your ParentVM that makes up a linked clone…