Making VMware Update Manager 5.1.1 (and 5.5) work with SQL 2012

06/07/2013 – UPDATE: A reader commented, and this is still an issue with 5.1.1a.

11/25/2013 – UPDATE: Thanks to user comments, VMware has finally published a KB to this issue: http://kb.vmware.com/kb/2050256 also users report (as does the KB) this is an issues on 5.5.

My lab was getting pretty dirty, so I thought why not start from scratch with vSphere 5.1.1. I figured it was also a great time to refresh my old lab SQL Failover Cluster with Server 2012 and SQL 2012 too. I had been wanting to play with AOAG and the other new(er) toys 2012 had to offer anyway.

From what I can tell, technically vSphere is officially supported on SQL 2012??? Being the rebel I am, I pressed on undeterred by a support matrix anyway.

Everything went as planned during the vSphere Install, and I was pretty happy. Then it came time to get Update Manager working. I installed it as usual, creating the required 32-bit DSN using the SQL 11.0 native client (what comes with SQL 2012). It installed normally and worked for about 3 minutes. Then the Update Manager service started to die repeatedly. I checked out the logs in C:\ProgramData\VMware\VMware Update Manager\Logs, and I saw this:

mem> 2013-05-24T14:18:25.299-07:00 [02472 info ‘VcIntegrity’] Logged in!
mem> 2013-05-24T14:18:25.611-07:00 [03288 error ‘Default’] Unable to allocate memory: 4294967294 bytes
mem> 2013-05-24T14:18:25.720-07:00 [03288 panic ‘Default’] (Log recursion level 2) Unable to allocate memory

I was like oh, some sort of Java nonsense. I tinkered around a bit, looked in the VMware KB and Google. Nothing really seemed to help.

I started to wonder if SQL was the issue, so I bumped the Update Manager DB down to 10.0/SQL 2008 compatibility mode…. no joy. Then I installed the 10.0 native client from SQL 2008 R2 media, and recreated the 32-bit DSN. I started Update Manager back up and BAM …it seems to be stable for a couple days now.

If this wasn’t a lab I’d call VMware to complain, but alas it is lab. looked through the 5.1.1 release notes, and I don’t see anything about this? For the record, all other portions of vSphere worked fine with 11.0 native client, including SSO.

Till next time…

VMware vSphere ADAM/LDS issues after an in-place OS upgrade.

I’m not a huge fan of doing in-place OS upgrades, but sometimes its just a necessary evil. Today I upgraded one of our vCenter servers from Server 2003 R2 64-bit to Server 2008 R2, which is a supported upgrade path from Microsoft.

The OS upgrade itself went smoothly, but about 10 minutes after the final reboot vSphere Service Status alerted on these two issues:

• LDAP replication health monitor – Failed to initialize LDAP instance manager
• LDAP backup task monitor – JoinTool initialization error

If you didn’t already know, vCenter relies upon Microsoft ADAM which was renamed Lightweight Directory Service. vCenter uses this as a repository for things like roles, license keys and many other metadata-ish stuff.

I searched around the VMware KB & Google and really didn’t find anything useful. Then I dug through the vCenter Webservices Logs (vws.log), and ran into this:

Action: Local ldap environment verification
Problem: LDAP tools not found in “C:WindowsADAM”

I zeroed in on: Problem: LDAP tools not found in “C:WindowsADAM and compared that directory between a known working vCenter on Server 2008 R2 and this problem child server.

Sure enough 3 files were missing:

• DSACLS.EXE
• LDIFDE.EXE
• REPADMIN.EXE

After synchronizing that directory with the working server, I restarted vCenter Web Services and the errors went away! My assumption would be that during the upgrade those files were nuked as the LDS role was re-applied.

For folks who might not know, here’s a VMware KB article for log file locations: KB1021804

Till next time…