I tried to go to 6u1 some months ago and that failed too. Yesterday afternoon I tried to go from 6.0 to 6.0u2 and I continue to get the 1603 error message with the vcsservicemanager.msi installation/update.
I have contacted VMware support, and have an open case for this. But, I was hoping someone here will have encountered this issue and came up with a solid fix/resolution.
For the record, before I tried this time I did take a snapshot, then stopped all the VMware services (except for VMware tools). I logged in with an account with local administrative rights.
The server this is running on is 2012 R2 (a VM). I'm wondering if there's a Windows update that the cause. IF there's an update that's known to conflict with the update installs, I'd love to know. The VM that this is running on was originally running vCenter 5.5. I went through the upgrade when 6.0 came out (waited about a month before installing 6.0).
Attaching vminst.log and vim-vcs-msi.log files. The pkgmgr-comp-msi.log file is too large at 75MB.
I've had success by disabling the Syslog Collector and retrying the upgrade.
That was already disabled when I made the latest attempt, that failed.
Could you tell me if you use Oracle Database ? because in my case with windows 2012, I observe this file : vCenterServer\cfg\vmware-vpx\vcdb.properties that contains url = jdbc:oracle:thin:@//IP_SERVER:1521/INSTANCE_NAME and generate your error.
During the installation, when the file is created and when the install try to start the service change like this : url = jdbc:oracle:thin:@IP_SERVER:1521:INSTANCE_NAME
No Oracle here. vCenter is using the db that gets deployed with it
Getting same error in my environment.
Have you got a chance to get any progress on this with VMware Support.
Thank you in advance!
End result of (I lost track of how many hours) working with support is I need to make a NEW vCenter Server to replace the FUBAR'd one.
I have to decide if I'm going to go with a postgres database or if I'm going to use SQL 2014 (I have a VM setup as a SQL server now). While I don't have a ton of user accounts in vCenter, there's enough to make it a task to set them up again IF I go with SQL. I need to look a bit deeper to see if there's enough benefit to use full SQL or keep with postgres. I'm going to add another host to my cluster soon. I should still be under 15 hosts connected to the vCenter Server. If there's stability gain by using SQL, I'll make the change and add the users all over again.
Most annoying thing is I was able to upgrade from 5.5 to 6.0 without issue. But try to apply either 6u1 or 6u2 and it's no go.
I've been struggling with this issue for two weeks when upgrading to U2A build 4541947, and finally support came through with a solution.
In our case, the cause was vCenter JRE not being updated correctly.
To workaround the issue, remove the contents of the jre and then perform the upgrade.
Steps:
C:\Program Files\VMware\vCenter Server\jre\bin\libvecsjni.dll
C:\Program Files\VMware\\vCenter Server\jre\lib\ext\vmware-endpoint-certificate-store.jar
Thank for saving me a call to VMWare support. This workaround appears to have resolved the issue I was experiencing on one of my vcenter install's. thanks!