Deploying VMware vSphere 5.1 Single Sign On, Inventory Service and vCenter Server

As I had to deploy 2 new instances of vCenter over the weekend in Linked Mode, I took the opportunity to document all the steps so I could write a blog post demonstrating the steps for the deployment.  The follow demonstrates a VMware vSphere 5.1 vCenter deployment with all the services installed onto the server and a full SQL 2008 R2 Standard Server installed directly onto the same vCenter server.

Prerequisites

Begin by creating an Active Directory domain account that you’ll be using to run the vCenter service and grant it Act as part of the operating system permissions to the vCenter server.  You can use a GPO to assign the permission or edit the local computer policy.  For the purpose of this example, I will use the Local Computer Policy so open up the Run prompt and run:

gpedit.msc

Navigate to Local Computer Policy –> Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> User Rights Assignment

Edit the Act as part of the operating system policy and add the vCenter service account in:

Next, add the vCenter service account into the local Administrators group on the vCenter server:

With the permissions for the service account set, proceed with adding the .NET Framework 3.5.1. feature onto the server by opening PowerShell ane executing the following cmdlet:

Import-Module ServerManager

Add-WindowsFeature as-net-framework

You can use the Server Manager to confirm that it is installed by navigating to the Features node:

Set up Single Sign On (SSO) Database

The scripts that we’ll be using to create the database used by the Single Sign On (SSO) service can be found in the following location (assuming you’ve extracted the package to your C drive):

C:\VMware-VIMSetup-all-5.1.0-880471\Single Sign On\DBScripts\SSOServer\schema\mssql

1. rsaIMSLiteMSSQLCreateSchema.sql
2. rsaIMSLiteMSSQLDropSchema.sql
3. rsaIMSLiteMSSQLDropUsers.sql
4. rsaIMSLiteMSSQLSetupTablespaces.sql
5. rsaIMSLiteMSSQLSetupUsers.sql

The scripts we’ll be using are:

1. rsaIMSLiteMSSQLSetupTablespaces.sql
2. rsaIMSLiteMSSQLSetupUsers.sql

Begin by launching SQL Server Management Studio and opening the first script:

rsaIMSLiteMSSQLSetupTablespaces.sql

CREATE DATABASE RSA ON PRIMARY(

    NAME='RSA_DATA',

FILENAME='C:\CHANGE ME\RSA_DATA.mdf',

    SIZE=10MB,

    MAXSIZE=UNLIMITED,

    FILEGROWTH=10%),

FILEGROUP RSA_INDEX(

    NAME='RSA_INDEX',

FILENAME='C:\CHANGE ME\RSA_INDEX.ndf',

    SIZE=10MB,

    MAXSIZE=UNLIMITED,

    FILEGROWTH=10%)

LOG ON(

    NAME='translog',

FILENAME='C:\CHANGE ME\translog.ldf',

    SIZE=10MB,

    MAXSIZE=UNLIMITED,

    FILEGROWTH=10% )

GO

-- Set recommended perform settings on the database

EXEC SP_DBOPTION 'RSA', 'autoshrink', true

GO

EXEC SP_DBOPTION 'RSA', 'trunc. log on chkpt.', true

GO

CHECKPOINT

GO

------------------------------------------------------------------------------------------------------------------------------------------------------------------

It’s important to note that names RSA_DATA and RSA_INDEX are supposed to be hard coded in the Single Sign On service and while this may change in the future, it’s best to not attempt to change them.  With that being said, you are free to change the database name RSA to a different name.  Whether you change use a different name would be your choice but to keep the database recognizable to anyone upon first glance, I’m going to continue using RSA as the name.  This means that the only content I’m going to change is the location of the mdf, ndf and ldf files highlighted in RED:

CREATE DATABASE RSA ON PRIMARY(

    NAME='RSA_DATA',

FILENAME='E:\Databases\RSA_DATA.mdf',

    SIZE=10MB,

    MAXSIZE=UNLIMITED,

    FILEGROWTH=10%),

FILEGROUP RSA_INDEX(

    NAME='RSA_INDEX',

FILENAME='E:\Databases\RSA_INDEX.ndf',

    SIZE=10MB,

    MAXSIZE=UNLIMITED,

    FILEGROWTH=10%)

LOG ON(

    NAME='translog',

FILENAME='E:\Logs\translog.ldf',

    SIZE=10MB,

    MAXSIZE=UNLIMITED,

    FILEGROWTH=10% )

