VMware will introduce a new component in version 6 named the VMware Platform Services Controller (PSC).

Single Sign On (SSO) was the first component to be converted into the PSC. SSO was released in vSphere 5.1 and contained some major issues. This forced a rebuild to SSO 2.0 for version 5.5. In the new release, vCenter, vRealize, vRealize Automation along with vCloud Director, can now use the shared PSC component.

PSC will contain the following functionalities as of now:

PSC uses the vPostgres database that is integrated into vCenter and the database is the same in both Windows and Appliance versions. PSC also self-replicates; it doesn't use ADAM, which means it is now possible to replicate the Windows vCenter and vCenter appliance between each other.

You can embed PSC within vCenter or use an external database instead of the vPostgres database. The guidance from VMware, if you are running less than eight vCenters, is that it is best to use the embedded PSC, so that vCenter will only connect to the internal PSC.

If you are going to have more than eight vCenters, VMware recommends you use an external PSC, rather than using the embedded one. This way, you can setup PSC in a highly available and load-balanced service sharing between all of your vCenters.

The Certificate Store and the Certificate Authority (CA) are new components that will help you with vSphere certificates management. The VMware Certificate Authority (VMCA), which is also new, performs as the root certificate authority and manages its own certificates, or it can handle certificates from an external certificate authority (CA). VMCA allows the provisioning for each ESXi host requiring the signed certificate. This will be added to the vCenter inventory as part of the upgrade. This provides the viewing and managing of the vSphere Web Client certificates, which allows the management of the entire workflow of the certificate lifecycle with the new VMCA.

The management limits of vCenter Server Appliance (VCSA) have also been expanded. With version 5.5, you could manage up to 100 hosts and up to 3,000 powered on Virtual Machines (VMs). Now, version 6 of vSphere allows you to manage 1,000 hosts and an increase of 10,000 powered on VMs. IBM DB2 continues to be the embedded database, and Oracle remains as the only supported external database. This is because Microsoft will not officially support the ODBC driver for Linux; the driver that is currently used is community supported.

The web client continues increased performance gains, along with tagging improvements and many other new functions. Flash is still used, which means there is not a native HTML5 web client for now.

