Manage delivery groups

Introduction

This article describes procedures for managing delivery groups from the management console. In addition to changing the settings specified when creating the group, you can configure other settings that are not available when you create a delivery group.

The procedures are organized by categories: general, users, machines, and sessions. Some tasks span more than one category. For example, “Prevent users from connecting to machines” is described in the machines category, but it also affects users. So, if you can’t find a task in one category, check a related category.

Other articles also contain related information:

• Applications contains information about managing applications in delivery groups.
• Managing delivery groups requires the Delivery Group Administrator built-in role permissions. For details, see Delegated administration.

General

• Change the delivery type
• Change StoreFront addresses
• Upgrade a delivery group
• Manage Remote PC Access delivery groups
• Change the license for a delivery group
• Organize delivery groups using folders

Change the delivery type of a delivery group

The delivery type indicates what the group can deliver: applications, desktops, or both.

Before changing an applications type to the Desktops type, delete all applications from the group.

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Edit in the action bar.
3. On the Delivery Type page, select the delivery type you want.
4. Select Apply to apply any changes you made and keep the window open. Or, select OK to apply changes and close the window.

Change StoreFront addresses

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Edit in the action bar.
3. On the StoreFront page, indicate whether you will specify a StoreFront server address later (Manually) or select Add new to specify the StoreFront servers you want to be used (Automatically).
4. Select Apply to apply any changes you made and keep the window open. Or, select OK to apply changes and close the window.

You can also specify StoreFront server addresses by selecting StoreFront in the left pane of the console.

Upgrade a delivery group or revert an upgrade

Upgrade a delivery group after you upgrade the VDAs on its machines and the machine catalogs containing the machines used in the delivery group.

Before you start the delivery group upgrade:

• If you use Citrix Provisioning (formerly Provisioning Services), upgrade the VDA version in the Citrix Provisioning console.
• Start the machines containing the upgraded VDA so that they can register with a Delivery Controller. This process tells the console about what needs upgrading in the delivery group.
• If you must continue to use earlier VDA versions, newer product features might not be available. For more information, see the upgrade documentation.

To upgrade a delivery group:

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Upgrade Delivery Group in the action bar. The Upgrade Delivery Group action appears only if upgraded VDAs are detected.

The display indicates you which, if any, machines cannot be upgraded and why. You can then cancel the upgrade, resolve the machine issues, and then start the upgrade again.

After the upgrade completes, you can revert the machines to their previous states. Select the delivery group and then select Undo in the action bar.

Manage Remote PC Access delivery groups

If a machine in a Remote PC Access machine catalog is not assigned to a user, the machine is temporarily assigned to a delivery group associated with that catalog. This temporary assignment enables the machine to be assigned to a user later.

The delivery group-to-machine catalog association has a priority value. Priority determines which delivery group that machine is assigned to when it registers with the system or when a user needs a machine assignment: the lower the value, the higher the priority. If a Remote PC Access machine catalog has multiple delivery group assignments, the software selects the match with the highest priority. Use the PowerShell SDK to set this priority value.

When first created, Remote PC Access machine catalogs are associated with a delivery group. This association means that machine accounts or Organizational Units added to the catalog later can be added to the delivery group. This association can be switched off or on.

To add or remove a Remote PC Access machine catalog association with a delivery group:

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a Remote PC Access group.
3. In the Details section, select the Machine Catalogs tab and then select a Remote PC Access catalog.
4. To add or restore an association, select Add Desktops. To remove an association, select Remove Association.

Change the license for a delivery group

To change the license entitlement for a delivery group, follow these steps:

1. Select Delivery Groups in the navigation pane.

2. Select a group and then click Edit in the action bar.

3. On the License Assignment page, select the license you want the group to use.

4. Click Apply to apply any changes you made and to keep the window open. Or, click Save to apply changes and to close the window.

For more information about delivery group level entitlements, see Multi-type licensing.

Organize delivery groups using folders

You can create folders to organize delivery groups for easy access.

Required roles

By default, you need to have the following built-in role to create and manage delivery group folders: Cloud Administrator, Full Administrator, or Delivery Group Administrator. If necessary, you can customize roles for creating and managing delivery group folders. For more information, see Required permissions.

Create a delivery group folder

Before you start, plan how to organize your delivery groups. Consider the following:

