VMware Cloud Community
Bill_Oyler
Hot Shot
Hot Shot

Migrating from Embedded SSO 5.5 to External PSC 6.0 via uninstall/reinstall method

I understand that the "official" procedure for migrating a vCenter from an "embedded" SSO 5.5 instance to an "external" SSO 5.5 instance is to follow the KB to "re-point" the vCenter, Inventory Service, and Web Client using various CLI scripts.  I've tried this procedure several times in our lab with poor results (vCenter service restarting endlessly, log files growing endlessly, etc.).  In contrast, performing an uninstall of vCenter (following the KB to cleanly uninstall) and then re-installing vCenter, pointing to the existing SQL database and the new external SSO 5.5 server, worked perfectly.  I realize that I lost the Inventory database, but this did not seem to affect anything.  Are there any other side-effects of performing a vCenter uninstall and re-install, pointing to the new SSO 5.5 instance via the installation of vCenter?  This seems like a viable option and cleaner than running all of the CLI scripts.  It also gives you the option to move to a fresh clean VM (perhaps with a different OS such as Win2012 R2).  Am I missing anything that might result in this being unsupported by VMware?

Bill Oyler Systems Engineer
Tags (2)
10 Replies
paurgie
Contributor
Contributor

Sorry to add just a 'me too' post, but ... me too!

This seems to be a predicament that many people may end up being in come 6.0 based on some of the supported architecture documents on the support site.  I'll elaborate -  Say your architecture in 5.5 includes a couple of sites and SRM, all running with embedded SSO.  I would imagine this is a pretty common scenario because at this size no one ever claims that you should split SSO out, or even how to go about doing it.  Moving from 5.5-6, with embedded SSO will end up in an 'all-in-one' server in 6.0.  The problem lies in that the architecture docs they say that if you have multiple sites dedicated SSO is the supported place to be.

The problem here comes that the only way to get there is to re-point, and if your experience is common, that may not be very clean in itself.  I've asked our support rep to clarify, since that seems like a huge kludge that a lot of people could be facing... still waiting to hear back.

Reply
0 Kudos
Bill_Oyler
Hot Shot
Hot Shot

Yes, I have quite a few SRM, vSphere Replication, and VMware View customers with multiple vCenters, all using "embedded" SSO 5.5.  For Enhanced Linked Mode to be supported, they will need to migrate to the "external" PSC 6.0 model.  I really like the "re-install vCenter and point to existing SQL database and external SSO 5.5 server" method, because it enables the customer to deploy vCenter on a fresh new Win2012 R2 VM without all of the in-place upgrade garbage from 5.0 -> 5.1 -> 5.5 -> 6.0.  However I would really like VMware to publish an official statement saying that they support this method.  At this point the only downside I am seeing is that the Inventory Database is lost (but this contains very little critical information), and third party Web Client extensions are lost (but this is OK because you typically want to re-install newer versions of Web Client extensions anyway).  Overall I am very pleased with the "re-install vCenter and point to existing SQL database and external SSO 5.5 server" method.  vCenter has never run better in our lab after doing that.

Bill Oyler Systems Engineer
Reply
0 Kudos
Bleeder
Hot Shot
Hot Shot

At least on Windows, a lot of the vCenter server advanced settings are not kept in the database, but in vpxd.cfg.  If you uninstall/reinstall fresh, you will lose these settings.  You may then be left wondering why things aren't working as before.

Reply
0 Kudos
Bill_Oyler
Hot Shot
Hot Shot

I just checked my two vCenters and the "vpxd.cfg" file does not seem to contain much of anything that I would actually want to keep after a re-install.  For example it seems to have a few TCP ports, a UDP port, license key info, some file paths, the FQDN of the SSO/PSC server, SSO username, all of which would be specified during the vCenter re-install (and you would not want to keep the old PSC/SSO server names, since the whole point of this exercise is to use a different PSC server).  So I am curious how important this file really is.  Also, VMware's official KB on performing a clean re-install of vCenter says to remove the C:\ProgramData\VMware\VMware Virtual Center directory, which contains this file, so I can't imagine VMware considers it to be critical:

Reinstalling VMware vCenter Server 5.x and 4.x (2003493)

http://kb.vmware.com/kb/2003493

Bill Oyler Systems Engineer
packetboy
Contributor
Contributor

Hi,

    I am definitely interested in this thread.  I am also in the same boat..  We currently are running 5.5 on two vCenter servers one in Prod one in DR with embedded multisite SSO.

I have worked out that yes I need to move our Prod and DR SSO to external to two new 2012R2 SSO dedicated VM's but I would also like to use two new 2012 R2 VMs for vCenter for Prod and DR as well so your idea of an uninstall \ reinstall sounds perfect..

Bill have you done this in prod yet?

For your vCenter uninstall \ reinstall step did you uninstall off an old VM and reinstall 5.5 onto a new 2012 VM then upgrade it to 6.0?   Or did you just installed 6.0 directly to the new 2012 VM?

Cheers,


PB.

Reply
0 Kudos
DaveMo
Contributor
Contributor

I've also tried the KB to "re-point" the components and had it fail miserably. I'm trying the uninstall/reinstall method now.

I find it a little surprising that VMWare doesn't have a clearly documented procedure (yet) for moving from 5.5 with an Embedded SSO to 6.0 with an external PSC, since the external PSC appears to be the way to go for even slightly complex topologies.

Reply
0 Kudos
paurgie
Contributor
Contributor

I should add some status, since we're going down this road in the lab.

The repoint to a new SSO worked well, provided one very important bit.  In our environment SSO is basically a pass-through to AD, we have next to no users defined in VMware SSO.  What this means is that the SSO environment is basically a throw-away component, and I treated it as such.  I stood up a new pair of SSO servers for our sites with a new SSO domain, one per site, and repointed those per the documentation.  When I tried to join the new servers to the old SSO domain, things went south in a hurry.

After the repoint, the upgrade goes pretty smooth.  The vC installer realizes everything and installs a PSC only and a vC only (with friends) and we're on our way.  Even moving the external windows PSC to an appliance works pretty well.  I'm having tons of fun with SRM and certificates, but that's a whole different topic.

Reply
0 Kudos
sgtserge
Contributor
Contributor

Anyone tried to upgrade inplace to 6.0 with embedded PSC then remove all and reinstall only vCenter connected to external 6.0 PSC?

Sergio

Reply
0 Kudos
Bill_Oyler
Hot Shot
Hot Shot

PB -- For my uninstall/re-install of vCenter, I've done a few different scenarios with success:

- Same VM/same OS/same hostname/same IP

- Different VM/different OS/same hostname/same IP

- Different VM/different OS/same hostname/different IP

These scenarios all seem to work.  I've never changed the vCenter hostname, so I can't say if that will work or not.  Changing IP's does not seem to matter, and changing OS type (Win2008 R2 to Win2012 R2) does not seem to matter.

I am still curious what VMware has to say about this "uninstall / re-install and point to new external PSC" method.  It would be nice if they would post a KB on the topic.

Bill

Bill Oyler Systems Engineer
Reply
0 Kudos
rafajimot
Contributor
Contributor

With the 6.0 update 1 ... there are a new feature: a manager for the PSC management.

Did anyone test this feature?. It can be useful to reconfigure the PSC schema after an upgrade.

Reply
0 Kudos