vRealize Orchestrator (vRO) licensing pitfall

vRO is a powerful tool used when you want to automate repetitive tasks on your vSphere environment. It has various plugins which bring integration with other VMware products as well as integration with third party hardware and software solutions.
vRO is a workflow based tool, besides the default workflows you can also create custom workflows. These workflows are stored in the vRO database together with the configuration data, depending on the use case you can choose either between a embedded database that is based on vPostgress or you can choose to use a external database solution based MS SQL or Oracle.

About the use cases which could use the embedded database, VMware documentation is not really clear on this. Because the Install and Configure documentation on vRO version 6.0.1 states that the embedded database should only be used for testing or PoC purposes. But the Install and Configure documentation on vRO version 6.0.3 states that default database option is suitable for small- or medium-scale environments. What is clear is that when you use the embedded database you cannot set up vRO to work in cluster mode, or change any licenses and the server certificate by using the vRO configuration interface.

So why am I writing about the database choice of vRO, well recently at a customer which uses vRO to automate tasks we ran into a operational issue when nobody could logon to the newly deployed vRO instance. It became clear that this vRO instances had been running on the default evaluation license, which stops working after its 90 day evaluation / grace period.
The solution would be simple, just login to the vRO configuration page and update the license key. But as documented in the Install and Configure documentation, when the embedded database is used you cannot update the license key from the configuration page. The only way to do this is to run the license update workflow from within vRO itself.
This was not possible because logon the the vRO client did not work because of the expired evaluation license. A solution to this "chicken and egg" problem was not easily found.

So how do you solve this problem, I first need to mention that I did not find this solution. All credits for the solution described below go to Martijn Went (@MartijnW01).

As mentioned earlier, when your vRO license is expired you cannot logon the the vRO client and run workflows. But you can logon to the vRO configuration page, after you first start the configuration service.

• Start the service and logon to the configuration page
• Go to the Database sub menu
• Change the database type to anything other than embedded, this will make License sub menu become available.

• Go to the License sub menu and go to the vCenter license tab and enter the details about the vCenter that needs to be used to license this vRO instance. Leave the port (443) and path (/sdk) default. Enter vCenter credentials and apply changes.
• After the connection to the vCenter is made the license will be verified, check the license details on the vCenter license tab you are on.
• Go back to the Database sub menu and change the database back to embedded
• Now you should be able to start the vRO service again.
• After the service is started, logon the the vRO client and run the workflow to license vRO to the vCenter license.

Now all should be operational again, the only thing that we had to do to be fully operational was reconnecting vRO to all vCenters within the environment. Not sure if this is related to the vRO configuration actions, but for some reason the vRO instance lost connection to the vCenters.

I'm sure this is not a supported solution, but VMware GSS did not have a solution on hand when they where contacted regarding this issue. The solution they found that might work, was to manually edit the database (replace the evaluation license key).