• You can nest folders up to five levels (excluding the default root folder).
• A folder can contain delivery groups and subfolders.
• All nodes in Full Configuration (such as the Machine Catalogs, Applications, and Delivery groups nodes) share a folder tree in the back-end. To avoid name conflicts with other nodes when renaming or moving folders, we recommend you give different names to first-level folders in different nodes.

To create a delivery group folder, follow these steps:

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. In the folder hierarchy, select a folder and then select Create Folder in the Action bar.
3. Enter a name for the new folder, and then click Done.

Tip:

If you create a folder in an unintended location, you can drag it to the correct location.

Move a delivery group

You can move a delivery group between folders. Detailed steps are as follows:

1. From Manage > Full Configuration, select Delivery Groups in the left pane.

2. View groups by folder. You can also turn on View all above the folder hierarchy to view all groups at a time.

3. Right-click a group and then select Move Delivery Group.

4. Select the folder to which you want to move the group, and then click Done.

Tip:

You can drag a group to a folder.

Manage delivery group folders

You can delete, rename, and move delivery group folders.

Be aware of that you can delete a folder only if it and its subfolders don’t contain delivery groups.

To manage a folder, follow these steps:

1. From Manage > Full Configuration, select Delivery Groups in the left pane.

2. In the folder hierarchy, select a folder, and then select an action in the Action bar as needed:

   • To rename the folder, select Rename Folder.
   • To delete the folder, select Delete Folder.
   • To move the folder, select Move Folder.

3. Follow onscreen instructions to complete the remaining steps.

Required permissions

The following table lists the permissions required to perform actions on delivery group folders.

Users

• Change user settings
• Add or remove users

Change user settings in a delivery group

The name of this page appears as either User Settings or Basic Settings.

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Edit in the action bar.
3. On the User Settings page, change any of the settings in the following table.
4. Select Apply to apply any changes you made and keep the window open. Or, select OK to apply changes and close the window.

Add or remove users in a delivery group

For detailed information about users, see Users.

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Edit Delivery Group in the action bar.

3. On the Users page:

   • To add users, select Add, and then specify the users you want to add.
   • To remove users, select one or more users and then select Remove.
   • Select or clear the check box to allow access by unauthenticated users.
4. Select Apply to apply any changes you made and keep the window open. Or, select OK to apply changes and close the window.

Manage user assignments

To manage user assignments:

1. In Manage > Full Configuration, select Delivery Groups.
2. Select a group and then select Edit Delivery Group in the action bar.
3. On the Machine Allocation page, add or remove users. To add users, browse to them or enter a semicolon-separated list of user names.

When entering user names, consider the following:

• If the users are in Active Directory, enter the names directly. If not, enter the names in this format: <identity provider>:<user name>. Example: AzureAD:username.

Machines

• Change assignments of machines to users
• Update a machine
• Add, change, or remove a tag restriction for a desktop
• Remove a machine
• Restrict access to machines
• Prevent users from connecting to a machine (maintenance mode)
• Shut down and restart machines
• Create and manage restart schedules for machines
• Load manage machines
• Manage Autoscale

In addition to the features described in this article, see Autoscale for information about proactively power managing machines.

Change assignments of machines to users in a delivery group

You can change the assignments of single-session OS machines provisioned with MCS. You cannot change assignments for multi-session OS machines or machines provisioned with Citrix Provisioning.

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Edit in the action bar.
3. On the Machine Allocation page, specify the new users.
4. Select Apply to apply any changes you made and keep the window open. Or, select OK to apply changes and close the window.

Update a machine in a delivery group

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select View Machines in the action bar.
3. Select a machine and then select Update Machines in the action bar.

To choose a different image, select Master image and then select a snapshot.

To apply changes and notify machine users, select Rollout notification to end-users. Then specify:

• When to update the image: now or on the next restart
• The restart distribution time (the total time to begin updating all machines in the group)
• Whether users are notified of the restart
• The message users will receive

Add, change, or remove a tag restriction for a desktop

Adding, changing, and removing tag restrictions can have unanticipated effects on which desktops are considered for launch. Review the considerations and cautions in Tags.

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Edit in the Actions bar.
3. On the Desktops page, select the desktop and select Edit.
4. To add a tag restriction, select Restrict launches to machines with the tag and then select the tag.

5. To change or remove a tag restriction, either:

   • Select a different tag.
   • Remove the tag restriction by clearing Restrict launches to machines with this tag.
6. Select Apply to apply any changes you made and keep the window open. Or, select OK to apply changes and close the window.

