Advanced Connection Groups – The Sanity Check

Share on facebook
Share on twitter
Share on linkedin
Share on reddit
Share on stumbleupon

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.


Leave a Reply.

8 thoughts on “Advanced Connection Groups – The Sanity Check”

  1. Missing the main issue where the connection group members COM setting needs to be aligned. i.e. if one member of the ACG has COM enabled than all members need to have the same setting.

    This can cause problems as some applications fail to function when COM enabled.

    Also, depending on the deployment scenario the package may need to be updated (if not using the Deployment Config file).

      • Yes…

        Some apps fail with COM enabled so unfortunately ACG is not a silver bullet for communication between App-V apps.

  2. Hi,

    I have 2 questions on connection group:
    1) I have 2 versions(1.0 and 2.0) which is having dependency which is common to both version. But i cannot use the option “use any versions” to use latest version since few users uses version 1 and others uses 2.0 due to license restrictions. We need to keep both. Do we need to have 2 separate connection group in this instance?Please advise
    2. How does connection group picks latest version. The application should contain same package ID to use “use any version”?


  3. Hi Manju,

    In this scenario you should create two connection groups for each version. The ‘use any version’ feature picks the latest version for the PackageID.

    • Thanks. I have one more question.

      We have 2 version of the package with different package ID and version which was created by 2 different team. Is there way where we can modify latest App-v package to change package ID to maintain same package id for all version.


  4. Hi Thamim Karim,

    We have Application A with user settings keys.The settings are getting saved when user changes the values as standalone publish.
    But once Application becomes part of connection group. Application user settings will not get saved if user updates path. For each launch it pulls up defaults user settings. Is it know behavior for connection group application?


Comments are closed.