Note: As ever before you begin – make sure the FQDNs of your proposed PSC and vCenter are listed in DNS – and reserve your IP addresses accordingly. The vCenter install validates your IP/DNS configuration and won’t let you proceed until its correct.

WARNING: Please pay close, close attention to your FQDNs as during the process built-in certificates are created which if you subsequently correct/change hostname will be invalid.

In this scenario – I wanted the appearance of multiple vCenters across many sites – and wish to link them together for ease of administration – and the sharing of licensing repositories. This ensures licenses can be assigned freely around the organisation – and not be “locked” to specific site location. This more distributed model is not supported with the “embedded” deployment type – where the vCenter and PSC service reside in the same instance – and seems to have been introduced with vSphere 6.5 U1. So I would have two PSC and vCenters one for New York and the other for New Jersey.

There now 8 supported topologies for multiple vCenters and “Enhanced” Link Mode – and 3 depreciated one as well. Far too many possible permutations for me to cover – so I would seriously considering studying the documentation in full. I would recommend starting https://kb.vmware.com/s/article/2147672 which gives a good round-up of all them.

VMware’s “Linked Mode” feature has a number of names – from Linked Mode to Enhanced Linked Mode, to now it being also called “Hybrid Link Mode”. Most of the changes have come about as the company pivots away from vCenter’s historical Microsoft Windows roots, to being purely a Linux based Virtual Appliance. However, In 2017, VMware announced a partnership with Amazon to extend vSphere functionality into Amazon Datacenters and integration with its Amazon Web Services (AWS) environment. This development prompted VMware to modify linked-mode functionality to also include management of assets in Amazon’s cloud. Hence “Hybrid” mode is now the favoured term. Hybrid mode in its full functionality is only available for those who have both vSphere on-premises and a vSphere subscription with Amazon. Whatever its name – linked mode addresses a scenario for where multiple vCenter persist for geographical or political reasons – and it has been decided to provide one-login identity to both systems.

It’s entirely possible that you may wish to install another vCenter at different site or location. In this configuration I had a single PSC Domain (vsphere.local) and single Active Directory Domain (corp.local) – but with two SSO sites – one called New York, and the other called New Jersey.

In our case I have two different vCenters and PSC in two different sites – however, they will part of the same SSO domain and linked together. The KB article referenced at the beginning of this section outlines this accordingly – although in my case there will for the moment just one vCenter under each PSC.

1 Single Sign-On domain 1 Single Sign-On site 2 or more external Platform Services Controllers

This configuration is not without limitations:

• In the event of a Platform services Controller failover the vCenter Servers will need to be manually repointed to the functioning Platform Services Controller.
• vCenter Servers attached to higher latency Platform Services Controller may experience performance issues

New York: PSC – Establishing the SSO Domain

Note: Deploying the PSC comes in two stages – the 1st Stage being the primary deployment to a VMware ESXi Host, and the 2nd Stage being the post-configuration of the SSO component.

STAGE ONE: DEPLOYMENT

1. Mount the .ISO image to workstation or VM that has access to the same network as your destination VMware ESXI host.

2. Once mounted browse to D:\vcsa-ui-installer\ to find your preferred installer – in our case we were using a Windows10 jumpbox into the lab environment we used Win32.

3. Double-click the Installer

4. Select the option to Install

5. In a multi-site and multi-vCenter configuration – the install is two-stage process – first the installation of the Platform Services Controller (PSC) service itself, and then the installation of the vCenter element.

6. Accept the EULA

7. For a multiple-site deployment I can’t use the “Embedded Model” where both the vCenter and PSC reside in the same appliance. For multi-site deployments it is now a requirement to separate the vCenter and PSC roles.

8. Next we need to specify an VMware ESXi host to deploy the vCenter together with the “root” account and password

Note: You will be prompted to accept the default untrusted SSL thumbprint/certificate of the host.

9. Next assign an VM name for the PSC Appliance, together with a password for the default “root” account. The name is virtual machine name, not the FQDN of the appliance. In this case I used “pscnyc” representing the PSC for the New York Datacenter.

