This article will help you get vRA installed, and configured. I am doing this so that I can work with the SovLabs plug-in that connects Veeam Backup & Replication to vRA – I will detail that in another article in the near future. Getting vRA working first is enough work!
This article will help you get vRA working in your lab. It is not a production ready install – for example it is not cluster.
I am using vRA 7.5 with vSphere 6.7 Update 1.
vRealize Automation is a portal system. It has a very wide range of features / flexibility in that portal. It can also be connected to other systems. For example, I am going to connect it to vSphere so that provisioning of virtual machines can happen. This can be done with a range of different approvals, and notifications. Virtual machines can be deployed and decommissioned as well. There are plug-ins that can be purchased to make it easier to connect to other systems. For example one such plug-in I am familiar with enables connection to Veeam Backup & Replication. What does that mean? When a VM(s) is provisioned it is automatically added to a backup job. It also adds to the portal the ability to restore files and VMs.
Here is some stuff to get done before you start.
- Be sure to check out the release notes.
- Get the bits – from here.
- We need an IaaS service account, which should be a domain users, but with local admin on the IaaS VM. It also needs dbo permissions for the IaaS database. For the install sysadmin is also required.
- We need an IaaS Windows VM. In my lab it is called ias01.thewhites.ca, and has 2 vCPU and 4 GB of RAM.
- We need to know the SQL server info.
- You will need to supply a passphrase for the database, and make sure you know what it is. It should be used across the install. This passphrase cannot have a double quotation mark (“) in it.
- We need a vSphere End Point service account.
- We need an FQDN for the vRA appliance, and make sure it is already done and resolvable. I am using vra01.thewhites.ca.
- We need a FQDN for the IaaS VM. Again make sure it is resolvable before it is used. I am using ias01.thewhites.ca.
- Time is important, so make sure your windows domains, and hosts are pointing at the same time source.
- We need a vRealize Automation admin password, make sure it is complex and you know what it is. It cannot have a trailing equal sign (=).
- On the SQL server, and the IAS you may need to make some Distributed Transaction Coordinator changes – use this article to help.
Install Process – Appliance
The deploy of the appliance is pretty standard. Use the HTML5 client and deploy the OVA. On the customize template screen you will need to add the root password, as well as the VM name and networking info.
After the screen is the summary.
It doesn’t take long to deploy the OVA.
If necessary, power on the appliance.
Next we access the appliance at https://fqdn:5480 and log in as root and our new root password. Once we log in a wizard pops up.
- We approve the EULA and we see next deployment options.
- The default is good, minimal install and IaaS. So one appliance and one Windows VM.
- In our next screen we can download the agent to do our IaaS but we also make a decision and do some config for time.
- You can see in the next screenshot how I configured time.
- For the NTP source, you can change the .ca. to .us. if you are working in the US.
- Us the green + to add addition NTP sources.
- Use the Change Time Settings button at the bottom to make your changes.
- We cannot use the Next button until an IaaS machine is talking to vRA.
- Now you must log into your IaaS machine and execute the MSI that we downloaded.
- In the first serious page, you need to enter your vRA address and more.
- Note the full FQDN and 5480 I used above?
- After you have the credentials entered, you use the Load button to pull in the finger print. Then use the checkbox to accept it.
- Next we need to specify our IaaS service account.
- Once you hit Next it is installed and a moment later you will see it in the Appliance setup.
- And it has enabled the Next button too.
- Next we are on a new page. But, we need to be on the IaaS machine now for this page so log out.
- Log back on the IaaS machine.
- The wizard starts up but is on the next step now. Use the Run button to see if the VM has the necessary prereq’s to be used as a IaaS machine.
- In my lab the check took not too long.
- When I do the Show Details I see a long list of things with check-marks and few without. So I use the Fix button.
- The fix includes a restart. Before it restarts I see that my status now has a green check-mark so that looks good. After the restart I log back in and do the Run again.
- As you might guess, I got a green check-mark so I do a Next.
- I am prompted next for the vRA appliance FQDN.
- Next we need to assign a strong password to the default tenant account.
- Now we need to do a few things with the IaaS host. FQDN, admin account, and a database security password.
- Next is our database stuff.
- Remember that our IaaS service account has sysadmin rights on the SQL server? That is necessary.
- Next we deal with Distributed Execution Managers but that screen is already to go.
- The next screen is the Agents screen. It suggested I had a network issue between the appliance and the agent. I did not think so so I used the Validate button and it ended up saying all good.
- In the Appliance certificate screen fill in the fields that need it, and hit the Save button. This will generate a new cert for you.
- In Web certificate screen fill in the same fields again, and hit the Save button.
- On the next screen, titled Validation, you can choose to validate or not.
- But I choose to Validate. Will take some time, but I do not want to install again.
- If you have any fail, expand them, and do Previous until you get back where you can fix. Than validate again.
- Next we are prompted to take snapshots. Or do a backup. I am actually doing a backup.
- Some useful info if we have an issue! But I go for the Install button.
- And after maybe 30 – 40 minutes I see this.
- Next we need to submit our license.
- After that we are asked about joining the Customer Experience Improvement Program and I am a big believer in that so I do.
- Next you have the option to configure some initial content which is very good for a proof of concept. I am not going to do that and just continue.
So vRA is now installed. That is good indeed.
Default Tenant Access
Now we need to configure access to the default tenant. This will allow the config of the ‘inside’ of vRA to progress.
BTW, the default tenant was created when we configured SSO.
- Log in at https://vra_fqdn/vcac
- Use the administrator credentials we did with SSO.
- Click on the blue vsphere.local.
- Then change to the Local Users area.
- Local users are tenant specific and can only work within the tenant they are created.
- Create a user and start it with the green +.
- The passwords do need to be complex!
- On the Administrators tab you can assign local users that you have created to the different roles of Administrator or IaaS administrator. The IaaS admin is responsible for creating and managing endpoints.
You now have vRA installed and working. In my next article I will connect it with vSphere and make it ready for provisioning.
- The really useful stuff for the install can be found in Chapter 2 of the install guide – you can find it here.
- Eric has a nice outline for the vRA 7.0 simple install – here it is.
- vRA log locations – KB article. BTW, when you need to look at the Management agent log, look first at the last line in the Error log – it was very helpful to me at one point.
- MSDTC issues help – here.
- Early in this process I had an issue. The Time Offset did not fill. I solved it when I looked in the Management Agent log files – the one called Error and found I had misspelled the vRA appliance FQDN. So had to clean out the agent, and delete the appliance and do this again.
- Another issue I had, in the validate step, was my MSDTC was not configured correctly. This was for the IaaS machine and the SQL server. So I had to fix that. S
o for Win2K16 that was MSDTC -uninstall, reboot, MSDTC -install, MSDTC –resetlog, confirm the install was OK in the Application event log, then make sure the Distributed Transaction Coordinator service is set to automatic, and running. Then make sure the MSDTC can get through the Windows Firewall. However, that made no different.Still had the issue, than a friend shared this link. It helped!
We have gotten vRA working, and next we will integrated with my lab vSphere. So I have a portal now, and soon will be able to provision and decommission VMs as necessary. Very cool stuff. I would like to thank Kim Delgado – Customer Success Architect for VMware – for the help, as well as Brian Baggett – Cloud Automation Architect – SovLabs.
I will be working on integration of vRA and vSphere, next with Veeam after that.
=== END ===