Locked Out of vCenter 5.1

Recently, I was called in to help a client out with a vCenter 5.1 install and came across the somewhat common issue of being locked out of vCenter (which is most common after the upgrade process). After some investigation, it appeared the proper Identity Sources were configured and SSO, in general, looked okay. After scratching our heads a bit, I decided to take a look inside the vCenter DB and verify account/group access. Since this was a clean installation, and not an upgrade, the only account in the vCenter DB was the one specified during the installation wizard. This was a SQL DB, so the table where this access can be found is in the “VMW.VPX_ACCESS” table, within the vCenter DB.

Note: If you are going to attempt this procedure, make sure you have a good/valid backup of the entire DB that you can restore.

To verify/modify access:

1. Stop all vCenter Services
2. Use SQL Management Studio to connect to the DB
3. Expand the vCenter DB (in my case, the name is ‘VCDB’)
4. Expand the Tables and right click on the “VMW.VPX_ACCESS” table; select “Edit Top 200 Rows”.
5. You should see a single row (if this is a new install) with the group/account details that you setup as part of the install wizard, in the “PRINCIPAL” column.

VPX_ACCESS_1

6. Make any necessary changes to the account details and close the table
7. Restart vCenter services and see if access has been restored

In this particular scenario, it was found that the client entered the incorrect details during the install wizard, which is why no one was able to access vCenter.

Datastore Heartbeat Setup Inconsistencies – 5.1

After an initial configuration that I was doing on a new cluster setup I noticed some inconsistencies in the options and wording between the web client and the vSphere client [fat client] in 5.1. Now, I have noticed little differences, here and there, between the two, in other areas, but those differences were small enough to automatically pickup what options mapped to one another between the web and fat client. However, when I was configuring datastore heartbeating, I noticed that the wording is much different in comparison; I had to read over it a few times and do a little testing to map the settings out 100%.

Consider the following Visio depiction of my test environment:


vSphereDemo01

What I found was that despite HA being configured and managed at the cluster level, when configuring datastore heartbeating on Cluster-B using the web client, it reported the total number of hosts in the datacenter that had the same datastores mounted; ie it reported 4 hosts since the hosts in Cluster-A also have datastores DS02 & DS03 mounted. In contrast, the fat client reported the ‘proper’ number of hosts in the cluster, which is 2.

I can’t speak to what the negative implications are, if any, but it’s something I felt was worth noting when configuring from the web client.

In regards to the wording being different, see the screen snip below that shows the two settings panes and the wording differences between the two sets of options. This screen snip also shows the differences in the number of hosts mounting the datastores.

DSHeartBeatSnip