Upgrade to vCenter 5.5 with Heartbeat

[JimKnopf99]

Hello all,

i am just reading some paper about upgrading to the new vCenter Version 5.5 with vcenter Heartbeat.

In the new heartbeat Installation and upgrade paper on page 53 i read this.

"Before attempting to upgrade from vCenter Server 5.0 or vCenter Server 5.1 to vCenter Server 5.5 you must

install the VMware vSphere Single Sign-On (SSO) 5.5 component separately on a different machine (not on

the Primary or Secondary node) and then protect SSO on the separate machine with vCenter Server Heartbeat"

I could not belive it! Is that true that i need a seperate machine for my sso Installation? For what? We seperate the Installation in one Hardware and one VM Machine. I could not buy a new machine only for my SSO Installation.

Is it true or could i install all of the vCenter components on one machine?

Thanks

Frank

[dmihaescu]

Thanks Mike, but I am one of the engineers working on the HB product. SSOupgradeUtil does more than setting up Log4j.

[mabrown76]

Good to know, thanks Daniel.

[bendter]

Thank you for the replies.  So the upgrade from 5.0 to 5.5 with vCSHB would be to uninstall vCSHB, upgrade 5.0 to 5.5 and then do a fresh install/clone with the vCSHB software.  That way all of the 5.5 components could be run from the same server.

[mabrown76]

You don't need to go through an uninstall. Upgrade to Heartbeat 6.6, on your secondary node make it active, rename the computer account to the shared name, install SSO & the web client & then upgrade the rest of the components, rename the computer back to its original name then do the same on the primary server after you have validated the secondary is working as it should. Remember to do DB backups & snapshot the VMs in case you have any issues.

Mike

[mabrown76]

An easier way then I posted above is to follow the steps in this KB, VMware KB: Upgrading Single Sign-On 5.1 to 5.5 when vCenter Server Heartbeat is installed they also pertain to vCenter 5.0 even though it's not specifically called out, this will ensure SSO 5.5 is installed with the public name without having to rename the servers like I suggested above.

[bendter]

Mike,

I'm finally starting to work on the v5.5 upgrade.  I attempted to use the information you provided in your article "Upgrading vCenter when using vCenter Heartbeat, Part 2".  and the information posted above.  The issue I'm running into is when SSO is installed, even though it shows the public IP address it still picks up the Heartbeat server's FQDN instead of the Public FQDN.  After installing 5.5 everything works fine until you try a failover.  And then you see that vCenter tries to access SSO via the FQDN of the Primary Heartbeat server and since SSO is now running on the Secondary server vCenter cannot start.  During the installation any place that required the SSO login I had to use the Public IP address instead of the the Public FQDN because if I specified the Public FQDN the installation would fail to contact the SSO.

I am going to try the upgrade again this time changing the domain name of the servers to the public name before installation as you stated above.  This is a little bit of a challenge because we do not have AD permissions to change the Domain name of a server and we will need to remove and then re-add the servers to the domain.

I'll reply back with the results.

[bendter]

After several tests I have concluded you cannot upgrade from vSphere 5.0 to vSphere 5.5 with Heartbeat v6.6 installed.  Following the instructions carefully resulted in not even being able to get past upgrading vSphere Web client on the secondary Heartbeat server.  Issuing the command "SSOupgradeUtil.exe pre" allows SSO to appear to install correctly but as soon as I attempt to install vSphere Web client the upgrade cannot access SSO either by FQDN or IP address.

The closest I got was putting the putting the secondary server on the Domain with the Public name, upgrading it, putting it back on the domain with the secondary name, putting the primary server on the domain with the public name, upgrading it, putting it back on the domain with the primary name.  All of the other steps were followed as outlined in the KB article.  This resulted in vSphere running fine on the Primary server but not being able to fail over to the secondary node.  First, because when Heartbeat discovered the SSO services it configured them to start after vCenter and vCenter will not start until SSO is running.  Moving the SSO services ahead of the vCenter service allows everything to start properly on the Primary node, but when failing over to the secondary node vCenter cannot start due to this error as recorded in vpxd.log:

Unable to create SSO facade: Invalid response code: 404 Not Found.

My only solution at this point is to uninstall vCenter Heartbeat, upgrade vSphere and re-install vCenter Heartbeat.

Has anyone actually performed the steps from KB article 2059820 and upgraded vSphere from 5.0 to 5.5?  Our configuration is everything runs on a single server, SQL,  vCenter, and SSO (no SSO in 5.0).

Bill