vSphere 6.0 Install Pt. 2: Platform Services Controller


In this second installment of the vSphere 6.0 installation series we cover the new service called the Platform Services Controller. This new service has consumed the SSO service, and added a number of new features. vCenter functionality is now divided into two primary roles, the management node and the PSC. The remainder of this article will cover this split, what the PSC is, and what it means to your vCenter topology.

Blog Series

vSphere 6.0 Install Pt. 1: Introduction
vSphere 6.0 Install Pt. 2: Platform Services Controller
vSphere 6.0 Install Pt. 3: Certificate Management
vSphere 6.0 Install Pt. 4: vCenter Upgrade Best Practices
vSphere 6.0 Install Pt. 5: ESXi Upgrade Best Practices
vSphere 6.0 Install Pt. 6: Install Windows PSC
vSphere 6.0 Install Pt. 7: Config SQL DBs
vSphere 6.0 Install Pt. 8: Toolkit Configuration
vSphere 6.0 Install Pt. 9: SSL Templates
vSphere 6.0 Install Pt. 10: Install VCSA PSC
vSphere 6.0 Install Pt. 11: VMCA as Subordinate
vSphere 6.0 Install Pt. 12: PSC Machine Certificate
vSphere 6.0 Install Pt. 13: Directory Services Certificate
vSphere 6.0 Install Pt. 14: Windows vCenter Install

Permalink to this series: vexpert.me/Derek60
Permalink to my Toolkit script: vexpert.me/toolkit60

Prior to vSphere 6.0 most people thought of vCenter as a single component. Some larger complex deployments may have had multiple SSO servers, but you still think of SSO as fundamental to vCenter. Starting in vSphere 6.0 vCenter is being decoupled into two distinct parts. The first is known as the Platform Services Controller (PSC), and the remainder are all the vCenter services. You can see this in the VMware graphic below, showing the management node (vCenter services) and the PSC. Other VMware products like the vRealize suite can utilize the PSC services, such as authentication.


When you install vCenter now, it no longer prompts you for various components. It installs the full suite every time…whether you want everything or not. This full suite includes the following components:

  • vCenter Server
  • vSphere Web Client
  • Inventory Service
  • Profile-driven storage
  • Auto Deploy
  • Syslog Collector
  • ESXi Dump Collector
  • and more…

Separately installable IS vSphere Update Manager. You can combine the VCSA (vCenter appliance) and a Windows VUM server, so it makes sense they give you the option to separately install VUM. The only other separately installable component is the vSphere authentication proxy. Keep in mind you still need the Windows thick C# client to manage all the VUM features. VMware is working on a VUM replacement, but it’s TBD when that will be released. Personally I wouldn’t look for that anytime soon.

Platform Services Controller (PSC)

As we all remember with vSphere 5.1, VMware introduced a major new component called SSO, or single sign on. In the 5.1 days this caused a lot of headaches and pain, particularly around SSL certificates. The situation was improved in vSphere 5.5 with SSO 2.0, and VMware provided more guidance to customers for SSO topologies. Fast forward to vSphere 6.0, and now there’s a whole new component called Platform Services Controller (PSC). PSC is a shared service that supports vCenter server and vCenter server components. Various VMware products can use the PSC such as vCenter and vRealize Operations. Think of PSC as a foundational service which provides the following services:

  • License service (formerly held by vCenter)
  • Single Sign-on Service (Secure Token Service, identity management service, directory service)
  • Lookup Service
  • VMware Certificate Authority (VMCA)
  • VMware Endpoint Certificate Store (VECS)
  • Authentication framework daemon
  • Component Manager Service (CM)
  • HTTP reverse proxy

The big news here is the brand new VMware certificate authority (VMCA) and VMware Endpoint Certificate store (VECS). This will have a major impact on how you deploy and manage certificates in a vCenter environment. More to come on that in my next post.