VMware is keeping the VI Client (C#) for at least the next few releases. Progress continues with the web client and there are continuous improvements to the speed. So far, most customer feedback has been a preference for the older, yet familiar, clients. At this point in time, there will be no new functionality added to the old client, but the support will remain. Therefore, the old client will manage less functions than the new VCSA.

Now that we have completed the overview of the new and updated components, let's begin the steps needed to upgrade vCenter.

Remember to always check the What's New in VMware vSphere 6.0 document found on the VMware website to find the most current information about the product. The What's New in VMware vSphere 6.0 can be found at http://www.vmware.com/files/pdf/vsphere/VMware-vSphere-Whats-New.pdf.

The new vCenter installer for the Windows version has been streamlined. Now, there is a return to a single installer, with all input collected up front. There is also an improved pre-check function with more items checked. You also have a choice between the external (pre-existing) or the internal (embedded) option of PSCs during the installation process.

The procedure for upgrading has not changed since the last version of vCenter. The following are the vCenter upgrades that you can perform from a standalone installer or Update Manager:

Use this process if you are migrating from a pre-5.5 version. SSO in vCenter 5.5 does not use a database.

If you are not sure of the current password for the RSA_USER/RSA_DBA, you will need to go to the SSOServer\utils folder. Open an administrative command prompt and type the following:

ssocli manage-secrets -a listallkeys

Make sure both vCenter Single Sign-On services are stopped. After verifying that the services are stopped, you can:

Two SQL Server users are created when installing SSO:

The RSA_DBA is the account used during an installation and is not needed for the migration. During the migration process, the RSA_USER will be used. The login/user is added to the target SQL Server and the password along with the required permissions are set.

Open an administrative elevated command prompt and move to the default directory of the SSO server directory\utils. Type in the following:

ssocli configure-riat -a configure-db –database-host newdbhost –database-port newdatabaseport –rsa-user RSA_USER –rsa-user-password password -m master_password

In the preceding code, replace the following:

The rsa-user password will only work with the rsa-user option.

Prepare to edit two files jndi.properties and config.properties using your preferred text editor (for example, Notepad.exe) and using elevated permissions.

For the first file, SSOServer\webapps\ims\web-inf\classes\jndi.properties, check the following values:

com.rsa.db.type=MSSQL.
com.rsa.db.instance=RSA. (your RSA instance dbname is)
com.rsa.db.msserverinstance= . (Leave empty when using the default MSSQLSERVER instance on the target server)
com.rsa.db.hostname=destinationSQL server.
com.rsa.db.port=1433.

Pay special attention to com.rsa.instanceName and remember that this does not refer to the SQL Instance. This refers to the SSO instance and you should not change this.

For the second file, SSOServer\webapps\lookupservice\WEB-INF\classes\config.properties, check the following values:

db.url=jdbc:jtds:sqlserver://;serverName=;portNumber=1433;databaseName=RSA. PortNumber has to be added here.
db.user=RSA_USER
db.pass=yourpassword
db.type=mssql
db.host=destination SQL server fqdn.

Make the changes to the lines in order to match your environment. Now, save the files and start the service for your vCenter Single Sign-On.

Stop the vCenter services if they are not already stopped. Include all the services for vCenter, excluding Update Manager, SSO, and Orchestrator. After all the services are stopped:

Then, create the login/user to the target SQL Server, and set the required password and permissions. The user for the vCenter database must be db_owner and also dbo on the Microsoft DB system database can be found on the target server.

Now, use the ODBC Manager (64-bit) to change the System DSN being used by your destination SQL Server.

After the changes are complete, check the connection to verify whether it works.

The next step is to modify the ODBC connection found in the registry:

Navigate to Start | Run, type regedit, and then click on OK. This will start the Registry Editor and the window will open. Move to HKEY_LOCAL_MACHINE | SOFTWARE | VMware, Inc. | VMware VirtualCenter and make a change to the key DbInstanceName by removing its current Value data. Do not delete this key. See the following screenshot:

Then change the key DbServerType. Edit the Value data from SQL Express value Bundled to Custom, as displayed in the following screenshot:

Now, navigate to HKEY_LOCAL_MACHINE | SOFTWARE | VMware, Inc. | VMware VirtualCenter | DB and change key 4. Do this by entering the new ODBC driver, changing the ODBC in place of the original. If this did not change, verify the value and leave it alone. You will add the user for vCenter Server SQL to key 2. You need to set the password that is kept in key 3. This is completed by opening an Administrator command prompt and typing C:\Program Files\VMware\Infrastructure\VirtualCenter Server\vpxd.exe -p.

Now, on the SQL Server, you need to recreate the SQL jobs. This is completed by using the SQL Server Management Studio and going to SQL Server Agent.

Use the following list to create the job list:

To add the jobs, browse to C:\Program Files\VMware\Infrastructure\VirtualCenter Server\sql and open the equivalent SQL file using Open | file and choose the vCenter database. Next, execute each Query and continue through each one. When you find the existing jobs, make sure to check that each matching SQL user in jobs is the right one. Choose a job and right–click on it; then go to properties to make sure the user and database name is right. If they are incorrect, recreate them.

Review the vcdb.properties file by going to C:\ProgramData\VMware\VMware VirtualCenter (for Windows 2008R2 and higher). Make sure to use Explorer to uncheck hidden and protected files. Then, edit the vcdb.properties file value url= ;integratedSecurity\ to:

The following screenshot shows the edited vcdb.properties file value url= ;integratedSecurity\ is set to true:

The remaining should match sqlserver://<your SQL server>\\SQL instance;databaseName=\dbname; dbtype=mssql.

Check to be sure the Windows user has the permissions to the SQL database. The user also needs to run VMware VirtualCenter Management Webservices and VMware VirtualCenter. Run regedit again and move to HKLM\System\CurrentControlSet\Services\ to remove the old service values from SQL Express from the DependOnService Multi string found in the vCenter services. Do not delete the value, just remove the VIM_SQLEXP from the data. The other dependencies should not be changed. Start the service for vCenter and use the logs to verify everything has started up.