I have recently come across an issue in our vRA 7.3.1 environment where the AD sync started failing all of a sudden.
The error message looks as in the screenshot below:
This error basically means that vRA is not able to communicate with the Active Directory (Lets say my Domain is dallas.com and my vRA appliance hostname is dc1-vcf-vra-01.dallas.com) to update the AD groups and Users for authentication.
The error also means that the vRA is complaining that the connector hostname (in this case it is dc1-vcf-vra-01) doesn’t match the Common Name (CN) in the certificate which is the FQDN (dc1-vcf-vra-01.dallas.com).
Opened a ticket with VMware support and here are the troubleshooting steps recommended so far by them:
1. /usr/java/jre-vmware/bin/keytool -v -list -keystore /opt/vmware/horizon/workspace/conf/tcserver.keystore
Check the The Common Name in the self signed cert. It will be set to node hostname.
2. mkdir /root/tmp-bkp
3. mv /usr/local/horizon/conf/flags/fips* /root/tmp-bkp ( No file named fips or starting with fips in the flags directory as FIPS is not enabled in our environment)
Install Self Signed Cert and update the keystore
5. mv /root/tmp-bkp/fips* /usr/local/horizon/conf/flags (had to skip it as I was not able to execute the above fips* command)
6. service horizon-workspace restart
Will update this post with more steps once VMware support comes back to resolve this issue.
This post details the installation and configuration of the vRealize Suite Life Cycle Manager 1.2 which was recently released by VMware to automatically provision vRA components as part of their Cloud initiative.
First, Download the Life Cycle Manager ova from the vRealize Suite 2017 components and deploy it using the vCenter web client
Once the vm has been deployed and powered ON, you will have to go to a web browser to configure the appliance.
Hello Peeps, Recently I was configuring vRA 7.4 at a customer’s place and came across an issue where the vRA appliance tries to talk to the external SQL server and fails with an error.
Here is the error:
After digging into the logs on both vRA and on the SQL server, here is what was determined as the issue
The SQL server has TLS 1.0 disabled and the vRA appliance was trying to communicate to the SQL server using TLS 1.0 instead of TLS 1.2 as the client has disabled TLS 1.0 on all its windows servers.
Troubleshooting steps tried:
Tried enabling TLS 1.0 and its Ciphers on the SQL server with no success
Checked with the Firewall team and they said that there is no firewall between the vRA appliance and the SQL server
Tried this in a different environment and it worked fine, just doesn’t work in this particular environment.
Looks like the issue was with the SQL server and its Service Pack. SQL Server 2012 needs SP3 or higher to accept TLS 1.2 protocol. As soon as I upgraded my SQL server to SQL 2012 SP4, the communication worked fine and the vRA appliance was able to talk to the SQL server!!
Hope this helps in case you come across this issue.
I have been thinking of writing this post for a while and here you go…
In vSphere 6.0 U2, you can have an External PSC or an Embedded PSC. The below process is to add an External PSC to the Active Directory Domain.
Login into the vCenter server, go to Administration tab, go to System Configuration –> Nodes and click on the PSC node you want to add to the domain.
once credentials are provided, click OK to proceed.
Note that the only way for you to know that this process is complete is that you get no error and there is no entry in the recent tasks tab in the vSphere web client. If that is the case then the domain add is successful.
Now, you will need to reboot the PSC
In a similar way, you can add the remaining PSC’s to the domain and finally, you will need to add the Identity source to the vCenter server itself under single sign-on
Recently, I came across an issue while configuring a new instance of VDP 6.1.8 appliance while performing vCenter Registration to the vCenter appliance 6.5 with an external Platform Services Controller.
below is the error message I have been getting
I have provided the administrator account user credentials to the VCSA (vCenter server) with the default ports but still received the error.
Upon some deep troubleshooting, found out that the SSO server is the Platform Services Controller (PSC) since my environment had an external PSC and here is how you resolve this issue:
De-select the checkbox “Use vCenter for SSO authentication”, and add the Platform Services Controller hostname/IP in the new SSO entry line.
Now, you can test the connection and it will be a success
This is how the issue was resolved. Hope it helps someone out there.
This is with VDP version 6.1.8 connecting to VCSA 6.5 with External PSC
Recently, I have come across an issue with the PSC’s not joining to the domain (They disconnected from the domain automatically) after upgrading the vCenter components (PSC01, PSC02 and vCenter windows server) from 6.0 Update 2 build 3634791 to 6.0 Update 2a build 4632154 or to 6.0 Update 3b build 5326079. This issue occurred as the windows domain controller was 2012 R2 and SMB 2 was the communication protocol to the domain controller. we have to enable SMB 2 on the PSC’s for them to communicate to the domain after the Upgrade.
here is the process to enable SMB2 on the PSC’s —
login to PSC01 and run the following command to check the values