Scan failed with vCenter Update Manager

SNAG- 2012 04 13 14.40.35

Some time ago I was at a customer who planned to rollout some patches using VMware vCenter Update Manager on ESXi hosts.

First scan went OK, but stage and remediate complained about not able to reach the download location. Next I ran down a simple checklist.

  1. Does the host (or all) have a baseline attached and what if, which baseline is attached.
    It turned out the cluster had the standard “critical host patches” baseline attached, which of course is OK.
  2. Restarted the update manager service on the vCenter Server, but no effect.
  3. Does the update manager server have internet access.
    The hosts appeared to have internet access using the proxy. The test proxy button showed that update manager was able to access internet pages like www.vmware.com and testing it myself manually also returned a positive result. Wandering through the logs of Update Manager it showed a 404, which indicates the server couldn’t reach a page of some sort.
  4. Not being too focused I then still believed it had something to do with the internet connection, so we tried bypassing the proxy and authorized the server to access internet directly. Still no positive result.
  5. Now the 404, popped up in my mind again, also the previous result of the internet check proved the server could access internet except for the fact that the page it was connecting to did not exist (404 = not found).
  6. I gave it a rest and made it home, that evening I tried some google magic to find a common cause for it, but could not find one that fitted right in. The one issue that kept popping up was about a downloaded patch being corrupted.
  7. The next day I queried the knowledge base again and found out that VMware updated the download location of the patches. The locally cached metadata still refers to the previous download location. The VMware knowledge base article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2001631

So the issue was the metadata not being updated with the new location of the updates, instead it used the old metadata cache with the wrong url location to access the updates.

Removing the metadata manually forced the creation of new metadata and with the next scan & remediate action we saw no errors and the updates where applied successfully.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.