Getting started with VCF Part 3 – vRealize Automation Prerequisites

Continuing on my journey of ramping up on VMware Cloud Foundation (VCF), my next step is to go through the deployment of vRealize Automation. This is again done via the vRealize Suite Lifecycle Manager (vRSLM). We’ve already seen how to deploy out vRealize Operations through vRSLM in part 2. And in part 1, we saw the initial VCF management domain deployment. In this post we will take a detailed look at what needs to be put in place in order to be able to deploy vRealize Automation (vRA). Now, there are quite a number of prerequisites needed before we can even begin with the deployment. This will be the primary focus of this post, ensuring that we get everything correctly in place before we start on the deployment of vRA.

Download the appropriate vRA bundle

Just like we did when using vRSLM to deploy vROps, we have to locate the correct version to pull down. This is available in the VCF 3.9 Release Notes. We will be deploying vRealize Automation v7.6 in this post.

Apply the Prerequisites

There is a list of 7 installation prerequisites in total for vRA. Some of them are very straight-forward, others are quite a bit more complicated as we shall see. Let’s start with the simpler requirements.

Step 1. Active Directory Account for vRA Service

vRA requires an Active Directory account for certain services. This account needs to be created with the ability to join computers to AD Domain. More details on how to correctly configure this account can be found in the VCF 3.9 planning guide here.

The account also needs to be added to The Operator Account group, as well be delegated to Join a computer to the domain.

Step 2. License Key

vRA required a license key. This should be added to the Administration > Licensing section of the SDDC Manager. My current set of licenses in my lab is now similar to the following:

Step 3. Network Configuration

There are a significant number of virtual appliances and VMs that will be deployed as part of vRealize Automation. If the vRA components are being deployed to a network segment that is not same as the management components (e.g. SDDC Manager), you will need to ensure that the vRealize network is routable to the management network.

Step 4. DNS & IP allocation

The following set of appliances/VMs deployed as part of vRA will require FQDNs and IP addresses.

  • vRealize Automation appliances: 3 + 1 x Load Balancer Virtual IP = 4
  • vRA IaaS Web Server: 2 + 1 x Load Balancer Virtual IP = 3
  • vRA IaaS Manager + DEM Orchestrator: 2 + 1 x Load Balancer Virtual IP = 3
  • vRA DEM Worker: 2
  • vRA Proxy Agent: 2
  • MS SQL Server for vRA: 1

This are a total of 15 FQDNs and IP addresses that need to be allocated before starting. A full list can be found in the VCF 3.9 planning and preparation guide. I’ve omitted the vRSLM and the NSX Edge since these were already deployed when we rolled out vROps in part 2. Note that the Load Balancer Virtual IPs do not require a new appliance or VM; these Virtual IPs are stood up on the NSX Edge.

Those are the simpler pre-reqs to get sorted. Let’s now focus on the more complicated pre-reqs to get vRA deployed in VCF.

Step 5. MS SQL Server

vRealize Automation has a requirement for a SQL Server database to store its IaaS components. This needs to be manually deployed and configured before vRA can be rolled out. The full list of instructions are here in the VCF 3.9 Planning and Prep Guide. In my lab, I used a virtual machine with Windows Server 2016 and SQL Server 2016. There are a number of posts already which describe how to provision SQL Server 2016 step-by-step, so I won’t cover there here. However, I will spend a little bit of time on the additional tuning required. You will also require MS SQL Severe Management Studio installed to make the necessary configuration changes.

5.1 Assign vRA service account SQL Server sysadmin role

vRealize Automation needs to create and run scripts on the SQL Server database. Thus this permission is needed. Details on how to implement this prerequisite are found here.

5.2 Configure Distributed Transaction Coordinator (DTC)

This is required to coordinate transactions between vRA and SQL Server. Details on how to do it are found here. The MSDTC is found in the Component Services. The MSDTC security settings should be changed from the defaults which are show below, so as to allow Network DTC Access, allow Remote Clients, and both inbound and outbound Transaction Manager communication:

5.3 Enable Firewall access between MSDTC, SQL Server and vRA

One new inbound firewall rule is needed, and some inbound firewall rules need to be amended to allow vRA speak to the MSDTC and SQL Server database. These steps are found here. Once configured, it should look something like this:

5.4 Registry Settings

We need to create a few/modify registry entries, which can be done from PowerShell. These are the commands needed. Alternatively you can use the UI driven tool, regedit.

Set-ExecutionPolicy Unrestricted

Set-ItemProperty -Path ‘HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System’ -Name ‘EnableLUA’ 0

