Connection groups have been given a lot of attention in the latest SP3 release of App-V 5.0 in what is now a more flexible and more dynamic overall picture of how we can manage these groups. There are two main improvements that have been brought into the fold:
Pre-SP3 for App-V 5.0 every package in a connection group had to be published to the user/machine where the connection group was being deployed otherwise it would fail to be registered. For example if I had Paint.NET with a selection of plugins all held inside a connection group published to my users:
But one of these packages was no longer published to my users for whatever reason, for example the license expired so it had to be decommissioned, in this example the plugin “Donut”:
Because all packages in the connection group are not present or available the user the connection group would fail to be delivered on the client:
This presented a bit of a manageability challenge as administrators would need to constantly check that consistency between packages published and connection groups published was in sync. A user would need access to every package in a connection group to receive it, if a package was published then the administrator would need to ensure it was also removed from the connection group. This challenge was further expounding when managing different sets of users. Imagine we had different users who were licensed for and used different combinations of these plugins with Paint.NET, we would essentially need to create multiple connection groups for each desired combination of packages.
Now things are much more simple with the optional parameter we have with the App-V Server:
By simply ticking the box next to indicate that the Donut plugin is optional it will mean even if my user does not have it, the connection group will still go ahead and publish the connection group with the other packages:
Use Any Version
Another new improvement to connection groups is the use any version option which does exactly what you would expect! It allows makes a connection group flexible to the version of a particular package that needs to be present. This again addresses some of the manageability challenges we may of had previously with connection groups.
For example say pre-SP3 we decided to upgrade Paint.NET to a new version, publish it to our users and unpublish the older version:
Our connection group would now not be delivered as users will have lost access to version 1 and only have access to version 2:
This version sensitivity again could potentially add a big overhead to management of connections groups as every update to a package would need to be checked against connection groups it may affect. This is again further expounded when we have different users using different versions of a package that require connection groups as we would need to create separate groups for the different combinations of package.
Luckily this is all in the past as we can now simply check the box that says Use Any Version:
Ticking this box against the Paint.NET package means we can now deploy new versions without worrying about the sensitivity of connection groups it may reside in. Aslong as the user/machine has any version of the package, the connection group will go ahead and publish.
So how does this all work I hear you ask? Simple, its all made possible by the new 2014 schema which evaluates the group metadata held on the publishing server. Notice the true and false values against our new PackageOptional and VersionOptional values in this connection group:
Off the back of this the client publishes a new connection group PackageGroupDescriptorTemplate.xml which leverages the new settings in a brand new 2014 schema.
Notice the * values next to VersionId on certain packages and the IsOptional values:
This all the gets parsed into a traditional PackageGroupDescriptor.xml that we are used which contains the packages we should have the connection group in this particular instance based on the template above.
I’ve talked about connection group priorities in depth here and how priorities can be used to overcome these. Pre-SP3 has to be down via PowerShell on the App-V Management Server however this has now been brought into the console as a configurable:
And as if that wasn’t enough check out Merged Roots in App-V 5.0 SP3 for another reason why connection groups are even easier to manage in App-V 5.0 SP3…
Also if you want a more in depth look run down of how connection groups behave check out this post: Advanced Connection Groups – A Sanity Check