I received a patch from the VMware support team: VMware-vRO-Appliance-184.108.40.2063-13917939-updaterepo.iso
When you are an Admin (part of the admin AD group in the VSPHERE authentication setup) you can see a new section "Groups" in the HTML5 UI under "Administrator"
This allow you to create "vRO Groups" and to assign AD Users or AD Groups + defining which Workflows this vRO group can run.
However it seems to only supports "run" role at the moment.
If you need edit, I think you must be an Admin.
Unfortunately for us this is a blocker as we have many AD groups that needs "edit" role to create workflows.
They had screwed up the import of groups in the fix they sent me.
After some back and forth they fixed it in a more recent .iso.
However, after drilling into things more, it has become clear they broke much more under the hood.
They simplified the roles into "admin" and "run"
That's not enough.
I created workflows that enabled our OS admins to run workflows against the VMs under THEIR groups/folders.
The Linux guys couldn't run their workflows against the VMs in the windows folders and vice versa.
Now, with the "simplified" roles the Linux guys can see and run workflows against any VMs in the infrastructure.
That's not going to fly AT ALL.
I brought this to the developer's attention and their response was:
"The connections to > vSphere must be configured to use session per user instead of a shared session. This means the user cannot escalate his/her permissions > when performing vSphere operations."
That is also NOT going to fly. My workflows simply will not work anymore.
In essence, they have completely broken all of the work I put into this and rendered Orchestrator useless in our environment.
Worse, they have proven I can't trust VMWare not to take away a feature I came to rely on in order to sell it back to me in some other product.
So, I had a conversation with a couple of the devs yesterday.
I'm not sure if it was fruitful or not, but they are at least now aware of how the changes they made have broken my orchestrator environment.
I asked them "What was the reason you guys removed roles from Orchestrator?"
At first, they dodged the question, but when I persisted they said "We removed roles from Orchestrator in order to add value to vRealize Automation"
In other words, they removed roles from vRO so they could sell them back to us in vRA.
The roles and permissions for vRO are two separate and different things. Roles are something totally new that we did not have in the past and in the java client, so I would not consider this as a missing feature. Roles are administrator and workflow developer and they have predefined set of permissions on what they can see and do. Admin can see all the functionalities in vRO, including administrative ones. Workflow developer can see a limited set of functionalities excluding almost all administrative ones(allowing just git history and inventory from Administration section). So, roles are the functionalities scoped limitations.
Groups functionality is the one related to permissions and content scoped and could be treated as a new permission model in the html 5 vRO client. Using groups you can create a group, to add users to it and add specific content to be visible just for the users in this group. And here comes the difference between vRA licensed and vSphere licensed vRO - vRA license allows admin to give the users in the group edit permissions to the content, vSphere license allow the admin to give just run permissions for this content in the group. This limitation came as part of License restriction limitations for vSphere licensed vRO instances we started two years ago. You can always put manually vRA license in your vSphere authenticated vRO and to get the full features set.
Oh, so it's not the roles that you took away, it's the groups. But the end result is the same.
And unless you guys are giving away free licenses of vRA, the upshot of it is that you still took away functionality that we HAD, and some of us built services around.. and are now suggesting we buy it back?