VMware Cloud Community
BrettK1
Enthusiast
Enthusiast

VRA 8.6 - 'Change Owner' finds no matching users to change to?

I've deployed a VM to a Project.  The user I wish to change owner to is a member of the 'Project Members' group.

When I select 'Change Owner' on the deployment, the 'change owner' dialog pops up, but contains NO options for a New Owner ("No matching values found").  No searches return any results  (there are 15 accounts in this group for testing, but nada).  The user and groups all appear synced correctly in vIDM, the user can log into vRA fine, they can see the deployment and play with it (all VMs in the project are shared)...  Tried with multiple projects with different member groups to the same effect.  Any ideas?

Reply
0 Kudos
20 Replies
emacintosh
Hot Shot
Hot Shot

I think last time we tried this, the only "owners" we could select were the actual groups we give permissions to in the Project.  If we assigned a particular user to a project, then that user could be selected.  But we assign groups to projects (not users), so this functionality has been mostly useless for us.  We're still on 8.4.2.

Reply
0 Kudos
BrettK1
Enthusiast
Enthusiast

I was afraid it was something like that (I considered adding a user instead of a group for testing...)
Well, so you know, this hasn't been 'fixed' in 8.6.1.
There's a few basic pieces of functionality that need to exist before 8.x can go production (this and 'offboarding' for 2).  I wonder who'll be ready for production first, me or it!

Reply
0 Kudos
vmittal83
Contributor
Contributor

As per VMware this should be fix in 8.6.1 but it is fixed not yet. Change owner gives only option of user which are add in Project not the group. Let us know if you get any workaround on this. 

Reply
0 Kudos
CHPD
Contributor
Contributor

Hi!

I'm running on 8.6.2 and still have this issue. Does someone have a workaround for this?

kr

Reply
0 Kudos
AlexNTTA
Contributor
Contributor

As mentioned, the only solution is to actually add the user to the project (vs being in a group). Once you've changed owner, you can remove the user from the project. Not a good "solution" for  me because  I don't like to add users to a project, just groups.

Tags (1)
Reply
0 Kudos
RebeccaW
Enthusiast
Enthusiast

Thanks for the head up on this still being an issue in 8.6.2!

This will be a non-starter for us. I have around 800 people in the group for our general users and am not about to starting having them put in tickets to have us manually add the person they want to transfer a server to explicitly in a project they are already in via the security group so they can do it then take them back out of explicitly being there again. The whole point is self-service.

Off boarding will be an issue as well. Each month we have servers that were recovered from backup as a different vSphere machine object and we have to unregister the old one and import the new one in 7.6. 

Reply
0 Kudos
BrettK1
Enthusiast
Enthusiast

I've raised both these issues with our account team and engineers, and suggest anyone else who can should as well.

 

Reply
0 Kudos
MehdiLimonadi
VMware Employee
VMware Employee

Hi Everyone,

I'm Mehdi Limonadi, a Product Manager for the vRealize Automation Product.

This feature request is a known issue and is a very high priority for us. We are in the final stages of deploying the feature/fix that allows members within AD groups added to a project as available options in the "Change Owner" day-2 action for deployments.

You should see this in the next few release cycles, keep your eyes on the patch notes! I'll make sure it's prominently in there for everyone facing this issue.

 

gojkotodorovic
Contributor
Contributor

HI, in our environment (8.6.2) we did a workaround - D2A: first, check if the user exists in the AD, assign the user to the project as a member, change owner and remove the user from the Project.

AlexNTTA
Contributor
Contributor

Right, I mentioned that work around above. It seems they will fix this in 8.7 though which will hopefully come within a week or so.

Reply
0 Kudos
MehdiLimonadi
VMware Employee
VMware Employee

You're reading my post a bit too optimistically 😅 I'll be clear, it is NOT in the 8.7 release, but it is coming in the next few release so please keep watching the patch notes

Reply
0 Kudos
AlexNTTA
Contributor
Contributor

LOL, sorry! At least it is acknowledged and being addressed "soon" ™️.

Reply
0 Kudos
garyhaight
Contributor
Contributor

dupe
Reply
0 Kudos
garyhaight
Contributor
Contributor

i have done something similar in a WF - run the wf, enter in the AD user, checks if their group is in the project, adds the user, calls the action changeowner - owner is set - then it removes the user from the project. The issue i am having is if i make this a custom action it errors out with something like - there is an action already in progress please wait until it is finished - i am paraphrasing of course. So i am trying to figure out a way to call the official changeowner directly without having to use the deployment.action method. Any ideas or help - i am not sure if you made yours a custom action or not so.... @gojkotodorovic 

Reply
0 Kudos
gojkotodorovic
Contributor
Contributor

Hi, all my actions are default vRO ("invokeRestOperation"). I had a situation where the action produced an error message, but after every executed action, I grabbed the link to check the status of the action (with the one sleep of 15s between requests). Bellow, you can see the sample, and it has been used for the migration vRA7x to 8x (approx 2000 VMs without any issue).

gojkotodorovic_0-1648104111432.png

 

Reply
0 Kudos
VA323
Contributor
Contributor

This should be addressed in 8.8 as per Release notes:

https://docs.vmware.com/en/vRealize-Automation/8.8/rn/vrealize-automation-88-release-notes/index.htm...

 

  • Support change owner Day2 action for single user that is part of an AD group

    Support changing deployment owner to users that are part of AD groups which are project administrator or project member.

    Note: If user is a project viewer or supervisor, they are not eligible to be owner of a deployment.

garyhaight
Contributor
Contributor

vRA 8.8 indeed has fixed the issue for AD group user validation for change owner; i.e. it will search AD groups now for the user account in question YAY!! the built in Day 2 action works

 

Note: however if you have tied the owner to any custom properties like email address associated with the owner when you change to the new owner you will need an EBS sub to change the payload and post back to the deployment

Reply
0 Kudos
emacintosh
Hot Shot
Hot Shot

Is anyone finding success with this now?  We are migrating to the SaaS offering, and it seems like this is still an issue.  We are assigning groups as members for a project.  If I try to change the ownership of a deployment in that project to a user that is in that group, they are not found.  If I add the user to the project directly first, then it works.  Even if I simply add them to the project, save it, remove them from the project and save it again (so it's just the group again), then it works.  

Has anyone else had a similar experience?  We'll be be (programmatically) setting the owners for thousands of onboarded deployments based on who owns them in the current on-prem environment, but it looks like we still need to run through this process of adding users directly to the project first.  Assuming we're not doing something wrong, this is really disappointing.

Reply
0 Kudos
RebeccaW
Enthusiast
Enthusiast

On version 8.8 and am able to Change Owner to a user that is a Member of the Project via a synced AD Group from vIDM.

Using the Change Owner action though we are seeing something odd. If you paste the username (no leading\trailing spaces) it does not resolve. However if you manually start to type it then it will start to show matching users that are eligibile. Paste of the same username works just fine in the owner filter of the Deployments. Not sure if that will impact your API work (we need to do the same with all the onboarding that is needed) but our users are going to be confused. It will be bad enough that they have to use username and cannot type in the person's name like in version 7.6.

Reply
0 Kudos