I recently came across an issue where the vRealize Life Cycle Manager 2.1 has the Deploy option greyed out in SDDC Manager in VCF 3.10.x and the issue looks like the screenshot below:
The issue happened as we were using VLAN Backed Network for vRealize products instead of AVN in this version of VCF
The solution is as follows:
Log in to SDDC Manager by using a secure shell (SSH) client, use the account vcf to login into SSH session
Type su to elevate to root and enter the root_password.
Enter the following and press enter.
echo "feature.vrealize.enable.non.avn.deployments=true" >> feature.properties
chown vcf:vcf feature.properties
chmod 644 feature.properties
When prompted enter Y to confirm. vRealize Suite deployments using SDDC Manager will now be deployed to VLAN backed networks
I have recently come across an issue in our new VCF 3.10.x build that when we try to deploy the VRA using SDDC Manager, we get an error that the AD Account we have provided can’t validate with the Domain.
The warning is as shown in the picture below:
Note That I had to change a few details and also blur some details from my environment due to privacy reasons.
The Error basically states that VRA is not able to communicate to my domain lab.com with the service account lab\svc_vra_adm because it is trying to contact test.lab.com instead of lab.com Domain
test.lab.com is a DNS Zone in our actual root Domain lab.com and all our VRA Appliances have the host records added to test.lab.com instead of the root domain.
After multiple tries and VMware support, we got to know that VRA (7.x and 8.x) doesn’t support explicit identification of the Active Directory domain name. The kb article which mentions this issue is
The Solution is to make sure that the host records of your VRA is the same as your ‘Actual‘ Domain, in this case lab.com and then retry the validation using the SDDC Manager with the same service account lab\svc_vra_adm
Next, We Create a New Environment and then create an New VRA environment using vRLCM
Go to Home and Click on Create Environment to get started
Agree to the EULA, click Next
Enter the License
Select the Certificate which we have generated before and click Next
This is where things have gotten tricky in this version as we have multiple options to define the VRA environment including the windows template to create new vms themseleves.
let us go step by step process
Under Product Properties, provide the windows server username and password which you want to access after the box has been provisioned using the windows template.
In the above configuration, We have only 3 VMs being deployed in VRA Simple Configuration.
VRA Primary Appliance
VRA DB server (Database server)
VRA IAAS web server (this contains iaas-web server, iaas manager, iaas DEM Worker and proxy-agent-vsphere )
Once all the Product details of VRA are put in, we will proceed to the precheck phase.
Next, we click on Validate & Deploy option to deploy the vms
Make sure you disable UAC in the windows template and then click on Validate & Deploy option to continue.
NOTE: The re-validation took more than 30 mins in my lab to complete. Not sure why it took a lot of time, but I suggest you all to be patient during this process as there is no way to speed it up.
NOTE that at this point, I haven’t installed SQL Software on the SQL Server, but VRSLM has created an windows server for both the db and iaas install. I will have to install SQL Server on the db windows VM and see how it goes.
This Post is pending and I will be updating it soon once I have some clarification on if I need to install and configure the SQL software in the vRA SQL server windows machine or will the scripts do it if I provide the SQL ISO file. Stay Tuned …….
This Blog Post is to Install & Configure vRealize Life Cycle Manager 2.1 in my lab environment.
The reason why I had to install vRLCM 2.1 is to install and configure vRA 7.4/7.5 in my environment.
Deploy the vRLCM OVF file in the lab and the below screenshots will show the configuration after deploying the appliance.
After you login into the vRLCM appliance, the self help starts and below are the screenshots.
Now, Let us change the root password of the appliance from the settings option -> System Administration and click on SAVE to move ahead with the configuration.
Next, we configure NTP Servers and DNS Servers from Servers and Protocol option
Next, we configure the Product Binaries (Where we download the vRA 7.x version using the my vmware account or using the Product Binaries option)
In my case, I have downloaded vRealize Automation 7.6 version to install and configure in my lab.
We will continue with the vRA 7.6 configuration below.
First, Let us configure the Certificates in vRLCM so that the certificate can be used to Deploy the components through vRLCM.
Click on Certificate Management on the left hand side, I will be Generating an CSR as I would like to use my AD CA Signing Authority to generate an Certificate for this instance.
Once the CSR is generated, use it to create an Cert and then download the Cert chain which will be in the .p7b format. Use this cert chain to create an pem file.
In my case, I used Cygwin in windows to create an pem file, but with an .cer extension. I had to open the csr file generated which contained the key certificate and then open the generated .cer file by using Cygwin to input the Domain Certificate (in this case, its the vrlcm certificate from the CA, Intermediate CA and Root CA into the Import field and imported it.
NOTE: These are the links which helped me to use Cygwin on my Windows machine to generate the PEM file from existing cert.p7b file
Use the Command ” openssl pkcs7 -inform PEM -outform PEM -in certnew.p7b -print_certs > certificate.cer ” after copying the certnew.p7b file into the C:\cygwin64\home\username directory to generate a new .cer file
Next, We create a Data Center
Next, We Add vCenter Server to this Data Center we created
Since, This Post was getting too big, I have decided to split it into 2 parts. The Installation of vRA and its configuration is explained in the next part.
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.
VMware support confirmed that the Common Name (CN) in the self signed Certificate has the FQDN and to follow the steps in the KB article https://kb.vmware.com/s/article/2145268 to check the postgres database for the connector and there we found the issue and rectified it.
From the KB 2145268, I followed the below steps:
Log in to each appliance and type hostname.
If the hostname is shortname and not FQDN, update it from VAMI.
Ensure that the following tables display all the appliances with the FQDN.
Connect to the database by running this command:
su - postgres /opt/vmware/vpostgres/current/bin/psql vcac
Set schema as SaaS by running this command:
set schema 'saas';
Verify the appliances hostnames in the ServiceInstance table by running this command:
select * from "ServiceInstance";
If the hostnames in the table are short, update the hostnames to FQDN by running this command:
update "ServiceInstance" set "hostName"='<new_hostname>' where "id"='<row_id>';
Verify the appliances hostnames in the Connector table by running this command:
select * from "Connector";
If the hostnames in the table are short, update the hostnames to FQDN by running this command:
update "Connector" set "host"='<new_hostname>' where "id"='<row_id>';
I had to substitute new_hostname as the FQDN of my vRA appliance (my case dc1-vcf-vra-01.dallas.com) and the row_id is the ID of the row in which the host name is displayed.
Once I made the modifications in the ‘ServiceInstance’ and ‘Connector’ and restarted the vRA appliance, my AD Sync started to Sync.
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