Also keep in mind that you can mix and match PSC embedded installs along with external instances. All will share the same SSO domain, and will replicate other information like licensing. This lets you start out small, say with an embedded install, and expand in the future with a replicated external instance. Or perhaps you add a second datacenter down the road, with a local vCenter instance. There’s a limit of 8 PSCs per site.

Do keep in mind that if you start out with an embedded install (vCenter + PSC), there’s no supported method to “move” the PSC to a dedicated server or add more PSCs. So my advice is to start out by dedicating a VM to the PSC, and anther VM to all the other vCenter services. This provides maximum scalability, and future proofs your infrastructure for the foreseeable future.

High availability (HA) for the PSC service is via an external load balancer, such as a Citrix Netscaler or F5. Unfortunately built-in HA didn’t make it into this release, so we must rely on a third party solution. In the VMware graphic below you can see three vCenter instances, all pointing to a redundant and load balanced PSC deployment.



vCenter single sign-on allows vSphere components to communicate with each other using secure tokens rather than authenticating separately to each component. The SSO service is comprised of the security token service, administration server, VMware directory service (vmdir) and identity management service. The STS service uses SAML tokens for authentication. The administration server allows administrators with the proper privileges to manage the SSO service. VMdir is a multi-master, multi-tenant directory service that uses LDAP, much like Active Directory. However it does not use AD nor ADAM/ADLS. It uses port 389 and 11711. If there is more than one instance of PSC in your environment then one update in vmdir will be replicated to all other instances. Vmdir also stores some certificate information. The identity management service processes identity sources and STS authentication requests.

Starting with vSphere 6.0 SSO is either deployed via the embedded PSC (co-resident with your vCenter server) or as part of an external PSC deployment. Of great importance is the order of installation. If you are using an external PSC, then it must be installed prior to vCenter server. This make sense, as vCenter depends on a number of the services in the PSC. If you choose the embedded install then everything is installed in the right order.

A single external PSC deployment can support up to eight vCenter instances. Each new vCenter instance connects to the same PSC server. If you are a monster enterprise environment and have more than 8 vCenters then you can deploy multiple PSC instances.

When you deploy the SSO component you will need to configure a password for the ad***********@vs*****.local account. This password needs to be at least 8 characters, one lower case character, one numeric character and one special character. And the length must NOT exceed 20 characters. Only use visible ASCII characters, meaning you can’t use a space. You are also not allowed to use the single quote (‘) either. Other special characters may cause problems (remembering the SSO 5.1 and 5.5 days) so be sure to test out your “complex” passwords.

By default users are locked out of the SSO service after five consecutive failed attempts in three minutes. Accounts are unlocked after five minutes. These policies can be changed, if desired. See the vSphere Security Guide for additional details.

Below is a graphic from VMware showing the progression of SSO to the PSC, from vSphere 5.1 to 6.0.



As you can see, the Platform Services controller is new to vSphere 6.0 and incorporates a number of new services. Medium to large deployments can get complex, with a mix of multiple vCenter servers and highly available PSCs. Carefully evaluate your business requirements for scalability and high availability, then chose a the simplest deployment model that best meets those requirements.

Print Friendly, PDF & Email

Related Posts

Notify of
Newest Most Voted
Inline Feedbacks
View all comments
Zsolt Pamuki
February 11, 2015 1:53 am

After struggling a bit with SSO on 5.5, this PSC looks interesting.

February 19, 2015 8:28 am

ok i might be jumping the gun, but if you separate out the PSC, how would you load balance the web client for availability? in our (5.5) environment we have a pair of servers running SSO and vsphere webclient, both of these services are load balanced and support multiple vcenters.
i see a mention of an 'http reverse proxy' as a component of PSC – does this have something to with it?

March 24, 2015 3:06 am

Hi Derek,
In the PSC diagram above, it shows replication between PSCs on the same site (as indicated by “Same Site” at the left hand side of the diagram). Can you clarify what is meant by “site” in this instance? Is it “datacentre” or are you referring to, or is it the “Site Name” that you configure when creating a new Single Sign-On domain?