Migrating from Embedded SSO to External PSC

One increasingly common question VMware Support receives from customers is around the topic of going from vCenter Server 5.5 with an embedded SSO to vCenter Server 6.0 with an external PSC.

The best piece of advice I can give is simply to re-configure your environment on vCenter Server 5.5 first. You have a lot more flexibility, especially when it comes to re-pointing / re-registering. Some important gotchas to make note of are:

  • It is not supported to re-register vCenter Server 5.x bits to a PSC 6.0
  • You cannot re-register vCenter Server 6.0 to a PSC 6.0 that does not reside in the existing SSO Domain.
  • You cannot install SSO 5.5 and join a PSC 6.0 (and vice versa)

If you’re a single vCenter instance shop, and don’t plan on having more vCenter’s any time soon, then keeping everything on one box would still make sense.

However, if you have multiple vCenter’s, or plan on having multiple, then you might want to re-configure how things are setup to align with VMware’s recommended topologies outlined in this article. List of recommended topologies for VMware vSphere 6.0.x (2108548)

Whilst the “deprecated” topologies are still supported for vSphere 6.0, I would pay attention to the following statement:

Topologies that are deprecated and will be unsupported in the future. These topologies are not recommended.

 

Take a typical 2 vCenter 5.5 environment. Two windows machines with all the vCenter 5.5 components installed, and the SSO components in Multisite.

1

Our goal is to end up with two vCenter 6.0, each with an external PSC, in a single SSO Domain.

Important: Before beginning, break the vCenter Linked Mode configuration if applicable.

5

Deploy new external SSO Servers.

  • First things first, spin up two new SSO Servers.
  • Do not join these to the existing embedded SSO Servers.
  • Install the first SSO Server as “Standalone”
  • Install the second SSO Server as “Multisite”

2

Re-register the Inventory Service, vCenter Server, Web Client

  • Just follow this KB Article to re-register each component to it’s new external SSO.
  • If you have other components (vCO, vRA, etc) then they too will need to be re-registered with the new external SSO Servers.

Re-pointing and re-registering VMware vCenter Server 5.1 / 5.5 and components (2033620)

3

Uninstall the embedded SSO Servers

  • Simple enough. Just uninstall the embedded SSO Servers on each site.

4

Upgrade to 6.0

  • Upgrade the external SSO Servers to a PSC 6.0 (one at a time)
  • Upgrade the vCenter Servers to 6.0 (one at a time)
  • Don’t forget to take backups and snapshots prior to any upgrade.

5

Overall it’s fairly straight forward and the above process can be scaled to more vCenter’s.

Advertisement

17 thoughts on “Migrating from Embedded SSO to External PSC”

  1. Just a note, I have done repoints to the 6.0 PSC from the 5.5 vCenter during a botched vCenter 6 upgrade (after a rollback to snapshot). Not sure if it will only work in this case or not.

    Like

    Reply

  2. I wanted to stress that you’ll have to unlink vCenter server if using linked mode (as described in KB2033620) before re-registering with the new SSO instances. In my case I had to do a rollback and unlink them first as I ran into some issues during the re-registering process.

    Like

    Reply

  3. Nice article, with clear illustrations. I am, however, wondering that with the added functionalities of U1 and U2 (improved repointing of vCenters to PSCs) isn’t it easier to:
    1) Upgrade vCenter 5.5 (embedded SSO) to 6.0 (embedded PSC)
    2) Deploy a new external PSC, join in the existing SSO domain
    3) Repoint vCenter 6.0 (embedded PSC) to the new external PSC
    4) Remove embedded PSC from vCenter 6.0
    Would this be a supported upgrade path? The disadvantage of your approach would be the need to create a new SSO domain, which would requires a different name for the SSO domain…

    Like

    Reply

    1. Thanks for the feedback.
      Your steps would be supported but there have been some known issues as a result of converting from Embedded PSC to External (not going to go into them here).
      Just a note on 4) the embedded PSC cannot be removed, the binaries and services will still remain, just in a disable state.
      Also, with regards the approach outlined in this post, you do not have to (nor can you with 5.5) choose a different name for the SSO Domain. When you deploy the new external SSOs they would also use the name vsphere.local. You would have two independent vsphere.local domains. Renaming vsphere.local only came about in 6.0.

      Like

      Reply

      1. Thanks for your prompt reply. I take it you would recommend the procedure from your article over my suggestion? I am curious about those issues from repointing vCenter from embedded PSC to external PSC though, any KB links?

        I am surprised that VMware documentation for an upgrade procedure to a ‘recommended topology’ from a ‘simple’ installation of vCenter 5.5 is not available. Searching for it led me to your article.

        I am setting up designs and procedures for doing major 6.0 upgrades for several linked, simple vCenter 5.5 deployments. I am looking for the most robust and supported way of upgrading our simple vCenter 5.5 installations to vCenter 6.0 with external PSCs.

        Like

  5. Thank you for the detailed article. My question is how long can that period be when you upgrade one of the sso node to a psc node? We have several vcenters which are at embedded sso 5.5 right now, and are in different domains. My plan was to deploy external sso for them and while deploying these new sso servers, keep them all in the same sso domain. After that I plan to upgrade those sso to PSC 6.0 one by one. However I am not sure how much time period I can keep between each of those updates. And also if one of my sites is at 6.0 first, and the others are at sso 5.5, is it going to break the sso domain or replication? I am almost certain about this next question but I would still like to confirm that does it matter which site I upgrade first when going to PSC 6.0? As far as I know there is no master or slave nodes in the SSO configuration, as long as they are setup for ring topology.

    Like

    Reply

    1. Hi Virtualcloud,
      With regards having mixed SSO 5.5 and PSC 6.0 in the same SSO Domain, VMware does not support this. All SSO’s in an SSO Domain should be upgraded to 6.0.
      For the second question, yes it does not matter which SSO node you begin the upgrade to 6.0 on.

      Like

      Reply

  6. I found that I could not do the repoint with 5.5 since I went from 4.5 – 5.5 skipping 5.1 and it had to do with certs in 5.5

    repoint to a new/different SSO, if you stand up your new SSO environment using 5.1 first, then upgrade it to 5.5, and then repoint, it should work. 5.1 will use certificates with subjects that will work with the repointing script, whereas 5.5 apparently does not. It’s also important to note that if you are have a multi-site or HA SSO environment, then SSO 5.1 must be installed on all nodes prior to upgrading them to 5.5, otherwise the fresh 5.5 install on the additional nodes will still use the bad certs.

    Like

    Reply

  7. im confused by your 4th step… removing the embedded PSC… how do you do that?
    i have found no clear kb articles saying that this process is actually required once you repoint to the external PSC.. ?

    Like

    Reply

  9. How to re-configure the 5.5 Appliance environment for the same? The KB articles are confusing. Could you provide all the steps?

    Like

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s

%d bloggers like this: