vMegie

VCSA: Consolidating SSO Domains and Ensuring a Successful Migration

Posted on Author Jeremiah MegiePosted in vSphere

The vCenter Server Appliance is all the rage right now. No, it’s not a fad, in fact if you want to make sure you can take advantage of all the latest cool features, you should make the jump. The days of Windows and MS SQL are over, at least as far as vSphere management is concerned.

Over the past year, I’ve done a lot of migrations for customers. While all of them were successful, the journey wasn’t without some bumps along the road. Sure, the platform is different, and there’s a learning curve, but the appliance is far more efficient, faster and stable than its Windows counterpart. The question is, how do you move to it? Well there’s two options – build a new one and swing your hosts over, or migrate your existing vCenter. Both are valid options! While this isn’t going to be a step-by-step guide on how to migrate to the VCSA, I do want to talk about how to make your migration successful.

Multiple SSO Domains

The only step-by-step I’m going to outline for the upgrade is this one since I get a lot of questions on it. Often, I see customers with multiple, segregated, environments. This is usually in the form of two sites with a vCenter and some number of hosts, each site on their own little island (i.e.; different SSO domains). After all, this is the easiest way to deploy vSphere – stand up a Windows VM, do a simple vCenter install so all components reside on the same VM and TA-DA, VMWARE!

The first thing everyone thinks when they move to v6 is – Web Client, single pane of glass (Enhanced Linked Mode, or ELM). But it’s not that simple. For ELM to work your vCenters must reside in the same SSO domain. With this in mind we have to figure out which supported architecture we want to build out, and move to this architecture before upgrading/migrating to v6.

So, pick your poison:

I’d recommend reading both so you don’t choose one that’s deprecated in 6.5 – future proof yourself! We’ll step through an example, and I’ll choose the most common one I see based on my experience. By no means am I saying this is right for your specific use case.

In this scenario, we want our final architecture to have two sites; each site has a single vCenter and two PSCs in each site, but in the same SSO domain. The vCenter is pointed at a single PSC with an additional PSC in play just in case a repoint is needed due to the primary PSC failing.

To accomplish this, we need to externalize SSO in Site-A, then externalize SSO in Site-B but add it to the same SSO domain with the following steps:

Site-A

  1. Deploy a new Windows VM for your new SSO Server, be sure to create DNS records.
  2. Install the vCenter Single Sign-On component with the 5.x media (use the exact same version as your vCenter), choose option 1 to install the first SSO Server.
  3. Repoint the Inventory Service, vCenter Server, and Web Client to the new SSO Server.
  4. Uninstall the vCenter Single Sign-On component from vCenter.

Site-B

  1. Deploy a new Windows VM for your new SSO Server, again, be sure to create DNS records.
  2. Install the vCenter Single Sign-On component, but this time choose option 3 for an additional vCenter with a new site, and when prompted provide the SSO information for Site-A.
  3. Repoint the Inventory Service, vCenter Server, and Web Client to the new SSO Server.
  4. Uninstall the vCenter Single Sign-On component from vCenter.

To repoint the components listed above, your first need to unzip C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregtool\sso_svccfg.zip, then run the following commands. The commands are the same for both vCenter 5.1 and 5.5; however, you’ll need to use “admin@System-Domain” for 5.1 and “administrator@vsphere.local” for 5.5.

C:\Program Files\VMware\Infrastructure\Inventory Service\scripts\is-change-sso.bat https://NEW_SSO_FQDN:7444/lookupservice/sdk "administrator@vsphere.local" "YOUR_SSO_PASSWD"
C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregtool\sso_svccfg\repoint.cmd configure-vc --lookup-server https://NEW_SSO_FQDN:7444/lookupservice/sdk --user "administrator@vsphere.local" --password "YOUR_SSO_PASSWD" --openssl-path "C:\Program Files\VMware\Infrastructure\Inventory Service\bin/"
C:\Program Files\VMware\Infrastructure\vSphereWebClient\scripts\client-repoint.bat https://NEW_SSO_FQDN:7444/lookupservice/sdk "administrator@vsphere.local" "YOUR_SSO_PASSWD"

Once both sites are done, we have a single vCenter with external SSO Server in each site, but on the same SSO domain. At this point we have a good 5.5 architecture in place to migrate to the VCSA.

Product Version Validation

There are several things we want to do going into the migration to ensure its successful. Some of this seems like common sense, but you’d be surprised at how easy it is to overlook.

First things, first – What version of vCenter are you currently using? If you’re looking to migrate to VCSA 6, you need to have vCenter 5.5 installed. If you’re looking to migrate to VCSA 6.5, you can upgrade from vCenter 5.5 or 6. If you’re using anything less than 5.5, you’ll need to do an in-place upgrade first.

Additionally, check your ESXi host versions, if you’re using 5.1 or earlier, you will not be able to manage these hosts in vCenter, so you’ll need to plan accordingly.

Aside from checking your vCenter/host versions, you want to make sure that any other products integrating with vCenter are supported as well – SRM, NSX, vRA, backup software, etc. You can validate this by using the VMware Interoperability Matrix and validating with third party vendors directly.

Prep Work and Tips

Most of the problems I run into during the actual migration process come from skipping things in this section. Again, some of this stuff may sound like common sense, but pay close attention here.

Database Cleanup: I can’t stress this enough. Whether you did a fresh 5.5 install for your environment, or have done multiple upgrades, PLEASE prep the database. The procedure is the same for both 6.0 and 6.5, and be sure to check your SQL Native Client version and ensure you’re using at least v10.

Additionally, if you’ve been upgrading your vCenter since vSphere 4 or earlier, I’d strongly recommend doing a fresh install of the appliance. While I have had some success with customers who have upgraded from v4, I have had some problems, and have had no success with customers who have been upgrading since before v4. I’m not hanging the migration tool out to dry here, but from a database perspective, there have been so many changes to the schema, tables, data and other variables, you’re bound to run into problems. It’s not worth it in my opinion.

