Destroy fails in 7.4 due to deleted user?

[michael_stefani]

Ran into an issue in 7.4 where an expired deployment hits the archive limit and then fails to delete itself.  The error below is what's logged in the destroy request.  Basically a user left the company, but is still listed as the owner of the deployment.  In previous versions I don't feel as though vRA / vCAC cared if the owner was still actively entitled to vRA.  I've got a support case open with VMware on this, but was curious if anyone else had ran into it.  The system attempts to destroy the deployment every few hours and just keeps failing.  I've also attempted to destroy it manually with the same results although I intentionally didn't try the "force" checkbox as I wanted to see what support says.

Request initialization failed: Unable to find user XXXXXXXXX of tenant XXXXXX in the principal service.

[sbeaver]

Have you tried running the workflow to change the owner to a good acount?

[aseaz404 · Accepted solution]

We've run into this issue and have addressed it with a couple of (non-ideal) workarounds.  The first one is to take ownership of the deployment as soon as we know the user won't be around, I imagine not helpful in your situation since you're letting the item expire.  The other process we've used, since our AD accounts stick around for several weeks after a user has left (blame our provider) is to reassign the account to the AD group that belongs to the corresponding business group.

[michael_stefani]

OK, I was kind of assuming I could change ownership and then run the delete.  It's a decent workaround, curious if this is a bug or a "feature".      We might just build something out in orchestrator that checks owners against AD weekly or something along those lines to catch these earlier.  Thanks for the replys

MIke

[aseaz404]

We banged our heads against this for a couple of days.  We come from a vCloud Director background and there are a lot of things that don't make much sense to us, this being one of them.  We probably need to change our mindset on how we approach deployments and I can't say if this is a bug.  Suffice it to say there are a lot of things that were really simple to do that we either can't do anymore or take some cumbersome steps.  We haven't tried the workflow suggestion.

Alex

[maxgrechnev]

@michael_stefani

What VMware support says to do with the deployment? Force delete does not help...

[michael_stefani]

They didn't have a real solution for us.  Basically told us to change the owner of the deployment to an active user and then perform the destroy which works fine.  More of a workaround in my opinion than a true fix.  I haven't upgraded to 7.5 yet to see if it's been resolved or not in that upgraded version.

[maxgrechnev]

Changing the owner also fails in my case. In fact any request fails with the same error. Did you really succeed with the owner change?

[michael_stefani]

Yeah, I'm almost positive we worked around it by changing the owner.  I do think we had to unexpire the deployment though before we could change the owner.  Not sure if that's the issue you're running into or not.

[KuChGi]

I've had no luck at all with this either. Seems like once it gets past the expiry time, you're just stuck.

[MTJohnson]

Here's what I got from support to help with this (In my case our user accounts are actually switching domains).  DANGER, this may completely break your vRA.  Don't do it without backups, snapshots, I'm not responsible, etc...

1. SSH to the vRA machine and enter the psql console

* su postgres

* psql vcac

2. Check if the target user has a record in the catalog's table.

SELECT COUNT(id) FROM cat_principal WHERE ref = '<newOwner@owner-domain.com>';

a) If the user has no records in this table, go to the Entitlement, create a temporary entitlement, select the Business group where the target user is member, uncheck "All Users and Groups" and explicitly add that user under "Users and Groups" section.

    Make sure to set the entitlement to "Active". Go to next step and without adding anything there just Finish the creation.

    In the end reinvoke the query from above to make sure that the user is now part of cat_principal table. The temporary entitlement can now be deleted.

3. Replace all resources of the deleted user with the target user

UPDATE cat_resource_owners

SET "owner_id" = (SELECT id FROM cat_principal WHERE ref = '<newOwner@owner-domain.com>')

WHERE "owner_id" = (SELECT id FROM cat_principal WHERE ref = '<currentOwner@owner-domain.com>');

[GeekSwag]

Same issue... Change Owner failed and Force Destroy did nothing. I was finally successful in deleting the deployment by searching for the VM at  Infrastructure > Managed Machines and choosing 'destroy' from there.   :smileyconfused:

[xpurpleblack]

Does this cause the error messages to stop filling up the logs?