I was working on a build this week where I ran into an interesting problem. I thought it would be worth sharing in case anyone comes across this in the wild.

Scenario

vCAC Appliance Name: vcac–01a.corp.local

vCenter Server Name: vcsa–01a.corp.local

1. Registration of vcac–01a.corp.local against vcsa–01a.corp.local:7444 was successful.
2. An attempt to reach https://vcac–01a.corp.local/shell-ui-app resulted in a redirection to https://vc–01a.corp.local:7444/tokeninfo

What went wrong?

In this case, the vCenter Server had been renamed from vc–01a.corp.local to vcsa–01a.corp.local. What you may not be aware of is that vCAC pulls the SSO url information from either:

1. /etc/vmware-identity/hostname.txt (vCenter Server Appliance or the Identity Appliance); or

2. C:\ProgramData\VMware\CIS\cfg\vmware-sso\hostname.txt (Windows SSO)

This file is not automatically updated when the guest name changes, so the redirect fails.

What are the implications?

Apart from this specific scenario, this is also going to raise it’s head if you attempt to point the vCAC Appliance at a Load Balancer in front of one or more SSO instances. Registration will succeed, however your vCAC Appliance will then connect directly to the value inside the hostname.txt file – bypassing the Load Balancer.

How do we fix it?

Updating the file with the new hostname allows us to overcome this for the rename scenario. There are some additional steps required for passing sessions through a load balancer which will be dealt with in a later post.