Welcome to Part 3! In this post, we’ll have a deeper look into how Isolation Groups are implemented in XenDesktop.

Isolation Groups are effectively a VDA setting, passed to all VDAs that describes the packages in the isolation group.

Isolation Groups are Citrix’s implementation of Connection Groups in a XenDesktop environment, and it underlies the implementation.

You can view Connection Groups on the VDA that have been created in response to having created an Isolation Group in Citrix Desktop Studio using the PoSH commandlet :

Get-AppVClientConnectionGroup –all:

Figure: Viewing connection groups on the VDA

You’ll notice that we you can identify a connection group created by XenDesktop by it having the name of the isolation group prepended with “XD-“

Accordingly, you can see the packages in the Connection Group via Microsoft’s powershell appv clikent powershell API call:

Get-AppvClientConnectionGroup –all –Name “XD-Jedit with Java”).GetPackages():

packages in isolation group
Figure : Packages in the connection groups created by XenDesktop

Technically, when creating an isolation group in Citrix Desktop Studio, a VDA setting is created that is created by the broker service on the DDC which is also known as a BrokerMachineConfiguration. This comprises two parts, a BrokerMachineConfigurationSlot and the actual values/data for this configuration is referred to as a BLOBs.  You can think of it as key=value pair in this regard.

BrokerMachineConfigurationSlot(IsolationGroup) = BLOB(definition of the isolation grouop)

These, as explained earlier, are sent down to the VDAs (to the VDA broker agent) and represent Isolation Groups and/or published app-v applications and these are made available in the VDA’s registry for the components on the VDA to act upon:


Figure: BrokerMachineConfigurations representing published AppV applications(ApplicationStartDetail) and Isolation Groups

The COM server, the AppV broker plugin and the ctxAppPLauncher on the VDA are responsible for managing these settings. The two main settings that are central to Isolation Groups are the list of published applications and the list of isolation groups created.

You can see these master configurations/policies/vda settings defined on the DDC by issuing:

Get-BrokerMachineConfiguration | where {$_.Description –like ‘ApplicationStartDetails*’}

This represents each of the published AppV applications in delivery groups.


The Policy member is a byte encoded list of the applications that are included in the application’s package – this is all sent down to the VDA.

Get-BrokerMachineConfiguration | where {$_.Description –like ‘IsolationGroup*’}

This represents the isolation groups associated with VDAs in XenDesktop.


The Policy member is a byte encoded list of the applications that are included in the isolation group and if they are explicit or automatic – this is all sent down to the VDA.

The corresponding data is pushed down to the VDAs and is accessible in the registry in HKLM\Software\Policies\Citrix\AppLibrary key. Within this key are two entries, ApplicationStartDetails and IsolationGroups. Both are multi-line string entries.

The ApplicationStartDetails registry entry represents any AppV application that has been published to the VDA’s Delivery group. The format of which is:

Application Guid\\path\to\constituent\sequence.appvPackage GuidVersion Guid ; Name

For example 4 published applications appear like this:

2cf3d855-9034-48b8-a715-36a66eb5de19;\\ddc.london.local\appvshare\Opera.appv;9736474d-81d6-4106-a1d8-733acc80a7ae;26a84795-24c6-4f01-adf3-f07e1b624bde;Opera12_10 1652

0976032c-8175-4e9c-8ba1-e37eb68781c0(Application Guid);\\ddc.london.local\appvshare\JEdit.appv(sequence location);826bb0b7-f585-4413-ad85-8efe1a019652(package guid);3c54e7ff-8700-471b-87d4-2b8d61fad488(version guid);jEdit(name)


The IsolationGroups registry entry represents all isolation groups that have been created.

The format of which is:

Isolation Group Guid ; Name ; Description | <list of ApplicationStartDetails>

If the package is marked as explicit in the isolation group, the application will be a GUID, otherwise it will be in the format of an ApplicationStartDetail format described above.

If an explicit application GUID also exists in the ApplicationStartDetails entry that means that the application is published, otherwise it means it’s not published and will not be included in the isolation group.

For example an Isolation Group registry blob may look like this:

f3b21485-ed90-4d4d-8ccd-c90b4789c6e6(Isolation group GUID);Jedit with Java(name);(empty description)|0976032c-8175-4e9c-8ba1-e37eb68781c0(explicit package)|a1ffb44c-3e6c-499a-8887-001b70063f6c(explicit package)|c1d078eb-8400-4ece-abdd-7d915fd70de3;\\ddc.london.local\appvshare\JRE7.appv;61d1851f-51e3-4558-89e3-e66767c7a18b;293b4348-8ddb-4698-a431-93872ab8f008;About Java(an automatic package’s pplication)|a6b62af2-2fde-446a-8f7f-5d283ce52693;\\ddc.london.local\appvshare\JRE7.appv;61d1851f-51e3-4558-89e3-e66767c7a18b;293b4348-8ddb-4698-a431-93872ab8f008;Java_TM_ Platform SE binary|e3c26f92-3363-439f-a41d-0ff70ca316d3;\\ddc.london.local\appvshare\JRE7.appv;61d1851f-51e3-4558-89e3-e66767c7a18b;293b4348-8ddb-4698-a431-93872ab8f008;Java_TM_ Web Start Launcher

On the VDA there are 4 components that interact with these registry entries and setting up and isolation group.


Figure 8: Creating Isolation Groups on the VDA

  1. The broker AppV plugin (which is part of the broker agent) on the VDA will receive BrokerMachineConfiguration(settings that represent new/modified isolation groups and/or published AppV applications) sent by the Broker Service on the DDC after these have been created/published in Citrix Desktop Studio.
    1. This component runs as the launching user and is responsible for reading the registry blobs on the VDA and fetching the published AppV application’s package sequence from the defined \\unc location of the package and putting them into a local cache folder on the VDA in preparation for having the app-v client, which is installed on the VDA, ‘add’ and ‘publish’ those packages and/or ‘create’ isolation groups (connection groups) on the VDA. See COM component who is responsible for doing this.
  2. pzVirtAppComServer which is responsible for interacting with the AppV client to ‘add’ the package to the AppV subsystem on the VDA from the local cache folder, as well as ‘creating’ Connection Groups for each of the Isolation Group entries in the registry. This runs as a local administrator as it needs to call the AppV client SDK which requires admin rights for ‘adding’ packages and creating isolation groups.
    1. Adding: Add-AppVClientPackage
    2. Creating: Create-AppVConnectionGroup
  3. exe is responsible for enabling and publishing connection groups and packages to the launching user respectively. This runs as the launching user.
    1. ‘Publishing’ an app-v package to the launching user, the ctxAppVLauncher calls Publish-AppVClientPackage
    2. ‘Enabling’ an isolation group, the ctxAppVLauncher calls Enable-AppvClientConnectionGroup. This is the equivalent of ‘publishing’ an AppV package to the launching user.
  4. App-V PoSH SDK is Microsoft App-V’s client interface, provided by the AppV client on the VDA, that we use to drive the above’s MS AppVClient Posh SDK commands.

When an Isolation Group is created on the VDA, it has an associated version GUID, older versions of that Isolation Group will be removed unless they are being currently used by running applications in that isolation group.

In that case the original, older Isolation Group will remain active while the new version of that connection group version will be created with a lower priority. Meaning the new version (with its changes to its packages) won’t be applied while the older version of the Isolation Group is still being used.

How this works is that we determine the new priority that we’ll need to use to create this connection group:

If the packages, in the isolation group we want to create, are in any other existing isolation groups on the VDA,

Then we get the lowest priority value of all of those connection groups, and make ours lower:

This means that when there is a conflict (launching application is in multiple enabled & existing connection groups), the existing isolation group with the highest priority, will be used over this new one – at launch time.

We lower the priority of the new connection group, by incrementing the priority ‘value’ i.e. 0 = highest priority, 1 = Lower, 2 = Lower still etc…

Dual admin App-V deals with conflicting connection groups (groups that share the same applications) by allowing you to change the priority of connection groups in the management server when these conflicts occur. Because this option is not available to Single Admin, we avoid conflicts entirely from occurring instead with this priority adjustment policy strategy. Otherwise applications might fail to launch entirely.

This also means that when such a conflict occurs (and we lower our priority because of it), the first connection group created is always used, the other lies dormant (lower priority) until the first connection group is deleted.

The last connection group that was created in shown in the ConnectionGroup.xml file in the cache folder.

The older version will remain present and be given preference during application launching. The new version, by virtue of it being created with a lower priority than the original will effectively be queued for usage until it can be applied: When all applications within the older version are shut down and it can be removed by the COM server, then the newer version will take its place (It will now have the higher priority).

Because the COM server is only active when there is a new change to the IsolationGroups blobs or the ApplicationStartDetails blobs, it may take a while before the connection group is removed. Until then, during launch, if the older Isolation Group is now not being used, it will be disabled and thus the newer version will be available for use. The disabled Isolation Group will be removed later when a new Isolation Group is either modified or a new app-v application is published. This can be forced by restarting the broker application but is unnecessary as its disabled now anyway and can’t be used.