Set-ItemProperty -Path ‘HKLM:\System\CurrentControlSet\Services\TCPIP6\Parameters’ -Name 'DisabledComponents' -Value 0xff

5.5 Create and Configure the SQL Server DB

A new database needs creating, called vRADB01. After creating the vRADB01 SQL database, a few modifications/tweaks are needed on the SQL Server Database itself. These are setting the Recovery Model to Simple, setting to an earlier compatibility level (either 100 or 120), allowing snapshot isolation, and finally turning on Read Committed snapshots. These can be found in the Options page when creating the database. Here is a screenshot taken from my database, highlighting the changes. Full details can be found here.

That is the SQL Server database setup. Let’s now look at the OVA template that will be used for the IaaS image, that will be used by 8 VMs during vRA deployment.

Step 6. IaaS Template OVA

This is the OVA template that will be used by the vast majority of vRA components when it comes to the deployment. It will be used by the web servers, proxies, managers and DEMs (DEMs are the Distributed Execution Managers, responsible for the executing provisioning and deprovisioning tasks). There is quite a bit of setup, so let’s step through it. Most of the instructions can be found here.

6.1 Virtual Hardware

The virtual machine will need 2 vCPUs, 8GB Memory and at least 50GB of virtual disk. It should also be configured to use the VMXNET3 network driver.

6.2 Operating System requirements

I used a Windows Server 2016 Guest OS for my IaaS template OVA. The Internet Explorer browser will need to have the Enhanced Security Configuration feature disabled. The OVA should also have Remote Desktop Connections enabled. These can be done via Server Manager > Local Server as shown below:

6.3 Registry Settings

We need to make similar registry changes to what we did on the SQL Server VM, which again can be done from PowerShell. These are the commands needed Alternatively you can use the UI driven tool, regedit. These can be found here.

Set-ExecutionPolicy Unrestricted

Set-ItemProperty -Path ‘HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System’ -Name ‘EnableLUA’ 0

Set-ItemProperty -Path ‘HKLM:\System\CurrentControlSet\Services\TCPIP6\Parameters’ -Name 'DisabledComponents' -Value 0xff

6.4 Java Runtime Environment (JRE)

A Java Runtime Environment (JRE) needs to be installed. This will need to be downloaded from Oracle. Today, it seems you need to create an account with Oracle in order to pull a JRE down from their site. I downloaded version jre1.8.0_241.

6.5 Environment Variables

Once the JRE has been installed, a new environment variable needs to be created.

The path to the Java binary should also be added to the system path. To do that, you simply edit the current path environment variable of the VM and add it as follows:

If you type in java.exe -version from PowerShell or the C:\ prompt, it should return the version to you.

6.6 Microsoft Source Path access

This involved copying a folder (\sources\sxs) from the Windows Server 2016 install media to the C:\sources\sxs on the OVA template. Once this has been done, the registry needs to be updated, so that entry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Servicing\LocalSourcePath points to the location of the installation files on C:\sources\sxs.

6.7 Enable Secondary Login with automatic startup

This can be done from the Services tool.

6.8 Enable DTC Network and Security options

This step is *not* in the guide, and should be taken care of by vRSLM. However, one of solutions architects said that I could also go ahead and make these changes before I convert the VM to an OVA. Just like we did with the SQL Server in part 5.2, launch Component Services and set the values for Distributed Transaction Coordinator (DTC) Network and Security properties as described in that section.

6.9 Join Active Directory

The final steps are as follows:

  1. Reboot the VM
  2. Join the VM to Active Directory using the vRA Service Account setup previously
  3. Verify that you can login withe vRA Service Account
  4. Shutdown and Power off the VM

6.10 Convert template to an OVA

To convert the powered off VM to an OVA, you simply use the OVFTool, which is downloadable from My VMware. Ensure you use the correct version of OVFTool with your vSphere Infrastructure or you may get some weird cURL errors. OVFTool version 4.3 seems to work well with vSphere 6.7 U3. Here is the command I ran to convert the VM to an OVA that can be used by SDDC Manager/vRSLM later on:

Step 7. Certificates

Yes. I left the best until last – certificates. There is quite  bit of work needed here. First, we are going to use one of our Windows hosts and give it the role as CA server. Then we will connect our SDDC Manager to that CA. Finally, we will generate a certificate chain for our vRA appliances and VMs that need it, and pass that off to vRSLM which it will use when deploying our our vRealize Automation environment.

7.1 Creating a MS Windows Active Directory CA server

