---
This is the first post in a series of blog articles about configuring vSphere 5.1.0A. Links to the other parts are below:
VMware vCenter 5.1 Installation: Part 2 (Create vCenter SSL Certificate)
VMware vCenter 5.1 Installation: Part 3 (Install SSO Service SSL Certificate)
VMware vCenter 5.1 Installation: Part 4 (Install Inventory Service)
VMware vCenter 5.1 Installation: Part 5 (Install Inventory Service SSL Certificate)
VMware vCenter 5.1 Installation: Part 6 (Create vCenter and VUM Databases)
VMware vCenter 5.1 Installation: Part 7 (Install vCenter Server)
VMware vCenter 5.1 Installation: Part 8 (Install Web Client)
VMware vCenter 5.1 Installation: Part 9 (Optional SSO Configuration)
VMware vCenter 5.1 Installation: Part 10 (Create VUM DSN)
VMware vCenter 5.1 Installation: Part 11 (Install VUM)
VMware vCenter 5.1 Installation: Part 12 (VUM SSL Configuration)
VMware vCenter 5.1 Installation: Part 13 (VUM Configuration)
VMware vCenter 5.1 Installation: Part 14 (Web Client and Log Browser SSL)
VMware vSphere 5.1.0A was released on October 25th, and 5.1 GA was released in mid-September. Given all of the new components and architecture of vCenter, I wanted to walk through the entire configuration process from scratch assuming a greenfield environment. The original 5.1 release had a lot of, shall we say, bugs and issues related to the SSO service and SSL problems.
This series covers:
- vCenter 5.1.0A Installation on Windows Server 2008 R2
- SSO service, Inventory Service, vCenter Server, vSphere client, vSphere Web client, and VUM
- Configure SSL certificates for all vSphere services
On another security note the SQL server MUST be configured to allow both Windows integrated authentication AND SQL authentication. SQL authentication is very weak, which makes the use of SSL for the database connection that much more imperative. Should the SQL server only allow Windows integrated authentication you will likely get the following error:
Error 29115.Cannot authenticate to DB.
Use SQL studio to login to your SQL server, open the server properties then use the less secure option of SQL Server and Windows Authentication mode. Restart the SQL services.
These instructions reflect using vSphere 5.1.0A, which has a different database setup than the 5.1 GA release. I would strongly urge you to use only the 5.1.0A release, and not 5.1 GA. ?
1. I provisioned a Windows Server 2008 R2 SP1 VM, with 2 HDs, and all of the latest Windows updates. This is just for my modest home lab, so I'm not modifying my 3GB/1vCPU configuration, and this will be an all-in-one server configuration. 6GB, and even 8GB of RAM for an all-in-one server is recommended, otherwise vCenter and SSO will run verrrrrrrry slowly.
I also created a service account (SVC-VCTR02-001) in AD, and added that account to the local Administrator's group on what will become the vCenter 5.1 server. You need to ensure the service account also has the "Act as part of the operating system" user right on the vCenter server. If the Administrators group has the right then you are covered. If not, explicitly add the service account to the user right as shown below. Should you need to add the account, reboot the server after so that it takes effect.
2. Login as the newly created vCenter service account and launch the vSphere 5.1.0A (build 880471) installer from the ISO image and you are presented with the following screen.
3. At this point if you try and install the .NET 3.5 SP1 from this screen it will fail, since you need to add the "feature" to the OS. Open the Server Manager and add the .NET Framework 3.5.1 feature and wait for the install to complete.
4. Now you can continue with the vSphere Installer and either do a "Simple Install" or install each component separately. Since I like to customize the installation location and possibly other settings, I don't want Simple. Unlike prior vCenter installations, there is a new software installation order. So don't just jump to the vCenter installer and expect it to work.
5. Click on vCenter Single Sign On, then click on Install. Select the appropriate language and wait for the wizard to open. After clicking through the licensing agreements and carefully reading all of the patents, you are presented with the following screen with several options:
6. One of the cool features about the SSO service is that you can have multiple instances, fronted by a hardware load balancer for HA. Since SSO is required for functional vCenter and other VMware services, having a highly available SSO service is important in production environments. Given the greenfield installation in my lab I left the default option selected since I have no existing SSO instances. On the next screen (shown below) you have two more options. To leave the door open to a future HA configuration I chose the second option.
The password must have at least eight characters, at least one lowercase character, one uppercase character, one number, and one special character. Maximum password length is unknown, but a reader said 32 characters did not work but 16 did.
Note: Do NOT use the ^ ; * $ ; " symbols in the password, as it may cause a "Error 29133.Administrator login error." further on in the installation process. VMware has a KB article regarding these special characters here.
8. At this point you are presented with a dialog asking what kind of database you want to use. Unfortunately, if you want to use a full blown SQL server the DB creation process is a bit manual. Since I want to use my SQL Server 2008 R2 enterprise instance in my lab, I selected the second choice.
I created a custom database creation script, based on the canned VMware script mentioned in the wizard above. In my case I called the database "D001_VMware_SSO". Run this script in SQL studio, modified to your liking. Note that you CAN NOT change "RSA_DATA" or "RSA_INDEX" as the SSO service is hard coded to use them and the install WILL fail if they are not present.
----
USE MASTER
GO
CREATE DATABASE D001_VMware_SSO ON PRIMARY(
NAME='RSA_DATA',
FILENAME='K:\Microsoft SQL Server\MSSQL\Data\D001_VMware_SSO_Data.mdf',
SIZE=10MB,
MAXSIZE=UNLIMITED,
FILEGROWTH=10%),
FILEGROUP RSA_INDEX(
NAME='RSA_INDEX',
FILENAME='K:\Microsoft SQL Server\MSSQL\Data\D001_VMware_SSO_Index.mdf',
SIZE=10MB,
MAXSIZE=UNLIMITED,
FILEGROWTH=10%)
LOG ON(
NAME='translog',
FILENAME='L:\Microsoft SQL Server\MSSQL\Data\Logs\D001_VMware_SSO_Log.ldf',
SIZE=10MB,
MAXSIZE=UNLIMITED,
FILEGROWTH=10% )
GO
EXEC SP_DBOPTION 'D001_VMware_SSO', 'autoshrink', true
GO
EXEC SP_DBOPTION 'D001_VMware_SSO', 'trunc. log on chkpt.', true
GO
CHECKPOINT
GO
-----
Create a new user using SQL Server authentication, such as SSO_User, and modify the password options as needed. I would suggest not expiring the password, and certainly can't select the option to change at next login. The password must be 32 characters or less, and cannot contain semicolon (;), double quotation mark ("), single quotation mark ('), circumflex (^), and backslash (\).
11. Repeat the process but create a second user, say SSO_DBA.
12. In SQL Studio on your SSO database you now need to add your two newly created users so they have proper permissions in the database. For the SSO_DBA user I granted it db_owner permissions for both the schemas and database. For the SSO_User I only granted db_owner for the database.
13. Now that the database is properly configured, switch back to the vCenter server and enter the database information you used. If you do NOT want to use SQL SSL encryption you can click next and proceed to step 15.
Second, you can configure a Java keystore with the public key of your SQL SSL certificate CA so the JDBC driver can validate the certificate. This is more secure and the preferred option.
To configure blindly trusted SQL SSL follow these steps:
On the vCenter Single Sign On screen above, click on Next, then click on Back. You should now see the JDBC URL populated but greyed out. Check the box next to "I will enter the JDBC URL myself". At the end of the connection string add the following two options:
;encrypt=true;trustservercertificate=true
For example, my JDBC URL is (single line):
jdbc:sqlserver://;serverName=D001SQL01.contoso.net;port=1433;
databaseName=D001_VMware_SSO;encrypt=true;trustservercertificate=true
A. First you need to export the public root CA certificate to a DER encoded file so the Java keytool can import it. In my case I use an internal MS CA.You can do this a variety of ways, but I like using the MMC tool to do this. The process assumes your vCenter server has the root CA certificate in its certificate store.
B. Open a blank MMC, add the Certificates snap-in, and manage the Computer account.
C. Open the Trusted Root Certification Authority then browse through the certificates to find the one matching the Certificate Authority that was used to issue the certificate to your SQL server. Once you find the certificate, right click an Export it. Click through the wizard until you get to the screen below.
D. Make sure DER encoded is selected and export the certificate. I called it root.cer and put it at the root of my C:\ drive for easy access. Note: If you went crazy with your CA and configured it for SHA256 and elliptical curve encryption algorithms then the Java keytool won't import the certificate.
E. Open an elevated command prompt then change directory to where the SSO installer files extracted themselves and find the jre\bin directory. In my case this was:
C:\Users\SVC-VCTR02-001\AppData\Local\Temp\{DEC4C346-414B-4814-9BF3-CAC14154B55A}\jre\bin
F. Create a Java keystore by issuing the following command (using the path of your SSO service account). Enter a keystore password (write it down). When prompted to trust the certificate type Yes.
keytool -import -alias root -file c:\root.cer -keystore c:\users\SVC-VCTR02-001\jks.keystore
G. With the keystore now created, it is time to update the JDBC connection string back in the SSO installer. Add the 'truststore' and 'truststorepassword' connection options with the appropriate path and password. If everything validates you should see the screenshot in step 15.
jdbc:sqlserver://;serverName=D001SQL01.contoso.net;port=1433; databaseName=D001_VMware_SSO;integratedSecurity=true; encrypt=true;truststore=C:\Users\SVC-VCTR02-001\jks.keystore;truststorepassword=testpassword
15. Here, if you were using a hardware load balancer, you would enter the FQDN of the VIP. Since I'm just installing one SSO instance, I'll stick with the FQDN of the vCenter server.
16. At this point I input the vCenter service account details. Note that if you input the wrong password you will get an error "Could not find the specified user on provided domain." which is not entirely correct. The user exists but you just fat fingered the password.
17. On the next screen I left the HTTPS port the default, then sent the installer off on its merry way.
18. After the SSO service installs, it generates a number of unique passwords. For safe keeping, I would store these passwords in a secure location. Although you may never need most of them, several passwords are lost forever when you install your own SSL certificate. Should you need to access the default keystores, you are out of luck.
Open an elevated prompt and type:
"c:\Program Files\VMware\Infrastructure\SSOServer\utils\rsautil" manage-secrets -a list
At this point the vCenter Single Sign On service should have successfully installed and you screen captured/wrote down the SSO passwords. If you have more SSO installation problems than I've covered here, check out their release notes for a laundry list of gotchas for the SSO installer. You can check out Part 2 here.?
18. After the SSO service installs, it generates a number of unique passwords. For safe keeping, I would store these passwords in a secure location. Although you may never need most of them, several passwords are lost forever when you install your own SSL certificate. Should you need to access the default keystores, you are out of luck.
Open an elevated prompt and type:
"c:\Program Files\VMware\Infrastructure\SSOServer\utils\rsautil" manage-secrets -a list
At this point the vCenter Single Sign On service should have successfully installed and you screen captured/wrote down the SSO passwords. If you have more SSO installation problems than I've covered here, check out their release notes for a laundry list of gotchas for the SSO installer. You can check out Part 2 here.?