10. Next select a datastore within which the PSC will be held. On an unconfigured VMware ESXi host it is likely all you will see is local storage. In a fully configured VMware ESXi host you should be able to see the datastore(s) that have been mounted to it – these can take the form of FC, iSCSI, NFS or VSAN capable storage.

11. Next select which network the PSC will reside on together with it’s FQDN, IP address, subnet mask, default gateway and DNS name servers. On an unconfigured VMware ESXi host you will see just “VM Network”. This should be the same network as the ESXi Host. If the ESXi host is using VLAN Tagging to separate the management network – you will need to use ESXi Web-Client to change the VLAN Tag value for “VM Network” for this to functional. In our case I configured a VM network called “Management” on all our hosts for this purpose.

12. Select Finish to review your settings and upload PSC Appliance to the VMware ESXi host

STAGE TWO: POST-CONFIGURATION

In this stage we configure the time configuration and the SSO settings.

1. Next configure the preferred time synchronisation process. Typically, all VMs get their time from the underlying VMware ESXi host – which in turn is configured for an external NTP time source. Enable the SSH access if you intend to use the new vCenter Server High Availability function.

2. Choose to Create a new SSO Domain. It’s tempting to make the VMware SSO Domain match the Microsoft Active Directory Domain. I would caution against this – as it can create the confusion or appearance that the two domains are the same entity. They are not. They are completely separate – as we saw earlier this chapter if you desire Microsoft Active Directory integration that can handled as discrete process.

3. Indicate if you wish join VMWare’s Customer Experience Improvement Program (CEIP)

4. Review your settings and click Finish

New York: Install vCenter

Note: Deploying the vCenter comes in two stages – the 1st Stage being the primary deployment to a VMware ESXi Host, and the 2nd Stage being the post-configuration of the SSO component.

STAGE ONE: DEPLOYMENT

1. Mount the .ISO image to workstation or VM that has access to the same network as your destination VMware ESXI host.

2. Once mounted browse to D:\vcsa-ui-installer\ to find your preferred installer – in our case I was using a Windows10 jumpbox into the lab environment I used Win32.

3. Double-click the Installer

4. Select the option to Install

5. The install is two-stage process – first the installation of the PSC service itself, and then the installation of the vCenter appliance.

6. Accept the EULA

7. For simple single-site deployment the “Embedded Model” where both the vCenter and PSC reside in the same appliance. However, for multi-site deployments it is required to separate the vCenter/PSC roles.

8. Next we need to specify an VMware ESXi host to deploy the vCenter together with the “root” account and password

Note: You will be prompted to accept the default untrusted SSL thumbprint/certificate of the host.

9. Next assign an VM name for the Appliance, together with a password for the default “root” account. The name is virtual machine name, not the FQDN of the appliance. In this case I used “vcnyc” representing the vCenter for the New York Datacenter.

10. Next we can set the appliance size – this will allocate CPU and Memory commensurate with the number of hosts/virtual machines the vCenter will eventually support.

11. Next select a datastore within which the VCSA will be held. On a unconfigured VMware ESXi host it is likely all you will see is local storage. In a fully configured VMware ESXi host you should be able to see the datastore(s) that have been mounted to it – these can take the form of FC, iSCSI, NFS or VSAN capable storage.

13. Next select which network the vCenter will reside on together with its FQDN, IP address, subnet mask, default gateway and DNS name servers. On a unconfigured VMware ESXi host you will see just “VM Network”. This should be the same network as the ESXi Host. If the ESXi host is using VLAN Tagging to separate the management network – you will need to use ESXi Web-Client to change the VLAN Tag value for “VM Network” for this to functional. In my case I configured a VM network called “Management” on all our hosts for this purpose.

From this point onwards what you will see is status bars as the vCSA is uploaded to the VMware ESXi host, and configured.

STAGE TWO: POST-CONFIGURATION

Note: In this stage I configure the time configuration and the SSO settings.

1. Next configure the preferred time synchronisation process. Typically, all VMs get their time from the underlying VMware ESXi host – which in turn is configured for an external NTP time source. Enable the SSH access if you intend to use the new vCenter Server High Availability function.

