vRA7 – vRealize Orchestrator 7

Here I am going to explain how to configure a vRealize Orchestrator 7 appliance and configure it as external Orchestrator for vRealize Automation 7 – the latter is merely a ticketbox – but a single screenshot is a tad too boring 🙂

First I have replaced the VAMI certificate – I have written another article about it HERE

This is not the vRealize Orchestrator Server Certificate – that comes later – but the certificate used when connecting to the appliance admin interface 🙂

Once you deployed the appliance, browse to the vRO page

While you there – install the client. You can do this later anyway, but like I say – may as well 🙂

From here – launch the

Orchestrator Control Center

Click Certificates

I personally have my own CA in my lab so I will replace the vRO Server Certificate.

Click Orchestrator Server SSL Certificate

Click Import > Import from a PEM-encoded file

Browse to your certificate and click Import

Click Import again to confirm

Important: RESTART the appliance as per note below. I have ignored it before and continued to configure vRO in order to just have one reboot. It seems vRO loses the certificate unless you reboot every time it asks for it. Not sure if that is a bug or intentional – but it is annoying one way or another

Now select Trusted Certificates

Here we need to add the certificates we intend the vRO appliance to interact with, in my case vCenter and vRealize Automation

Again click Import

Here you can either upload the certificate or simply point it to whatever you want to add

https://vCenter:443
https://vRA Appliance
https://IaaS Server

and so on. You can see above two certificates. The last one is my CA certificate which includes a full chain and also includes Subject Names for every component, from vRA Appliance to IaaS Server, vRO appliance and everything in between. Hence you see only two

Anyway – as I say, here upload or ‘point and click’

Next click Manage Plug-Ins

Now here is the thing. IF you are using the internal vCO instance coming with vRA – you likely have all the plugins you need – including vRA etc.

BUT – if you use the external vRO appliance, then you will need to install them. The VMware website is a bit tricky to navigate at times and finding all those plug-ins might not be as straight forward.

The easiest way to get the whole lot is by downloading them from the vCO instance shipped with vRA .. Two ways of doing that

a. You login to the vRO Controlcenter shipped with vRA – in the same Manage Plug-Ins screen you are able to download each individual plug-in

But this can become very tedious, very quickly. Plus you may have disabled the internal vRO instance anyway. So the next best thing (well, THE best thing really) is you SSH to the vRA appliance and download the lot. So

b. Download them from the vRA appliance.

The plug-ins are located on the vRA appliance in

/usr/lib/vco/app-server/plugins

Then effectively just go through the wizard and install each of the plug-ins you need.

Example:

Browse to the .DAR file and click Install

Confirm the plug-in and click Install again – here you can see the full name of the plug-in

Once more it tells you to restart. On one occasion I was able to install multiple plug-ins and restart once, on another I had to restart after each plug-in. Speaking of consistency.

Once you installed the plug-ins, enable them – you need to confirm that for each plug-in you enable 🙁

Under the Startup Options you can then restart the server .. a few times .. over and over again

Next we need to configure the authentications

Click Configure Authentication Provider

Here you need to decide what you want.

Integrate with vRealize Automation
Integrate with vCenter Server
Integrate with BOTH

In order for the authentication to work for BOTH – both have to belong to the same SSO domain. That however is not necessarily supported. Whilst you can use the PSC for vRA, you cannot use vRA for the PSC (hope it makes sense).

Let me try to explain.

Here you can see I have used vRealize Automation as Authentication Mode

The configured user group vRA7-Admins is now admin in vRO. In my environment the same user has also admin permissions in vCenter.

BUT: Because both my PSC and vRA use their own SSO domain, I will be unable to register the vRO with vCenter. You essentially won’t be able to start workflows from within the webclient. You will see that you can indeed register the vRO server with vCenter and it will work without problems (when using the configuration workflows – more to that later), but the vRO instance will still not show up in the web client.

Now the other option

Use vSphere as Authentication Mode

