How to remove a vCenter from Enhanced Linked Mode
Sounds like a simple task to remove a vCenter from Enhanced Linked Mode (ELM). Basically ELM enables more vCenter instances to use a single SSO-domain. Most solutions I found talked about offline respectively dead vCenter instances. But I was looking for a solution to get a running vCenter out of ELM. And it should stay online after the removal! Fortunately, there is a simple way to accomplish this task. This post shows how.
Disclaimer: Please note that the options I have tested are based on my testing environment. There may be setups that give a different result. So be sure to test properly and make solid backups before doing this in your production environment!
The environment I tested in was very simple. Two vCenter appliances (vc-l-99a and vc-l-99b) in version 7.0 Update 3n and one ESXi host in each of them. First vCenter was installed using a new SSO-domain. The second vCenter joined this domain during the initial deployment.
Although there is basically a how-to description – see the notes – I wanted to test the effects of the procedure on various settings. So I tested a few options to see what happened to them after the vCenter left ELM. These options are:
- Additional identity source. In my case, I added an AD domain (corp.local).
- Permissions on vCenter layer and beneath.
- Content Library.
- Tags, tag-categories, permission and assignment.
- Folders and Permissions.
- Machine Certificates.
Procedure to remove a vCenter from Enhanced Linked Mode
First of all, do backups! I highly recommend these methods – both of them!
- Snapshot each vCenter in power-off state.
- File-based backup in VAMI.
To remove vCenter – in my example vc-l-99b – from ELM I did the following steps:
- Shut down vc-l-99b.
- Login to vc-l-99a via SSH, enter
shelland perform the following command:
cmsso-util unregister --node-pnid vc-l-99b.corp.local --username email@example.com --passwd *******
Basically this command unregisters the specified vCenter from ELM and restarts all services.
- Use FQDN for parameter
node-pnid. If you are unsure about your PNID, this command shows it:
/usr/lib/vmware-vmafd/bin/vmafd-cli get-pnid --server-name localhost
- In my case, SSO-domain named vsphere.local. Use your own.
- Use FQDN for parameter
- Check removal. Unregistered vCenter should be removed from vCenter-UI.
- Start second, unregistered vCenter. In my case vc-l-99b.
- Repoint vCenter to a (new) SSO-domain. In this example, I create a new SSO-domain named vsphere2.local locally in vCenter vc-l-99b. To do this, I ran the following command in vc-l-99b.
cmsso-util domain-repoint -m execute --src-emb-admin Administrator --dest-domain-name vsphere2.local
Important notes appear, read carefully!
In summary, this means that the following happens when the execution is confirmed:
- Licenses, tags and authorization data will be exported and imported.
- Global permissions are lost.
- Solutions and plugins are unregistered and must be re-resister manually.
- Previous Licenses are copied to the new SSO-domain.
cmsso-utilperforms the following tasks.
- Export data.
- Re-install Platform Controller Services (PSC) in vCenter appliance.
- Register services.
- Import data.
- Start all services.
The tasks are straightforward and work as expected. I was able to login as firstname.lastname@example.org after the procedure was finished.
Checks after removal
Additional identity source
Because of the PSC re-installation, identity sources are gone. Just localos and vsphere2.local are available.
Permissions on vCenter layer and beneath
Permissions remain intact. At lease permission-definition per object/layer stays in database. But the user/group behind the definition is not available anymore. Means, I still can see my corp.local users, but because this identity source is gone, users are not able to login. It sounds worse than it is. Just add the identity source and preserved permissions have their validity again. Do not forget to add identity source users to vCenter groups again.
Library and its items are still in place.
Tags, tag-categories, permission and assignment
Tags were exported and imported during the removal process. However, tag permissions are lost as they are global permissions.. Assignments have been restored.
Folders and Permissions
Folders and permissions stay intact. The objects also remain in the directories.
Certificates have not changed too.
- The steps in this post are based on VMware vSphere Product Documentation.
- More options and parameters for
cmsso-utilsee documentation Syntax of the Domain Repoint Command.
- vCenters in my test used self-signed certificates. See how to Replace machine certificate in vSphere.
cmsso-utilcommand for repointing can also be used to “rename” SSO-domain. But be very careful if you plan to do this.