VMware Update Manager: I don’t see this too often, but some customers have VUM installed directly on the vCenter Server in 5.5, and that’s fine, but if you’re going to migrate to the VCSA, you’ll need to move it. So, stand up another Windows VM and install VUM because it won’t come over when you migrate to VCSA 6.

If you’re migrating to VCSA 6.5, you’re in luck, because VUM is now integrated!

NTP and DNS: This one is pretty simple, make sure your ESXi hosts are using NTP, and when you run through the migration process, make sure you use the same NTP servers in the wizard.

DNS is a given as well, we all know that vSphere is heavily dependent on DNS, so make sure forward and reverse lookups work.

However, one interesting thing I’ve run into several times is concerning Active Directory based DNS. When you spun up your Windows vCenter server and joined it to the domain, if you didn’t create a static entry, you probably have a dynamic entry that got created. That’s all well and good, but make sure you change that to static before you migrate. When your old vCenter server gets powered off, eventually your domain controller goes through its automated process of aging out old records, your vCenter DNS record will disappear and make for some really fun troubleshooting!

Virtual Switches and Portgroups: The requirement to deploy the VCSA is to either deploy it to a VSS, or a VDS with an ephemeral portgroup. If you’re using VSS, you’re all good, you have nothing more to do other than choosing the same portgroup as your current vCenter in the wizard.

If you’re using VDS, go ahead and create a temporary portgroup with ephemeral binding, call it whatever you like, give it the same VLAN ID as the portgroup your current vCenter is using. After your migration is successful you can move the VCSA to original portrgoup and delete the temporary one.

Accounts and Passwords: The last thing you want to do during a migration, or when troubleshooting, is scramble for usernames and passwords. Make a list of all the accounts in play and validate their passwords. Here’s a common list:

  • ESXi root
  • Local Administrator on Windows Servers
  • vCenter Service Account
  • Domain User with ability to join computers to the domain
  • SQL Account(s) for vCenter/VUM
  • SQL SA (optional)
  • vCenter SSO Admin (administrator@vsphere.local)

A few other tips to ensure you’re successful:

  • Install the Client Integration Plugin from the ISO, this is forgotten a lot.
  • Set DRS to be conservative, and record the ESXi host that your vCenter and SSO servers are registered to. I like to deploy the appliances to the same host for efficiency, and it also lets you know where your VMs are should you have to access the console to troubleshoot.
  • VCSA and Active Directory – About half the time, in my experience, the VCSA doesn’t want to join the domain during the migration. Read the error carefully, it reads backward to me, you want to continue the migration, not cancel it. After the migration is completed, you can attempt to re-join it to the domain. Again, this is hit and miss depending on the customer’s AD environment. Note: joining the VCSA to the domain is not required since the PSC will handle authentication for you.
  • If you don’t absolutely need your performance and historical data, skip migrating it over in the VCSA migration wizard. Depending on how large your database is, it could turn an hour migration into a full day migration. If you need the data, that’s ok too, just make sure to account for the time it will take.

The Migration

Now that you’ve gone through and checked everything, you’re in a good position to kick off your migration. Copy the migration-assistant folder to all SSO and vCenter servers, the desktop is fine.

Start with Site-A and migrate the SSO server to a PSC, after it’s complete, login to the web interface of the PSC and ensure its joined to the domain. Login to the vCenter at Site-A and ensure you can authenticate properly, then repeat the process for the SSO server in Site-B.

Once both sites are using PSCs you can migrate each vCenter. Make sure to do each component separately. Do not attempt to do parallel migrations:

  1. Site-A: Migrate SSO to PSC
  2. Site-B: Migrate SSO to PSC
  3. Site-A: Migrate vCenter to VCSA
  4. Site-B: Migrate vCenter to VCSA

After the migration is complete, login to the web client > Administration > System Configuration, and ensure you can see four nodes (2 PSCs, 2 VCSAs) and make sure you change your Active Directory domain to the default Identity Source (Home > Configuration > Identity Sources). Validate everything looks good – IP, domain, certificates, inventory objects, charts, roles and permissions, add your new vSphere 6 licenses, change DRS back, change the portgroup back on your appliances (if applicable) and you’re good to go!

Rollback

If you run into problems, and you need to rollback, it’s incredibly easy. Since the migration process simply deploys appliances, then exports and imports your data before shutting down its Windows sources, it never actually modifies the VMs or the database. The only thing that potentially changes is your AD computer account will get deleted. So, to roll back, power off the appliances, delete them, power up your Windows VMs, and rejoin to the domain.

Wait! We forgot something!

No, not really, I was saving this part for last. So, if you remember, we chose an architecture at the beginning that would help safe guard us in the event a PSC in one of the sites failed. If a PSC fails, you can restore it from backup, or rebuild it. But in the meantime, you kind of need something up and running. Now that you have a VCSA and PSC appliance in both sites, this is incredibly easy.

First create DNS records for a new PSC in each site, then deploy a new PSC using the normal installation media. When you go through the wizard, specify that you want to join an existing SSO domain, and choose the appropriate site. Do this in each domain. Once the PSC is up, if you log back into the web client, go to Administration > System Configuration, you should see six nodes – 2 PSCs and 1 VCSA for each site. Now, if a PSC fails, you can simply repoint the VCSA to the other PSC in the same site (since they’re replicating data)!

Oh, and by the way, since ELM is enabled by default, you can now see both sites in the web client no matter which one you login to.

Useful Links:

I hope this helps your migration to the appliance a successful one!

#migrate2vcsa

X-Post: Originally posted on Virtual Insanity.