As it is VMware View season I ran into a new problem deploying new virtual desktops in the virtual infrastructure I presented to you in this article.

The people who read it know that the infrastructure serves various clients/customers so I have to deploy various virtual machines varying from Windows XP to Vista. Last week I deployed a virtual machine and asked a colleague to install all software and tools needed for this client site. It took him a day to get the virtual machine ready, after that I tweaked and tuned it to run in a VMware View environment and converted it to a template.

When I created a desktop pool with this template the fun started. The deployment went great but when the virtual machine powers on, guest customization should kick in and it didn’t. At first I investigated the obvious things, like correct sysprep version, check the customization specification, vmware tools, etc.

Then when I logged on I noticed that the customization does start but it’s waiting for something and eventually times out. Inspection of the virtual machine revealed that in the network adapter device options both options (connected, connect at power on) were not selected so I thought something was wrong with the deployment of the template. So I checked the template, everything was fine, network correctly configured and so on. Then I found an article in the VMware knowledge base stating that when converting a virtual machine to a template all virtual machine specifications like CPU, memory, network, etc is stored in the vCenter database and not in the vmtx file like with a virtual machine. So I deleted the virtual machine from the inventory, added it again with no result. Then I removed the virtual machine from the inventory, created a new virtual machine with a slightly different name, copied the disk file, connected it to the new virtual machine and ………….. same situation still :(

Then I thought maybe this is not the problem but standard behaviour. Maybe when deploying a virtual machine from a template the process disables the network interface to prevent NetBIOS name conflicts. The local disk does contain a \Sysprep folder so maybe the problem is that the sysprep process does not run succesfully.

After some googeling I found a VMware KB article stating that this may be caused by 3rd party Data Loss Prevention (DLP) applications installed on the template, which may cause issues with the tcpIP stack in the virtual machine. The solution was simple: ‘Remove the DLP application and deploy the template again.’

When I converted the template to a virtual machine and started it I found Symantec Endpoint security installed in the virtual machine so I removed it and converted the virtual machine back to a template and tried it for the ##### time. And with succes!!

Failure of the guest customization was caused by Symatec Endpoint Security so I will add this to the checklist to prevent spending hours troubleshooting.