Manage delivery groups

Introduction

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

Procedure categories include: 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. If you can’t find a task in one category, check a related category.

Other articles also contain related information:

• Applications contain 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 delivery type of a delivery group

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

Before changing an application only or desktops and applications type to the desktops only type, delete all applications from the group.

1. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.
3. On the Delivery Type page, select the delivery type you want.
4. Click Apply to apply any changes you made and keep the window open. Or, click OK to apply changes and close the window.

Change StoreFront addresses

1. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.
3. On the StoreFront page, select or add StoreFront URLs. These URLs are used by the Citrix Workspace app, which is installed on each machine in the delivery group.
4. Click Apply to apply any changes you made and keep the window open. Or, click OK to apply changes and close the window.

You can also specify StoreFront server addresses by selecting Configuration > StoreFront in the navigation pane.

Upgrade a delivery group or revert an upgrade

Upgrade a delivery group after you upgrade the Virtual Delivery Agents (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 continue to use earlier VDA versions, newer product features are not available. For more information, see the upgrade documentation.

To upgrade a delivery group:

1. Select Delivery Groups in the navigation pane.
2. Select a group and then click Upgrade Delivery Group in the Actions pane. 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 by selecting the delivery group and then clicking Undo in the Actions pane.

Manage Remote PC Access delivery groups

If a machine in a Remote PC Access machine catalog is not assigned, 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 the machine’s assigned delivery group 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. 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. Select Delivery Groups in the navigation pane.
2. Select a Remote PC Access group.
3. In the Details section, click the Machine Catalogs tab and then select a Remote PC Access catalog.
4. To add or restore an association, click Add Desktops. To remove an association, click Remove Association.

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. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.
3. On the User Settings (or Basic Settings) page, change any of the settings in the following table.
4. Click Apply to apply any changes you made and keep the window open. Or, click OK to apply changes and close the window.

Setting	Description
Description	The text that Citrix Workspace (or StoreFront) uses and that users see.
Enable delivery group	Whether the delivery group is enabled.
Time zone	The time zone in which the machines of this delivery group must reside. The option lists the time zones supported by the site.
Enable Secure ICA	Secures communications to and from machines in the delivery group using SecureICA, which encrypts the ICA protocol. The default level is 128-bit. The level can be changed using the SDK. Citrix recommends using more encryption methods such as TLS encryption when traversing public networks. Also, SecureICA does not check data integrity.

Add or remove users in a delivery group

For detailed information about users, see Users.

1. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.

3. On the Users page:

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

Import or export user lists

For delivery groups containing physical single-session OS machines, you can import user information from a .csv file after you create the delivery group. You can also export user information to a .csv file. The .csv file can contain data from a previous product version.

The first line in the .csv file must contain comma-separated column headings (in any order), which can include: ADComputerAccount, AssignedUser, VirtualMachine, and HostId. Subsequent lines in the file contain comma-separated data. The ADComputerAccount entries can be common names, IP addresses, distinguished names, or domain and computer name pairs.

To import or export user information:

1. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.
3. On the Machine Allocation page, select Import list or Export list, and then browse to the file location.
4. Click Apply to apply any changes you made and keep the window open. Or, click OK to apply changes and close the window.

Machines

• Change assignments of machines to users
• Change the maximum number of machines per user
• 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 managed machines
• Power managed 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. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.
3. On the Desktops or Desktop Assignment Rules page (the page title depends on the type of machine catalog the delivery group uses), specify the new users.
4. Click Apply to apply any changes you made and keep the window open. Or, click OK to apply changes and close the window.

Change the maximum number of machines per user in a delivery group

1. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.
3. On the Desktop Assignment Rules page, set the maximum desktops per user value.
4. Click Apply to apply any changes you made and keep the window open. Or, click OK to apply changes and close the window.

Update a machine in a delivery group

1. Select Delivery Groups in the navigation pane.
2. Select a group and then click View Machines in the Actions pane.
3. Select a machine and then click Update Machines in the Actions pane.

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 master 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 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. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.
3. On the Desktops page, select the desktop and click 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. Click Apply to apply any changes you made and keep the window open. Or, click 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. Select Delivery Groups in the navigation pane.
2. Select a group and then click View Machines in the Actions pane.
3. Ensure that the machine is shut down.
4. Select the machine and then click Remove from Delivery Group in the Actions pane.

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: 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. Select Delivery Groups in the navigation pane.
  2. Select a group and then click Edit Delivery Group in the Actions pane.
  3. On the Access Policy page, select Connections through NetScaler 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. Click Apply to apply any changes you made and keep the window open. Or, click OK to apply changes and 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, a teaching lab on a corporate network subnet which prevents access from that lab 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 -.

  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. Select Delivery Groups in the navigation pane.
2. Select a group.

3. To turn on maintenance mode for all machines in the delivery group, click Turn On Maintenance Mode in the Actions pane.

   To turn on maintenance mode for one machine, click View Machines in the Actions pane. Select a machine, and then click Turn On Maintenance Mode in the Actions pane.

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

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. 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. Select Delivery Groups in the navigation pane.
2. Select a group and then click View Machines in the Actions pane.

3. Select the machine and then click one of the following entries in the Actions pane:

   • 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 is powered off before the updates finish.

Citrix recommends that you prevent single-session OS machine users from selecting Shut down within a session. See the Microsoft policy documentation for details.

You can also shut down and restart machines on a connection.

Create and manage restart schedules for machines in a delivery group

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 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.

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 are restarted only once.
• The more the schedules differ in start and duration times, it’s more likely that multiple restarts 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. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.
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.

Add (apply) tags

When you configure a restart schedule that uses a tag restriction, ensure that the tag has been added 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. Select Delivery Groups in the navigation pane.
2. Select the group containing the machines controlled by the schedule.
3. Click View Machines and then select the machines you want to add a tag to.
4. Click Manage Tags in the Actions pane.
5. If the tag exists, enable the check box next to the tag name. If the tag does not exist, click 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. Click Save in the Manage Tags dialog.

Create a restart schedule

1. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.
3. On the Restart Schedule page, click Add.

4. On the Add Restart Schedule page:

   • Type a schedule name and description.
   • If you’re using a tag restriction, select the tag.
   • In Restart frequency, select how often the restart occurs: daily, weekdays, weekend days, or a specific day each week.
   • Using the 24-hour clock, specify the time of day to begin the restart.

   • For Restart duration, choose whether all machines are restarted at the same time, or the total length of time to begin restarting all the affected machines. An internal algorithm determines when each machine is restarted during that interval.

     Note:

     Another restart duration choice is available when using PowerShell. See Restart after drain.

   • In Send notification to users, choose whether to display a notification message on the affected machines before a restart begins. By default, no message is displayed.
   • 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 is not repeated.

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

     If you want the message to include the number of minutes before restart, include the variable %m%. For example: “Warning: Your computer is automatically restarted in %m% minutes.” The value decrements by five minutes in each repeated message. Unless you chose to restart all machines at the same time, the message displays on each machine at the appropriate time before the restart, calculated by the internal algorithm.

   • To enable the schedule, select the check box. To disable the schedule, clear the check box.
5. Click Apply to apply the changes you made and keep the window open. Or, click OK to apply changes and close the window.

Restart after drain

Another restart duration value is available when using PowerShell to create or update a machine restart schedule (New-BrokerRebootSchedulev2 or Set-BrokerRebootSchedulev2).

When you enable the restart after drain feature with the -UseNaturalReboot <Boolean> parameter, all machines are restarted after draining all sessions. When the restart time is reached, machines are put into the drain state and then restarted when all sessions are logged off.

This feature is supported for delivery groups containing single-session or multi-session machines. The machines must be power managed.

In an on-premises environment, this feature is supported only when using PowerShell. The feature is not available in Studio.

Edit, remove, enable, or disable a restart schedule

1. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.
3. On the Restart Schedule page, select the check box for a schedule.
   • To edit a schedule, click Edit. Update the schedule configuration, using the guidance in Create a restart schedule.
   • To enable or disable a schedule, click Edit. Select or clear the Enable restart schedule check box.
   • To remove a schedule, click 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 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 03:00). A site database outage occurs one hour before a scheduled restart begins (02:00). The outage lasts six hours (until 08:00). 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, resulting 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. You cannot set this value when configuring a restart schedule in Studio.

