After upgrading from 2.5 Update 1 to Update 2 the Update Manager failed to scan hosts. It said that the metadata was missing. The metadata is supposed to be downloaded by the update manager on a regular basis and it worked nicely in Update 1.

What puzzled me even more was that both my VI servers failed with the same message. Downgrading the Update Manager (UM) to the version from Update 1 fixed the problem, but that didn’t comply with my wish for running Update 2.

After reading some logs I discovered that my ESX 3.5 Update 2 host is looking for “http://winserver:80/vci/hostupdates/hostupdate/esx/esx-3.5.0/contents.xml.sig” when it tries to scan for updates. This file is created by the UM when it downloads updates. Or, it should have been created.

After looking in the default datastore for the UM I realized that there were only a single file there, namely “update_metadata.xml”. This file describes the different updates available so that the Update Manager Client (UMC) can display the available patches. In UM Update 1 there were a number of folders and subfolders in the datastore folder too: “hostupdates/hostupdate/esx/esx-3.5.0″ for example. As of UM Update 2, these folders are no longer created. No wonder why the update scan fails miserably…

After taking a quick look at the UM configuration file (C:\Program Files\VMware\Infrastructure\Update Manager\vci-integrity.xml in my case) I see that the download location for the patches are https://www.vmware.com/PatchManagementSystem/patchmanagement . This page is just a placeholder for a redirect to another page: http://vip-patchmgmtwlc.vmware.com:7004/patchMdSvc?WSDL . The error is quiteeasy to spot: the hostname doesn’t resolve.. But, the same page is referred to in UM Update 1. So, no solution yet…

Update 1 @ 2008-07-28: After reinstalling the Update Manager, changing ports and flushing the database it looks like it is downloading files again. Minus 10 points to VMware for extremely poor and irrelevant logging, plus 10 points to me for fighting with UM for most of the evening. VMware: please, fix your error messages :-)

Update 2 @ 2008-07-28: Even though I specify that the UM should identify itself as 192.168.20.3, the esx host tries <machine name>. This gives me some trouble since the machine is outside the default search domain in DNS and therefore it will not resolve. The solution is to set the DNS settings manually, but I really believe that the UM should use the FQDN to identify itself instead of just the machine name as it would solve a lot of potential problems.

Update 3 @ 2008-08-02: Solved!