Getting smashed on vCenter 5.1 SSO Install

[TonyNguyen]

VMWare Experts,

Getting smashed on the vCenter 5.1 SSO Install and was wondering if I could get some assistance.

This is what I've done so far:

1.) Execute the "rsaIMSLiteMSSQLSetupTables.sql"

2.) Change only the "C:\Changeme" portion of the script which was "C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2K8R2\MSSQL\DATA

3.) Execute the script which created a database named RSA

I then went to vCenter Simple Install which started out installing the SSO which I got held up on.

Under Database Type: I chose MSSQL:

I am drawing a blank next on the syntax remaining fields.

The relevant server names are:

SQL Servername: TEST-SQL01.test.local

SQL Named Instance: SQL2K8R2

vCenter Server: TEST-VC01.test.local (where I will be installing the SSO, Inventory service, etc)

No idea on what to set for the Database Name, Windows Authentication, JDBC URL, etc.

I tried to follow the install guide and there was no mention of if I needed to set up ODBC connections or anything like that.

Any help would be greatly appreciated.

[TonyNguyen]

Any thoughts from the experts out there?

I see 14 replies to a softball question like "Does my 5.0 keys work in 5.1" so hoping to get a fraction replies for this harder question. :smileygrin:

[MATTBR · Accepted solution]

Sure, I'll be glad to assist you, Tony!  Admittedly, I thought the vSphere 5.1 Installation and Setup Guide was a little kludgy on SSO, too.

Assuming you already have a supported MSSQL DB running and are installing SSO on another Windows VM or server (separating SSO from vCenter is a best-practice), here's what I recommend you do to turn up SSO with a remote MSSQL DB (not a local MSSQLEXPRESS).

Note:Your SSO Windows server doesn't have to belong to an AD domain at this point since you can associate SSO with AD et al. later via the vCenter Web Client, but if it is joined before running the SSO install, it will save you this step.

While there may be other supported methods to install SSO, here are the basic steps that worked for me:

• Locate the rsaIMSLiteMSSQLSetupTables.sql on the vCenter 5.1 installation ISO ([CD Drive]:\Single Sign On\DBScripts\SSOServer\schema\mssql\) and double-click on it within the server running MSSQL, which will open up in SQL Management Studio for editing.
  
• Edit three[C:\CHANGEME\...] paths in the SQL script with the appropriate folder paths to your DBs & Trans Logs.  In my case, I put the DB and Index on D:\MSSQL\DB and the Logs on E:\MSSQL\LOGS
  
• Execute the script and if all is well, it will create an RSA database in MSSQL and complete successfully
  
• [IMPORTANT] Right-click on the top-level SQL Server icon and Select Properties, highlight Security and select the SQL Server and Windows Authentication mode (this is now a VMware requirement as indicated on page 241 of the vSphere 5.1 Installation and Setup Guide) and click OK.
  
• Restart MSSQL Service & Agent for this setting to take effect.
  