Once more I am using vRA7-Admins as admin group for vRO. I can now register the vRO instance with vCenter – and can see the server in the web client.

Great – and I can still add the server to vRealize Automation – also great. But why not do it that way anyway you may ask.

There is one difference – and that potentially rules out this option.

If you configure vRO to use vSphere for authentication – you will not be able to add the vRO server using SSO authentication – you can still do it – but you will need Basic authentication – effectively by providing credentials for the external vRO instance.

Why is that a problem? If you develop workflows which interacts with vRA items – for the sake of argument say CatalogItems – the items returned, will not be the ones of the user logged into vRA – but the ones the user of the external instance you configure – specifically the ones it has access to.

So depending on what you intend to develop / do with the vRO instance – you may have to decide for one or the other.

In most cases however, if you intend to use vRO in vRA, then you likely want to use vRA items such as CatalogItems etc. – so you will need to use vRA as Authentication, rather than vSphere.

If you just want to add it for testing purposes and your main goal is to use vRO in your web client – use vSphere.

I hope that makes all sense – I am not sure if VMware will allow to use vRA for SSO authentication even for vCenter in the future – but it is not possible as of today (Jan 2016)

Anyway, moving on. So this is my lab – I don’t develop workflows but want to use it for some testing – so I do want to add workflows into vRA – but I don’t develop my own ones and I don’t care about the details.

So here I am using vSphere as Authentication Mode and select my admin group vRA7-Admins

Now click Licensing

You should either see your vRA license or vCenter license

Now it is time to do some stuff in the Orchestrator itself.

From the main page – click Start Orchestrator Client

PS: I hate Java

Here login with a user belonging to the group configured before

Accept the certificate

First I add a vCenter Instance

Browse to the workflow below and click

Enter your vCenter details (and ignore cert warnings unless your vCenter has a properly signed certificate)

Enter your credentials. Whether you use Session Per User or Shared Session, depends on the way you develop workflows – I always use Shared Session as I don’t care if workflows run under the same admin user.

The workflow should finish successfully

You should then be able to browse your vCenter inventory from within the vRO client

Next we need to register the vRO instance with the vCenter – that effectively hooks it into the vCenter Web Client

Run the workflow and select your newly added vCenter

That also should finish successfully

Your vRO Server should now pop up in your vCenter web client (You may need to log off and back in again)

Now we have vRO integrated into vCenter – time to integrate it into vRealize Automation

Browse to Administration > vRO Configuration > Server Configuration

Enter here the details of the external vRO instance we just configured.

As mentioned (remember the limitations) – here I use Basic Authentication. If you would select SSO – you won’t get success in adding the server in as vRO now uses vSphere for SSO

Click Test Connection and when successful – click OK

Accept the certificate

The thumbprint should match your vRO Server Certificate

Acknowledge the warning

As a test, start to create a XaaS Blueprint (ASD back in vRA 6.x days)

You should now be able to see the workflow tree structure of your external vRO instance.

In addition to configuring the internal or external vRO instance – you can also add an Orchestrator Endpoint

The vRO Endpoint is mainly used for

Workflow execution through internal stubs
NSX Integration

This is really a case by case thing so I won’t go into too much details – but once you have created the required credentials, you can add the same vRO instance you just configured, as Endpoint

The next possible configuration would probably be a vRO cluster – but that is quite easy

Create an external DB
Configure first node
Export Settings from first node
Import Settings to second node
Attach second node to first node
Configure LB

Details can be found HERE

I might create another Article for it – but there is one downside to it – the use of the vRO Client is not supported when using a cluster configuration. You effectively have to (technically) either break / re-create the cluster when developing workflows, or have a development vRO instance for the development and then import the workflows into your cluster.

But that is it really – any questions – ask 🙂 (See About)

Oh one additional nugget – let’s just assume you want to use vRO to create workflows in order to interact with vRA (going ‘in’ rather than ‘out’) – you need to add vRA to vRO

You need these two workflows