Remove a machine from a delivery group

Removing a machine deletes it from a delivery group. It does not delete it from the machine catalog that the delivery group uses. Therefore, that machine is available for assignment to another delivery group.

Machines must be shut down before they can be removed. To temporarily stop users from connecting to a machine while you are removing it, put the machine into maintenance mode before shutting it down.

Machines might contain personal data, so use caution before allocating the machine to another user. Consider reimaging the machine.

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select View Machines in the action bar.
3. Ensure that the machine is shut down.
4. Select the machine and then select Remove from Delivery Group in the action bar.

You can also remove a machine from a delivery group through the connection the machine uses.

Restrict access to machines in a delivery group

Any changes you make to restrict access to machines in a delivery group supersede previous settings, regardless of the method you use. You can:

• Restrict access for administrators using delegated administration scopes: You can create and assign a scope that permits administrators to access all applications, and another scope that provides access to only certain applications. For details, see Delegated administration.

• Restrict access for users through SmartAccess policy expressions: Use policy expressions to filter user connections made through Citrix Gateway.

  1. From Manage > Full Configuration, select Delivery Groups in the left pane.
  2. Select a group and then click Edit in the action bar.
  3. On the Access Policy page, select Connections through Citrix Gateway.
  4. To choose a subset of those connections, select Connections meeting any of the following filters. Then define the Citrix Gateway site, and add, edit, or remove the SmartAccess policy expressions for the allowed user access scenarios. For details, see the Citrix Gateway documentation.
  5. Select Apply to apply any changes you made and to keep the window open. Or, select Save to apply changes and to close the window.

• Restrict access for users through exclusion filters: Use exclusion filters on access policies that you set in the SDK. Access policies are applied to delivery groups to refine connections. For example, you can restrict machine access to a subset of users, and you can specify allowed user devices. Exclusion filters further refine access policies. For example, for security, you can deny access to a subset of users or devices. By default, exclusion filters are disabled.

  For example, to prevent access from a teaching lab on a corporate network subnet to a particular delivery group, regardless of who is using the machines in the lab, use the command: Set-BrokerAccessPolicy -Name VPDesktops_Direct -ExcludedClientIPFilterEnabled $True -.

  You can use the asterisk (*) wildcard to match all tags that start with the same policy expression. For example, if you add the tag VPDesktops_Direct to one machine and VPDesktops_Test to another, setting the tag in the Set-BrokerAccessPolicy script to VPDesktops_* applies the filter to both machines.

  If you are connected using a web browser or with the Citrix Workspace app user experience feature enabled in the store, you cannot use a client name exclusion filter.

Prevent users from connecting to a machine (maintenance mode) in a delivery group

When you need to temporarily stop new connections to machines, you can turn on maintenance mode for one or all machines in a delivery group. You might do this before applying patches or using management tools.

• When a multi-session OS machine is in maintenance mode, users can connect to existing sessions, but cannot start new sessions.
• When a single-session OS machine (or a PC using Remote PC Access) is in maintenance mode, users cannot connect or reconnect. Current connections remain connected until they disconnect or log off.

To turn maintenance mode on or off:

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group.

3. To turn on maintenance mode for all machines in the delivery group, select Turn On Maintenance Mode in the action bar.

   To turn on maintenance mode for one machine, select View Machines in the action bar. Select a machine, and then select Turn On Maintenance Mode in the action bar.

4. To turn maintenance mode off for one or all machines in a delivery group, follow the previous instructions, but select Turn Off Maintenance Mode in the action bar.

Windows Remote Desktop Connection (RDC) settings also affect whether a multi-session OS machine is in maintenance mode. Maintenance mode is on when any of the following occur:

• Maintenance mode is set to on, as described earlier.
• RDC is set to Don’t allow connections to this computer.
• RDC is not set to Don’t allow connections to this computer and the Remote Host Configuration User Logon Mode setting is either Allow reconnections, but prevent new logons or Allow reconnections, but prevent new logons until the server is restarted.

You can also turn maintenance mode on or off for:

• A connection, which affects the machines using that connection.
• A machine catalog, which affects the machines in that catalog.

Shut down and restart machines in a delivery group

This procedure is not supported for Remote PC Access machines.

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select View Machines in the action bar.

