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
Login using root and the password you have configured during the OVA deployment.
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://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
Then effectively just go through the wizard and install each of the plug-ins you need.
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
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
Login to vRealize Automation as System Administrator or Tenant Administrator
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
- Add vRA Host
- Add the IaaS Host of a vRA Host
First run the Add a vRA Host
And use the following details (obviously you need to change the details to reflect your environment)
Once the workflow finished successfully ….
… you should be able to browse the vRA environment
Next step is to add the IaaS host of that vRA host
Here start the Add the IaaS Host of a vRA Host
Here my details, again, amend them accordingly
Again, ensure the workflow finishes successfully
Once done, you should once again be able to browse the IaaS part of your vRA environment
Done .. I am outta here 🙂