Update Manger : Metadata for patch missing / Updates View incomplete

[Max2002]

Hello dear Community,

I am having a problem with the Update Manage for the VCMS 2.5.

1.) Always when i scan a host for updates i get the error "Metadata for patch missing".

2.) The first and initial schedule of the Update Manger for downloading updates worked and i see all 20 patches in my

Update view (within the Baseline).

2a) Although my Baseline contains 20 fixes i only see 2 uncompliant updates. (Be aware a reinstall of vcms on a different machine deliver the same issue)

Opening or disabling the esx firewall (packet filter) doesn´t worked either. Shortly telling that the following discussions don´t help.

http://communities.vmware.com/thread/124019

Thanks in advance for your help

[forbes]

Hi Max2002,

By any chance, did elect to store your downloaded patches to another drive letter (not your system drive - C:)

I am having the same issue (which is not fixed with normal fixes

found in the forum ATM) and I suspect it is because the docroot is on

the system drive. Unfortunately, I'm still unsure how to fix it.

Forbes Guthrie

http://www.vmreference.com

[mike_laspina]

Hi,

If you connect to the VC are you able to schedule once and download the updates using the plugin menu?

The update manager requires that the VC can reach the internet. Can you browse the internet from the VC without authentication.

It could be a proxy server issue.

check the vci-integrity.xml file in the Update Manager installation directory

You can use vum-proxyAuthCfg.exe to configure the proxy.

[forbes]

Hi Mike,

no proxy server in the way for me. Yes a "scheduled" download does work, but not a manual one

Forbes Guthrie

[mike_laspina]

Is the local windows firewall running?

[forbes]

No the windows firewall is turned off.

The issue is being caused by storing the patch files on a non-system disk (selected this option during the install). Other than moving them back to the default location, I think I will have to wait until VMware resolve this.

Forbes Guthrie

[mike_laspina]

Is it a space issue?

If so just enable dynamic disk and add a new disk using a volume mount point to the same directory.

[mike_laspina]

I have mine in a non default location and I do not have any problems with that.

D:\VPMPatches is where they are currently.

[foam]

So I had a similar problem. I have a mutlihomed Central Server running SQL 2005 with a database for Central and one for Update Manager.

Custom install ODBC System DNS, firewall scoped, VM Center OK, Update Manager pointed to wrong NIC, changed during install. Still got Metadata error. Changed binding order. Reboot (did not reinstall or make any other change). Everthing works fine.

Got the same result if I did a full install. (Which uses the DNS name of the server not the IP address.)

Hope that helps.

Matt

[admin]

I had this also it was due to the fact Update Manager was using port 80 and I had changed it to 81, so I modified the ports to be open on the ESX Host.

A quick test is to open all on was ESX host outgoing and incoming using esxcfg-firewall allowall command

[forbes]

It's not a space issue, a firewall port issue, nor a dual NIC problem.

I got fed up, and uninstalled Update Manager, cleared all the DB tables and made sure that there wasn't anything left in the registry/file system. Did a fresh install (with it left pointing to the default locations). Everything was working great again and I patched all my Host servers.

However I have just followed this VMware KB article:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100415...

to repoint things to another partition.

Its broken again. When I try to scan a host for updates I get the "Metadata for Patch Missing" again. I can run the scan OK from the scheduled updates, but as soon as I try to do it manually it errors out. I have restart the UM service, the client, the plugin...

:smileyangry:

Forbes Guthrie

[mike_laspina]

Maybe this is somehow related to a rights issue.

When you invoke it manually the security comes into play.

[forbes]

Hi Mike,

I'm running the client as a domain admin, so I'm sure if that would be an issue. Its the same account that was working right before I moved the path locations. I have also checked the file system permissions and they are identical.

Thanks.

Forbes Guthrie

[mike_laspina]

Permissions are a UNION function at an object context. So if you are a member of Domain Users and Domain Admins which is default and a role is applied to the Domain Users local group it would then UNION the lower permission and it would overide.

So that's why I noted it, this issue you are experiencing seems outside of the normal, thus the outside of box thinking.

[forbes]

"thus the outside of box thinking"

And I appreciate it! However there is nothing funky about our permissions. Its all default, no-one has been granted or denied any special privileges.

Here's a few quick tails after creating the error:

vmware-vci-4.log

Waiting for a task to complete...

Sent NotFound response for GET /vci/hostupdates/hostupdate/esx/esx-3.5.0/contents.xml.sig

Sent NotFound response for GET /vci/hostupdates/hostupdate/esx/esx-3.5.0/contents.xml.sig

Sent NotFound response for GET /vci/hostupdates/hostupdate/esx/esx-3.5.0/contents.xml.sig

vmware-vci-log4cpp.log

-

---

Invoking scan on integrity.VcIntegrity:Integrity.VcIntegrity session 2E903931-B594-4A8D-B5DF-99FC7BC32AAA

Arg entity:

(ManagedObjectReference) [

'vim.HostSystem:host-366'

]

Arg baselineId:

(int) []

Arg updateId:

(int) []

Arg option:

(integrity.VcIntegrityScanOption) {

dynamicType = ,

reason = ,

targetVm = false,

}

-

---

Leave Validate. Succeeded for integrity.VcIntegrity.scan on target: Integrity.VcIntegrity

Save the VC task info into the database: task-3750

Invoke done: integrity.VcIntegrity.scan session: 2E903931-B594-4A8D-B5DF-99FC7BC32AAA

Result:

'vim.Task:task-3750'

Filter added for : session[3FBFC279-4D61-46B0-9AB4-1747AE61E812]0922DC41-5682-4C6F-BBB7-17F02F6F3FFD

The number of tasks: 1

Scheduling task ScanTask that imposes 2 for Alpine new load: 2 Starting task ScanTask

VciTask , type: com.vmware.vcIntegrity.ScanTask }: Setting VC task state to: running

Task started...

Locking host-366

The number of tasks: 2

Scheduling task VciHostScanTask that imposes 1 for Alpine new load: 3 Starting task VciHostScanTask

Add scan host: host-366

No authentication data for current VC user

The number of tasks: 3

Scheduling task ChainedTaskContainer Starting task ChainedTaskContainer

Locking host-366

The number of tasks: 4

Scheduling task SingleHostScanTask that imposes 3 for ESX: host-366 new load: 3 that imposes 2 for Alpine new load: 5 Starting task SingleHostScanTask

Task started...

Patch depot url: http://192.168.14.61:9080/vci/hostupdates/hostupdate

Checking firewall configuration for host: server.domain.com

Ruleset name: updateManager

Firewall ruleset already activated

Depot for update: Unknown corrupted. remove the package from DB.

Patch Metadata Not Found:

Task execution has failed: SingleHostScan : Patch Metadata Not Found:

A subTask finished: VciHostScanTask SerializeToVimFault fault: (integrity.fault.VcIntegrityFault) { dynamicType = , msg = "" } Converted fault: (vim.fault.ExtendedFault) { dynamicType = , faultTypeId = "com.vmware.vcIntegrity.VcIntegrityFault", data = (vim.KeyValue) [ (vim.KeyValue) { dynamicType = , key = "dynamicType", value = "", }, (vim.KeyValue) { dynamicType = , key = "dynamicProperty", value = "", } ], msg = "" } VciTask , type: com.vmware.vcIntegrity.ScanTask }: Setting VC task state to: error Task finished... Removing task ScanTask that imposed Alpine load:2, new load: 3 Removing task VciHostScanTask that imposed Alpine load:1, new load: 2

Removing task ChainedTaskContainer that imposed Alpine load:0, new load: 2

Removing task SingleHostScanTask that imposed ESX load:3 for esx host-366, new load: 0 that imposed Alpine load:2, new load: 0

Task finished...

The number of tasks: 0

Filter removed for : session[3FBFC279-4D61-46B0-9AB4-1747AE61E812]0922DC41-5682-4C6F-BBB7-17F02F6F3FFD

Delete VC task from database: task-3750

No changes to firewall configuration for: updateManager

Why would changing the default locations, as per VMwar's own KB, make UM think there is a corruption on the DB? This is the same error as before. The DB is brand new. Just patched a couple of hosts (successfully and without incident/error), moved the locations, and now errors. Especially when this only happens when I run it manually.

Forbes Guthrie

[mike_laspina]

Do you have both paths in green changed to the new location?

Is the security on the new location set the same as the original locations?

<!-- location of server data -->

<patchStore>C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Data\</patchStore> <!-- . -->

<!-- Web server related configuration -->

<enableWebServer>true</enableWebServer>

<webServerPort>9084</webServerPort> <!-- 9084 -->

<docRootMap>

<!-- The default document handler will provide access to the client plugin and to clients.xml. Files that are installed by the installer should be served by this namespace handler.-->

<docRootGlobal>

<namespace>"/vci/downloads"</namespace> <!-- download namespace -->

<path>./docroot/vci/downloads</path>

</docRootGlobal>

<!-- A dedicated handler for host updates provides access to update related collateral downloaded by the server.-->

<docRootHostUpdates>

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

<path>C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Data\</path>

</docRootHostUpdates>

</docRootMap>

[forbes]

Do you have both paths in green changed to the new location?

Yep

Is the security on the new location set the same as the original locations?Yep

Forbes Guthrie

[mike_laspina]

Then there is only one item left I can think of that would cause this and that is a reference in the VUM database that does not get changed but is a dependacy to the previous paths.

[forbes]

I am more inclined to think that it is a reference in one of the signature files, which were created when the successful scans ran before moving the location. I have looked in the VUM DB tables before and I don't think it holds paths to things.

Forbes Guthrie

[mike_laspina]

I would not be able to tell until I am at home, There are fields names which refer to a variety of different paths.