2. Next we configure the new vCenter for New York to use its respective PSC installed and its SSO settings configured earlier

3. Review the configuration and click Next and Finish

New York: Join PSC to Microsoft Active Directory

Joining vCSA to Active Directory Domain

1. Login to the vSphere Web Client as administrator@vsphere.local

2. Navigate to Home >>> Deployment >> System Configuration

3. Under System Configuration, click Nodes

4. Under Nodes, select the PSC and click the Manage tab

5. Advanced, select Active Directory, and click Join

Note: The OU component here is optional, but if used the OU must be referred to using the LDAP format. vCenter does NOT need to be joined to the Active Directory domain, as its participation is controlled by the membership of the PSC with which it configured.

Delegating Responsibility to using Active Directory Groups

With a clean installation vCenter use its own internal director service called “Single Sign-On” (SSO) as the primary authentication domain. The default username is administrator@vsphere.local. It is possible add the Active Directory domain to SSO, and enable user accounts and groups from it as the logon to the web-client.

Note: If you are using the vCenter Server Appliance you must add it to the domain.

1. Login to the vSphere Web Client as administrator@vsphere.local

2. From the home location, navigate to >>Administration >>Singe Sign-on >>Configuration and select the Identity Sources tab

Note: Click the green + to update the configuration.

3. Select the radio button – “Active Directory (Integrated Windows Authentication”.

Note: This type of authentication enables the pass-though of your logged on local credentials from the Windows domain to the web-client.

4. After clicking OK, this should add the domain to the list

Next I can add in accounts to the vCenter to delegate responsibility. The best method it create a group in Active Directory called “vCenter Admins”, and populate it with user accounts from the administration team.

5. Navigate to Home >>> Global Inventory Lists >>>vCenter Servers and select your vCenter Server

6. Select the Permissions tab

Note: Click the green + to update the configuration.

7. Click Add, in the subsequent dialog box select the domain, and from the second pull-down list “Show Groups First”. Select the group created – and click Add

8. Finally, assign the “Administrator” role and click OK

Once enabled, you should be able to login with your Microsoft Active Directory domain credentials based on membership of the appropriate groups.

Enabling AD User/Groups to Manage VMware SSO

Even if you give a Microsoft AD user/group complete rights to vCenter from a top-level container – this doesn’t necessarily give those AD user/groups rights to manage SSO itself. This handled by different subset of permissions and rights. Typically, SysAdmins like to do this delegation to prevent situations such as loosing, forgetting or getting locked out of VMware SSO, which then prevents further administration. VMware SSO has its own systems of password policies and lockouts.

1. Login to the vSphere Web Client as administrator@vsphere.local

2. From the home location, navigate to >>Administration >>Singe Sign-on >>Users & Groups

3. Select the Groups Tab and Select the Administrators group

4. Click the Add Member icon which resembles the figure of person with small green +

5. From the Domain and User and Group pull-down lists – select your Microsoft Active Directory Domain, and Show Groups First

6. Locate your delegated user/group from the list, and click the Add button

Repeat Above for New Jersey

The deployment of the subsequent vCenters and PSC follows a very similar workflow to the first that established the VMware SSO domain. There are of course some notable differences.

Most significantly:

• The Subsequent PSC for New Jersey joins rather than creates the VMware SSO domain – providing the FQDN of the PSC that initially created the SSO domain together with the username/password to access it:

Then the administrator will asked if you wish want to join the existing site (NewYork) or create a new site in this case called “NewJersey”

• The Subsequent vCenter for New Jersey (vcnj.corp.local) joins its PSC relative to their site location (pscnj.corp.local)

• The PSC for the New Jersey location will need adding to the Microsoft Active Directory Domain

Note: As both vCenters are part of the same VMware single-sign-on domain and part of the same Microsoft Active Directory Domain – there’s no need to grant rights to the vCenter Admins group – neither does the SSO Password Policy need to be modified – however, the local password expiration of the “root” account still applies – and in lab environments you may wish to turn that off.

At the end of the process I had two vCenter side-by-side in Enhanced Linked Mode: