By design, App-V applications are isolated from each other and each AppV application is run within its own separate virtual environment—they do not share any data with other AppV applications.
While this application isolation is welcome, as it promotes application compatibility by preventing any cross-application conflict, there is a need, at times, to overcome this restriction in certain strategic scenarios.
Typically, if multiple applications need to share data, they’d have to be sequenced together into one monolithic AppV package/sequence.
Management of the constituent individual applications within that package separately would not be possible. This means AppV applications sequenced together in this fashion could not be updated or upgraded separately without re-sequencing or re-creating the package (now with any updated applications therein).
By default, Microsoft App-V provides a mechanism to deal both with overcoming this absolute isolation between AppV applications (sharing data between applications) and the need to be able to separate constituent applications for easier package management and maintenance. This mechanism is called Connection Groups. This enables a “shared isolation environment” between two or more separately managed packages, all placed within the same Connection Group. All packages (and their applications) can then communicate and ‘see’ each other, thereby overcoming their default individual isolation.
Membership to a connection group is flexible, and an application can be moved or removed into or from other connection groups to gain access to the shared isolation environment of those packages. These applications are now free to be updated individually before being added back into a Connection Group.
The Connection Groups feature is provided by the Microsoft AppV Management Server.
You can find more information on Connection Groups in the Microsoft AppV documentation.
The use cases for Connection Groups (Isolation Groups)
The main scenario in which you’d like to share two or more applications’ virtual environments this way (allowing them to ‘see’ each other), is when one is a runtime dependency of the other (meaning one needs to see the other application in order to run, such as needing to ‘see’ the Java Runtime Environment) particularly if the launching application is a Java application for instance that thus requires it. Another example in the same vain is having say acrobat reader and safari in the same connection group so that Safari/Chrome/Firefox can launch .pdf files when the user clicks on a link to a .pdf file.
The other scenario is when separate applications are designed to co-habitat by default, say to extend the functionality of one application such as an application plugin, which would require both the plugin and the host application to be in the same isolation environment or Connection Group (or in our case, a Citrix Isolation Group when in XenApp):
Citrix supports integrating with an existing “Dual Admin” App-V implementation (which would include an existing AppV Management/Publishing Server) into XenDesktop as well as a native (“Single Admin”) App-V support which works without the need of an existing Microsoft AppV management server. The former is to support existing App-V infrastructure and the latter is typically for new deployments where AppV is not yet used but can be easily used in XenDesktop with minimal configuration and without the need for installing additional AppV infrastructure.Connection Group Support in XenApp
Dual admin has native support for Connection Groups, while Single Admin’s implementation of Connection Groups within a XenApp environment is achieved by using “Isolation Groups” feature in the same way. In this document I’ll describe what Isolation Groups are, how they work but they are basically Connection Groups in a XenApp environment.
Figure 2 Managing AppV in XenDesktop (Single Admin)
Creating an isolation Group
You can add App-V packages to isolation groups in Citrix Desktop Studio through the “Isolation Groups” tab and applies only to packages that have been added to Studio – Single Admin(Dual Admin support already supports Connection Groups).
Creating an isolation group effectively manages the creation and maintenance of Connection Groups on the VDA.
Creating Isolation Groups is a global operation, where isolation group configuration policies are pushed down to all delivery groups and then are selectively applied to delivery groups according to the delivery group meeting the isolation groups’ package requirements.
Package requirements are set when defining an Isolation group. This is done by setting packages as either “Explicit” or “automatic”:
Figure 3 Adding packages to an Isolation Group
This will create an Isolation Group containing the candidate packages you’ve selected. These packages will now be able to share the same isolation group and interact with each other without restriction. As Isolation Groups is a feature of Single Admin integration, you are only able to add packages that you’ve directly added to Citrix Desktop Studio from a UNC share.
- Explicit packages will be included in the isolation group only if the package is published to the launching user i.e. added to a delivery group.
- Automatic packages will be included in the isolation group without requiring the application to be published to the launching user (It need not be added to a Delivery Group and it will be available automatically on the VDA). This automatic package is transparently ‘pushed’ to the VDA automatically by the VDA’s broker AppV plugin, copying it from the package’s UNC path directly to the VDA.
Isolation Groups are shared across all VDAs (Delivery Groups), however they only effectively activate depending on how the isolation group’s package restrictions are met (explicit or automatic package inclusion)
That is it for this brief introduction to Isolation Groups in Xen Desktop. The take away from this is that it’s easy to add Connection Groups functionality to Xen Desktop without AppV servers which manage it.
