I have this thing where when I deploy things in my lab at home I do it manually and without reading documentation. I find that by doing this I will run into common problems that happen during deployments. The first time I installed VCAC at home just completing the pre-reqs were a pain and took a ton of time but I learned alot more about roles and features that are required than I wanted to.

This is something that I think everyone should do but my second install is based on documentation. I found this post from the PowerCLI blog that saved me a ton of time and if I could find the person that did this I would buy them a beer and a plastic barbie mobile

 

http://blogs.vmware.com/PowerCLI/2014/09/vcac-6-1-pre-req-automation-script-released.html

 

I would hope that in future releases that this would be a part of the install but I’m glad that someone found an issue and wrote something to solve it.

This problem pissed me off for a while last night when I was trying to rebuld my lab after being on the road for a while.

I almost always deploy a VCSA and configure it with defaults on the wizard and then customize the IP, Hostname, Time, etc later. This finally came back to bite me and it was only with vCAC.

I know to regenerate the certificates after setting the IP and hostname but I didn’t realize that there are entries on the VCSA that don’t update.

When trying to join the SSO instance on the appliance from the vCAC appliance I was greeted with the following extremely generic message.

2014-11-05_10-56-48

I have had this happen before and I almost always assume it’s time or DNS so I checked the consoles

2014-11-05_11-01-31

Welp….I started going through the vCAC logs but I wasn’t able to find anything due to it not being really configured.

With a bit of googling I found this

http://brianragazzi.wordpress.com/2014/09/09/vcac-6-1-sso-configuration-gotcha/

I decided to hit the SAML Metadata URL to see if something was broken. I have seen it before not matching

https://192.168.1.220:7444/websso/SAML2/Metadata/vsphere.local

2014-11-05_12-22-20

That is not my hostname and is the old DHCP address

So I started to dive into the VCSA and check out the logs

Under /var/log/vmware/sso I was going through the vmware-identity-sts.log file and found the following messages

2014-11-05_11-05-44

That appears to be the original IP and not the 192.168.1.220 that I have in DNS. After verifying that the IP was correct and that forward and reverse lookups were working…I had to start looking at the VCSA itself.

Since the error was in the vmware-identity log I decided to look in /etc/ and there was a sub directory for vmware-identity. Going through that I found these 2 files

2014-11-05_11-17-29

And when you cat out these files you find the old entries.

2014-11-05_11-18-11

a

You need to stop vpxd and idmd because it will just keep re-writing this file over and over which I didn’t notice for a good 2 minutes.

2014-11-05_11-25-20

2014-11-05_12-13-10

Now go ahead and edit the files. I didn’t want to go through and do it by hand so I just used this string

sed -i s/192.168.1.18/192.168.1.220/g sso.properties

For the hostname file you actually want your fqdn instead of the ip

sed -i s/192.168.1.18/vc5.lab.local/g hostname.txt

That will go through and replace 192.168.1.18 with 192.168.1.220. So just change the values to your IPs / hostname and you are good to go

Go ahead and start the services again

2014-11-05_12-15-03

Let’s check the SAML metadata by heading to https://192.168.1.220:7444/websso/SAML2/Metadata/vsphere.local

2014-11-05_12-20-09

Looks like the updates took place!

Try to join vCAC to SSO again

2014-11-05_12-18-06

 

Huzzah! I can’t wait for something else to break.