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:
Optional Packages
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.
New Schema
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.
Priority Settings
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
7 thoughts on “Connection Groups 2.0 in App-V 5.0 SP3 – More Manageable & More Flexible”
Is it possible to have two connection groups with for Example Excel in common where :
> CG1 has app-v pkg : Excel
has app-v pkg : Excel Add-In
> CG2 has app-v pkg : Excel
has app-v pkg : some other apps … or nothing
Same question asked differently
– Is it possible to ‘decide’ witch connection group’s “Excel” instance to run ?
– Is it possible to have Excel running in different VE or connection group context ?
The one with the add-on or the one without ?
I got it,
I installed following app-v packages :
– Excel
– Notepad
– EssBase
I installed following two connection groups :
– CG1 with Excel & ESSBase having priority 0
– CG2 with Excel & Notepad having priority 1
To run Excel instance having the ESSBase Add-On loaded from the VE of CG1,
just click on the shortcut on startmenu or run Excel.exe
(as that first CG1 is the one with highest priority = 0)
To run Excel instance without the ESSBase Add-On loaded from the VE of CG2,
run cmd /appvve:notepad’sGUID_nottepad’sVersionID
and from that cmd that popped up run the Excel
Hi Yassine,
Looks like you found a work around for your own problem! The behaviour you are seeing was down to connection group priorities as you found out, here is more info around that: https://virtualvibes.co.uk/connection-group-conflicts-in-app-v-5-0/
How does the optional flag work if the user has access to the connection group. Doesn’t the connection group permissions give the user access to all the packages within the connection group regardless if they have no access to an individual package in that connection group.
Hi Simon,
No it doesn’t work in that way. A connection group merely publishes the relationship, there is still a requirement for the user to have individual packages published to them. That’s where the optional parameter comes in.
hi thamim,
we are packaging congnos application using app-v 5.0 sp3. this apps has few prereq’s like jre, jdk, oracle, sql developer. there is a shortcut which requires admin privileges(service account).
when we run this application the shortcut launched fine with the service account. but when we create connection group the application fails to launch.
do we have any idea?
No sorry i would need much for information to help you. Are there any visible errors messages? Anything in the App-V event logs?
Comments are closed.