Splitting Enhanced Linked Mode (ELM)

Products

VMware vCenter Server 7.0 VMware vCenter Server 8.0

Issue/Introduction

Enhanced Linked Mode (ELM) is a feature of VMware vSphere that allows multiple vCenter Server instances to be joined together in a unified management environment, forming a single vSphere Single Sign-On (SSO) domain.

This enables administrators to use the vSphere Client to view, search, and manage the inventories of all linked vCenter Servers from any participating node.

Administratively, ELM provides the following benefits:

Unified access: Users can log in with a single account and manage resources across all linked vCenter Servers.
Centralized visibility: Inventories and resources such as VMs, hosts, clusters, and datastores are accessible from any node in the environment.

All vCenter Servers in ELM are members of the same SSO domain, which ensures that the contents of the vmdir database are automatically replicated to every node. The replicated items typically include:

Local SSO users and groups
Tags and categories
Global permissions

Within an ELM setup, vCenter Servers utilize a shared Security Token Service (STS) signing certificate to authenticate user sessions and service interactions. Additionally, the TRUSTED_ROOTS store is replicated across all nodes, ensuring consistent trust anchors for SSL/TLS communications within the SSO domain.

At times, it may become necessary to break Enhanced Linked Mode, such as when removing a node from the Single Sign-On (SSO) domain.

Environment

VMware vCenter Server 7.x

VMware vCenter Server 8.x

Resolution

A vCenter can be removed from Enhanced Linked Mode by repointing its node from the shared SSO domain to its own standalone domain. This process breaks the link and isolates the vCenter, allowing it to operate independently.

Warning:

Offline snapshots off all nodes in linked mode must be taken to allow for single point in time roll back. If vCenter HA is in use on any of the nodes it must be destroyed before attempting this process.

Shut down the node being repointed (for example, vCenter C)
With the node to be moved powered off, the next step is to decommission it from the existing SSO domain. For example, to decommission Node C, log in to either Node A or Node B and execute the following command:
```
cmsso-util unregister --node-pnid Node_C_FQDN --username Node_B_sso_administrator@sso_domain.com --passwd Node_B_sso_administrator_password
```
Example:

cmsso-util unregister --node-pnid nodeC.vCenter.com --username administrator@your_domain_name --passwd #####
This command unregisters Node C from the SSO domain. After execution, all vCenter services on the node where the command was run will automatically restart. References to Node C are removed from that vCenter, and the changes replicate to all remaining SSO partners, maintaining domain consistency.
Power on vCenter C to begin the domain repointing process.
Using the following command on vCenter C will repoint the node to its own domain/SSO. The value for "destination_PSC_domain" can be any valid domain name; however, using "vsphere.local" is recommended for consistency and best practice:
```
cmsso-util domain-repoint -m execute --src-emb-admin Administrator --dest-domain-name destination_PSC_domain
```

Example:

cmsso-util domain-repoint -m execute --src-emb-admin Administrator --dest-domain-name vsphere.local

5. Please note that you need to run the cmsso-util unregister command on the second node (Node B) if there are two nodes (A&B) to release the partner information from the node.

Note: The following information/configuration is lost on the vCenter following a domain repoint and may need to be re-created:

- Custom local SSO user accounts
- Global Permissions
- Rejoin vCenter Server to Active Directory Domain, if needed
- Re-register external plugins and solutions

6. Follow the steps to remove stale global permissions of previous domain: Remove stale global permissions of previous domain after domain repointing