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
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.
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.
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.
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.
I am also having the same issue!
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.
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.
Brilliant -- that did it! Thanks!
It worked for me too, thank you very much!