Home > Blogs > VMware vSphere Blog


Upgrading vCenter when using vCenter Heartbeat, Part 2

In Part 1 I covered how to upgrade vCenter Heartbeat to version 6.6 which is required for vCenter  5.5.

Once the Primary and Secondary nodes are upgraded to vCenter Heartbeat 6.6 we can begin upgrading to vCenter 5.5 and any optional components (such as VUM or AutoDeploy) that may be installed also.

The first decision before we move on is if Single Sign-on (SSO) will be installed locally to the vCenter (recommended for most customers) or if SSO will be deployed in a centralized fashion (recommended for customers with 8 or more vCenters in a single site).

If you fall into the category that most customers do and have less then 8 vCenters in a site you’ll want to install SSO on each vCenter and during the install of your 2nd and subsequent SSO instances, make sure to select additional SSO server in the same site so it will join the existing vsphere.local security domain. To install SSO on a Heartbeat protected server you’ll need to download SSOupgradeUtil.exe from KB 2059820 and put it on both nodes.

If you fall into the category of customers that has 8 or more vCenters in a site and want to go with a centralized SSO and Web Client model you don’t need to worry about the SSOupgradeUtil.exe steps below, but you do need to setup the centralized SSO and Web Client server(s) before proceeding.

The first step in upgrading is to backup your databases (SSO, vCenter, VUM), we’ll be restoring them at a later step so keeping them on disk is recommended, you also need to backup the SSL folder from your secondary server, this folder is located at C:\programdata\VMware\VMware VirtualCenter\SSL. Once the backups are complete move the vCenter services onto the Secondary node and follow the steps below:

  1. Shut down vCenter Heartbeat, ensure the option “Do not stop protected applications is selected”.2013 11 07 00 24 43
  2. Set the vCenter Heartbeat service to Manual startup mode on both servers.
  3. Ensure User Account Control is disabled or run open a command prompt as an administrator, run the SSOUpgradeUtility.exe with the pre option such as: SSOUpgradeUtil.exe pre
  4. Start the SSO installer, verify that the IP shown is the Public IP, if your management or channel IP is shown remove the IP’s from the NIC and start the install again and add them back once SSO install is complete.
  5. Ensure DNS resolution is working, indicated by the green check mark.2013 11 07 00 37 15
  6. If SSO is currently on the server the setup  process will detect it and upgrade it, if it is not you will need to add your identity sources after you’ve installed the web client, in both cases you are asked to provide a password for the administrator@vsphere.local account. If you are using the custom installer you will also be able to choose if this is your first SSO server, additional SSO server in the same site or additional SSO server in a new site.
  7. Once the SSO installer finishes go back to your command prompt and run SSOUpgradeUtil.exe with the post options such as: SSOUpgradeUtil.exe post
  8. Next upgrade the Web Client, you will be asked for a SSO administrator username and password, administrator@vsphere.local is pre-populated, enter the password for that account, accept the SSL certificate when prompted and finish the upgrade.
  9. Next upgrade the Inventory Service. You will be given the option to keep your existing database or start with a new one. The Inventory Service serves as a read cache for the Web Client, but it also stores the tags you’ve created in the 5.1 Web Client so it’s recommended that you choose to upgrade your existing database. You’ll also be asked for a SSO administrator username and password, administrator@vsphere.local is pre-populated, enter the password for that account, accept the SSL certificate when prompted and finished the upgrade.
  10. Next upgrade vCenter Server. You’ll be asked if you want to upgrade your existing database (yes you do!) you’ll have to check a box stating you’ve backed up your database and SSL keys, you’ll also be asked for a SSO administrator username and password, administrator@vsphere.local is pre-populated, enter the password for that account, accept the SSL certificate when prompted. Verify the URL for the Inventory Service is correct and finish the upgrade.
  11. Upgrade any additional components you have such as VUM, AutoDeploy, Syslog collector, etc.
  12. Open the configure server vCenter Heartbeat utility, navigate to the machine tab and select that the Primary server should be the Active server.2013 11 07 00 47 54
  13. Start the vCenter Heartbeat service on the Secondary node, leaving the startup mode as manual, once the service is started reboot the server.
  14. Restore your vCenter and VUM databases from the backup taken earlier, its not necessary to restore the SSO database as no changes were made to it.
  15. On the Primary node open the configure server vCenter Heartbeat utility, navigate to the machine tab and select that the Primary server should be the Active server.
  16. Start the vCenter Heartbeat service on the Primary node.
  17. Now repeat the same upgrade process, including running SSOUpgradeUtil.exe, on the Primary node.
  18. Once finished, change the vCenter Heartbeat service to Automatic on both nodes and reboot the Primary.
  19. Once the Primary is available, open the vCenter Heartbeat Manage Server snap-in.
    • Click on the Applications tab and then Tasks, right click the “Protected Service Discovery” task and choose Run Now.
    • Click on Services, ensure the list is updated with the new 5.5 SSO services .2013 11 07 00 55 13
    • Click on the Server tab and then Summary and then click the Start Replication button and choose “Do not attempt to start protected applications”.
    • Click on the Application tab and the Plug-ins.
    • Click on “VirtualCenterNFPlugin.dll” and then click the uninstall button.
    • Click on the install button and navigate to C:\Program Files\VMware\VMware vCenter Server Heartbeat\R2\plugins\VMwareVirtualCenter\201.5.4.13406 and select VirtualCenterNFPlugin.dll.
    • Click on “VirtualCenterNFPlugin.dll” and then click the Edit button and enter the username and password of the account used to connect to vCenter.
This entry was posted in Uptime, vCenter Server, vSphere and tagged , , on by .
Mike Brown

About Mike Brown