Scheduled restarts for machines in maintenance mode

Note:

This feature is available only in PowerShell.

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

For example, the following cmdlet creates a schedule that restarts machines that are in maintenance mode (in addition to machines that aren’t 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. This feature is available only in PowerShell.

Load managed 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 unavailable when they launch a session.

  You can monitor the load index in Director (Monitor), Studio (Manage) 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.

Power managed machines in a delivery group

You can power manage only virtual single-session OS machines, not physical machines (including Remote PC Access machines). Single-session OS machines with GPU capabilities cannot be suspended, so power-off operations fail. For multi-session OS machines, you can create a restart schedule.

In delivery groups containing pooled machines, virtual single-session OS machines can be in one of the following states:

• Randomly allocated and in use
• Unallocated and unconnected

In delivery groups containing static machines, virtual single-session OS machines can be:

• Permanently allocated and in use
• Permanently allocated and unconnected (but ready)
• Unallocated and unconnected

During normal use, static delivery groups typically contain both permanently allocated and unallocated machines. Initially, all machines are unallocated, except for manually allocated ones when the delivery group was created. As users connect, machines become permanently allocated. You can fully power manage the unallocated machines in those delivery groups, but only partially manage the permanently allocated machines.

• Pools and buffers: For pooled delivery groups and static delivery groups with unallocated machines, a pool (in this instance) is a set of unallocated or temporarily allocated machines that are kept in a powered-on state, ready for users to connect. A user gets a machine immediately after logon. The pool size (the number of machines kept powered-on) is configurable by time of day. For static delivery groups, use the SDK to configure the pool.

  A buffer is an extra standby set of unallocated machines that are turned on when the number of machines in the pool falls below a threshold. The threshold is a percentage of the delivery group size. For large delivery groups, a significant number of machines might be turned on when the threshold is exceeded. So, plan delivery group sizes carefully or use the SDK to adjust the default buffer size.

• Power state timers: You can use power state timers to suspend machines after users have disconnected for a specified amount of time. For example, machines suspend automatically outside of office hours if users are disconnected for at least 10 minutes.

  You can configure timers for weekdays and weekends, and for peak and nonpeak intervals.

• Partial power management of permanently allocated machines: For permanently allocated machines, you can set power state timers, but not pools or buffers. The machines are turned on at the start of each peak period, and turned off at the start of each off-peak period. You do not have the fine control that you have with unallocated machines over the number of machines that become available to compensate for machines that are consumed.

Power manage virtual single-session OS machines

1. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.
3. On the Power Management page, select Weekdays in Power manage machines. By default, weekdays are Monday to Friday.
4. For random Delivery groups, in Machines to be powered on, click Edit and then specify the pool size during weekdays. Then, select the number of machines to power on.
5. In Peak hours, set the peak and off-peak hours for each day.
6. Set the power state timers for peak and non-peak hours during weekdays: In During peak hours > When disconnected, specify the delay (in minutes) before suspending any disconnected machine in the delivery group, and then select Suspend. In During off-peak hours > When disconnected, specify the delay before turning off any logged-off machine in the delivery group, and then select Shutdown. This timer is not available for delivery groups with random machines.
7. Select Weekend in Power manage machines, and then configure the peak hours and power state timers for weekends.
8. Click Apply to apply any changes you made and keep the window open. Or, click OK to apply changes and close the window.

Use the SDK to:

• Shut down, rather than suspend, machines in response to power state timers, or if you want the timers to be based on logoffs, rather than disconnections.
• Change the default weekday and weekend definitions.
• Disable power management. See CTX217289.

Power manage VDI machines transitioning to a different time period with disconnected sessions

Important:

This enhancement applies only to VDI machines with disconnected sessions. It does not apply to VDI machines with logged off sessions.

In earlier releases, a VDI machine transitioning to a time period where an action (disconnect action=“Suspend” or “Shutdown”) was required remained powered on. This scenario occurred if the machine disconnected during a time period (peak or off-peak times) where no action (disconnect action=“Nothing”) was required.

Starting with Citrix Virtual Apps and Desktops 7 1909, the machine is suspended or powered off when the specified disconnection time elapses, depending on the disconnect action configured for the destination time period.

For example, you configure the following power policies for a VDI delivery group:

• Set PeakDisconnectAction to “Nothing”
• Set OffPeakDisconnectAction to “Shutdown”
• Set OffPeakDisconnectTimeout to “10”

Note:

For more information about the disconnect action power policy, see https://developer-docs.citrix.com/projects/delivery-controller-sdk/en/latest/Broker/about_Broker_PowerManagement/#power-policy and https://developer-docs.citrix.com/projects/delivery-controller-sdk/en/latest/Broker/Get-BrokerDesktopGroup/.

In earlier releases, a VDI machine with a session disconnected during peak times remained powered on when it transitioned from peak to off-peak. Starting with Citrix Virtual Apps and Desktops 7 1909, the OffPeakDisconnectAction and the OffPeakDisconnectTimeout policy actions are applied to the VDI machine on period transition. As a result, the machine is powered off 10 minutes after it transitions to off-peak.

If you want to revert to the previous behavior (that is, take no action on machines that transition from peak to off-peak or off-peak to peak with disconnected sessions), do one of the following:

• Set the “LegacyPeakTransitionDisconnectedBehaviour” registry value to 1, the equivalent of true which enables the previous behavior. By default, the value is 0, or false, which triggers disconnect power policy actions on period transition.
  • Path: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\DesktopServer
  • Name: LegacyPeakTransitionDisconnectedBehaviour
  • Type: REG_DWORD
  • Data: 0x00000001 (1)
• Configure the setting by using the Set-BrokerServiceConfigurationData PowerShell command. For example:
  • PS C:\> Set-BrokerServiceConfigurationData HostingManagement.LegacyPeakTransitionDisconnectedBehaviour -SettingValue $true

A machine must meet the following criteria before power policy actions can be applied to it on period transition:

• Has a disconnected session.
• Has no pending power actions.
• Belongs to a VDI (single session) delivery group that transitions to a different time period.
• Has a session that disconnects during a certain time period (peak or off-peak times) and transitions to a period where a power action is assigned.

Change the percentage of VDAs in a powered state for catalogs

1. Adjust the peak hours for the delivery group from the Power management section for the delivery group.
2. Make a note of the Desktop Group name.

3. With administrator privileges, start PowerShell and run the following commands. Replace “Desktop Group Name” with the name of your desktop group that has a changed percentage of the VDAs running.

   asnp Citrix*

   # Set-BrokerDesktopGroup "Desktop Group Name" -PeakBufferSizePercent 100

   A value of 100 means that 100% of the VDAs are in the ready state.

4. Verify the solution by running:

   #Get-BrokerDesktopGroup "Desktop Group Name"

   

It can take up to an hour for changes to take effect.

To shut down the VDAs after the user logs off, enter:

# Set-BrokerDesktopGroup "Desktop Group Name" -ShutDownDesktopsAfterUse $True

To restart VDAs during peak hours, so that they’re ready for users after they log off, enter:

# Set-BrokerDesktopGroup "Desktop Group Name" -AutomaticPowerOnForAssignedDuringPeak $True

Sessions

• Log off or disconnect a session, or send a message to users
• Configure session prelaunch and session linger

Log off or disconnect a session

1. In the Studio navigation pane, select Delivery Groups.
2. Select a delivery group and then select View Machines in the Actions pane.
3. In the middle pane, select the machine, select View Sessions in the Actions pane, and then select a session.
   • Alternatively, in the middle pane, select the Session tab and then select a session.
4. To log off from a session, select Log off in the Actions pane. The session closes and the user is logged out. The machine becomes available to other users unless it is allocated to a specific user.
5. To disconnect a session, select Disconnect in the Actions pane. Applications continue to run in the session and the machine remains allocated to that user. The user can reconnect to the same machine.

You can configure power state timers for single-session OS machines to automatically handle unused sessions. For details, see Power managed machines.

Send a message to a delivery group

1. In the Studio navigation pane, select Delivery Groups.
2. Select a delivery group and then select View Machines in the Actions pane.
3. In the middle pane, select a machine to which you want to send a message.
4. In the Actions pane, select View Sessions.
5. In the middle pane, select all sessions and then select Send Message in the Actions pane.
6. Type your message and click OK. You can specify the level of severity if needed. Options include Critical, Question, Warning, and Information.

Alternatively, you can send a message by using Citrix Director. For more information, see Send messages to users.

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) and 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 extra 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. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.

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. Select Delivery Groups in the navigation pane.
2. Select a group and then click Edit Delivery Group in the Actions pane.

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.

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 can 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.