Installing Minimal vRA 7: Part 2 Deploying The vRA Appliance

Now that we know what we’re aiming for we can get the really easy bit out of the way right now.  Deploying the  vRA 7 Virtual Appliance.  Throughout this example I’m using the svc-vra-admin account created in step 1 as it has rights for pretty much everything.

NOTE: My lab was running vSphere 5.5 when I did this blog post so screenshots below are from the c# client and NOT the Web client (yes, yes I know….).  Any additional posts after install will probably be from the Web Client and vSphere 6.0

Deployment Steps

I’m going to assume here that you have already downloaded the vRA 7 appliance OVA from VMware website.  If not, go do it now.

Step 1: Create a DNS entry for your appliance

vRA and, indeed, most other VMware products really like DNS to be set up correctly or they will behave most oddly.  Therefore, before deploying the vRA appliance you should.

  1. Log on to your server hosting DNS (in my case my labs AD).
  2. Create a new A record and associated PTR for the vRA appliance.
    1. e.g vra7.lab.local,
    2. Ensure the Create Associated Pointer (PTR) record option is ticked (if using Windows DNS).
  3. Check the new name is ping-able from within your environment.

Step 2: Deploy the OVF

With that step out of the way we can now deploy and configure the appliance.

  • Open Virtual Center and select File > Deploy OVF TemplateSnapCrab_LABVC01lablocal - vSphere Client_2016-1-5_12-5-39_No-00.png
  • The  deployment wizard will start.  Select your downloaded OVA file and continue through the steps (Shown Below).  These initial steps allow you to pick a name and location for the appliance.  My values are shown for example.  Continue until you get to the Disk Format stage of the wizard.
Select the source of your OVA file and continue…
Ignore the details and continue…
Press Accept without reading just like everyone else and continue…
Give you VM a sensible name (e.g. use your DNS name) and continue…
Select Your host / cluster and continue…
Select a resource pool if you want to and continue…
Select the datastore you want to deploy to…
  •  This next window is probably where you want to start paying actual attention to the  wizard.  The default option here is Thick Provisioned, Lazy Zeroed.  For a quick deployment and a lab setup this is silly and wasteful so ensure you select Thin Provisioned and continue…
Select Thin Provisioning and continue…
  • The next screen is the most important to get exactly right now or else there will be issues later down the line.  You’ll need to fill out:
  • Initial Root Password: Something memorable for logging in as root (Don’t Forget This!)
  • Enable SSH service in the appliance: Checked. As this is a lab we want to turn this on as we’re going to play.  If you were installing that as a production system you should leave this off for security reasons and only enable it when required.
  • Hostname: The FQDN of your appliance as its been set up in DNS. <server>.<domain>.<whatever> or, in my case: vra7.lab.local
  • Default gateway:  Your route to the internet or network for this appliance
  • Domain Name: The domain suffix of the VM <domain>.<whatever> or, in my case. lab.local
  • Domain Search Path: the NETBIOS style name of the domain all user / security accounts are contained in e.g. <Domain>.  In my case it’s just called “lab”
  • Domain Name Servers:  The IP Addresses  (IPV4) of the DNS server to use for the appliance.  In this example DNS is installed on my AD server so I use this IP.
  • Network 1 IP Address: the IP V4 network address you want to assign to the appliance.
  • Network 1 Netmask: The subnet mask for the appliance.

Once you’re sure all of the entries are correct for your environment continue…

Make sure all these entries are accurate!
  • Check the details are correct, click next and get the appliance provisioning into your lab.  Make sure you check the Power on after deployment option.  Saves waiting around!
Ready to deploy!  Go Make A Cuppa.
  • Wait for the VM to deploy and turn on  Once it’s up and running open up a CMD / PowerShell window and ping the appliance via it’s DNS name.  This ensures that DNS is working correctly and the appliance has successfully applied it’s network settings. If it fails here fix DNS resolution before going any further.


That’s it.  The appliance is now up and running  and it should even look like this if you go to the console and take a look.


