Advanced Connection Groups – The Sanity Check

Since the release of App-V 5.0, connection groups have been a highly rated feature of the release, it is something that brought about a whole new level of flexibility and manageability compared to dynamic suite composition in 4.x. However connection groups have evolved overtime and there are many nuances to behaviours depending on how they are used. This set of statements reflects the current state of play with the latest version (App-V 5.0 SP3) and I will update it should things change. I hope it serves as a quick sanity check and a guide when planning your connection group strategy…

The Sanity Check

1. Connection groups use two key files

Connection groups work off a template and effective .xml. The PackageGroupDescriptorTemplate.xml provides a structure to compose (template) and the PackageGroupDescriptor.xml is the current composed connection group (effective)

There is also a third file called UserPackageGroupDescriptor.xml which is generated when a connection group is published to the user and acts the same as the effective connection group descriptor but for the user

2. Connection groups can be published either globally or to user

This is achieved by using the -Global switch when running the Enable-AppvClientConnectionGroup cmdlet

3. Connection groups can contain a mixture of both user and globally targeted packages

This is done on a package level by adding the -Global switch when running the Publish-AppvClientPackage cmdlet

4. Connection groups targeted globally cannot contain any user targeted packages

If attempting to deliver a mixed scope connection group to the computer you will get the following event 1048 error:

5. Connection groups targeted at the user can contain both user and computer targeted packages

Mixed scope connection groups always need to be targeted at the user

6. Connection groups must have at least one mandatory package

There must be at least one mandatory package per connection group otherwise delivery will fail with the following event 8004 error:

7. Connection groups will fail to publish if a mandatory package is not published

Mandatory packages are required to be present in cache for a connection group to be published otherwise delivery will fail with the following event 8012 error:

8. Packages will fail to unpublish if they are a mandatory member of a published connection group

Packages must be detached from any connection groups for which they are mandatory members before they can be published otherwise the action will fail with the following event 1016 error:

9. Packages in a connection group set to use any version or set as optional will always use the latest version in cache when initially delivered

Regardless of whether a package is published, aslong as it is present in cache it will be generated into the effective connection group when the connection group is delivered. For regeneration behaviour after delivery of connection groups read the following:

10. Connection groups added or targeted globally will automatically be re-generated on add/remove of an eligible optional package

This can be found in %PROGRAMDATA%\Microsoft\AppV\Client\Catalog\PackageGroups\

11. Connection groups added or targeted globally will automatically be re-generated on add/remove of an eligible use any version package

This can be found in %PROGRAMDATA%\Microsoft\AppV\Client\Catalog\PackageGroups\

12. Connection groups enabled to the user will automatically be re-generated on publish/unpublish or remove of an eligible optional package

This can be found in %APPDATA%\Microsoft\AppV\Client\Catalog\PackageGroups\

13. Connection groups enabled to the user will automatically be re-generated on publish/unpublish or remove of an eligible use any version package

This can be found in %APPDATA%\Microsoft\AppV\Client\Catalog\PackageGroups\

14. Connection groups can hold priorities which dictate how overlap conflicts are resolved at launch

This is handled by the Priority=”_” value within the effective .xml. More details on connection group conflicts can be read here

15. Packages within a connection group have priority over each other

This is dictated by the order in which the packages are listed in the connection group (highest priority first). Merged roots in SP3 now mean that conflicting paths will be merged however file conflicts will still be handled via the priority handler I.e file will be read from package with most priority where it can

16. Connection group priority, optional and use any version is not supported within SCCM 2012 native functionality

This applies when using the native ‘Virtual Environments’ functionality for connection groups within SCCM 2012 at this point in time

17. Connection groups can be enabled or disabled to a specific user by an administrator using PowerShell

This is achieved by using the -UserSID parameter when using the Enable-AppVClientConnectionGroup or Disable-AppVClientConnectionGroup cmdlet

18. Connection group members should all have the same settings for COM isolation/integration

By default all COM integration is set to isolated however if you have changed this in any of your member packages then it must be set consistently the same across all others. If not you will receive the following 20001 error and the connection group will not publish.