The requirement of a database for the vSphere collection of products is typically a stressed relationship for those looking to use the product (typically server or virtualization administrators) and those looking to run a collection of databases and instances (typically DBAs). Many server folks are somewhat averse to mucking around in the world of SQL databases. This holds especially true when your DBAs are of the long beard, robe, and sandal wearing variety, lording over their cryptic domain with an iron fist. No offense intended to the hard working DBAs out there, but this is often the Dilbert-esque perception. 🙂

With vCenter 5.1, yet another database is now required (in addition to the vCenter database and other products like Update Manager, vCloud Director, etc.). This one is for the Single Sign On (SSO) service. There are a couple things I find that puzzles people when they hear about SSO:

First, the database’s default name is RSA, not SSO.
And second, the install directions ask for a pair of SQL accounts for “DBA” and “User” access.

Perhaps this header tidbit from one of the scripts I’ll cover below offers some clues on the name.

Fortunately, VMware is nice enough to provide some SQL scripts that I will show you how to use.

If you’ve already completed this section on SSO Database creation and configuration, move on to Part 2 which covers the service installation.

Video Walkthrough

If you feel so inclined, I have provided a video covering this entire article. Otherwise, keep scrolling down for more SSO database goodies.

As always, if you enjoyed the video please toss me a “Like” and if you want more videos on the channel I’d appreciate your subscription. 🙂

Preparing The SQL Instance

The first step is to locate and edit the two scripts needed to build your shiny new database.

Note: Obviously there is a way to just cheat this process – you can make one SQL account and use it for all of your “vCenter Stuff” databases. I tend to think that having an army of service accounts for this is overkill for many environments. But hey – I just see what actually goes on out in the field. With that said, I’ll walk through the process for the SSO process assuming that you’re going to use unique accounts.

Navigate to the following path on your vCenter Installation DVD:

\Single Sign On\DBScripts\SSOServer\schema\mssql

Inside you’ll see a bunch of scripts. The two we’re interested in are:

rsaIMSLiteMSSQLSetupTablespaces
rsaIMSLiteMSSQLSetupUsers

The first script (SetupTablespaces) will create your database and will be covered first.

Database Creation

Connect to the database instance using SQL Server Management Studio as a user with administrative or sysadmin powers and open the SetupTablespaces SQL file. I typically just RDP into the SQL server and run it there. Within the script exist several fields that you can, and should, change.

I’ve highlighted the name of the database with a red box – by default it is “RSA” but you can make it whatever you want. In this example, I’ve made it “WAHLNETWORK”.
Additionally, change the path to the three files to match your server’s folder structure. By default, the path is “CHANGE ME” to help nudge you to changing it. It would be really weird if you had an actual folder with that name. 🙂 In my case, it is the “E:\” drive. I’ve denoted the path changes with a green check mark.

Once your script looks good, press F5 or click Execute. Congratulations, you have an empty database!

User Creation and Permissions

The next step is to run the rsaIMSLiteMSSQLSetupUsers script. From SQL Management Studio, open the script and edit it to match the information you provided when creating the database.

Similar to the database script, I’ve highlighted where the database name needs to be changed with a red box. This is only if you changed the default name of “RSA” to something else.
I put green check marks on the area where you set the SQL account passwords. It will be in plain text while you run the script, so make sure that no spies are looking over your shoulder. Make sure the passwords meet your SQL server’s complexity requirements – failure to do so will result in the accounts not being able to log in. If you find yourself stuck in this situation, just change the passwords to something complex enough to meet requirements before attempting to install SSO.

Execute the script. If you see a result of “Command(s) completed successfully” you should be in the clear.

What are the User Accounts For?

Per VMware:

Why are the RSA_DBA and RSA_USER users required, and what SQL access rights do they require?
RSA_DBA is used for creating the schema (DDL) and requires DBO permissions. RSA_USER reads and writes data (only DML).

Verifying Access

Now that the bits and pieces are in place, do a quick check to make sure the permissions applied correctly.

The RSA_DBA Account

Check the Security > Logins section for the RSA_DBA account (or whatever you named it). Make sure the “User Mapping” area shows that the account is the dbo for your database, both as the user and schema, which is “WAHLNETWORK” in my example below.

The RSA_User Account

Right click on your new database and click on the Permissions section. You should see that RSA_USER is showing in the list with type “User” and has been granted the “Connect” permission.

Thoughts

You’re now done with the database portion of configuring Single Sign On. In Part 2, I cover installation of the service.

Here’s a list of reference materials that you can source for your installation:

I’ve also compiled a list of some other blogs discussing the SSO Database below. If you have a blog post on the subject, please let me know and I will add it to the list!