Making all other blogs seem exciting!
RSS icon Home icon
  • Making VMware Update Manager 5.1.1 (and 5.5) work with SQL 2012

    Posted on May 24th, 2013 ashinn No comments

    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: 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.

    Posted on July 26th, 2012 ashinn No comments

    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:


    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…