Missing VCO Plugin from the vSphere Web Client

[sbeaver]

This is driving me a little nuts and covers all the vco servers I have in multiple datacenters.  A little background  I have multisite SSO configured so each vCenter servers in each datacenter are using the same SSO.

From the VCO client I can see the vCenter servers in the inventory and are able to drill down into each of them so I believe this shows the plugin in configured correctly. The plugin is configured to use a shared session and the account used has admin rights to vCenter

When I login to the C# client in the plug-in Manager I can see vRealize Orchestrator 6.0.0 listed as available plugins (my vRO 6 cluster connects to the vCenter but is using the Identity Appliance as its SSO which is not the same as the vCenter Servers)  I have multiple vCO 5.5 clusters that are using the same SSO as the vCenter servers)

From the vCenter MOB I can see all the VCO servers registered in the ExtensionManager as I would expect but when I logon to the web client I do not see VCO listed as an available plugin or the in the Solutions Manager and no VCO tab displaying on any of the different datacenters.

So what in the world am I missing? 

Steve

[iiliev]

Most likely it is permissions-related issue.

vSphere Web Client connects to available vCO servers (their IPs are fetched from the extension manager) by making REST API calls passing a SAML token acquired on behalf of the user logged in the vSphere Web Client, not the admin user you configured for vCenter plug-in shared session mode.

What happens if you try to login into vCO Java client using the same user you use to login into vSphere Web Client? Are you able to login successfully and to browse the inventory? If not, then you should give permissions on vCO side to this user/group.

Also, I'm a bit unclear what exactly is your deployment. Apparently, you have a mix of 5.5 and 6.0 servers. Which SSO is used by vSphere Web Client? In general, the SAML tokens acquired in vSphere Web Client need to be validated by vCO server, which usually means vCO should be configured to use the same SSO as vSphere Web Client.

[MikaelPareChabo]

I have the same problem. I tried to log in with the same user that I'm using in the Java Client, I still don't see the vCO extension.

[sbeaver]

Thanks for taking the time to respond!!

What happens if you try to login into vCO Java client using the same user you use to login into vSphere Web Client? Are you able to login successfully and to browse the inventory? If not, then you should give permissions on vCO side to this user/group. 

I am able to logon to the vSphere Web Client as well as the vCO client with the service account and are able to browse the inventory successfully.  This account is admin in vCenter and a part of the VCO_Admin groups

Also, I'm a bit unclear what exactly is your deployment. Apparently, you have a mix of 5.5 and 6.0 servers. Which SSO is used by vSphere Web Client? In general, the SAML tokens acquired in vSphere Web Client need to be validated by vCO server, which usually means vCO should be configured to use the same SSO as vSphere Web Client.

About my environment, each of my datacenters have a clustered pair of 5.5 vCO that have each of the vCenter servers in that datacenter configured via the vSphere Plugin. These VCO servers and vCenter servers are all configured to use the SSO servers that are behind a vShield Edge and set up in a Multisite SSO configuration.  Each datacenter is a seperate SSO site.

Now in my vCAC environment  I have a clustered pair of 5.5 vRO and another clustered pair of vRO 6.0   Can not completely make the cutover because of the way the new REST plugin has tightened security and will not take self-signed certificates that do not match the server name completely.  I do not control the other product that I have to make calls to so in the meantime while waiting for them to update that systems certificates I have to hold on to the 5.5 pair for the rest communication to that system.  Both vRO clustered pairs are configured to use the Identity Appliance as their SSO and ALL the vCenter servers in ALL datacenters have been configured in the vSphere plugin which is why you are seeing the mix.

Make sense?