Part of my role at VMware is to work closely with our customers and partners, sharing experiences and feedback with internal VMware Product Management and Engineers to help make our products better. One area that has been dominantly more focused than others over the last 12 months has obviously been vCenter Single Sign-On.
Due to this feedback, one of the drivers for the new vCenter Single Sign-On was to provide backwards compatibility and to highlight this, a recent Knowledge Base article released.
Although this sounds interesting and a change to the way VMware typically recommends its upgrade process, I want to highlight what the use cases are for actually running a mixed version of vCenter Server components in the environment. Yes VMware does support the use of running a vCenter Server 5.1 and its Inventory Service against an updated vCenter Single Sign-On 5.5 and vSphere Web Client 5.5 and this was done to ease the following two limitations found with vSphere 5.1 and vCenter Single Sign-On.
vSphere 5.1 users were affected with limited Active Directory integration via the use of Active Directory LDAP connectivity. Environments where vCenter Single SIgn-On was used to connect users and groups from multiple Active Directory domains via the use of one and two way trusts and/or across Active Directory forests became very challenging. Customers had to get creative with this challenged connectivity either via defining multiple identity sources within vCenter Single Sign-On or by the editing of vCenter Server permissions to reflect vCenter Single Sign-On groups populated with fully qualified domain naming of users and groups from multiple Active Directory domains. In some rare cases authentication was just not possible.
Another area lacking from support was the upgrading of vCenter components when using multiple vCenter Servers with a centralized vCenter Single Sign-On architecture. For full compliance all vCenter Servers would be required to be upgraded to maintain the same version across the environment. This obviously would lead to lengthy maintenance windows to achieve the upgrade or the risk of running unsupported when vCenter Server didn’t match the vCenter Single Sign-On version.
Obviously in an ideal world, VMware fully recommends the updating of all vCenter Server components to maintaining the same version throughout the vCenter Server stack as this will ease management and future upgrade procedures. If you are a customer affected by the use of multiple Active Directory domains or centralized vCenter Single Sign-On architecture, please review the following.
Customers running vSphere 5.1
If you are on vSphere 5.1 and have experienced either of the above two items above and unable to upgrade the entire solution to vSphere 5.5, upgrading just the vCenter Single SIgn-On and vSphere Web Client only to version 5.5 is the next best offering to eliminate these issues, and fully supported by VMware.
Customers running vSphere 4.0 / 4.1 / 5.0
If you are running a previous to vCenter Server Single Sign-On environment (vSphere 4.0, 4.1 or vSphere 5.0) and looking to upgrade to a newer version with vCenter Single Sign-On, I would review the permissions within vCenter Server and identify if your environment is utilizing multiple domains with vCenter Server permissions. If you are using multiple domains with your permissions I would first recommend moving straight to vSphere 5.5 which resolves this and is supported with direct in-place upgrading from vSphere 4.0 and higher running on a x64 Operating System.
If you are unable to go to vSphere 5.5 due to lack of compatibility with other VMware or third party solutions and also use vCenter Server permissions with users across multiple active directory domains, I would recommend moving to vSphere 5.1 Update 1 with the vCenter Single Sign-On and vSphere Web client deployed on version 5.5 and ahead of the upgrade process.
If you are planning an upgrade of you vCenter Server environment to a centralized vCenter Single Sign-On architecture (VMware recommendation for 8 or more vCenter Servers per single location), I would recommend using a centralized vCenter Single Sign-On 5.5 with vSphere Web Client 5.5 which can service authentication requests from both vCenter Server 5.1 and vCenter Server 5.5 simultaneously.
If you do proceed and move to a vCenter Server environment that uses mixed versions of vCenter SErver components, you will also need to be aware that additional tools like the SSL Automation tool, the C# desktop client and products like vSphere Update manager are version specific to vCenter Server and multiple version of the same tools maybe required.
NOTE: The vSphere Web Client 5.5 is required to administer the vCenter Single Sign-On 5.5 services.