Now you are  ready to move on to the next stage of preparing the Windows server for the IaaS install.  You can do this the easy way or the hard (but interesting way).  I learnt on vCAC 6.0.x so have a healthy distrust for the automatic pre req install. So, I did it manually first.  Only LATER did I try the automatic method and find out that it actually works…. So I present both ways.

Hard Way: Installing Minimal vRA 7: Part 3a – Manually Installing Pre-Requisites
Easy Way: Installing Minimal vRA 7: Part 3b – Automatically Installing Pre-Requisits


Installing Minimal vRA 7: Part 1 Which Version For The Lab?

Finally, after pretty much a full year of waiting VMware released version 7 of the vRealize Automation suite.  Rumour is that it’s far easier to install, more stable and bug free than before.  Given the difference between the hell that was 6.0.1 and the, much better but still poor, 6.2.2 releases I’ve had the pleasure of deploying I’m hopeful of significant progress.  Obviously I want to check it out as son as possible so this series of Blogs will be about getting it deployed in my home lab.

Installing In A Home Lab

vRA is a beast when it comes to system requirements 6.x was massive but 7 is much improved.  Gone are the requirements for a separate Identity appliance (SSO) and pSQL DB to talk to the vRA host.  Both of these as now included in the basic appliance.  It’s still beefy though so, for a 1st time I’m going to deploy the “minimal” version of vRA

So, What Does It Look Like?

The minimal install looks like this:


This is nice and simple for the lab.  We only NEED two boxes.  One vRA appliance and one Windows Box for the IaaS components, agents and SQL.

In this series of blog posts I’m going to be using a SQL server I already have as part of the lab (the same one that houses my Virtual Center DB). Therefore I’ll be interacting with three boxes that make up the install.

So, What’s Being Provisioned?

The vRA7 lab install will be made up of:

  • 1 x vRealize Automation appliance, which deploys the management console, manages Single Sign-On and houses the internal PSQL DB and Orchestrator server.
  • 1 x Windows Server box (2012 R2) for the  Infrastructure as a Service (IaaS) components.  This includes the Web Server, Model Manager Data, Manager Service (agent), Distributed Execution Managers (worker and orchestrator) as well as the agents for vSphere / vCenter etc.

What Have I already Provisioned?

  • An MS SQL Server for the IaaS Database (Server 2012).  This is already set up in my lab.
  • An Active Directory Domain with a domain already set up.  This is fr creating users and groups with relevant permissions.

What We Need To Proceed

To complete the install you’ll need:

  • 1 x vRA7 OVF file from VMware to deploy the appliance.
    • Download from the MY VMware site.
  • 1 x Vanilla Windows 2012 R2 server for the IaaS components
    • 2 x vCPUs
    • 8GB RAM
    • 60GB HDD (30GB Windows, 30GB Free for IaaS Components)
  • 1 x Licence Key for vRA.
    • It doesn’t work without one so don’t try (installs, wont log in)

Accounts And Logins Required

Before you start it’s best to create any users and groups you may require now.  vRA has some specific requirements such has insisting that the IaaS server is installed as the account that has local admin rights on the Windows Server. I have created the following users and groups that are used in my Active Directory.

User: svc-vra-admin
This is my generic service account that I create for anything vRA related.  In this case it’s used to log on and install the IaaS components as well as run the vRA services (i.e. the service runs AS THIS USER).  It’s also the account I give permissions in vCenter to have admin access for data collection later in the process.  In a real world environment you probably shouldn’t just use the one account. However, as this is a lab PoC test I have.

Member Of Groups:
vRA Administrators 
– For defining an account as having vRA admin permissions.
vRA Users – For defining an account as a standard user.
VC Admins – Group giving members admin rights to my Virtual Center.
vRO Admins – Group giving members admin rights in vRO.

Additional Standard Groups This User Is A Member Of:
Domain Admin
Domain Users

NOTE:  This isn’t close to best practice.  In a shared environment, anything facing the internet or a real deployment Create seperate users as appropriate.  After this simple guide I will be doing an “Enterprise” install with the correct segregation of duties. This solution is, obviously, not production ready!

Once you’ve got all this downloaded and provisioned You’ll be ready for the Next Stage.  Deploying the vRA Appliance