Apps Should Follow The User
I recently completed a project at a customer who had hundreds of App-V apps that were being streamed at login to users in their non-persistent virtual desktops. This was resulting in long (10-minutes) login times until a usable desktop was ready, an extra 2GB of RAM being consumed, and lots of extra SAN consumption (because the apps were cached to the VDI disk in an attempt to speed things up, which is generally unsuccessful because the cached files would be out of date on the VDI disk when the App-V package was updated)
The business solution was to distribute each app only to a user that wanted it. Technically, this is done by creating Active Directory security groups for each app, and publishing the App-V package to the specific security group. This is a well-understood and perfectly supported method. In fact, the customer was already doing this with the few dozen licensed apps, where the software department managed the membership in those groups, based on who was licensed to have copies of that software.
But what about all the free open-source, or enterprise-licensed apps, where users should be free to get them if/when they want? You don't want users having to call the Help Desk or enter a ticket every time they want to obtain or relinquish an app (not to mention that the average user doesn't probably understand the AD SG concept behind it). And App-V doesn't provide a tool for individual selection - the App-V client GUI just refreshes them or saves them your local disk for offline use in an persistent environment.
There are quite a few tools that can be set up for allowing users to self-manage AD group membership, such as Microsoft Identity Manager (MIM, formerly Forefront Identity Manager FIM), scripts or .Net code which (if given permission in AD) can manipulate AD memberships directly. This customer had already deployed Quest ActiveRoles Server (ARS), with allows granular membership control, as well as PowerShell modules.
Although not the most ideal for user interfaces, we wrote a PowerShell GUI which retrieves the App-V inventory of packages out of the App-V database, presents a check-box list to the user, makes the requested changes through ARS, and then triggers the App-V client to refresh (after waiting for a slight AD replication latency). This was partly done so that the customer could maintain the code in the PowerShell IDE without having to have expertise in Visual Studio maintaining and compiling something like a C#.net application.
To ease the migration, we used the App-V reporting functions to determine who was using which apps in the past x months, and pre-populated them into those security groups, so that on cut-over Day 0, virtually nobody recognized that they were missing any apps (that they never used), but they all appreciated the faster login and snappier performance.
A similar effect can be achieved in thick-client environments if you set up user collections in SCCM and distribute App-V packages to the user collection instead of to the machine collection. However, be advised that in some cases, delivering an App-V package to a machine where an app is already installed can result in a FAIL, or user confusion with double icons at least. So, if you don't have good software baseline control of what is installed where (or not), you might need to write a detection script in your deployment type.
I just realized that this blog is here, and that https://blogwtk.wordpress.com is there. I forgot that TechNet blogs were migrating to Wordpress. I'll keep this for technical discusssions, but if you're interested in life on a wonderfully different continent, check that out.