3. Select the machine and then select one of the following actions in the action bar:

   Note:

   • The following actions apply only to machines that are power managed.
   • Some options might not be available, depending on the machine state.

   • Force shut down: Forcibly powers off the machine and refreshes the list of machines.
   • Restart: Requests the operating system to shut down and then start the machine again. If the operating system cannot comply, the machine remains in its current state.
   • Force restart: Forcibly shuts down the operating system and then restarts the machine.
   • Suspend: Pauses the machine without shutting it down, and refreshes the list of machines.
   • Shut down: Requests the operating system to shut down.

For non-force actions, if the machine does not shut down within 10 minutes, it is powered off. If Windows attempts to install updates during the shutdown, there is a risk that the machine will be powered off before the updates finish.

Create and manage restart schedules for machines in a delivery group

Note:

• When a restart schedule is applied to a delivery group with Autoscale enabled, its machines are just powered off and left for Autoscale to power them on.
• When restart schedules are applied to random single-session machines, those machines are powered off rather than restarted, to save costs. We recommend that you use Autoscale to power on machines.

A restart schedule specifies when machines in a delivery group are periodically restarted. You can create one or more schedules for a delivery group. A schedule can affect either:

• All the machines in the group.
• One or more (but not all) machines in the group. The machines are identified by a tag that you apply to the machine. This is called a tag restriction, because the tag restricts an action to only items (in this case, machines) that have the tag.

For example, let’s say all of your machines are in one delivery group. You want every machine restarted once every week, and you want the machines used by the accounting team restarted daily. To accomplish this, set up one schedule for all machines, and another schedule for only the machines in accounting.

A schedule includes the day and time the restart begins, and the duration. The duration is either “start all affected machines at the same time” or an interval it will likely take to restart all affected machines.

You can enable or disable a schedule. Disabling a schedule can be helpful when testing, during special intervals, or when preparing schedules before you need them.

You cannot use schedules for automated power-on or shutdown from the management console, only to restart.

Schedule overlap

Multiple schedules can overlap. In the example above, both schedules affect the accounting machines. Those machines might be restarted twice on Sunday. The scheduling code is designed to avoid restarting the same machine more often than intended, but it cannot be guaranteed.

• If the schedules coincide precisely in start and duration times, it is more likely that the machines will be restarted only once.
• The more the schedules differ in start and duration times, it’s more likely that multiple restarts will occur.
• The number of machines affected by a schedule also affects the chance of an overlap. In the example, the weekly schedule that affects all machines might initiate restarts faster than the daily schedule for accounting machines, depending on the duration specified for each.

For an in-depth look at restart schedules, see Reboot schedule internals.

View restart schedules

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Edit in the action bar.
3. Select the Restart Schedule page.

The Restart Schedule page contains the following information for each configured schedule:

• Schedule name.
• Tag restriction used, if any.
• How often the machine restarts occur.
• Whether machine users receive a notification.
• Whether the schedule is enabled. Disabling a schedule can be helpful when testing, during special intervals, or when preparing schedules before you need them.

Add (apply) tags

When you configure a restart schedule that uses a tag restriction, ensure that the tag has been added (applied) to the machines that the schedule affects. In the example above, each of the machines used by the accounting team has a tag applied. For details, see Tags.

Although you can apply more than one tag to a machine, a restart schedule can specify only one tag.

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select the group containing the machines to be controlled by the schedule.
3. Select View Machines and then select the machines you want to add a tag to.
4. Select Manage Tags in the action bar.
5. If the tag exists, enable the check box next to the tag name. If the tag does not exist, select Create and then specify the name for the tag. After the tag is created, enable the check box next to the newly created tag name.
6. Select Save in the Manage Tags dialog.

Create a restart schedule

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Edit in the action bar.
3. On the Restart Schedule page, select Add.

