With the release of vCAC 6.1 there have been some great improvements in the setup of the clustered vCAC appliances - none of the previous copying of configuration files between appliances - just a simple wizard to do it all for you. In my opinion this is superb.
You'll need to have deployed a load balancer of some sort - vCAC 6.0 build-out to distributed model – Part 3.1: Configure Load Balancing with vCNS or vCAC 6.0 build-out to distributed model – Part 3.2: Configure load balancing with NSX
Deploy vCAC Appliances
Deploy three vCAC appliances by running through the OVF deployment wizard, two to be configured as vCAC Appliance nodes and one to be the external vPostgres database.
Posts in this series
- vCAC 6.0/6.1 build out to distributed model: Deploy the Identity Appliance
- VCAC 6.0 build-out to distributed model – Part 1: Certificates
- vCAC 6.0 build-out to distributed model – Part 2: vPostgres
- vCAC 6.0 build-out to distributed model – Part 3.1: Configure Load Balancing with vCNS
- vCAC 6.0 build-out to distributed model – Part 3.2: Configure load balancing with NSX
- vCAC 6.0 build-out to distributed model – Part 4: Deploying and clustering a secondary vCAC Appliance
SSO is a fundamental requirement when deploying vCAC, whether for a distributed or simple installation. This walk through goes through the deployment and configuration of the vCAC Identity Appliance, which provides a stand alone SSO instance for vCAC.
Some of the posts in this series are completed with vCAC 6.0.1, others will be with 6.1. Where there are differences I will aim to point them out!
Deploying the OVF
Deploying the OVF is very simple, just run through the wizard:
The appliance will perform a reverse lookup to get it's hostname - if you have pre-staged a DNS A and PTR record, and have a reservation set for the VM. If you statically assign an IP address, make sure you use the FQDN in the hostname field - not doing so will cause issues with the self-signed certificates and also when you join the Active Directory domain.
The NSX Edge Gateway comes pre-armed with the ability to provide an SSL VPN for remote access into your network. This isn't a new feature (SSL VPN was available in vCloud Networking and Security), but it's worth a run through. I'm configuring remote access to my Lab, since it's often useful to access it when on a client site, but traditional VPN connections are often blocked on corporate networks where HTTPS isn't.
So recently I came across an error in the vSphere windows "fat client" when trying to use the search field.
So a quick look at the VMware knowledge base brought up the following article
So I went ahead and followed the KB artricle and then tried to search again.. the following error was generated.
Also while logging into the vSphere web client the following error appears.
I had access to the SSO components etc.. but vCenter and related objects were null, now I have seen this issue before when the in use domain account has not been added to the vCenter as an admin so I re-logged with the [email protected] account (which had no errors when logging in) and browsed through to the vCenter server permissions tab and I could see all of the appropriate accounts listed with the correct permissions.