• Create a new SQL user account (i.e. sso) under MSSQL Server -> Security -> Logins in the SQL Management Studio hierarchy (ensure the account won't require you to change the password upon first login) and give it SYSADMIN Server Role and dbo to the RSA DB under User Mapping, click OK.
  
  • Note:You can avoid running the other SQL "users" script mentioned in thevSphere 5.1 Installation and Setup Guide for SSO user creation if you do this step and let the SSO installer create the users needed instead.
    
• Log into your soon to be SSO Windows server as an Administrator
  
  • Note:Ensure your Windows server is properly Hostname'd, IP'd, with forward and reverse DNS and clocks sync'd.  See documentation for other general prerequisites, if needed.  You can join it to an AD domain if you wish at this time.
    
• Launch the vCenter 5.1 SSO installer from the vCenter 5.1 ISO.
  
• Create a primary node for SSO (assuming this is your first one), click Next.
  
• Select Create the primary node for a new vCenter Single Sign On installation (so you can scale later on), click Next.
  
• Enter in whatever master password you wish to use for SSO, click Next.
  
• Select Use an existing supported database, click Next
  
  • Note:Since SSO uses JDBC, there is no need to create a ODBC System DSN for SSO.
    
• Enter, RSAin the Database Name field, enter the FQDN of your MSSQL server in the Host name or IP address field and, lastly, enter sso (from my example earlier) in the Database user name field as well as the password you established, click Next.
  
  • Note: nothing else on this page needs to be modified
    
• Enter in to FQDN of the SSO server (not the IP!), click Next.
  
• Keep checkbox Use network service account, Click Next
  
  • Note:Since I didn't really have any specific guidance about using a service account with SSO, I just went with the default for now.  Perhaps in the future I'll use a service account, but given SSO is somewhat AD independent I thought I'd go with a safe choice and not use an AD service account that could be revoked if SSO was detached from that AD in the future.
    
• Select your favorite installation folder, Click Next.
  
• Keep default port, Click Next.
  
• Click Install!
  

SSO should install properly and create the appropriate SQL user accounts called RSA_USER & RSA_DBA.

• Disable or delete the sso SQL Admin account you created as it's no longer needed once SSO is installed.
  

Next, Install the vCenter Inventory Service wherever you like as well as the vCenter Server and Web Client (i.e. separate VMs)

Tip:You can no longer just log into vCenter 5.1 using a local (Windows) administrator account via the vSphere 5.1 Client.  To establish vCenter Administrator rights to a Windows/AD user account (assuming SSO has been associated with AD), first log into vCenter (via vSphere 5.1 Client) using admin as the Username and the SSO master password you created during the installation of SSO.  That will get you in and you can make permission adjustments as necessary.

Before I'm totally flamed for what others might offer as a more refined way to get SSO stood up, I realize VMware offers a few different implementation approaches and perhaps new best-practices will emerge in the coming months.  My intention was to share with Tony my success in getting SSO online and I hope this helps others struggling with this new vCenter service.

Please feel free to comment as to anything you feel could be improved upon with these general installation steps or let me know how this worked out for you.

-Matt

[admin]

Hi   TonyNguyen ,

Welcome to the communities .

I dont think anything more have to comment after reading MATTBR comment. Its excellent .

"Life is never easy for those who dream"

[TonyNguyen]

TOO LONG DIDN'T READ

..

Just kidding. Matt. Looks very comprehensive, thank you for the detailed reply. I will try this out right away and let you know what happens. Your 6 posts doesn't represent the knowledge dimes you are dropping!

[TonyNguyen]

Hi Matt,

Not successful yet, but will get there. Here is where I am stuck. Getting Databse connection has failed.

1.) It is rsaMSLiteMSSQLSetupTablespaces.sql script correct? Your file name differs a little bit.

2.) For the login name, say I use 'sso'. Do I pick WIndows authentication or SQL Server authentication?

3.) Under user mapping for 'sso', I check map to database RSA and leave the schema alone right? I also don't make any changes to the Database role memberships for RSA? I'm not clear on the step "and dbo to the RSA DB under User Mapping, click OK."

4.) My SQL Service is on a named instance called "SQL2K8R2", the top of SQL shows ECHQ-SQL01\SQL2K8R2

My settings are as follows:

Database Type: MSSQL

Database Name: RSA

Host name or IP address:  echq-sql01.test.local

Port: 1433

Use Windows Authentication: UNCHECKED

Use manually created DB users: UNCHECKED
Database username: sso

Database password: <what I created in SQL2008R2 under SQL authentication>

Hope this is enough troubleshooting information for you.

Thanks again for all the help.

[datamoj]

Hi TonyNguyen.

I got the same error when I followed these steps. The problem for me was when I made the user "sso" I had him checked to enter a new password on first login. Try making a connection to your DB with the user "sso" and see if he needs to change his password.

After I changed the password of "sso" my install went fine.

Hope this helps you

[MATTBR]

Guess I made the assumption that folks would uncheck that SQL login option when creating a new admin account.  I've updated the tasks...thanks for pointing it out.

[ITHugo]

Hi TonyNguyen,

Have you verified the port that your SQL server is listening on?  I had the same issue and my SQL server was not listening on port 1433 but on another port.  Try telnetting to your SQL server on port 1433 to see if you get a response.  Once I verified the port the install continued without any issues.

[TonyNguyen]

Hi Matt,

No problem.   The exercise has encouraged me to be better at SQL troubleshooting.I resolved the issues but unfortunately I can't say for sure that the checkbox is the problem because bad me made 10 changes at the same time.

The summary key points for me was:

1.) Create the service account first. Give it local admin to the SSO box, and sysadmin privileges in SQL.

2.) Create the database with the included script. This makes a database named 'RSA'

3.) Log into the SSO server as the account created in key point 1.

4.) Load the SSO installer and configure with the following settings:

Database Type: MSSQL

Database Name: RSA (if you went with the default created by the sql script)
Host Name or IP: The FQDN of the SQL server. For example, SQL01.CONTOSO.COM

Port: 1443

Use Windows Authentication checked

And like Hugo mentioned, firewalls between the SSO/VMWare Innventory/vCenter/SQL should be verified for troubleshooting.

Thanks everyone for the help.

[malabelle]

Hi 🙂

I installed as stated.

I can login to the :9443 with the admin and sso password.