4. On the Add Restart Schedule page:

   • To enable the schedule, select Yes. To disable the schedule, select No.
   • Type a schedule name and description.
   • For Restrict to tag, apply a tag restriction.
   • For Include machines in maintenance mode, choose whether to include machines that are in maintenance mode in this schedule. To use PowerShell instead, see Scheduled restarts for machines in maintenance mode.
   • For Restart frequency, select how often the restart occurs: daily, weekly, monthly, or once. If you select Weekly or Monthly, you can specify one or more specific days.
   • For Repeats every, specify how often you want the schedule to run.
   • For Start date, specify a start date for the first occurrence of the schedule.
   • For Begin restart at, specify, in 24-hour clock format, the time of day to begin the restart.
   • For Restart duration, choose whether to:
     • Restart all machines at the same time.
     • Begin restarting all applicable machines within a certain interval. An internal algorithm determines when each machine is restarted during that interval.

     • Restart all machines after draining all sessions. When the restart time is reached, machines are put into drain state and restarted when all sessions are logged off.

       Note:

       You can use this option for machines that are power managed and also for machines that are not power managed.

   • In Send notification to users, choose whether to display a notification message on the applicable machines before a restart begins. By default, no message appears.
   • If you choose to display a message 15 minutes before the restart begins, you can choose (in Notification frequency) to repeat the message every five minutes after the initial message. By default, the message does not repeat.

   • Enter the notification title and text. There is no default text.

     If you want the message to include a countdown to restart, include the variable %m%. Unless you chose to restart all machines at the same time, the message appears on each machine at the appropriate time before the restart.

5. Click Done to apply the changes and to close the Add Restart Schedule window.

6. Click Apply to apply the changes you made and keep the Edit Delivery Group window open. Or, click Save to apply changes and to close the window.

Immediately run a restart schedule

A restart schedule specifies when machines in a delivery group restart regularly. You can also run a restart schedule immediately to restart the machines in that schedule.

To run a restart schedule immediately, follow these steps:

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select the applicable delivery group and then select Edit in the action bar
3. On the Restart Schedule page, select a schedule that you want to run and then select Run schedule now.

Note:

• You cannot run a schedule immediately if it is configured with the Restart all machines after draining sessions setting.
• You can apply Run schedule now only to one schedule at a time.
• After you edit a schedule, Run schedule now becomes unavailable. Select Apply to make it available.

Edit, remove, enable, or disable a restart schedule

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Edit in the action bar.
3. On the Restart Schedule page, select the check box for a schedule.
   • To edit a schedule, select Edit. Update the schedule configuration, using the guidance in Create a restart schedule.
   • To enable or disable a schedule, select Edit. Select or clear the Enable restart schedule check box.
   • To remove a schedule, select Remove. Confirm the removal. Removing a schedule does not affect any tags applied to machines in the affected machines.

Scheduled restarts delayed due to database outage

Note:

This feature is available only in PowerShell.

If a site database outage occurs before a scheduled restart begins for machines (VDAs) in a delivery group, the restarts begin when the outage ends. This action can have unintended results.

For example, let’s say you’ve scheduled a delivery group’s restarts to occur during off-production hours (beginning at 3 am). A site database outage occurs one hour before a scheduled restart begins (2 am). The outage lasts six hours (until 8 am). The restart schedule begins when the connection between the Delivery Controller and the site database is restored. The VDA restarts now begin five hours after their original schedule. This action might result in VDAs restarting during production hours.

To help avoid this situation, you can use the MaxOvertimeStartMins parameter for the New-BrokerRebootScheduleV2 and Set-BrokerRebootScheduleV2 cmdlets. The value specifies the maximum number of minutes beyond the scheduled start time that a restart schedule can begin.

• If the database connection is restored within that time (scheduled time + MaxOvertimeStartMins), the VDA restarts begin.

• If the database connection is not restored within that time, the VDA restarts do not begin.

• If this parameter is omitted or has a zero value, the scheduled restart begins when the connection to the database is restored, regardless of the outage duration.

For more information, see the cmdlet help. This feature is available only in PowerShell.

Scheduled restarts for machines in maintenance mode

To indicate whether a restart schedule affects machines that are in maintenance mode, use the IgnoreMaintenanceMode option with the BrokerRebootScheduleV2 cmdlets.

For example, the following cmdlet creates a schedule that restarts both machines that are and machines that are not in maintenance mode.

New-BrokerRebootSchedulev2 rebootSchedule1 -DesktopGroupName <myDesktopGroup> -IgnoreMaintenanceMode $true

The following cmdlet modifies an existing restart schedule.

Set-BrokerRebootSchedulev2 rebootSchedule1 -IgnoreMaintenanceMode $true

For more information, see the cmdlet help.

Load manage machines in delivery groups

You can load manage multi-session OS machines only.

Load management measures the server load and determines which server to select under the current environment conditions. This selection is based on:

• Server maintenance mode status: A multi-session OS machine is considered for load balancing only when maintenance mode is off.

