VMWare Update Manager, lost patch files, how to re-download all?

[haen]

Hello,

we have a very small test/dev lab with a few ESX server and a VI Management server including update manager. This management server is only a standalone machine with two local disks. In the vci-integrity.xml we moved the location for the patch datastore to a second disk

<docRootHostUpdates>

<namespace>"/vci/hostupdates"</namespace>

<path>D:\VMWarePatchStore\Data\</path>

</docRootHostUpdates>

and

<patchStore>D:\VMWarePatchStore\Data\</patchStore>

Everything worked fine for several months, until the D: disk crashed and the whole data-store was lost. Well, of course no backup of this patch-store as the idea was that this data can at any time be re-downloaded, when needed. Only the C-Disk has backup.

Well, now we are at the stage where I need to re-download / populate this patch-store, but I can't figure out how to do this...

Last weekend several new 3.0.3 patches were released, and they were downloaded into the patchStore. But no 3.5.0 patches. (All our ESX-Servers are at 3.5-U2 all patches until December). When I run a "Scan for Updates" on any of the ESX-hosts, I get an error message in the esxupdate.log file on the ESX-host:

09Jan26-0842 DEBUG: summary: /usr/sbin/esxupdate --HA --flushcache -d http://<system-ip>:80/vci/hostupdates/hostupdate/esx/esx-3.5.0 scan

09Jan26-0842 DEBUG: root: Enabling hostagent interface

09Jan26-0842 DEBUG: db: dbfile = , 215 keys

09Jan26-0842 DEBUG: Depot: Download Rules: {'blacklist': '.rpm', '/headers'], 'exclusives': [}

09Jan26-0842 ERROR: root: IOError: HTTP Error 404: Not Found:

09Jan26-0842 ERROR: hostagent: BundleID:Unknown

09Jan26-0842 ERROR: hostagent: File:[http://<system-ip>:80/vci/hostupdates/hostupdate/esx/esx-3.5.0/contents.xml.sig]

09Jan26-0842 ERROR: hostagent: Extra:()

Well, of course the file can not be found, it was lost in the disk-crash. The D-Disk was replaced and I also manually created the necessary directory. But in the esx-3.5.0 sub-directory there is no content, and although the weekly signature update job runs and finishes successfully, the lost content is not automatically re-created. I assume that if there were new patches, they would appear there. But no "old" patches from before the disk-crash. If we add a ESX or need to re-install one, we need to patch them, so I want to patch-store to be "complete" and to contain at least the necessary patches released after 3.5.0-U2.

So... I'm wondering what to do. Do I need to de-install update manager and re-install it? I would like to avoid that. I could not find any command-line interface (don't even talk about GUI) so far. Any help?

Thanks in advance, Herbert

[jguidroz]

The Update Manager database still has entries saying the patches are on the D: drive, even though they are not there. The database entries need to be purged, or just create a new database and point your current Update Manager to the new database. All the updates will then be re-downloaded.

[haen]

OK, it seems like there is no "simple" solution to this issue. Basically the answer is: remove and re-install Update Manager.

So I decided to "hack the DB" in order to avoid the re-installation. As we have multiple LAN-Cards and had some strange behaviour when originally installing the VC-server/Update Manager, I wanted to avoid a re-installation and running into the issues again.

So I took the "MS SQL Enterprise manager", looked at the tables (there are not that many) and purged the content of all tables that seemed to contain information on "patches".

Order of steps:

- First I changed my existing baselines back to default ("Automatic" Baselines, removed the specific excludes)

- Stopped the Update Manager service

- Deleted logfiles

- Wiped the following tables (deleted all rows): VCI_PACKAGES, VCI_PACKAGES_LOCALES, VCI_SCANHISTORY, VCI_SCANRESULTS, VCI_SCANRESULTS_BASELINES, VCI_SCANRESULTS_TARGETS, VCI_UPDATE_PACKAGES, VCI_UPDATE_PLATFORMS, VCI_UPDATES

Note: I left the following tables alone: VCI_AGING-SNAPSHOTS ,VCI_BASELINES,VCI_BUNDLE_KEYS, VCI_CONTENT_KEYS, VCI_LOCALES, VCI_PLATFORMS, VCI_REMEDIATION_HISTORY, VCI_RESTORING_TEMPLATES, VCI_RUNNING_VC_TASKS, VCI_SCANHISTORY, VCI_SEQUENCE,VCI_TARGET_BASELINES, VCI_TESTFILES, VCI_UPDATE_BASELINES, VCI_VERSION

After that I restarted the Update manager andmanually triggered a download signatures This step continued to run for quite a long time (over the weekend). This morning I saw several gigabytes of patches downloaded and was able to "scan for updates" successfully (this did not work anymore due to the missing patches on the filesystem). I have triggered a Remediation task for tonight, as I can not have downtime during the day today. As there have been new patches released on the weekend, which need "maintenance mode" and reboot of the ESX servers, I will have the final check tomorrow morning.

Please note: The above is just what I did and seems to work for me. I would not recomment this solution.

I consider it risky to directly go to a database, so I don't consider this a good approach. But as we have a simple test-lab environment the worst that could happen would be to de-install Update Manager and re-install it. Therefor I decided to take this risk. I would not want to do this on a critical production environment. So deleting the table-content only took me ~5 minutes and then re-downloading ran over the weekend.