The introduction of Single Sign On in vCenter 5.1 causes issues because of local vs. domain accounts, and if you’re using linked mode, the SSO account. I recently had to do this with an upgrade to vCenter 4.1, and had many stumbling blocks that caused some delays in my project.
For the most part, linked mode is used by clients with Site Recovery Manager so that both the production site and the DR site are visible. This includes the protection status and placeholders so you can see what is protected for recovery. Linked mode also gives easier license sharing between sites, enabling installation of the same SRM key at both ends. It also provides automated transfer of per-VM usage between sites when migrating or failing-over between sites.
Keep in mind, that doesn’t mean you can exceed the total number for which you are licensed. For example, if you have a 25 VM SRM license you can install that license on both sites of the linked mode install. However, you’re still only allowed to protect up to 25 VMs; whether it’s 20 on one site and 5 on the other, or 25 at one and zero at the other. Linked mode will allow you to failover and then protect back, while automatically deducting the protected number of VMs from the appropriate license at either site (depending on where your protected VMs are running.) Linked mode vCenter instances need to authenticate against what appears to be a single SSO instance; whether it is a single SSO instance at one site, multiple SSO instances in HA mode, or multiple SSO instances in multi-site mode. Of those options when using SRM, my preference is to either not use linked mode at all, or to deploy SSO in multisite mode. A single instance or an HA cluster at one site will always introduce the risk that you cannot login during a disaster.
The final option is to not use linked mode, and to stand up independent VC and SSO instances at each site; managing them as separate entities all together. This is, of course, what you will do if you don’t want or need linked mode and multisite SSO. In any of these cases, SRM will function properly and only your approach and architecture will alter how you manage the environment.
The first and most important factor, is that you cannot use the simple install process of the vCenter installer. You must install each component individually. This is specifically because the simple install does not expose the functions of multi-site SSO or allow you to select primary and secondary roles of the SSO servers.
So for the first step, let’s log into the primary site vCenter Server, open the installer and choose to install SSO independently.
Next, choose the appropriate SSO deployment type. What we will want to do is to “Create the primary node for a new vCenter Single Sign On installation.” This will set up SSO as a standalone entity for your local vCenter, but also give you the ability to join the second site’s SSO install (when we get to that stage.) The point remains the same whether you’re doing a new install, an upgrade from VC 5.0, or even installing SSO on a separate system from your VC – choose to create a new primary node.
Now it will want to know a password for the SSO system domain password. Choose a good password, and write it down! We’ll need it a few times throughout the install, and the username for the SSO is different for vSphere 5.0+, and 5.5. That part is a bit confusing.
The next step is to choose the SSO sign-on type. We can choose to install a basic mode or a primary node for a new multimode SSO. Here we choose to “Create the primary node for a new vCenter Single Sign On installation” which will then give us the opportunity to join other SSO instances to this one.
The rest of the steps are simply next, next, next… – Keep in mind SSO domain admin password you choose, and keep both it and the https port written down somewhere, we’ll need that again later too.
Install or upgrade the Inventory service next, and then the vCenter Server.
When you install vCenter Server itself, make sure you do not join a Linked Mode instance – we are going to create a standalone instance and then later join the second site’s VC to this one. Also, when entering the SSO data into the VC install wizard, you’ll need to use the same ID and password you used for admin@System-Domain earlier. If you are doing 5.5, remember that this is different.
One thing I quite like about this install is the ability to populate the administrators group with a domain admin group. You can either choose to leave the default “Administrators” group, populate it with an ID or (as I did here), give it my “domain\Domain Admins” entry so all my domain admins would be automatically recognized as SSO admins. Also remember that local accounts are out now. Just use Domain Accounts.
You should then be up and running with a primary multi-node SSO operating standalone, and a standalone VC 5.1 using local inventory services and the local SSO.
This article originally appeared in VMware blogs here: https://blogs.vmware.com/vsphere/2013/02/linked-mode-with-sso-for-srm.html
