Hi all,
Problem:
Using the multi-node plugin with 5.5.2.1 I get an error when trying to add another Orchestrator. Error message:
Unable to convert object, 'com.vmware.o11n.plugin.vcoconn.model.RemoteServer@56aeb048' plugin exception reason : convertToResult() --> Finder 'VCO:RemoteServer' : unexpected error 'ch.dunes.model.sdk.SDKFinderException: convertToResult() --> Finder 'VCO:RemoteServer' : unable to invoke read method : 'name''
It works fine just using a NON-SSO configuration (out of the box with vcoadmin). As soon as I configure it for SSO it dosnt work anymore.
Even more wired: SSO configured, in the Add a vCO server dialog, choose SSO enabled:No, Shared:YES. Will add the Orchestrator but will report it as offline. You will have to delete its Config out of the resources to get rid of it as you cant even dlete it.
System:
Both Orchestrator Appliances are 5.5.2.1 and are configured to the same SSO (5.5U2).
Hi Windspirit,
A workaround to this is to set the settings "SSO enabled" to false and "Shared" to true and then to provide the shared account in the "Add a vCO server" workflow.
There is a KB article dealing with that issue - Using Single Sign-On authentication on a remote Orchestrator server might cause problems with the Multi-Node plug-in (2095701)
Hi Windspirit,
A workaround to this is to set the settings "SSO enabled" to false and "Shared" to true and then to provide the shared account in the "Add a vCO server" workflow.
There is a KB article dealing with that issue - Using Single Sign-On authentication on a remote Orchestrator server might cause problems with the Multi-Node plug-in (2095701)
Thats what I tried, and thats the wired stuff I mentioned, just wrote Shared:NO and thats wrong I meant YES. So no that dosnt work.
Can you retry the proposed setup.
I have tested this locally and by providing the shared credentials it is working fine.
This behavior is observed when you have improper configurations saved in the database. When you open the inventory the plugin tries to construct objects from these configurations and failes.
So make sure you do not have improper configurations. They are located in the Resources->Library->VCO->Configuration (Design View) and to be sure better delete all of the configs listed there
and then add a new remote vRO as the prescribed way.
I have tested this locally and it fails when you have improper configurations in the resources but when they are removed averything connects and works fine.
I have also deployed two vROs 5.5.2.1 with SSO 5.5.2.
Pls check your private messages in the forum. Thanks
OK...I could replicate that now.
However, one think I found is that this also happens if you added the SSL cert with IP instead of FDQN.
Anyway...CASE CLOSED.
THANKS