• Server load index: Determines how likely a server delivering multi-session OS machines is to receive connections. The index is a combination of load evaluators: the number of sessions and the settings for performance metrics such as CPU, disk, and memory use. Load evaluators are specified in load management policy settings.

  A server load index of 10000 indicates that the server is fully loaded. If no other servers are available, users might receive a message that the desktop or application is currently unavailable when they launch a session.

  You can monitor the load index in Director (Monitor), a Full Configuration management interface search, and the SDK.

  In console displays, to display the Server Load Index column (which is hidden by default), select a machine, right-click a column heading, and then select Select Column. In the Machine category, select Load Index.

  In the SDK, use the Get-BrokerMachine cmdlet. For details, see CTX202150.

• Concurrent logon tolerance policy setting: The maximum number of concurrent requests to log on to the server. (This setting is equivalent to load throttling in XenApp 6.x versions.)

  When all servers are at or higher than the concurrent logon tolerance setting, the next logon request is assigned to the server with the lowest pending logons. If more than one server meets these criteria, the server with the lowest load index is selected.

Manage Autoscale

By default, Autoscale is disabled for delivery groups. To manage Autoscale for a delivery group (if applicable), follow these steps:

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Manage Autoscale in the action bar. The Manage Autoscale window appears.
3. Configure settings as needed. For information about Autoscale settings, see Autoscale.
4. Select Apply to apply any changes you made and to keep the window open. Or, select Save to apply changes and to close the window.

Sessions

• Log off or disconnect a session, or send a message to users
• Configure session prelaunch and session linger
• Control session reconnection when disconnected from machine in maintenance mode

Log off or disconnect a session, or send a message to delivery group users

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select View Machines in the action bar.
3. To log a user off a session, select the session or desktop and then select Log off in the action bar. The session closes and the machine becomes available to other users, unless it is allocated to a specific user.
4. To disconnect a session, select the session or desktop and then select Disconnect in the action bar. Applications continue to run and the machine remains allocated to that user. The user can reconnect to the same machine.
5. To send a message to users, select the session, machine, or user and then select Send message in the action bar. Enter the message.

Configure session prelaunch and session linger in a delivery group

These features are supported only on multi-session OS machines.

The session prelaunch and session linger features help specified users access applications quickly, by:

• Starting sessions before they are requested (session prelaunch)
• Keeping application sessions active after a user closes all applications (session linger)

By default, session prelaunch and session linger are not used. A session starts (launches) when a user starts an application, and remains active until the last open application in the session closes.

Considerations:

• The delivery group must support applications, and the machines must be running a VDA for multi-session OS, minimum version 7.6.
• These features are supported only when using Citrix Workspace app for Windows, and also require more Citrix Workspace app configuration. For instructions, search for session prelaunch in the product documentation for your Citrix Workspace app for Windows version.
• Citrix Workspace app for HTML5 is not supported.
• When using session prelaunch, if a user’s machine is put into suspend or hibernate mode, prelaunch does not work (regardless of session prelaunch settings). Users can lock their machines/sessions. However, if a user logs off from Citrix Workspace app, the session is ended and prelaunch no longer applies.
• When using session prelaunch, physical client machines cannot use the suspend or hibernate power management functions. Client machine users can lock their sessions but should not log off.
• Prelaunched and lingering sessions consume a concurrent license, but only when connected. If using a user/device license, the license lasts 90 days. Unused prelaunched and lingering sessions disconnect after 15 minutes by default. This value can be configured in PowerShell (New/Set-BrokerSessionPreLaunch cmdlet).
• Careful planning and monitoring of your users’ activity patterns are essential to tailoring these features to complement each other. Optimal configuration balances the benefits of earlier application availability for users against the cost of keeping licenses in use and resources allocated.
• You can also configure session prelaunch for a scheduled time of day in Citrix Workspace app.

How long unused prelaunched and lingering sessions remain active

There are several ways to specify how long an unused session remains active if the user does not start an application: a configured timeout and server load thresholds. You can configure all of them. The event that occurs first causes the unused session to end.

• Timeout: A configured timeout specifies the number of minutes, hours, or days an unused prelaunched or lingering session remains active. If you configure too short a timeout, prelaunched sessions end before they provide the user benefit of quicker application access. If you configure too long a timeout, incoming user connections might be denied because the server doesn’t have enough resources.

  You can enable this timeout from the SDK only (New/Set-BrokerSessionPreLaunch cmdlet), not from the management console. If you disable the timeout, it does not appear in the console display for that delivery group or in the Edit Delivery Group pages.

