When I first took a look at how SCCM manages App-V connection groups I have to say I was really impressed with the flexibility of the rule based approach of Virtual Environments. Since then App-V connection groups have developed and moved forward, most notably with the recent SP3 release.
I have taken the opportunity while working with my banking client in London to revisit this feature in SCCM to understand how we could actually use this feature in our rollout and to understand if it can really fulfil our requirements. As I stressed in my recent session at Ignite, connection groups should be given adequate planning and consideration in any App-V rollout, after the packages themselves, this feature is second inline as far as management overhead and shouldn’t be an after thought.
So how do Virtual Environments stack up when we actually want to use them in large scale deployment?
Timing is always a sore subject when it comes to SCCM and a common gripe is that application delivery takes too long. We have been told that the latest service pack brings “improved performance that reduces the time required for apps to display after the first logon for non-persistent VDI environment” but from what I understand this is still no way near instant or close to App-V Server.
So what about connection groups? Well the good news they are not slower, virtual environments are assessed and delivered during standard refresh. This means the gap between application delivery and connection group delivery is minimal, in my testing this was approx. 3 seconds between delivery of two applications and the relevant connection group. You will see something similar to this in your AppEnforce.log:
Installing App-V 5.X virtual environment VirtualEnvironment ID : ScopeId_B69B2597-FF21-4C62-8E63-7390B5BD354F/VirtualEnvironment_73491fa0-ecbc-441d-b75a-1fe175b6862a, Revision: 1, with specified package list:AppvClientPackage.PackageId=”a1d329c8-09d2-4215-91a8-1b5085fa01e2″,VersionId=”95b62102-1931-498e-8376-d688c73a2acf”;AppvClientPackage.PackageId=”f3a60802-d922-4646-88f0-c69c398b45e6″,VersionId=”735ae163-9644-4abb-b35b-eb2539556b02″
This is a big deal as nobody wants applications being delivered without the required connection group, as they will most likely fail until the delivery. This does require that connection groups are defined before or at the same time as application deployment.
If the connection group is generated after application delivery I have found there is an extended wait of > 15mins by default before it is delivered.
The concept of optional members was introduced to the App-V Client and Server in the recent SP3 release however SCCM 2012 had this capability before.
Using the OR operator to connect members within a group means they will be considered optional for the connection group to be delivered. Keeping packages in a single group where possible therefore increases ease of management and overall flexibility. For example above we have included a mix of plugins within the same group which means they will all be non-mandatory for qualification to receive this connection group.
There is no concept of targeting connection groups to collections in SCCM 2012 like how you would applications, Connection Groups are not first class citizens like they are with App-V full infrastructure. Virtual Environments are ruled based definitions and are assessed dynamically client side if and when applicable, they are available globally and you either get them or not.
Also Virtual Environments can only contain deployment types from the application model so anything in the legacy package model cannot be used.
Mixed Member Targeting
SCCM 2012 will only deliver connection groups if all member packages are targeted to either user or machine exclusively. Mixed member targeting is supported with native App-V client and App-V server however this is not a possibility with Virtual Environments in SCCM. This can be a show stopper for some enterprises when planning Connection Group strategy especially when an organisation is moving from machine targeting to user targeting.
Use Any Version
While supersedance can be used to upgrade existing deployment types, the new deployment type must be explicitly specified in the relevant virtual environment, therefore there is no such thing or equivalent feature to “use any version” which the App-V 5.0 SP3 client understands. We can however use the optional OR operator to bring flexibility and accomplish in around about way the same behaviour but this still requires the manual addition of new deployment types.
Updates work as expected, when a connection group is changed in any way, it is reassessed at next policy refresh and updated accordingly.
Creating/Updating the connection group for Virtual Environment ScopeId_B69B2597-FF21-4C62-8E63-7390B5BD354F/VirtualEnvironment_73491fa0-ecbc-441d-b75a-1fe175b6862a. Context: User
There are two levels of priority and conflict resolution with connection groups, Virtual Environments unfortunately only handle one of these at present.
The first type of priority is between members of a connection group, this is handled purely by the ordering of members in the console itself, so if one package has a file or registry conflict with another then the highest in the chain will take priority.
The second type of priority is between connection groups themselves, a scenario described in detail here. SCCM currently does not give the ability to set the priority of a virtual environment nor does it handle any conflicts dynamically. So if Package A is a member of two separate connection groups and a user launches Package A, it will fail to launch. That is because SCCM delivers all connection groups with the same 4.2 billion priority value.
Due to the above shortfall you should be cautious not to every have a package that would be launched in more than one Virtual Environment.
Deleting a connection group from the SCCM console means it will be removed (eventually) from the client endpoints at next policy refresh.
Successfully disable and delete the connection group 72cb5e40-772b-404a-87ce-19a979633e37, Version Id eaf0c683-8b6d-47f4-a34e-faea27a19741, Context: User
Interestingly uninstalling a package which is a mandatory member of a connection group does not fail as it would in other deployment methods, SCCM client dynamically will create a new connection group which excludes the uninstall package and then go ahead and remove the package. This basically means an uninstall will always win and take place regardless of Connection Groups the package might be a member of. This could be seen as a positive or negative depending on your perspective. This also means you can end up having a connection group with just a single package as a member:
Before we unpublish the package a1d329c8-09d2-4215-91a8-1b5085fa01e2 version Id 95b62102-1931-498e-8376-d688c73a2acf for S-1-5-21-3366449900-1917713875-2491790561-500, check if we need to remove it from connection group
This isn’t something that can be precisely measured and while the sections above detail the behaviour you can expect, predictability can be an issue when working with Virtual Environments in SCCM.
One of the reasons for this is the loose way they are defined which means you might never gain a real grasp on which machines and users might have certain Connection Groups delivered to them. Also timing further expounds this feeling of vague control, for example sometimes after deleting a connection group I have found it is still present on my client the next day.
So to summarise, Virtual Environments have pros and cons in terms of management with SCCM. It has fell behind somewhat as Connection Groups have improved over time with the actual App-V product and some of these limitations might mean it isn’t a viable way to manage these package relationships if you have a complex environment. In other more simple scenarios Virtual Environments present a easy native way to deploy Connection Groups where timing and flexibility may not be as critical.