vRealize Orchestrator gotcha when configured with the configurationadmin

vRealize Orchestrator or vRO as I’ll call it through this post is clearly one of the most powerful features that are embedded into vRealize Automation and with our install wizard the ease of tying these two solutions together become even stronger. You may recall my post in the 6.x days and now all of that configuration goes away and is mostly out of the box.

The install wizard does a great job of getting you content quickly using vRO and specifically creating the configurationadmin account to build all of that out. Now if you’re like me and most of the customers I work with you have customized your vRA instance and tied it into active directory and moved away from that quick content that was stood up. The configurationadmin account may still exist and may even be entitled to some of the items in your catalog. I personally remove that configurationadmin account from any power and enable only an authorized active directory user or group. This leads us to our big gotcha!

Notice I have 3 simple catalog items in the screen shot here. This is one of my cloud admins view!



Let’s think about what happens if I want to request a catalog item using XaaS and vRO?

Here’s a quick screenshot using the catalog as an example and as you can see my configurationadmin account has no entitlement beyond the initial content. As you can see this would hinder the ability to request something on behalf of a user because our user can’t even get access to the items…



So the best way to fix this is use an authorized user and this may be a case where in all of your entitlements you add a service user that vRO can utilize for any requesting into vRA.

There is one other option you could use your configurationadmin account as that service account and entitle that to everything as well. Coming from corp america my gut is that is a bad idea as it’s not a controlled ID and security might frown upon it.

If you right click the sphere.local tenant and go to Update a vRA host you can alter that authenticated user



Follow the prompts, I personally change the “Host Name” setting from this



To this in order to make it readable and know who my service user is making the connections



Then enter the userid who is entitled and password



Wait for the reconfiguration. *Warning in my case I did have to exit Java as it crashed on my machine, if it appears to hang just restart your Java client and it will have completed.



Now take a look at my catalog items and you will see them matching with my above entitled options.



Now you may go forth and prosper by playing with some of the more advanced functionality like designing your own request form… Which we will illustrate in the coming weeks!



    • jt on March 21, 2018 at 8:49 pm
    • Reply

    Hi Gary,

    I am in the process of implemented your xaas request from technique in my VRA/VRO 7.3 environment and I run into a problem on the final submission of the request, and I was wondering if you could shed a light.

    I am getting [ (com.vmware.library.vcaccafe.request/requestCatalogItemWithProvisioningRequest) Error in (Dynamic Script Module name : requestCatalogItemWithProvisioningRequest#0) 404 ]

    Entitlements, tenants and business groups are setup correctly this has worked at one point, so I wonder what could have happened and how to I go about fixing it.

    Many Thanks for taking the time to read my message.


    1. Did you ever get this solved? I haven’t worked with 7.3 but the 404 error leads me to believe there’s an issue with the xaas redirect.

Leave a Reply

Your email address will not be published.