Mike Brown is a senior technical marketing manager in the Cloud Infrastructure Technical Marketing group. Mike has worked in the IT industry for more than 17 years. His focus is on reference architectures for VMware vCloud Suite and the software-defined data center (SDDC) as well as VMware vCenter Server, vCenter Single Sign-On, VMware vSphere Web Client, and resource management technologies such as vSphere Distributed Resource Scheduler, VMware vSphere Network I/O Control, VMware vSphere Storage DRS, and VMware vSphere Storage I/O Control. Mike has multiple industry certifications, including VMware Certified Design Expert (VCDX). Follow Mike on Twitter @vMikeBrown.

11 thoughts on “Upgrading vCenter when using vCenter Heartbeat, Part 2

  1. rommel humarang

    Hi Mike. Nice post. Are the steps exactly the same when upgrading from vcenter 5.50a to 5.50b with heartbeat 6.6?

    Reply
      1. Rommel Humarang

        Thanks! Curious on step 14. Why do we need to restore the databases?

        Another question, reading through the Heartbeat Install-Upgrade guide for 6.6, page 59, during Database setup it will prompt if this is an update or an upgrade. Which one should be selected for 5.5.0a to 5.5.0b?

        You have the following options: otherwise,
        ■ If applying an update, when prompted, select the Do not overwrite, leave my existing database in
        place option and continue with the update procedure.
        ■ If this is an upgrade, when prompted, select Upgrade existing vCenter Server Database and choose
        to Automatically upgrade the vCenter Agent. Continue with the upgrade procedure.

        Reply
        1. Mike BrownMike Brown Post author

          It’s an update, upgrades are major versions (5.1 to 5.5) updates are in the same major version (5.5a to 5.5b).

          Reply
        2. Mike BrownMike Brown Post author

          Sorry missed your first question. During the install the DB is updated, if you don’t restore it when you do the install on the 2nd vCenter the DB upgrade will fail and will cause vCenter setup to fail as a result.

          Reply
          1. Rommel Humarang

            HI Mike, I watched the just released Product Walkthrough for Heartbeat. As I understand, you need to restore the database since you are using one remote database for the 2 vCenter nodes. What will be the procedure if the SQL database is in the same server as vCenter Server? Is there still a need to restore the db when upgrading the 2nd vCenter server?

          2. Mike BrownMike Brown Post author

            Hi Rommel,

            As long as you make sure vCenter Heartbeat remains in a stopped state and doesn’t replicate the upgraded database to the other server you won’t have to restore the database before you upgrade that server.

            Mike

  2. Cédric

    Hi Mike,
    Great post. Thanks!

    We are going to upgrade our vCenter 5.0 U1 (without SSO…) to 5.5.0b soon.
    The vCenter Server is protected with vCSHB (already upgraded to 6.6).
    Are the steps the same, even if we do a fresh install and not an upgrade of SSO ?
    Or is there any other way to force the SSO installer to use the HB public FQDN and not the host FQDN?

    Kind regards,
    Cédric

    Reply
    1. Mike BrownMike Brown Post author

      Hi Cédric,

      Yes you would follow the exact same steps, including running the ssoupgradeutil, this is to make the SSO installer use the shared heartbeat name and not the local name of the machine.

      Mike

      Reply
  3. Stephen Wheet

    Sorry for the following book but I’ve hit a roadblock.

    Thanks for putting together this great article. I have done part 1 of the upgrade which was to upgrade to VCHB 6.6. That went without a hitch. I’m looking to upgrade from 5.1.0b to the latest 5.5. Here is the wrinkle, I’m using VCHB in the WAN mode. I have two physical vCenter servers which are connected to via WAN. Since we are using the WAN I have three IP’s assigned. 1 IP that has the shared DNS entry gets moved between, 1 IP that is the IP address of the server (and each vCenter server has a unique server name) and 1 channel IP address. Everything is working perfectly. My question is how does the procedure change with WAN. Reading through your article (which is great) made me pause because since this is WAN and not LAN and the IP is not shared, nor is the hostname, this may cause a problem. Here are my questions.

    In step 5 you talk about ensuring DNS is working. It looks like it grabs the host name. When setting up WAN heartbeat you have to use a shared DNS name for everything and not the host name. I’ve ran into this problem before when I went to add the Syslog collector after I had set up HB. I ended setting it up with the host name (didn’t give me the choice of specifying the dns name during install) and then edited the an XML file to change it to the shared DNS name. This wasn’t a big deal but it makes me very nervous with the SSO upgrade. Since everything has to be pointed to a shared DNS for WAN HB I’m worried that I may get this to work but then in the event of a failover everything would still be pointing to the hostname for SSO rather than the shared DNS name and fail.

    In step 14 you talk about restoring the databases. In your article is sounds like you do that on the secondary node but in the KB article is sounds like you do the restore on the primary node. Can you please clarify? It looks like you are wanting to backup the VCDB and the VUM database after it’s done the SSO patch but before the vCenter 5.5 upgrade which i understand. Then we take the SSO “fixed” VCDB and VUM databases and put them on the primary.. before we then again run the SSO upgrade. That last part confuses me. Why would we re-run the SSO upgrade again with databases that are already “fixed”?. Also if I restore the “fixed” VCDB and VUM databases on the primary and then try to start the services before I have ran the SSO upgrade on the primary .. won’t that cause a problem when I try and start the services?

    I’ve opened a ticket with Vmware support but not a lot of people use the WAN option so I’ve got a bunch of people scratching their heads. Any help would be appreciated.

    Reply
    1. Stephen Wheet

      Hey.. just noticed. something about the database question. I have the SQL database on the same server as the vCenter so I won’t have to do that extra restore so that answers that question. Still worried about the first question and the hostname.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>