SBOP BI Platform 4.1 SP01 and VMware Tools for Windows 9.0.5

general discussion
1

Anyone having issues installing SBOP BI Platform 4.1 SP01 on Windows 2008R2 virtual with VMware Tools for Windows 9.0.5?
No problems on physical servers, or virtual servers with VMware Tools for Windows 9.4.0. Sadly, our prod vm environment is not yet upgraded to 9.4.0. CMS and Audit tables on SQL Server 2008R2 on all tested platforms. Both the service account and the local account (servername$) granted owner rights.
A standalone install with the Sybase SQL Anywhere 12 works fine on Windows 2008R2 virtual with VMware Tools for Windows 9.0.5. A ‘no web tier’ custom install on Windows 2008R2 virtual with VMware Tools for Windows 9.0.5 with the CMS and Audit tables on SQL Server 2008R2 fails.
The installation hangs at the end, after the SIA service is started. The CMS starts, runs normally for a few minutes, then a started processing server ends with an error. Windows Event log then shows various issues with CMS and Audit connection. CMS then will not re-start, claiming port 6400 may already be in use. I suspect the CMS is confused, as it can contact the CMS database, but as there is an orphaned database lock, new request are backing up in the queue.
Although it behaves like a SIA service to database connectivity issue, the VMware tools version seems to be the only software difference. VMware Tools for Windows 9.0.5 appears to be supported in the PAM and virtualization support notes, but I am suspicious.
Commentary? Thanks in advance for your kind consideration.

Bill Jones (BOB member since 2002-10-11)

2

Moderator note:
Please, edit your post and remove all those empty line :? Use paragraphs to structure your train of thought.
Thanks.

Andreas :de: (BOB member since 2002-06-20)

3

For those who may be interested, I was able to resolve this issue by switching to a sql server id instead of using trusted authentication for the CMS and Audit connection. With trusted authentication, the install program, running as the logged on user, loads part of the CMS tables with the install program, then creates and starts the SIA service. The service is set to run under the local account. The SIA service then begins to also update CMS tables. Now two user ids are attempting to update the same tables. Database locks occur, something goes amiss and the installer completes with errors. Switching to a single sql server id and not using trusted authentication resolved this contention for me.

Interestingly, I did not have this issue in our test environment. This was a classic case of the server team delivering a test environment that did not match production. Different version of Vsphere, etc.

I do plan to switch back to trusted authentication for ongoing opertation, as that is the shop standard here.

P.S. Sometimes one sentence does a paragraph make. :wink:

Bill Jones (BOB member since 2002-10-11)