Many of you have now kicked the tires with vSphere 5.5 either in your home lab or on some servers at work and you’re anxious to get all the new goodies running in your production environment. Perhaps some of you early adopters are already running in full production, but we’re guessing many of you are just contemplating your major upgrade now.
VMware’s Tech Support staff tend to see a surge during the month of March in number of calls to support. But guess what? Many of the issues we’re anticipating are already resolved, and we’ve been busy compiling and documenting solutions to common problems that you can handle yourself.
Those of you installing or upgrading your vSphere hosts, and vCenter Server instances to version 5.5 will find the following KB articles and Support Insider posts of great interest.
While VMware highly recommends the deployment of all vCenter Server components into a single virtual machine (excluding the vCenter Server database), large enterprise customers running multiple vCenter Server instances within a single physical location can simplify the vCenter Single Sign-On architecture and management by reducing the footprint and required resources and specify a dedicated vCenter Single Sign-On environment for all local resources in each physical location.
For vSphere 5.5 the VMware recommendation is to centralize vCenter Single Sign-On when you have 8 or more vCenter Server instances in a given location (this is a soft recommendation).
Centralized vCenter Single Sign-On Architecture
Figure 1: A Centralized vCenter Single Sign-On Server environment
There can be increased risk when centralizing a vCenter Single Sign-On server (to why it is not recommended for smaller environments) due to the increased number of components affected if the vCenter Single-Sign-On server was to become unavailable, in short all vCenter Server components of all vCenter Servers registered will incur authentication loss (when compared to just the single vCenter Server instance when installed locally) and so availability of the vCenter Single Sign-On centralized server(s) is highly recommended. Continue reading →
One question that we often get from customers is how to load balance SSO. While we do have documentation and support for setting up Apache to load balance SSO many customers already own a load balancer or do not wish to use Apache. Continue reading →
A minor update to the vCenter Server 5.5 has been released
VMware vCenter Server™ 5.5.0a | 31 OCT 2013 | Build 1378901
vCenter Server Appliance 5.5.0a | 31 OCT 2013 | Build 1398493
Issues resolved with this release are as follows
Attempts to upgrade vCenter Single Sign-On (SSO) 5.1 Update 1 to version 5.5 might fail with error code 1603
Attempts to log in to the vCenter Server might be unsuccessful after you upgrade from vCenter Server 5.1 to 5.5
Unable to change the vCenter SSO administrator password on Windows in the vSphere Web Client after you upgrade to vCenter Server 5.5 or VCSA 5.5
VPXD service might fail due to MS SQL database deadlock for the issues with VPXD queries that run on VPX_EVENT and VPX_EVENT_ARG tables
Attempts to search the inventory in vCenter Server using vSphere Web Client with proper permissions might fail to return any results
vCenter Server 5.5 might fail to start after a vCenter Single Sign-On Server reboot
Unable to log in to vCenter Server Appliance 5.5 using domain credentials in vSphere Web Client with proper permission when the authenticated user is associated with a group name containing parentheses
Active Directory group users unable to log in to the vCenter Inventory Service 5.5 with vCenter Single Sign-On
Attempts to log in to vCenter Single Sign-On and vCenter Server might fail when there are multiple users with the same common name in the OpenLDAP directory service
Attempts to log in to vCenter Single Sign-On and vCenter Server might fail for OpenLDAP 2.4 directory service users who have attributes with multiple values attached to their account
Attempts to Log in to vCenter Server might fail for an OpenLDAP user whose account is not configured with a universally unique identifier (UUID)
Unable to add an Open LDAP provider as an identity source if the Base DN does not contain an “dc=” attribute
Active Directory authentication fails when vCenter Single Sign-On 5.5 runs on Windows Server 2012 and the AD Domain Controller is also on Windows Server 2012
The realese notes can be found here with full details, download now from www.vmware.com
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.
I was a little surprised how quickly these went live but can now share the VMworld vCenter Deep Dive and vSphere Upgrade series: Part 1 – vCenter Server breakout sessions from last weeks VMworld in Barcelona where my sessions were recorded and are now available for your viewing pleasure.
vCenter Server Appliance 5.5.0a | 31 OCT 2013 | Build 1398493
Last week, along with the rest of you, I learned about an authentication issue with vSphere Single Sign-On version 5.5 when running both the Active Directory (AD) domain control and the vCenter Single Sign-On Server on Windows Server 2012 (http://kb.vmware.com/kb/2060901).
In a nutshell, when your AD domain controller and your vCenter Single Sign-On are both running on Windows Server 2012, the single sign-on is unable to authenticate AD users. You get a “Cannot parse group information” error:
I was testing vSphere 5.5 upgrades in my lab and came across an interesting situation that you need to be aware of. In a nutshell, pay attention to how your Active Directory groups are configured on your vCenter Server and avoid nesting any domain level user or group accounts inside of local groups.
Here’s the situation I ran into. My lab was running a vanilla vCenter 5.1 install. In vCenter I only had one permission assigned, which is for the local “Administrators” group.
This release of VMware vCenter Server 5.1 Update 1 offers the following improvements:
vCenter Server is now supported on Windows Server 2012
Additional vCenter Server Database Support: vCenter Server now supports the following databases.
Microsoft SQL Server 2012
Microsoft SQL Server 2008 R2 SP2
Additional Guest Operating System Customization Support -vCenter Server now supports customization of the following guest operating systems:
Windows Server 2012
vCenter Essentials no longer enforces vRAM usage limit of 192 GB With vSphere 5.1 Update 1, the Essentials and Essentials Plus licenses no longer restrict virtual machine power-on operations when the vRAM usage limit of 192 GB is met.
Resolved Issues – This release delivers a number of bug fixes that have been documented in the Resolved Issues section.