GO

-- Set recommended perform settings on the database

EXEC SP_DBOPTION 'RSA', 'autoshrink', true

GO

EXEC SP_DBOPTION 'RSA', 'trunc. log on chkpt.', true

GO

CHECKPOINT

GO

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Executing the script above should create the RSA database shown in the Object Explorer on the left:

With the database created, the next step is to set up the 2 user objects required for accessing the RSA database.  To so do, use the following script:

rsaIMSLiteMSSQLSetupUsers.sql

USE MASTER

GO

CREATE LOGIN RSA_DBA WITH PASSWORD = '<CHANGE DBA PASSWORD>', DEFAULT_DATABASE = RSA

GO

CREATE LOGIN RSA_USER WITH PASSWORD = '<CHANGE USER PASSWORD>', DEFAULT_DATABASE = RSA

GO

USE RSA

GO

ALTER AUTHORIZATION ON DATABASE::RSA TO [RSA_DBA]

GO

CREATE USER RSA_USER FOR LOGIN [RSA_USER]

GO

CHECKPOINT

GO

------------------------------------------------------------------------------------------------------------------------------------------------------------------

It’s important to note that the comments state the following:

-- The DBA account is used during installation and the USER account is used during
-- operation. The user names below can be customised, but it is forbidden to include
-- reserved keywords like table or any characters other than letters, numbers, and _ .

So proceed with using the default user account names RSA_USER and RSA_DBA or change them if you would like to use another name.  For the purpose of this demonstration and to keep things consistent with the first script used to create the database, I will only change the passwords highlighted in RED:

USE MASTER

GO

CREATE LOGIN RSA_DBA WITH PASSWORD = '2wsx@WSX', DEFAULT_DATABASE = RSA

GO

CREATE LOGIN RSA_USER WITH PASSWORD = '2wsx@WSX', DEFAULT_DATABASE = RSA

GO

USE RSA

GO

ALTER AUTHORIZATION ON DATABASE::RSA TO [RSA_DBA]

GO

CREATE USER RSA_USER FOR LOGIN [RSA_USER]

GO

CHECKPOINT

GO

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Executing the script above should create the user accounts and assign the appropriate permissions to the RSA database:

Note the 2 accounts located under Security –> Logins:

• RSA_DBA
• RSA_USER

**Note that there is no need to run the other scripts such as:

rsaIMSLiteMSSQLCreateSchema.sql

… or you may run into the error message:

Error 29120. Database schema already exists

… that I blogged about earlier here: http://terenceluk.blogspot.com/2013/02/installing-vsphere-51-vcenter-single.html

Set up vCenter Database and ODBC

