Create Application Groups
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.
- You can use the tag restriction feature to publish applications from an Application Group, considering only a subset of the machines in selected Delivery Groups. With tag restrictions, you can use your existing machines for more than one publishing task, saving the costs associated with deploying and managing additional machines. A tag restriction can be thought of as subdividing (or partitioning) the machines in a Delivery Group. Using an Application Group or desktops with a tag restriction can be helpful when isolating and troubleshooting a subset of machines in a Delivery Group.
The following graphic shows a Citrix Virtual Apps and Desktops 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.
This simple layout uses tag restrictions to limit which machines will be considered for certain desktop and application launches. The site has one shared Delivery Group, one published desktop, and one Application Group configured with two applications.
Tags have been added to each of the three machines (VDA 101-103).
The Application Group was created with the “Orange” tag restriction, so each of its applications (Calculator and Notepad) can be launched only on machines in that Delivery Group that have the tag “Orange”: VDA 102 and 103.
For more comprehensive examples and guidance for using tag restrictions in Application Groups (and for desktops), see Tags.
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 Manage Application Groups.
By default, application session sharing between Application Groups is enabled. See Session sharing between Application Groups.
Citrix recommends that your Delivery Groups be upgraded to the current version. This requires:
- Upgrading VDAs on the machines used in the Delivery Group
- Upgrading the machine catalogs containing those machines
- 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 Delegated Administration 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 with Application Groups
When application session sharing is enabled, all applications launch in the same application session. This saves the costs associated with launching additional application sessions, and allows the use of application features that involve the clipboard, such as copy-paste operations. However, in some situations you may wish to turn off session sharing.
When you use Application Groups you can configure application session sharing in the following three ways which extend the standard session sharing behavior available when you are using only Delivery Groups:
- Session sharing enabled between Application Groups.
- Session sharing enabled only between applications in the same Application Group.
- Session sharing disabled.
You can enable application session sharing between Application Groups, or you can disable it to limit application session sharing only to applications in the same Application Group.
An example when enabling session sharing between Application Groups is helpful:
Application Group 1 contains Microsoft Office applications such as Word and Excel. Application Group 2 contains other applications such as Notepad and Calculator, and both Application Groups are attached to the same Delivery Group. A user who has access to both Application Groups starts an application session by launching Word, and then launches Notepad. If the controller finds that the user’s existing session running Word is suitable for running Notepad then Notepad is started within the existing session. If Notepad cannot be run from the existing session—for example if the tag restriction excludes the machine that the session is running on—then a new session on a suitable machine is created rather than using session sharing.
An 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.
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, new sessions are not started on it. New applications are started in existing sessions on the machine as needed using session sharing (providing that this complies with the session sharing restrictions described here).
You can only make prelaunched sessions available to Application Groups which have application session sharing allowed. (Sessions which use the session linger feature are available to all Application Groups.) These 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 Manage Application Groups.
You can prevent application session sharing between applications which are in the same Application Group.
An example when disabling session sharing within Application Groups is helpful:
You want your users to access multiple simultaneous full screen sessions of an application on separate monitors.
You create an Application Group and add the applications to it. If session sharing is prohibited between applications in that Application Group, when a user specified in it starts one application after another they launch in separate sessions, and the user can move each to a separate monitor.
By default, application session sharing 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 Manage Application Groups.
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.
The Delivery Groups page lists all Delivery Groups, with the number of machines each group contains.
- The Compatible Delivery Groups list contains Delivery Groups you can select. Compatible Delivery Groups contain random (not permanently or statically assigned) multi-session or single-session 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 only desktops, if both of the following conditions are met:
- The Delivery Group contains shared machines and was created with a XenDesktop version earlier than 7.9.
- 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 used) 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.
To add a tag restriction, select Restrict launches to machines with the tag and then select the tag from the dropdown.
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.
For information about where user lists are specified in a deployment, see Where user lists are specified.
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 Workspace app.
- 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 selected any of the following:
- Application Groups that have no associated Delivery Groups.
- Application Groups with associated Delivery Groups that contain no machines.
- A Delivery Group containing no machines.
- Manually defined: 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.
- Existing: 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.
- App-V: 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 App-V. 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 custom scope. By default, the All scope is selected. For more information, see Delegated Administration.
Enter a name for the Application Group. You can also (optionally) enter a description.
Review the summary information and then click Finish.