VMware Horizon Community
MaxStr
Hot Shot
Hot Shot
Jump to solution

How can I exclude a user from a group Appstack assignment?

I have a large AD group of users assigned to an Appstack, but a couple users are experiencing crashing so I need to exclude or disable them. I don't see a way to do this without removing the entire group and assigning everyone individually.

(AppVolumes Manager version 2.18)

Reply
0 Kudos
1 Solution

Accepted Solutions
julatoski
VMware Employee
VMware Employee
Jump to solution

Your deployment may benefit from the new application-based assignments in App Volumes 4.

Assigning individuals is much more convenient using a (current) marker.  With the marker, you won't need to re-assign them when you update your package.  So in affect you can manage the "group" on the application's dashboard.

If you would prefer to still manage the assignments via an Active Directory group, there may be another option for you.

From what I gathered from your original post, ideally you would like the ability to disable a package for an existing user by creating a negative assignment of sorts.  

Today when assigning an application, you can only choose the (current) marker or point to a specific package.   Perhaps an option to select "no package" when assigning an application would be ideal.

I suppose that with the App Volumes 4 inventory, you could do something similar.  Theoretically you could create a new "blank" package and assign it directly to the user instead of the group.  Since only one package for a given application can be delivered to a user and user assignments will override group assignments, the user would get the "blank" package instead of the package thought to be causing the issue.  While not ideal, this approach may potentially be of use when trying to find the bad actor.

This workaround aside, I will also take note of your suggestion.

Thank you for your feedback!


Jeff Ulatoski
Product Line Manager, App Volumes

View solution in original post

4 Replies
Ray_handels
Virtuoso
Virtuoso
Jump to solution

There is no exclude or deny in Appvolumes. You would need to create anither group where these users are not a part of unfortenately.

You could try and only assign to a specific computer prefix and add those other users to a different pool?

Reply
0 Kudos
Natestack
Enthusiast
Enthusiast
Jump to solution

I had a similar issue but what i did is remove the users from the AD group and assign directly to the user account.

I love app volumes its much like citrix if it works for all but not 1 or 2 users chances are the profiles are bad.

If it was not working for all chances are clearly something wrong with the appstack.

MaxStr
Hot Shot
Hot Shot
Jump to solution

I ended up removing the group and adding each user individually. It's a pain, hopefully VMWare will add some kind of exclusion feature.

Reply
0 Kudos
julatoski
VMware Employee
VMware Employee
Jump to solution

Your deployment may benefit from the new application-based assignments in App Volumes 4.

Assigning individuals is much more convenient using a (current) marker.  With the marker, you won't need to re-assign them when you update your package.  So in affect you can manage the "group" on the application's dashboard.

If you would prefer to still manage the assignments via an Active Directory group, there may be another option for you.

From what I gathered from your original post, ideally you would like the ability to disable a package for an existing user by creating a negative assignment of sorts.  

Today when assigning an application, you can only choose the (current) marker or point to a specific package.   Perhaps an option to select "no package" when assigning an application would be ideal.

I suppose that with the App Volumes 4 inventory, you could do something similar.  Theoretically you could create a new "blank" package and assign it directly to the user instead of the group.  Since only one package for a given application can be delivered to a user and user assignments will override group assignments, the user would get the "blank" package instead of the package thought to be causing the issue.  While not ideal, this approach may potentially be of use when trying to find the bad actor.

This workaround aside, I will also take note of your suggestion.

Thank you for your feedback!


Jeff Ulatoski
Product Line Manager, App Volumes