Application Groups let you manage collections of applications. You can create Application Groups for applications shared across different Delivery Groups or used by a subset of users within Delivery Groups. Application Groups are optional; they offer an alternative to adding the same applications to multiple Delivery Groups. Delivery Groups can be associated with more than one Application Group, and an Application Group can be associated with more than one Delivery Group.
Using Application Groups can provide application management and resource control advantages over using more Delivery Groups:
- The logical grouping of applications and their settings lets you manage those applications as a single unit. For example, you don’t have to add (publish) the same application to individual Delivery Groups one at a time.
- Session sharing between Application Groups can conserve resource consumption. In other cases, disabling session sharing between Application Groups may be beneficial.
The following graphic shows a XenApp or XenDesktop deployment that includes Application Groups:
In this configuration, applications are added to the Application Groups, not the Delivery Groups. The Delivery Groups specify which machines will be used. (Although not shown, the machines are in Machine Catalogs.)
Application Group 1 is associated with Delivery Group 1. The applications in Application Group 1 can be accessed by the users specified in Application Group 1, as long as they are also in the user list for Delivery Group 1. This follows the guidance that the user list for an Application Group should be a subset (a restriction) of the user lists for the associated Delivery Groups. The settings in Application Group 1 (such as application session sharing between Application Groups, associated Delivery Groups) apply to applications and users in that group. The settings in Delivery Group 1 (such as anonymous user support) apply to users in Application Groups 1 and 2, because those Application Groups have been associated with that Delivery Group.
Application Group 2 is associated with two Delivery Groups: 1 and 2. Each of those Delivery Groups can be assigned a priority in Application Group 2, which indicates the order in which the Delivery Groups will be checked when an application is launched. Delivery Groups with equal priority are load balanced. The applications in Application Group 2 can be accessed by the users specified in Application Group 2, as long as they are also in the user lists for Delivery Group 1 and Delivery Group 2.
Guidance and considerations
Citrix recommends adding applications to either Application Groups or Delivery Groups, but not both. Otherwise, the additional complexity of having applications in two group types can make it more difficult to manage.
By default, an Application Group is enabled. After you create an Application Group, you can edit the group to change this setting; see the Manage Application Groups article.
By default, application session sharing between Application Groups is enabled; see Session sharing between Application Groups below.
Citrix recommends that your Delivery Groups be upgraded to the current version. This requires (1) upgrading VDAs on the machines used in the Delivery Group, then (2) upgrading the Machine Catalogs containing those machines, and then (3) upgrading the Delivery Group. For details, see Manage Delivery Groups. To use Application Groups, your core components must be minimum version 7.9.
Creating Application Groups requires the Delegated Administration permission of the Delivery Group Administrator built-in role. See the Delegated Administration article for details.
This article refers to "associating" an application with more than one Application Group to differentiate that action from adding a new instance of that application from an available source. Similarly, Delivery Groups are associated with Application Groups (and vice versa), rather than being additions or components of one another.
Session sharing between Application Groups
When you use Application Groups, you can allow or prohibit application session sharing between Application Groups. (This extends the standard session sharing behavior available when using only Delivery Groups, as described in the first example below.) Application session sharing saves the costs associated with launching additional application sessions. It also enables the use of application features that involve the clipboard, such as copy-paste operations.
Example when enabling session sharing between Application Groups is helpful:
A user in Application Group 1 starts an application session by launching Word, and then launches Excel, while Word is still running. If the Controller finds Excel on the same server, the session is shared. (This is the basic session sharing feature that is used in Delivery Groups, if you don't use Application Groups.) If Excel is not found on the same server, and session sharing is enabled for Application Group 1, the Controller then attempts to share the session if the application is found on another server in the Delivery Groups associated with Application Group 1, or in Application Groups 2 and 3.
Example when disabling session sharing between Application Groups is helpful:
You have a set of applications that do not interoperate well with other applications that are installed on the same machines, such as two different versions of the same software suite or two different versions of the same web browser. You prefer not to allow a user to launch both versions in the same session.
You create an Application Group for each version of the software suite, and add the applications for each version of the software suite to the corresponding Application Group. If session sharing between groups is disabled for each of those Application Groups, a user specified in those groups can run applications of the same version in the same session, and can still run other applications at the same time, but not in the same session. If the user launches one of the different-versioned applications (that are in a different Application Group), or launches any application that is not contained in an Application Group, then that application is launched in a new session.
IMPORTANT: This session sharing between Application Groups feature is not a security sandboxing feature. It is not foolproof, and it cannot prevent users from launching applications into their sessions through other means (for example, through Windows Explorer).
If a machine is at capacity, sharing is not allowed.
Application session sharing between Application Groups must be enabled if you want to use the session prelaunch and session linger features; however, those features must be enabled and configured in each of the Delivery Groups associated with the Application Group; you cannot configure them in the Application Groups.
By default, application session sharing between Application Groups is enabled when you create an Application Group; you cannot change this when you create the group. After you create an Application Group, you can edit the group to change this setting; see the Manage Application Groups article.
Create an Application Group
To create an Application Group:
- Select Applications in the Studio navigation pane, and then select Create Application Group in the Actions pane.
- The Create Application Group wizard launches with an Introduction page, which you can remove from future launches of this wizard.
- The wizard guides you through the pages described below. When you are done with each page, click Next until you reach the Summary page.
All Delivery Groups are listed, with the number of machines each contains.
- The Compatible Delivery Groups list contains Delivery Groups you can select. Compatible Delivery Groups contain random (not permanently or statically assigned) server or desktop OS machines.
- The Incompatible Delivery Groups list contains Delivery Groups you cannot select. Each entry explains why it is not compatible, such as containing static assigned machines.
An Application Group can be associated with Delivery Groups containing shared (not private) machines that can deliver applications.
You can also select Delivery Groups containing shared machines that deliver desktops only, if (1) the Delivery Group contains shared machines and was created with an earlier XenDesktop 7.x version, and (2) you have Edit Delivery Group permission. The Delivery Group type is automatically converted to "desktops and applications" when the Create Application Group wizard is committed.
Although you can create an Application Group that has no associated Delivery Groups – perhaps to organize applications or to serve as storage for applications not currently in use – the Application Group cannot be used to deliver applications until it specifies at least one Delivery Group. Additionally, you cannot add applications to the Application Group from the From Start menu source if there are no Delivery Groups specified.
The Delivery Groups you select specify the machines that will be used to deliver applications. Select the check boxes next to the Delivery Groups you want to associate with the Application Group.
Specify who can use the applications in the Application Group. You can either allow all users and user groups in the Delivery Groups you selected on the previous page, or select specific users and user groups from those Delivery Groups. If you restrict use to users you specify, then only the users specified in the Delivery Group and the Application Group can access the applications in this Application Group. Essentially, the user list in the Application Group provides a filter on the user lists in the Delivery Groups.
Enabling or disabling application use by unauthenticated users is available only in Delivery Groups, not in Application Groups.
Where user lists are specified
Active Directory user lists are specified when you create or edit the following:
- A Site’s user access list, which is not configured through Studio. By default, the application entitlement policy rule includes everyone; see the PowerShell SDK BrokerAppEntitlementPolicyRule cmdlets for details.
- Application Group user list.
- Delivery Group user list.
- Application visibility property.
The list of users who can access an application through StoreFront is formed by the intersection of the above user lists. For example, to configure the use of application A to a particular department, without unduly restricting access to other groups:
- Use the default application entitlement policy rule that includes everyone.
- Configure the Delivery Group user list to allow all headquarters users to use any of the applications specified in the Delivery Group.
- Configure the Application Group user list to allow members of the Administration and Finance business unit to access applications named A through L.
- Configure application A’s properties to restrict its visibility to only Accounts Receivable staff in Administration and Finance.
Good to know:
- By default, new applications you add are placed in a folder named Applications. You can specify a different folder. If you try to add an application and one with the same name already exists in that folder, you are prompted to rename the application you are adding. If you agree with the suggested unique name, the application is added with that new name; otherwise, you must rename it yourself before it can be added. For details, see Manage application folders.
- You can change an application's properties (settings) when you add it, or later. See Change application properties. If you publish two applications with the same name to the same users, change the Application name (for user) property in Studio; otherwise, users will see duplicate names in Citrix Receiver.
- When you add an application to more than one Application Group, a visibility issue can occur if you do not have sufficient permission to view the application in all of those groups. In such cases, either consult an administrator with greater permissions or have your scope extended to include all the groups to which the application was added.
Click the Add dropdown to display the application sources.
From Start menu
Applications that are discovered on a machine in the selected Delivery Groups. When you select this source, a new page launches with a list of discovered applications. Select the check boxes of applications to add, and then click OK.
This source cannot be selected if you (1) selected Application Groups that have no associated Delivery Groups, (2) selected Application Groups with associated Delivery Groups that contain no machines, or (3) selected a Delivery Group containing no machines.
Applications located in the Site or elsewhere in your network. When you select this source, a new page launches where you type the path to the executable, working directory, optional command line arguments, and display names for administrators and users. After entering this information, click OK.
Applications previously added to the Site. When you select this source, a new page launches with a list of discovered applications. Select the check boxes of applications to add and then click OK.
This source cannot be selected If the Site has no applications.
Applications in App-V packages. When you select this source, a new page launches where you select the App-V server or the Application Library. From the resulting display, select the checkboxes of applications to add, and then click OK. For more information, see the App-V article.
This source cannot be selected (or might not appear) if App-V is not configured for the Site.
As noted, certain entries in the Add dropdown will not be selectable if there is no valid source of that type. Sources that are incompatible are not listed at all (for example, you cannot add Application Groups to Application Groups, so that source is not listed when you create an Application Group.
This page appears only if you have previously created a scope. By default, the All scope is selected. For more information, see the Delegated Administration article.
Enter a name for the Application Group. You can also (optionally) enter a description.
Review the summary information and then click Finish.