A quick fix could be to export the registry entry and install it during first boot.
ESXi 4.1 Update 1 & vCenter 4.1.
I didn't see any hidden drivers.
Hmm, how would I go about exporting the registry entry and installing on first boot?
I can confirm. I have the same problem after sysprep of Windows 2008 R2. ESX Build 381591 if that matters.
sysprep.exe /generalize /unattend:unattend.xml /oobe /reboot
<?xml version="1.0" encoding="utf-8"?>
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<cpi:offlineImage cpi:source="wim:d:\install.wim#Windows Server 2008 R2 SERVERSTANDARD" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
I've just been running a VMtools repair after deployment, but that's annoying.
I rebuilt my templates from scratch and the issue has gone away. The only real difference that I could think of is before I installed any windows patches, I installed SP1 for Server 2K8R2, then I proceeded to install any other patches.
I proceeded to shut the VM down, then converted VM to template. I've deployed VMs from it and issue is gone.
Hmmm, my template is built fresh from msdn 2008r2 iso with sp1. VMtools installed on first boot and then Windows Update for all patches with multiple reboots. Oh well
So after deployment from template the mouse driver is reverting back to the standard one?
Wish I had an answer for these annoyances but they do seem to be increasing. I've waded through similar issues in recent weeks after deploying my sysprep'd templates both Win7 and '08R2 after applying the SP1 and windows updates. A number of things to check, first there's the default display properties after the OS is cleanly installed, set hardware acceleration to the max with the default driver prior to even installing the VMware tools. There's an issue if you have old virtual HW version 4, in that case WDDM driver might install with VMware tools but then it doesn't actually work until you upgrade the virtual HW on the VM. I've found mouse issues are all tangled up with the above, fix that and the mouse gets back to normal. I've also seen these new VMs with the virtual hardware fail to have a working NIC after deploying with sysprep, that's another (new) bonus with SP1. The fix for that one is you have to delete the existing NIC from dev mgr and rescan so it reinstalls, then it starts working fine. These are all driver installtion issues with sysprep and it defeats the purpose deploying templates in the first place if I have to mess around with tons of stuff post-deployment....I'm blaming MS, their deployment system has been deplorable in my opinion since XP / 2003 and they had room to improve even then. It would not surprise me if they're 'looking' for VMware drivers now during reseal and allow some stuff to get botched on purpose. Let me guess, nobody running hyper-v has these issues?
I just installed a new 2008 r2 enterprise sp1. Did VMtools immediately, rebooted, loaded wddm driver, rebooted. Did all windows updates. Rebooted, did more, rebooted, did more. Minor changes to the admin profile. shutdown. cloned, booted up clone. ran my sysprep as specified above. rebooted and mouse was funky. checked device manager. shows PS/2 Compatible Mouse. all other drivers show fine. Repair VMtools, problem fixed.
Yeah, but this is what I don't get because all the tools repair is doing for the mouse is reinstalling the driver for VMware compatible pointing device or whatever it's called. The bigger mystery is why sysprep mini-setup PNP doesn't see the device properly and re-install the correct driver which is clearly intact and working prior to running sysprep. I have never seen an issue like this when running sysprep, old devices should be cleared from dev mgr and redetected during the pnp phase of mini-setup period. The NIC issue is another one, sorry to bring that one up in this thread but I'm sure others will hit that too, not just me. Maybe it's because the NIC is now seen as a USB device? It's weird stuff, you can eject the NIC when running the latest virtual hardware version? Maybe I need to choose another virtual NIC type instead of the default. This is under ESXi 4.1 btw..
I ran into the same issue with our 2008 R2 images - after a sysprep the mouse driver would revert to "PS/2 Mouse"...
It turns out that by default, sysprep will remove all PNP drivers during the Generalize phase, causing windows to re-discover drivers during the sysprep. The PNP scan gives a better ranking to the PS/2 drivers, and therefore selects them over the VMWARE one...
The solution appears to be the "PersistAllDeviceInstalls" sysprep option - this tells sysprep not to remove the PNP drivers during the generalize phase and leave the existing ones in place. Since the cloned VM wil have exactly the same hardware, there is no compelling reason to rescan for new drivers. With this option in place, the mouse driver remains set to "VMware Pointing Device" and continues to work fine after I sysprep a 2008 R2 VM.
Here's the XML that I added to my 2008 R2 answer.xml file to resolve the issue:
<component name="Microsoft-Windows-PnpSysprep" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
I'm having the same problem.
You stated that you added it to your answer.xml file, but when I do a clone I don't get an option to supply an answer.xml file.
So where to put it??
I am not using the guest OS customization feature of VMWare. The customization wizard generates it's own answer.xml file and invokes sysprep to perform the guest OS customzation. There is no way to adjust any of the advanced sysprep settings in the answer file it generates.
I am cloning without guestOS customization, then customizing the guest OS by invoking Sysprep in the cloned image and providing it with my own answer.xml file.
same here with Win7 SP1 and Win 2008 R2 SP1. No answer.xml used just a plain sysprep (c:\Windows\System32\sysprep\sysprep.exe) OOBE and generalize -> Shutdown
Repair VMware tools fix this.