If anyone was wondering on how to handle the Add-ins with Office and IE (all virtualized). I believe I put in place the only workable solution with App-V 5.0 in an RDS environment, see my post on June 25th 2013.
You need to create multiple Priority 0 connection groups and assign them to different AD groups.
1. Create a connection group that contains all the apps that everyone needs that benefit from being able to talk to eachother. Example: Default Apps connection group1 = Office, IE, Silverlight, Java, Adobe Reader, standard unlicensed COM add-ins for
Office, etc. then publish that to an AD user group that contains users who need that set of apps.
2. Create addtional connection groups that contain all the default apps plus the licensed user specific COM add-ins and publish that to another AD group that contains users who need that set of apps.
This works well and when the user logs into the published desktop they get all the "Default apps" plus their specific COM add-ins due to the AD group/Connection group membership. The potential big drawback to this approach is the number of connection
groups and corresponding AD groups you may end up managing. The more COM add-ins you have in the enviornment and the diversity of the user population will drive this number upward. I believe the right way to think about it for worst case scenarios is
2 to the X power where X is the numer of COM add-ins you have in the enviornment. Why? because a user could have a need for any combination of the COM add-ins available in your environment. The more logical groupings your can define and enforce the
less of a problem this becomes.
It appears that Microsoft did not think through this scenario when designing App-V 5.0, which in many ways is a great product even when compared to 4.6.
I would like to hear other solutions for this problem using App-V 5.0 and RDS/published desktops.
