vCenter 5.1 Installation(Part 1) – Preparing the Databases

After the introduction of vSphere 5.1, there seemed to be a lot of fuzz about the installation of the new vCenter components. I believe most of the hype was caused about how the initial vSphere 5.1 release behaved differently against expired certificates from how vSphere version prior to 5.1 behaved. In earlier releases, vCenter has only checked the expiry date of the certificate used during the initial install and fall to a backup mechanism if the certificate fail though the service would went up and the user would use vCenter as nothing has happened. To increase the security of vCenter and prevent man in the middle attacks, this behavior was changed in vCenter 5.1. vCenter 5.1 is always checking the validity of its certificates every time the service is being started & it would report an error if it does not find a valid certificate. As many customers had an expired vCenter certificates and did not know about it before upgrading to vSphere 5.1 they were caught off guard by this small behavior change where VMware has quickly released a quick workaround for it and a new patch were released to improve how vCenter response to this behavior.

The installation of vCenter 5.1 has been much smoother after releasing vCenter 5.1b & ESXi 5.1a, & to calm my readers nerve about installing vCenter 5.1, I will be showing in here a step by step the installation process of vCenter 5.1 in a simple way that show its not much more difficult than what used to be done in vSphere 5.0 if you know what you are doing. I will actually show the process of even creating and preparing the Databases required for vCenter. I know there is few posts out there describing the process, but they have either not included the DB part or still impeding many of the initial vSphere 5.1 release installation issues and workaround in them which can make the installation seems much more complex than it really is.

So before I share the installation steps with you, let’s talk a bit about what has changed in vSphere 5.1 installation from what used to be done in prior vSphere versions. vSphere 5.1 has added the feature of Single Sign On, which should allow you to login once and access multiple vCenters in your environment and should be able to help you to access many more VMware products in the future without having to over and over again each time you access each product portal. As well Single Sign On will allow companies to use different kind of LDAP servers like Active Directory, Open LDAP, NIS. Further, it will allow you to use multiple LDAP source at once even from the same LDAP type. For example you can assign permissions to vCenter for users from different Active Directory Domains without having any trust relationship between those domains which was not possible with earlier versions of vSphere.

In addition to Single Sign being added, now you have the option to separate vCenter components to multiple servers, which will allow vCenter to scale up even further. Unlike earlier versions of vCenter, now you can install each of vCenter Components(vCenter Service, Inventory Service, Single Sign On(SSO)) to different VMs or machines. One thing to remember though there is nothing stopping you from installing all of them to the same host unless you are reaching the scalability limit of vCenter at 10,000VMs and 1000 hosts. For most environments where they are not even close to those limits, there is nothing stopping them from installing all the components on a single host/VM. Actually If you are not approaching that limit I would always install the inventory service on the same host/VM with the vCenter Service.

The main one to decide on where to place it is the SSO Service. If you only have one vCenter and you don’t see yourself adding any more vCenters then having SSO share the same vCenter Service host/VM is a no brainier. Though if you have multiple vCenters that will utilize the same SSO, then you want to consider how will you protect the SSO service. If you have vCenter Heartbeat then you can install SSO on the same vCenter VM, & protect all the vCenter services with vCenter heartbeat. Another choice would be to install SSO on a separate VM and the protect it with its own availability mode. As you can see the decision of where to place the SSO service is more dependent on how you are planning to protect your SSO machine and what you are going to use it for, though if you have a small deployment then its safe to put all the vCenter components together. If you have a larger deployment its safe to put them all on the same host unless you are reaching the limits or if you want to protect your SSO with its built-in availability mode.

Before starting the installation of the vCenter services, you will need to prepare the prerequisites. To find out all of the supported operating systems & Databases supported by vCenter you can check the following VMware KB: where the same KB will help you with sizing vCenter for your requirements. For this installation, I am going to utilize Windows 2008 R2 for the vCenter Server OS, & MS SQL Server 2008 R2 for the Database. The instruction below assume you have already installed the database and the Windows OS prior to following the below instructions.