The first step for setting up the vCenter database is to create the database with the following script found on page 205 in the installation guide (http://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-51-installation-setup-guide.pdf):

use [master]
go
CREATE DATABASE [VCDB] ON PRIMARY
(NAME = N'vcdb', FILENAME = N'C:\VCDB.mdf', SIZE = 2000KB, FILEGROWTH = 10% )
LOG ON
(NAME = N'vcdb_log', FILENAME = N'C:\VCDB.ldf', SIZE = 1000KB, FILEGROWTH = 10%)
COLLATE SQL_Latin1_General_CP1_CI_AS
go
use VCDB
go
sp_addlogin @loginame=[vpxuser], @passwd=N'vpxuser!0', @defdb='VCDB',
@deflanguage='us_english'
go
ALTER LOGIN [vpxuser] WITH CHECK_POLICY = OFF
go
CREATE USER [vpxuser] for LOGIN [vpxuser]
go
use MSDB
go
CREATE USER [vpxuser] for LOGIN [vpxuser]
go

From this point, we need to make a decision on the following:

1. Set Database Permissions By Manually Creating Database Roles and the VMW
   Schema
2. Set Database Permissions by Using the dbo Schema and the db_owner Database
   Role

Option #1 takes a bit more time because you need to manually create the database roles and assign them to the service account while the latter simply assigns the dbo Schema and db_owner database role to your service account.  What’s interesting is that I believe option #1 was introduced in vCenter 5.0 because I don’t recall seeing this in the earlier deployment guides.  I’ve always used the 2nd option but it’s obviously not as secure because VMware does recommend option #1.  With that being said, I will only demonstrate option #2 as I for this particular deployment, I went with that route.

Since we won’t be using Windows Authentication (like my vCenter 4.1 post here: http://terenceluk.blogspot.com/2010/10/creating-vcenter-41-sql-database-and.html) and that we’ll be using SQL Authentication, we can pretty much just use the default script with the modifications highlighted in red:

use [master]

go

CREATE DATABASE [VCDB] ON PRIMARY

(NAME = N'vcdb', FILENAME = N'K:\Databases\VCDB.mdf', SIZE = 2000KB, FILEGROWTH = 10% )

LOG ON

(NAME = N'vcdb_log', FILENAME = N'L:\Logs\VCDB.ldf', SIZE = 1000KB, FILEGROWTH = 10%)

COLLATE SQL_Latin1_General_CP1_CI_AS

go

use VCDB

go

sp_addlogin @loginame=[vpxuser], @passwd=N'P@ssw0rd', @defdb='VCDB',

@deflanguage='us_english'

go

ALTER LOGIN [vpxuser] WITH CHECK_POLICY = OFF

go

CREATE USER [vpxuser] for LOGIN [vpxuser]

go

use MSDB

go

CREATE USER [vpxuser] for LOGIN [vpxuser]

Continue by clicking on the Execute button and ensure that the Messages windows outputs the message: Command(s) completed successfully.

Since we went with option #2 for this example, we will also need to execute the following:

use VCDB
go
sp_addrolemember @rolename = 'db_owner', @membername = 'vpxuser'
go
use MSDB
go
sp_addrolemember @rolename = 'db_owner', @membername = 'vpxuser'
go

 

Alternatively, if you want to combine both of the transact-sql statements together, you can execute the following in one shot:

use [master]
go
CREATE DATABASE [VCDB] ON PRIMARY
(NAME = N'vcdb', FILENAME = N'K:\Databases\VCDB.mdf', SIZE = 2000KB, FILEGROWTH = 10% ) LOG ON
(NAME = N'vcdb_log', FILENAME = N'L:\Logs\VCDB.ldf', SIZE = 1000KB, FILEGROWTH = 10%) COLLATE SQL_Latin1_General_CP1_CI_AS
go
use VCDB
go
sp_addlogin @loginame=[vpxuser], @passwd=N'P@ssw0rd', @defdb='VCDB',
@deflanguage='us_english'
go
ALTER LOGIN [vpxuser] WITH CHECK_POLICY = OFF
go
CREATE USER [vpxuser] for LOGIN [vpxuser]
go
sp_addrolemember @rolename = 'db_owner', @membername = 'vpxuser'
go
use MSDB
go
CREATE USER [vpxuser] for LOGIN [vpxuser]
go
sp_addrolemember @rolename = 'db_owner', @membername = 'vpxuser'

With the database created, the next step is to create the 64-bit ODBC DSN Connection by opening up the Start menu, navigate to Administrative Tools –> Data Sources (ODBC) then select the System DSN tab and click Add:

A common mistake I’ve come across when troubleshooting DSN creation problems is that a SQL Server driver was created instead of the SQL Server Native Client 10.0. So make sure you select the latter and click Finish.

SQL Server = WRONG

SQL Server Native Client 10.0 = RIGHT

Fill in the following fields:

Name: This is just a logical name and can be anything you want.

Description: Logical description.

Server: You can either put the NetBIOS or FQDN of the server name. I personally prefer the FQDN.

 

Since we’re not using a domain service account, select the radio button for With SQL Server authentication using a login ID and password entered by the user and enter the credentials for the account you configured during the database creation:

Make sure you change the default database to your vCenter database that you created earlier. The name in the installation guide is VCDB:

Leave the following settings as default and click Finish:

A window is now presented that allows you to test the ODBC connection. Proceed with clicking on the Test Data Source button to test connecting over to the vCenter database with the SQL Authentication credentials entered in one of the previous screens:

Confirm that the test completes successfully:

Once you click finish, you will now see your new ODBC DSN:

Set up vSphere Update Manager (VUM) Database and ODBC

Setting up the vCenter 5.1 Update Manager (VUM) database is pretty much the same as setting up the vCenter database and the following are the assumptions made for the VUM environment:

• We are going to use the same VPXUSER account that we are using for the vCenter database to access the VUM database with SQL Authentication

The following is the transact-sql to use to create the database and assign the appropriate permissions:

use [master]
go
CREATE DATABASE [VUMDB] ON PRIMARY
(NAME = N'vumdb', FILENAME = N'K:\Databases\VUM.mdf', SIZE = 2000KB, FILEGROWTH = 10% )
LOG ON
(NAME = N'vumdb_log', FILENAME = N'L:\Logs\VUM.ldf', SIZE = 1000KB, FILEGROWTH = 10%)
COLLATE SQL_Latin1_General_CP1_CI_AS
go
use VUMDB
go
CREATE USER [vpxuser] for LOGIN [vpxuser]
use VUMDB
go
sp_addrolemember @rolename = 'db_owner', @membername = 'vpxuser'
go

As with vCenter 4.1 and 5.0 Update Manager, the vCenter 5.1 Update Manager still uses a 32 bit DSN so make sure you open up the ODBC Data Source Administrator via:

%systemdrive%\Windows\SysWoW64\Odbcad32.exe

Then proceed with creating the DSN as shown in the following screenshots:

Change the default database to the VUM database:

Test the ODBC DSN:

Install vCenter Single Sign On Service (SSO)

Begin by launching the VMware vCenter Installer and selecting vCenter Single Sign On:

Select Create the primary node for a new vCenter Single Sign On installation:

Instead of selecting the Install basic vCenter Single Sign On option, select Create the primary node for a new vCenter Single Sign On installation:

**Note that we have nothing to lose with selecting the 2nd option because the SSO service will operate as normal even if we do not add an additional SSO node to the installation such as when we want to install another vCenter in Linked Mode.  If we were to choose the first option, we would not be able to add any additional vCenters to the environment.

Enter the password you would like to use for the admin@System-Domain account for the Single Sign On service:

Select Use an existing supported database:

Fill in the fields:

Host name or IP address <— The database server’s FQDN

Database Name <— The name of the database (we used RSA)

Port <— Leave as the standard 1433 unless this has been changed on the SQL server

Database user name <— The name of the database user account (we used RSA_USER)

Database password <— The password for the database user account

Database DBA user name <— The name of the database DBA user account (we used RSA_DBA)

Database DBA password <— The password for the database DBA user account

The following field should be automatically filled in with the FQDN of server you’re installing the SSO service on:

Before proceeding to the next prompt, click on the Back button to get back to the SSO database information prompt:

Note that the JDBC URL is now filled out.  Assuming that you don’t care to encrypt the traffic between the SQL server and the SSO service, you can proceed with the install.  If encrypting the traffic between the SQL server and SSO service is important, there are 2 ways to approach this and the first is to use the self signed certificate on the SQL server that isn’t trusted by the vCenter SSO service by default.  This can be done by appending the following to the end of the JDBC URL:

encrypt=true;trustservercertificate=true

… so that the URL would look something like this:

jdbc:sqlserver://;serverName=dbServer.domain.com;port=1433;databaseName=RSA;encrypt=true;trustservercertificate=true

The second option is to configure proper Certificate Authority issued certificates for securing the traffic.  I will not be going into this for this blog post so I’m simply going to append the string above to force the trust.

The FQDN should automatically be filled in for you:

While the following prompt is traditionally filled in with the account you are logged in, I noticed that this wasn’t the case for me so uncheck the Use network service account and fill in the vCenter domain service account:

Confirm the directory for the SSO files:

Unless there’s a reason why you need to change the SSO HTTPS port @ 7444, leave it as default:

Proceed with the install:

Install vCenter Inventory Service

Begin by launching the VMware vCenter Installer and selecting VMware vCenter Inventory Service:

Proceed through the wizard:

Accept the EULA:

Confirm the location to install the files:

The following field should automatically be filled in with the FQDN of the server you’re installing the Inventory Service on:

Accept the default ports unless they need to be changed:

Select the appropriate Inventory Size for the JVM Memory:

The Lookup Service URL should automatically be filled out for you so enter the vCenter Single Sign On administrator password:

Confirm to over write certificates:

Proceed with the install:

Install vCenter Server

Begin by launching the VMware vCenter Installer and selecting VMware vCenter Server:

Proceed through the wizard:

Note that Microsoft Visual C++ 2005 Redistributable will be automatically installed for you:

Accept the EULA:

Enter a license key if you have it already or you can enter it afterwards:

Select the ODBC DNS that was created earlier for the VCDB vCenter database:

Enter the credentials for the SQL Server Authentication vpxuser account:

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

**Note that if you receive the following error:

The DB user entered does not have the required permissions needed to install and configure vCenter Server with the selected DB…

This is most likely because you forgot to assign the permissions to the VCDB database for the vpxuser account. You can execute the following SQL commands to quickly assign the permissions:

use VCDB
go
sp_addrolemember @rolename = 'db_owner', @membername = 'vpxuser'
go
use MSDB
go
sp_addrolemember @rolename = 'db_owner', @membername = 'vpxuser'
go

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

You may receive the following warning message as you proceed which is just a reminder that the database is set to Full recovery model meaning the transaction logs (ldf) file will continue to grow if they are not backed up and/or truncated.  Whether you switch the recovery model to simple would depend on the backup strategy for the database.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

Uncheck the Use SYSTEM Account checkbox and enter the credentials for the vCenter domain service account:

Select Create a standalone VMware vCenter Server instance:

Confirm the default ports being used for the vCenter service:

Select the appropriate Inventory Size:

The Lookup Service URL should automatically be filled out for you so enter the vCenter Single Sign On administrator password:

Since we installed the SSO service for Multinode high availability and/or multisite, leaving the default Administrators would most likely throw the error:

Wrong input – either a command line argument is wrong, a file cannot be found or the spec file doesn’t contain the required information, or the clocks on the two systems are not synchronized. Check vm_ssoreg.log in system temporary folder for details.

The reason why this error is presented is because SSO installed to support multisites does not support local accounts which makes sense because you can’t possibly assign a local account on one vCenter to another since the directory is local to the server.  To proceed, change the field to a domain user or group.  In this example, I used domain admins:

The Lookup Service URL and vCenter Inventory Service URL fields should automatically be populated for you:

Confirm the folder to install the vCenter files:

Proceed with the install:

As noted in the following KB:

Active Directory Web Services fails to read the settings for the specified Active Directory Lightweight Directory Services instance
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023864

One of the items to check before concluding the install is to navigate to the following registry key:

HKLM\System\CurrentControlSet\Services\<ADAM_INSTANCE_NAME>\Parameters\Port SSL

… and check to see if the Port SSL key is of the type REG_DWORD and if it is the type REG_SZ as shown above then you will need to delete it and recreate it as a REG_DWORD with the decimal value of 636 shown below:

 

Install vSphere Client

Proceed with the install of the vSphere Client so you can test vCenter connectivity.

Install vSphere Web Client

Proceed with the install of the vSphere Client for vCenter connectivity through a browser and/or adding earlier vCenter 5.0 severs for management (vCenter 5.1 servers are automatically added):

The Lookup Service URL field should already be populated so continue by filling in the SSO administrator password:

To add vCenter 5.0 servers, launch the vSphere Administration Application from the Start Menu:

… and add it via the vSphere Web Client Administration Tool.  Remember that this is only for older 5.0 vCenters and not 5.1:

To verify that the vSphere Web Client is functioning as expected, launch it via the Start Menu:

Install vSphere Update Manager

The last component to install is the vSphere Update Manager service so being by launching the installer and select vSphere Update Manager:

Proceed through the wizard:

Accept the EULA:

I prefer to use the DNS name even though the default is set to the IP address of the server so make the appropriate changes and enter the vCenter server service credentials or another service account if you want to use a different account:

Select the ODBC DSN that was created earlier and type in the vpxuser account’s password:

Select the name of the server and accept the default ports:

I usually prefer to add separate drive for the location that the patches are downloaded to so make the appropriate changes:

Proceed with the install:

Test vCenter Connectivity

With all the components installed, proceed with launching the vSphere Client and test connectivity to vCenter:

Once logged in, verify that all the services are functioning as expected.  As a final check, it may also be worth while to check the services on the server to ensure they are all started:

• vCenter Single Sign On
• VMware vCenter Inventory Service
• VMware vCenter Orchestrator Configuration <— Manual startup
• VMware vCenter Orchestrator Server <— Manual startup
• VMware VirtualCenter Management Webservice
• VMware VirtualCenter Server
• VMware vSphere Profile-Driven Storage Service
• VMware vSphere Update Manager Service
• VMware vSphere Update Manager UFA Service <— Manual startup
• MVware vSphere Web Client

This concludes this blog post.  I will be posting the second part of this deployment at a later time where the second vCenter was installed and joined in Linked Mode.