• Thresholds: Automatically ending prelaunched and lingering sessions based on server load ensures that sessions remain open as long as possible, assuming that server resources are available. Unused prelaunched and lingering sessions do not cause denied connections because they are ended automatically when resources are needed for new user sessions.

  You can configure two thresholds: the average percentage load of all servers in the delivery group, and the maximum percentage load of a single server in the group. When a threshold is exceeded, the sessions that have been in the prelaunch or lingering state for the longest time are ended. Sessions are ended one-by-one at minute intervals until the load falls below the threshold. While the threshold is exceeded, no new prelaunch sessions are started.

Servers with VDAs that have not registered with a Controller and servers in maintenance mode are considered fully loaded. An unplanned outage causes prelaunch and lingering sessions to end automatically to free capacity.

To enable session prelaunch

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Edit in the action bar.

3. On the Application Prelaunch page, enable session prelaunch by choosing when sessions launch:

   • When a user starts an application. This is the default setting. Session prelaunch is disabled.
   • When any user in the delivery group logs on to Citrix Workspace app for Windows.
   • When anyone in a list of users and user groups logs on to Citrix Workspace app for Windows. Be sure to also specify users or user groups if you choose this option.

   

4. A prelaunched session is replaced with a regular session when the user starts an application. If the user does not start an application (the prelaunched session is unused), the following settings affect how long that session remains active.

   • When a specified time interval elapses. You can change the time interval (1–99 days, 1–2376 hours, or 1–142,560 minutes).
   • When the average load on all machines in the delivery group exceeds a specified percentage (1–99%).
   • When the load on any machine in the delivery group exceeds a specified percentage (1–99%).

   Recap: A prelaunched session remains active until one of the following events occurs: a user starts an application, the specified time elapses, or a specified load threshold is exceeded.

To enable session linger

1. From Manage > Full Configuration, select Delivery Groups in the left pane.
2. Select a group and then select Edit in the action bar.

3. On the Application Lingering page, enable session linger by selecting Keep sessions active until.

   

4. Several settings affect how long a lingering session remains active if the user does not start another application.

   • When a specified time interval elapses. You can change the time interval: 1–99 days, 1–2376 hours, or 1–142,560 minutes.
   • When the average load on all machines in the delivery group exceeds a specified percentage: 1–99%.
   • When the load on any machine in the delivery group exceeds a specified percentage: 1–99%.

   Recap: A lingering session remains active until one of the following events occurs: a user starts an application, the specified time elapses, or a specified load threshold is exceeded.

Control session reconnection when disconnected from machine in maintenance mode

Note:

This feature is available only in PowerShell.

You can control whether sessions that are disconnected on machines in maintenance mode are allowed to reconnect to machines in the delivery group.

Before late May 2021, reconnection was not allowed for single-session pooled desktop sessions that had disconnected from machines in maintenance mode. Now, you can configure a delivery group to allow or prohibit reconnections (regardless of session type) after disconnection from a machine in maintenance mode.

When creating or editing a delivery group (New-BrokerDesktopGroup, Set-BrokerDesktopGroup), use the -AllowReconnectInMaintenanceMode <boolean> parameter to allow or prohibit reconnections for machines that were disconnected from a machine in maintenance mode.

• When set to true, sessions can reconnect to machines in the group.
• When set to false, sessions cannot reconnect to machines in the group.

Default values:

• Single-session: Disabled
• Multi-session: Enabled

Troubleshoot

• VDAs that are not registered with a Delivery Controller are not considered when launching brokered sessions. This results in underutilization of otherwise available resources. There are various reasons a VDA might not be registered, many of which an administrator can troubleshoot. The details display provides troubleshooting information in the catalog creation wizard, and after you add a catalog to a delivery group.

  After you create a delivery group, the details pane for a delivery group indicates the number of machines that are expected to be registered but are not. For example, one or more machines are powered on and not in maintenance mode, but are not currently registered with a Controller. When viewing a “not registered, but should be” machine, review the Troubleshoot tab in the details pane for possible causes and recommended corrective actions.

  For messages about functional level, see VDA versions and functional levels.

  For information about VDA registration troubleshooting, seeCTX136668.

• In the display for a delivery group, the Installed VDA version in the details pane might differ from the actual version installed on the machines. The machine’s Windows Programs and Features display shows the actual VDA version.
• For machines with Power State Unknown status, see CTX131267 for guidance.