Below I will demonstrate how prepare the SQL Databases for your vCenter 5.1 installation in step-by-step fashion, though its worth mentioning setting up the vCenter Service DB & Update Manager DB has not changed since the previous vSphere version so if you are familiar with earlier vCenter installation feel free to set them up the way you always did though I included the instruction for them below for new comers. Though the main difference in setting up the DBs in preparation of vCenter Installation in vSphere 5.1 is the extra requirement of the SSO Database and the creation of two DB users for it. The below instruction walk you through the preparation of all the required DBs:

Preparing Database for vCenter 5.1  Components:

vCenter & Update Manager Databases preperation:

1-    Right click database and click on new database

Create vCenter 5.1 DB in MS SQL


2-    Fill the database name then hit OK to create the DB

Give the vCenter DB a name maybe vc01


3-    Repeat the step 1 & 2 to create the Update Manager DB

4-    Create new DB login by expanding security, then right click login, then click on New Login

Create SQL Database account for vCenter

5-    Complete the form of the new login as shown in the below screenshot. Make sure to untick the enforce password expiration and user must change password at next login

Ensure to use SQL Server Authenication for vCenter DB user

6-    Repeat steps 4 & 5 for the UM database

7-    Assign the vc user a db_owner access to both created databases(vCenter DB & UM DB) & MSDB by

8-    Expand your database => security => users => New user

9-    Assign db_owner privillages to the vc user created earlier. Repeat these steps for both vCenter & Update Manager Database as in the below screen shot.

Assign the vCenter DB user proper permissions

10-To create the SSO database use the DB Script that come up with the vCenter CD and can be found at: D:\Single Sign On\DBScripts\SSOServer\schema\mssql\rsaIMSLiteMSSQLSetupTablespaces.sql

11-Open the script in Microsoft SQL Server management Studio File => Open =>File & Choose the script file

Once the script is opened in Microsoft SQL Server management Studio Replace all 3 occurrences of C:\CHANGE ME with the path to the folder you want your databases to reside in as shown in the below screen shot. As well Make sure that you have created the folder to contain the DBs before executing the script.

Execute the script to create the RSA DB for the SSO Service

12-         Press the Execute button to execute the script and create the required databases.

13-         Expand your database and make sure the RSA database is created as shown at the left side of the below screenshot

Make sure the SSO Service Database is created properly

14-         Create two new logins RSA_USER & RSA_DBA and assign each of them a DB Owner on the RSA DB. You can achieve this by following step 4-9 though for the RSA DB this time & using the RSA_USER & RSA_DBA users.

This should get your SQL DBs ready to start your vCenter Services installation, though if this is a totally new SQL server you have setup for the environment, you want to ensure it allow TCP/IP Protocol connectivity as well remote connections. Follow the below steps to check on that quickly.

1- Make sure in SQL Server the “Allow remote connections to this server” is checked.

Ensure that you allow remote connections to your SQL Server

2- Ensure in SQL Server Configuration Manager that the TCP/IP protocol is enabled.

Ensure that TCPIP protocol is enabled for your SQL Server


Alright so you are now ready to proceed with vCenter Components Installation (vCenter Service, Inventory Service, & Single Sign On). I will be adding posts showing the steps by steps installation of each of those components quite soon as I have it written in a word document, but it take a lot of efforts to clean it up and make it ready for a blog post. Though keep checking as they will be here soon!

Update: The following Parts of this series have been Published.

vCenter 5.1 Installation(Part 2) – Single Sign On Installation

vCenter 5.1 Installation(Part 3) – vCenter 5.1 Inventory Service Installation

vCenter 5.1 Installation(Part 4) – vCenter Service Step by Step

vCenter 5.1 Installation(Part 5) – vSphere Web Client Step by Step


  1. Good work. I did a similar series last year for vSphere 5.1 as well, which incorporates using trusted SSL certificates and some automation scripts.


  1. […] Three vCenter components require a database. Single Sign On, vCenter Service, & Update Manager each of those components require its own database, where the creation of those databases have been documented at the first post in this series found at:  vCenter 5.1 Installation(Part 1) – Preparing the Databases. […]

  2. […] vCenter 5.1 Installation(Part 1) – Preparing the Databases […]

  3. […] vCenter 5.1 Installation(Part 1) – Preparing the Databases […]

  4. […] Preparing the Database for Single Sign On installation […]

Speak Your Mind