Template deployment issues after upgrade to VirtualCenter 2.5

[vvarnell]

Good afternoon,

After I upgraded VC from 2.01 Patch 2 to 2.5 I've noticed that my deployment from templates aren't working as before. It's almost like sysprep isn't installed (though I checked). I've done NUMEROUS deploys from the tremplate before. The customization specs appear to be complete and as they were before the upgrade.

The deployed VM doesn't get any of the changes that sysprep would implement, for example the name is the same (causing a "duplicate name" warning upon boot). I did notice on one deployment that there is a vmware created directory in the root with various executables and scripts (didn't catch the list, sorry). I ran the .BAT file in the directory and the customization appeared to kick off then (the VM rebooted and went through the normal sysprep steps).

Anyone else see this or something similar? Any fix?

VwV

[heathseals]

I have an environment where I'm experiencing something similar. I see all the sysprep/bootrun files on the target VM, but sysprep never runs. Did you find a cause/workaround/fix for this?

Thanks in advance,

-heath

[vvarnell]

GOT AN ANSWER, sort of.

The issue has something to do with VMware tools. When the template was deployed it would show up with a "Duplicate name exists on the network" warning (a Windows warning). After a minute or two the VM would reboot and go through the sysprepped processes. At one point after the reboot the alert about an unsigned driver for the network card would pop up and anything that depended upon network connectivity would fail, hence my issues.

So, what was it? A vmxnet driver oddity. When I checked the version of the driver in Windows I would see v. 2.0.0.8 on the driver file and v. 2.0.0.9 on the properties page. So, I looked at the patches available for ESX 3.0.2 and saw that there was a patch that updates the tools. I applied the patch and...no difference.

Hmmm. OK. What about ESX 3.5? I've got one machine in test with ESX 3.5 on it. I copied the Windows VMware tools ISO to a place where I could install the tools in my template from this version, ran through the process and...success. I then went through a reversal of the process to see if I could clarify the issue and it appears that the actual AMD driver for Windows 2003 was loading on that first boot (producing the "Duplicate name" warning). On the second boot, since there was already a driver in place, the unsigned driver warning comes up and my post-deployment scripts fail.

So, short version: update the VMtools to the ESX 3.5 version (version 2.0.1.8 on the vmxnet driver).