vRealize Automation (vRA) error when configuring SSO - "Trying to access remote SSO on host and port 7444, but the returned host is and port 7444."

Today I was getting the vRA error "Trying to access remote SSO on host <FQDN> and port 7444, but the returned host is <old hostname IP> and port 7444." after re-ipping the vCSA\SSO server.

More history;

When I first deployed the vcs 5.5 appliance I told the VM to use DHCP and then ran through the default config vCenter setup.

After this I realised that the VM was on the wrong network so had picked up an IP in the wrong subnet.

At this point I re-ipped the box correctly, and confirmed that forward and reverse DNS was correct, as was the self-signed SSL certificate.

Despite this, when I tried to change a vRA 6.2 server to the SSO service on the vCSA, I got “Trying to access remote SSO on host <the correct FQDN> and port 7444, but the returned host is <the old IP!!> and port 7444.”.

Fix information;

After triple checking everything (and yes, rebooting the appliance ‘for luck’!), I eventually had to resort to google, and found this article from Dec 2014;

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2096619

In it, VMware explain that a certain SSO server config file retains the old IP address\hostname after the system is renamed.

Unfortunately, the KB article refers to vCenter SSO running on Windows, and I was using the Linux-based appliance. I therefore wrote the below Linux fix instructions.

Linux Fix;

Go to the vCSA’s console in the vSphere client.

Press Enter to Login, use the username ‘root’ and the password you set when deploying the vCSA’s OVF template (if you left this blank, the default is probably ‘vmware’).

Enter this line, replacing <correct FQDN> with the actual FQDN I.e. vcs55.domain.local;

                echo <correct FQDN> > /etc/vmware-identity/hostname.txt

Once the above has been run, type the below and ensure the output shows the correct hostname;

cat /etc/vmware-identity/hostname.txt

This should all look something like this;

Once this is done, I found that no restart of either the SSO service, or the entire vCSA, was required – I did have the vCenter service down when I performed the above however.