As indicated earlier, this priority adjustment policy for new versions of an Isolation Group avoids conflicts where existing connection groups have any of the same packages and could causes the App-V Client to fail to determine which connection Group to apply.

This applies to new Isolation Groups that could potentially conflict with separate existing Isolation Groups because they have the same packages.

An Isolation Group is considered needing to be updated when its constituent packages are added to or removed.

Below is a picture which attempts to pull everything together:

High level overview of Isolation Group creation in XenDesktop


Figure 9: Overview of how Isolation Groups work in Single Admin

  1. Within the App-V node in Citrix Desktop Studio, AppV packages are added or Isolation Groups are defined. BrokerMachineConfigurations are created for these
  2. New App-V applications/Isolation Group details are created and stored in the AppLIbrary its PoSH SDK. These are also called by Citrix Desktop Studio to display packages/Isolation Groups in the UI.
  3. The AppLibrary stores details into its database.
    1. See Isolation Group documentation on how to access Isolation Group details via the AppLibrary’s PoSH interface.
  4. When an AppV application is published, a new broker application is created in XenDesktop, and an associated ApplicationStartDetail BrokerMachineConfiguration is created. This will be pushed down to the VDAs which belong to the Machine Catalogue associated with the delivery group in which it was published.
  5. Details about this published ‘appv’ broker application are stored in the broker database.
  6. Details about the published applications and created Isolation Groups (IsolationGroup and ApplicationStartDetails BrokerMachineConfigurations) are sent by the broker service on trhe DDC to the broker Agent on the VDA.
    1. This happens only when a published application is launched in receiver i.e. it’s not immediately when you create an Isolation Group or publish an AppV application.
  7. Isolation Group and ApplicationStartDetails (published AppV applications) Blobs are received on the VDA and stored in the registry.
  8. The Broker Agent notifies the AppV VDA Plugin of these blob changes
  9. It (AppV VDA Plugin) reads the blobs from the registry and fetches the packages outlined in the ApplicationStartDetails and adds them to the VDAs cache folder.
    1. The cache folder is c:\windows\temp\CitrixAppVPkgCache
    2. The launching user needs to have read/write access to this folder.
    3. This will rename that package to <application name>_<package guid>_<package version guid>.appv.
  1. It (AppV VDA Plugin) asks the COM server to ‘add’ the fetched packages from the AppV cache folder to the AppV subsystem on the VDA as well as create any isolation groups that are defined in the registry.
    1. This are administrative actions and as such are performed by the COM server which runs as a user configured during the VDA installation to be in the Administrators Group on the VDA (CtxAppVCOMAdmin)
  2. The broker plugin will also occasionally unpublish and remove packages from the VDA and local cache if they are no longer being used by XenDesktop.
    1. Technically only application are not in any isolation groups or published in XenApp
    2. This operation is performed by the COM server when new Isolation Groups or AppV-applications are published.

11b. This step shows how the AppV cache folder is populated from published application’s packages sequence network locations (This is done by the Broker Plugin as launching user and not the COM Server)

  1. On a launch the broker plugin invokes the ctxAppVLauncher component which publishes previously added packages (by COM server) and enables isolation groups (previously created by the COM server) to the launching user.
    1. It also disables older version of the connection group if not in use.
  2. exe locates the location of the published application in the AppV subsystem.
  3. Launches the AppV application and the AppV subsystem manages the launch including interpreting the Connection Groups that were created previously, in context of the launching application.

That’s it for this series on Isolation Groups in XenDesktop. Hope you have found it useful.


Why my Isolation Group is not being updated?

It’s possible that it’s still being used by running applications. Shutdown those applications and try relaunching as this should disable older isolation groups allow newer ones to take effect. Also ensure that these AppV applications are not running although seem to have closed: see

Ensuring app-v applications shut down after closing them. http://support.citrix.com/article/CTX138138

Why are their multiple version for the connection group on the VDA?

For every modification to an Isolation Group a new isolation group is created with a new version GUID which might not come into effect if the previous version of that connection group is still being used. So the new version and the old version can be present at the same time while the old version is still in use. The newer version is created with a lower priority and will be applied when the older version is automatically removed/disabled – when all its applications are shut down.

Why is my Isolation Group/Connection group not created on the VDA?

Isolation Groups details are sent to the VDA for creation only when an application that is within an isolation group is launched. If no launch is attempted, no isolation groups will be created on the VDA.

Also ensure that the launching VDA user has access to the UNC path of the application that the user is attempting to launch. If this is the case the appv package cache should contain the sequence formatted as mentioned above.

Refer to the product documentation on Isolation Groups: Citrix Citrix Isolation Groups documentation

Blog Banners -- FOOTER-2