When you have configured your vRA / vRO environment to utilise the vsphere.local tenant and you run the SovLabs configuration workflow, you will consistently get an error in the debug logs. Even if the health of the cluster is correct and the vRA stack has been rebooted / shut down and restarted you will still get the same error. This error sometimes happens and clears up after a few minutes, or after a restart of vRA. In this case, no amount of time or restarts fixes the problem.
You have configured your vsphere.local tenant to use the SovLabs module AND you have configured the vsphere.local tenant to run on an EXTERNAL vRO. While this is technically a supported scenario by vRA/vRO, the Configuration workflow for the SovLabs module will always fail with this error.
All version of the SovLabs modules
All versions of vRO / vRA
Setting the vsphere.local (default) tenant to use an external vRO appliance is not a common scenario, and is not supported by the SovLabs plugin at this time.
There are two ways to solve this:
Solution 1 – use the external vRO, but create a new tenant for it instead of using vsphere.local
Create a new tenant to use against your external vRO server.
This is the most common step as you want to retain your vRA / vRO design but will be required to go through and reconfigure your environment and complete the pre requisites for SovLabs again.
Steps 2.1 and 2.2 may be skipped as you would have run these against your external vRO already however all other steps should be reviewed against the new Tenant
Solution 2 – switch to the embedded vRO and continue to use vsphere.local tenant
Use the embedded vRO server
This will require a redesign of your environment to use the embedded vRO but will allow you to keep the default vsphere.local tenant name if this is what you wish.
Once you have finished configuring vRA and vRO you will have to go through all the Pre Requisite steps for the SovLabs module
SovLabs pre requisite steps : http://docs.sovlabs.com/latest/vRA/7.6/getting-started/