You can use other Certificate Authorities (CA) of course, but this is what I used in my lab as it was what I had to hand. I setup a Microsoft CA. You will need to refer to the appropriate MS documentation to do this. One of our architects also told me that, whilst not called out in the documentation, he includes all these Active Directory Certificate Services.

Once the CA has been created , a certificate template will need to be created, which will be referenced from SDDC Manager later. The steps to create the template can be found here.

Note that the Microsoft CA also needs to have an (IIS) web server running. With the IIS Web Server, you need to ensure that Basic Authentication is Enabled.

7.2 Configure Certificate Authority in the SDDC Manager

If everything is working, than you should be able to connect to your CA server and template from SDDC Manager, as shown here. Details on the steps can be found here. Once you have clicked ‘accept’ when the CA certificate details are displayed:

7.3 Generate a Private Key and Certificate Chain for the vRA appliances and VMs

To generate the private key and the certificate chain, you will need to open a shell to the SDDC Manager as the vcf user, become superuser and create the certs. This is the flow, but obviously you will be using your own values in many places. Note that both the component short-name and FQDN should be added. Full details on how to generate the certificates can be found here.

root@vcf-sddc-mgr-01 [ /opt/vmware/vcf/operationsmanager/scripts/cli ]# ./

Certificate generation menu:
1) generate_csr
2) generate_certificate
#? 2

Enter the resource type [vra]:

Currently, automated certificate generation is supported using Microsoft CA.

You must configure/update the CA configuration from the SDDC Manager UI before proceeding \
with certificate generation.

Are you sure you want to continue with certificate generation(y/n)? y

You are about to be asked to enter information that will be incorporated into your certificate request.

There are quite a few fields, for some of the fields there will be a default value, press \
enter key if you want to keep the default value.

Country Name (2 letter code) [US]: IE

State or Province Name (full name) [California]: Cork

Locality Name (eg, city) []: Cork

Organization Name (eg, company) [VMware Inc]:

Organizational Unit Name (eg, section) []: HCIBU

Common Name (e.g. server FQDN) []:

Key size [2048]:

Key algorithm [RSA]:

You are about to be asked to enter the the subject alternative names (SANs) to be included in the certificate.

Please enter the SAN one after another and enter 'done' once you have entered all the SANs.

Enter SAN : vcf-vra-app-01

Enter SAN :

Enter SAN : vcf-vra-app-02

Enter SAN :

Enter SAN : vcf-vra-app-03

Enter SAN :

Enter SAN : vcf-vra-dem-01

Enter SAN :

Enter SAN : vcf-vra-dem-02

Enter SAN :

Enter SAN : vcf-vra-web01

Enter SAN :

Enter SAN : vcf-vra-web02

Enter SAN :

Enter SAN : vcf-vra-mgr01

Enter SAN :

Enter SAN : vcf-vra-mgr02

Enter SAN :

Enter SAN : vcf-vra-alb01

Enter SAN :

Enter SAN : vcf-vra-mlb01

Enter SAN :

Enter SAN : vcf-vra-wlb-01

Enter SAN :

Enter SAN : vcf-vra-prx01

Enter SAN :

Enter SAN : vcf-vra-prx02

Enter SAN :

Enter SAN : done

List of SANs entered to be included in the certificate:


generating certificate...

Enter the file path to copy the private key file [/tmp/private_key.pem]:

Private key content is written to file: /tmp/private_key.pem

Enter the file path to copy the csr file [/tmp/csr.pem]:

csr content is written to file: /tmp/csr.pem

Enter the file path to copy the server certificate file [/tmp/server.pem]:

Server certificate content is written to file: /tmp/server.pem

Enter the file path to copy the server certificate file [/tmp/rootca.pem]:

Root CA certificate chain content is written to file: /tmp/rootca.pem

When we return to the vRA Deploy in vRSLM, we will need to copy and paste the contents from the private key private_key.pem and the Server certificate (chain) server.pem files.

That now completes the prerequisite steps. We are now ready to have vSRLM / SDDC Manager take us through the vRealize Automation deployment, which will roll out 11 appliances and VMs, and automatically configure them. We will look at that, and how we can monitor and troubleshoot the deployment, in an upcoming post. Then we look at commissioning some hosts and creating our first workload domain.

A big thank you to Brian O’Connell and Ken Gould for helping me with some of the finer points of the IaaS Windows Template – thanks lads!

For further references on how to deploy vRealize Automation from VMware Cloud Foundation, please check out the official 3.9 VCF documentation links here:

2 Replies to “Getting started with VCF Part 3 – vRealize Automation Prerequisites”

Comments are closed.