but inside it says it cannot connect to the vcenter.

When I installed the vCenter it went without failure.

When I try to login on the vcenter with the vsphere client with any account (even the admin and sso password) it says:

the vsphere client could not connect to <vcenterservername>

You do not have permissions to login to the server:

<vcenterservername>

Any ideas?

I was not able to install Update Manager either, since I cannot log in the vcenter server.

[DSeaman]

I'm writing up a series of vCenter 5.1 installation blogs, walking through the entire process and configuring trusted SSL certificates. I ran into a number of issues, so the instructions work around the hicups I found in my environment.

http://derek858.blogspot.com/2012/09/vmware-vcenter-51-installation-part-1.html

Still several posts left, but I'm working through them as fast as I can in my spare time.

[bedobash]

I am trying to setup SSO to point to a clustered SQL instance, so point it to a SQL server FQDN will not work.

For example: MFCS Server name is CLUSTER01, and SQL Server Instance is CLUSTER01SQL\TEST.

I can't figure out any way to feed this information to the install script that does not generate errors:

"null. Verify the connection properties, check that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port, and that no firewall is blocking TCP connections to the port." (when I point it to CLUSTER01SQL\TEST) OR

"Connection refused: connect. Verify the connection properties, check that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port, and that no firewall is blocking TCP connections to the port." (when I point it to SQLNODE1.fqdn)

Does SSO support backend clustered databases?

[bedobash]

I opened a support ticket with VMware and they state that vCenter 5.1 SSO does NOT support clustered databases at all at this time.

Which begs the question, how do you configure a highly available SSO deployment where the database is NOT highly available? I dont think this will go down very well unless VMware releases an update to fix this.

[malabelle]

from what I understand, you could double the sso installation behind a load balancer..

but frankly I've not managed to get it running on a single instance to date haha

What a piece of c**p

[LiamSinton]

Just wanted to add that this does work fine following MATTBR's instructions but make sure you don't create the RSA database in any other SQL instance than the root because I couldn't get it to work where I wanted it, in my SQLServer\vCenter instance (there's nowhere to include an instance name in the SSO wizard and adding \instancename after the FQDN or IP didn't work either.

You must use SQL authentication to connect to the database too as it fails using Windows authentication, see the release notes....

Connection to the MSSQL database fails during vCenter Single Sign On installation
The error message Database connection has failed appears when you install vCenter Single Sign On and you are using manually created MSSQL database users. For MSSQL databases, you must use SQL Server Authentication database users. Windows Authentication users are not supported.

Workaround: Ensure that the manually-created database users are using SQL Server authentication.

[Mephite]

Seconding the "do not install into a named instance".  This caught me up for a little today.

Had to go to the root instance on my database server and run the script to create the database there.

[ylkwang]

I managed to connect the SSO DB on a remote MSSQL 2008 named instance by entering the JDBC connection string:

jdbc:sqlserver://<serverName>:<portNumber>;instanceName=<InstanceName>;databaseName=RSA

Reference to JDBC URL: http://msdn.microsoft.com/en-us/library/ms378428(v=sql.90).aspx

Hope this helps.

David

[bedobash]

I was able to install (upgrade to) vSphere 5.1 by deploying a new VM for SSO, and installing SQL/SSO there. I verified SSO functionality by upgrading the vCenter web client, and logging in to web client with admin@System-Domain.

All of my vCenter modules had self-signed certificates (no domain/CA certs)

I then proceeded to upgrade all other packages, include vCenter, VUM, Auto deploy, etc... and only experienced issues related to user account rights to connect to vCenter (solution: make sure the account has the appropriate rights to the vCenter object).

Finally, I had to login to the vSphere client (or web client) to give the AD VMware administrators group to the vSphere Administrators permissions set, so my regular admin account has rights (as in 5.0)

Right now, the "Use Windows session credentials" isn't working (no passthrough) from either the vSphere client, or the web client; i have to manually enter username/password to login. This will be an issue for any sort of admin token users who don't login to servers via username/password. Has anyone experienced this and knows a solution/workaround? Otherwise I'll open a ticket with VMware.

[LiamSinton]

I logged the installation issues with VMware on Friday, spent about 2 -3 hours with them yesterday but go nowhere. No matter what we tried, we still ended up getting the 'Error 29114. Cannot connect to DB'.

They're trawling through the logs now and I'll update further when I know more.

Would love to know if anyone has actually managed to upgrade to 5.1 yet and still be able to login with domain credentials?!

bedobash, your issue where you can only login with admin@Sytem-Domain is worrying as I think that would stop all my Veeam backups working.

I think I might stay on 5.0 for a little longer ;-0