VMware Cloud Community
donikatz
Enthusiast
Enthusiast
Jump to solution

VUM4.1: Error on scan & patches not downloading

Everything worked fine before Update 1, but now I'm having two problems. I've tried reinstalling VUM4.1 from scratch to a fresh db, but the errors persist.

1) Error scanning host

When scanning a host (or group of), vSphere client errors: "VMware vCenter Update Manager had an unknown failure. Check Tasks and Events tab and logs for more details." In VUM log, I see the following error:

"[2009-12-16 11:25:21:709 'SingleHostScanTask.SingleHostScanTask' 3732 ERROR] Task execution has failed: Database error (vdb) "ODBC error: (42000) - [SQL Native Client][SQL Server]Cannot find either column "dbo" or the user-defined function or aggregate "dbo.vci_CheckBaselineConflict", or the name is ambiguous." is returned when executing SQL statement "{CALL vci_compBaselineComplianceLeaf(?,?,?,?)}"

After the scan the host does correctly shows the patch compliance level (patches is up to date or not), but remediation fails with the same error.

2) Patches don't download

Metadata downloads fine and connection tests all check out (no firewall issues, no proxy), but the VIMs don't download -- directories remain empty (this is a fresh install). No errors, though, VC indicates success. VUM log shows metadata being downloaded, but 0 counts for host updates or OS patches found. Status codes are either 200 or 304.

Any ideas? Thanks

0 Kudos
1 Solution

Accepted Solutions
jsreynolds
Contributor
Contributor
Jump to solution

Answer:

This is what worked for us. We don't use windows authentication; we use sql server authentication. But it still may apply.

Look for stored procedure, . Open it and modify.

Inside that procedure, search for the function name, (ours is on line 220).

It most likely is prefixed with "dbo.". If your database owner is something other than dbo (ours is "VMWareUser"), then you need to change the prefix from "dbo." to whatever your owner name is. Then execute to modify/alter the procedure.

Go re-run your baseline and it should work.

This worked for us. Your mileage may vary.

View solution in original post

0 Kudos
8 Replies
Paul11
Hot Shot
Hot Shot
Jump to solution

You had to separate the VirtualCenter-DB from the UpdateManager-DB. Look at:

http://communities.vmware.com/thread/246211?tstart=0

The Patches will than be downloaded, when they are needed, that's during the remediate.

It looks like that during the scan operation only the index is needed.

0 Kudos
donikatz
Enthusiast
Enthusiast
Jump to solution

Thanks, but as I wrote in the OP, a full VUM reinstall into a fresh db made no difference. Fresh = empty = separate from the VC db.

Also, in all previous versions downloads were unrelated to remediation as well they should be -- wouldn't you want to already have the binaries before scheduling the job, to minimize downtime? That's how every other remediation product I've ever used worked. Are you sure that's correct? If so, VMware has made some pretty shortsighted changes; it should be a user's choice rather than hardcoded.

0 Kudos
gary1012
Expert
Expert
Jump to solution

Bump on this... experiencing the same issues. Any updates?

Community Supported, Community Rewarded - Please consider marking questions answered and awarding points to the correct post. It helps us all.

Community Supported, Community Rewarded - Please consider marking questions answered and awarding points to the correct post. It helps us all.
0 Kudos
Mark_Latanzi
Contributor
Contributor
Jump to solution

I am also having the same issue!

0 Kudos
Mikeluff
Contributor
Contributor
Jump to solution

I'm getting the same thing, upgraded test hosts before Christmas and they are fine. Now doing production and I get the same error as you all seem to have...

I also can't run config backups as get some http error. Do you see the same?

I am only updating the hosts - not vCenter to U1.

0 Kudos
jsreynolds
Contributor
Contributor
Jump to solution

Answer:

This is what worked for us. We don't use windows authentication; we use sql server authentication. But it still may apply.

Look for stored procedure, . Open it and modify.

Inside that procedure, search for the function name, (ours is on line 220).

It most likely is prefixed with "dbo.". If your database owner is something other than dbo (ours is "VMWareUser"), then you need to change the prefix from "dbo." to whatever your owner name is. Then execute to modify/alter the procedure.

Go re-run your baseline and it should work.

This worked for us. Your mileage may vary.

0 Kudos
donikatz
Enthusiast
Enthusiast
Jump to solution

Brilliant -- that did it! Thanks! Smiley Happy

0 Kudos
cixtec
Contributor
Contributor
Jump to solution

It worked for me too, thank you very much!

0 Kudos