Manage delivery groups

Note:

You can manage your Citrix Virtual Apps and Desktops deployment using two management consoles: Web Studio (web-based) and Citrix Studio (Windows-based). This article covers only Web Studio. For information about Citrix Studio, see the equivalent article in Citrix Virtual Apps and Desktops 7 2212 or earlier.

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

• View group details
• Change the delivery type
• Change StoreFront addresses
• Change the functional level
• Manage Remote PC Access delivery groups
• Organize delivery groups using folders
• Manage App Protection

View group details

1. Use the search function to locate a specific delivery group. Refer to Search for instances for instructions.
2. From the search results, select a group as necessary.
3. Refer to the following table for descriptions of the group columns.
4. Click a tab in the bottom details pane for more information about this group.

Column	Description
Delivery Group	The group name and the session type. Session types include Single-session OS and Multi-session OS.
Delivering	The type of resources delivered from this group. Possible values include Applications, Desktops, and Applications and Desktops. “Static machine assignment” appears if the delivery group consists of dedicated machines.
Session in Use	The number of machines that are set up and the number of machines that are in a Disconnected state.
Allocated Count	The number of machines in the catalog assigned to a delivery group.
Folder	The location of the group within the Delivery Groups tree. It displays the name of the folder that the group is in (including the trailing backslash), or - if the group is at the root level.

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 left pane.
2. Select a group and then click Edit in the action bar.
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 Save to apply changes and close the window.

Change StoreFront addresses

1. Select Delivery Groups in the left pane.
2. Select a group and then click Edit in the action bar.
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 Save to apply changes and close the window.

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

Change the functional level

Change the functional level for the 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:

• 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 are not available. For more information, see the upgrade documentation.

To upgrade a delivery group:

1. Select Delivery Groups in the left pane.
2. Select a group and then click Upgrade Delivery Group in the action bar. The UChange Functional Level action appears only if upgraded VDAs are detected.

The display indicates you which, if any, machines cannot be changed to the functional level and why. You can then cancel the change action, resolve the machine issues, and then perform the change action again.

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

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

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

Action	Required permissions
Create delivery group folders	Create Delivery Group Folder
Delete delivery group folders	Remove Delivery Group Folder
Move delivery group folders	Move Delivery Group Folder
Rename delivery group folders	Edit Delivery Group Folder
Move delivery groups to folders	Edit Delivery Group Folder and Edit Delivery Group Properties

Manage App Protection

The following information is supplemental to App protection. Mind the following details:

• You must have a valid App Protection entitlement. To purchase the App Protection feature, contact your Citrix sales representative.

• App Protection requires XML trust. To enable XML trust, go to Settings > Enable XML trust.

• Regarding anti-screen-capturing:

  • On Windows and macOS, only the window of the protected content is blank. App Protection is active when a protected window is not minimized.
  • On Linux, the entire capture is blank. App Protection is active whether a protected window is minimized or not.

To choose an App Protection method for a delivery group, follow these steps:

1. Select Delivery Groups in the left pane.

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

3. On the App Protection page, you can see the following options:

   Options	Description
   Do not apply	Select this option to not apply the setting.
   Apply to this delivery group	Select Anti-keylogging and/or Anti key capturing options. Hover over each of these settings to read the details in the tool tip.
   Apply contextually	To apply this setting, configure the access policy in the Access Policy settings page.
   	Click Access Policy in the left pane and click Add. On the Add Policy page, do the following i. Enter a Policy name and configure the settings as required. ii. In the Filter and Value fields, enter the details and click Done. The new policy is listed in the App Protection page. Enable the required settings for this policy. iii. Click Save.

4. On the Delivery Group page, select the Delivery Group and click the Details tab at the bottom. The new App Protection settings applied are displayed.

Users

This section covers the following topics:

• Change user settings
• Add or remove users
• Manage user assignments

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 left pane.
2. Select a group and then click Edit in the action bar.
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 Save 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. Note: Changing the time zone on a delivery group might reboot the machines in that delivery group. To avoid this, ensure to change the time zone settings outside of production hours.
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 left pane.
2. Select a group and then click Edit in the action bar.

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 checkbox to allow access by unauthenticated users.
4. Click Apply to apply any changes you made and keep the window open. Or, click Save 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 two column headers, separated by a comma. Make sure that the first header is Machine Account and the second header is User Names. (You can include additional headers but they are not supported.) Subsequent lines in the file contain comma-separated data. The Machine Account entries can be computer SID, FQDN, or domain and computer name pairs.

To import or export user information:

1. Select Delivery Groups in the left pane.
2. Select a group and then click Edit in the action bar.
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 Save to apply changes and close the window.

Manage user assignments

Manage user assignments for machines in a delivery group. When desktop assignment rules are configured for the delivery group, machines are randomly assigned to users upon initial desktop launch and remain assigned to the users unless their user assignments are modified. If you want to manually assign an unassigned machine to specific users or change the existing user assignment for a machine, follow the steps described in this topic to make changes. Using these steps, you can also modify names displayed in the Citrix Workspace App for machines assigned to users.

Detailed steps are as follows:

1. In the console, select Delivery Groups from the left pane.
2. Select a group, and then select Edit in the action bar.

3. In the left pane, select Machine Allocation. The following details for each machine in the group appear:

   • Machine name: Shows the name of a machine.
   • Display name: Shows the machine’s display name in Citrix Workspace App.
   • Users: Shows users assigned to this machine. If desktop assignment rules are configured, machines are randomly assigned to users upon their initial desktop launch and remain assigned to them unless their user assignments are modified.

4. Locate a machine, and then assign users to it or change its user assignment:

   • Click Browser to browser to users.
   • In the Users column, enter a semicolon-separated list of user names.
   • Click Import from CSV file to import the setting details using a CSV file.

5. (Optional) If the machine is assigned to users, modify its display name as needed.

   Note:

   The Display name field is enabled only when the machine is assigned to users:

   • If the machine is assigned to a user based on a desktop assignment rule, this field shows the display name configured in that rule.
   • If the machine is manually assigned to users and the field is left blank, the delivery group’s published name (if specified) is used as the machine’s display name. The delivery group’s name is used if the published name is unspecified. Note that you can specify published names for delivery groups only through PowerShell.

6. Select Apply to apply changes and keep the window open. Or, select OK to apply changes and close the window.

Machines

• Change assignments of machines to users
• Enable Local Host Cache for power-managed single-session pooled VDAs
• 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
• Enable one-time restart schedule
• 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 left pane.
2. Select a group and then click Edit in the action bar.
3. On the Desktops or Desktop Assignment Rules page (the page title depends on the type of machine catalog that the delivery group uses), specify the new users.
4. Click Apply to apply any changes you made and keep the window open. Or, click Save to apply changes and close the window.

Enable Local Host Cache for power-managed single-session pooled VDAs

By default, power-managed single-session pooled machines are unavailable when in Local Host Cache mode. You can override the default behavior on a per-delivery group basis. Detailed steps are as follows:

1. From Studio, select Delivery Groups in the left pane.

   In the group list, groups containing single-session pooled machines provisioned by MCS or Citrix Provisioning display a warning icon.

2. Select a group as needed, then select Edit in the action bar.
3. On the Local Host Cache page, select Keep resources available.
4. Select Apply to apply any changes you made and keep the window open. Or, select OK to apply changes and close the window.

Alternatively, you can override the default behavior using PowerShell commands. For more information, see Application and desktop support.

Important:

Enabling access to power-managed single-session pooled machines can cause data and changes from previous user sessions being present in subsequent sessions.

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

1. Select Delivery Groups in the left pane.
2. Select a group and then click Edit in the action bar.
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 Save to apply changes and close the window.

Update a machine in a delivery group

1. Select Delivery Groups in the left pane.
2. Select a group and then click View Machines in the action bar.
3. Select a machine and then click Update Machines in the action bar.

To choose a different image, select 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 left pane.
2. Select a group and then click Edit in the action bar.
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 Save 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 left pane.
2. Select a group and then click View Machines in the action bar.
3. Ensure that the machine is shut down.
4. Select the machine and then click 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 resources 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 smart access policy expressions: You can configure access policy rules to control user access to a specific delivery group. Examples include:

  • Restrict access to a subset of users and specify allowed user devices.
  • Restrict access to users connected through Workspace (instead of StoreFront).
  • Restrict access to users connected through a specific Workspace URL.

This section guides you through how to restrict user access to delivery groups through access policy rules:

• About access policy rules
• Add access policy rules
• Manage access policy rules using Web Studio
• Add and refine policy rules using PowerShell

About access policy rules

You can configure multiple access policy rules for a delivery group. Apps and desktops in a delivery group appear in a user’s StoreFront or Workspace when the user’s connection matches any access policy rule you defined for the delivery group, irrespective of order.

Each rule can be individually enabled or disabled. A disabled rule is ignored when the access policy is evaluated.

In Web Studio, the Access Policy list includes the following default SmartAccess policy rules. You can add more as necessary.

• Citrix Gateway connections. This policy allows only user connections made through Citrix Gateway can access resources within the delivery group. User connections made through Workspace when either the Device Posture or Network Location features are enabled are also considered connections through Citrix Gateway.
• Non-Citrix Gateway connections. This policy allows only user connections made not through Citrix Gateway can access resources within the delivery group.

Note:

• To prevent the default rules from overriding a newly configured one, you must either disable the default rules or refine them to exclude the filters used in the new policy.
• The default policies can’t be deleted but they can be disabled. To disable a policy, click the Edit icon and then change the Policy state to Disabled.
• The policy list also shows rules added using PowerShell commands. Those policies can be deleted but can’t be edited in Web Studio.

Add access policy rules using Web Studio

An access policy rule comprises a set of filters. For more information about filters, see this article. When adding an access policy rule, you add multiple condition filters to the rule as needed.

To add a policy for a delivery group using Web Studio, follow these steps:

1. In the console, 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, click Add. The Add Policy page appears.

   

4. In the Policy name field, type a descriptive name for the policy. The name must be unique in your deployment.

5. To define the criteria for allowed user connections, follow these steps:

   1. Select Connections meeting the following criteria.
   2. Click Add criterion.
   3. In the Filter field, type the name of the filter that you want to use. In the Value field, type a desired value for the filter. For example, to allow only users connected through Workspace (instead of StoreFront) to access resources in this delivery group, type Citrix-Via-Workspace for Filter and True for Value.
   4. To add more criteria, repeat steps b-c.

   5. Select the relationship among the criteria:

      • Match any. Allows access only when the incoming user connection meets any of the configured filter criteria.
      • Match all. Allows access only when the incoming user connection meets all of the configured filter criteria.

6. To define the criteria for prohibited user connections, follow these steps:

   1. Select Connections not meeting any of the following criteria.
   2. Click Add criterion.
   3. In the Filter field, type the name of the filter that you want to use. In the Value field, type a desired value for the filter. For example, to prohibit users connected through the example.cloud.com Workspace URL from accessing resources in this delivery group. Type Citrix.Workspace.UsingDomain for Filter and example.cloud.com for Value.

   4. To add more criteria, repeat steps b-c.

      Note:

      User connections meeting any of the configured criteria are prohibited from resources in this delivery group.

7. Click Done.

   The new policy appears in the policy list.

8. Review and refine the default policy rules to avoid unintentional overlaps with connections covered by this new policy. To refine the existing policies, use the following ways:

   • Disable the default policy rules.
   • Configure the default policy rules to exclude the SmartAccess filters that you added to the inclusion criteria of the new policy. For more information, see Manage policy rules using Web Studio and Add and manage access policy rules using PowerShell.

   Important:

   As explained in About access policy rules, when a user’s connection matches one or more policy rules in a delivery group, the user gains access to its resources. Therefore, after creating a rule, you must carefully review and refine the existing rules to avoid any unintentional overlaps with connections covered by the new rule.

Manage access policy rules using Web Studio

You can use the inclusion and exclusion criteria to refine the default policies. For example, to restrict access to a subset of those connections, follow these steps:

1. Edit a default policy.
2. Select Connections meeting any of the following criteria.
3. Add, edit, or remove the SmartAccess policy expressions for the allowed user access scenarios.

For more information, see the Citrix Gateway documentation.

Add and manage access policy rules using PowerShell

You can use the following PowerShell cmdlets to add and manage access policy rules for delivery groups:

• New-BrokerAccessPolicyRule
• Get-BrokerAccessPolicyRule
• Set-BrokerAccessPolicyRule
• Rename-BrokerAccessPolicyRule
• Remove-BrokerAccessPolicyRule

For more information, see the relative articles in the Citrix Developer Documentation.

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 left 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 action bar.

   To turn on maintenance mode for one machine, click View Machines in the action bar. Select a machine, and then click 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 click 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. 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 left pane.
2. Select a group and then click View Machines in the action bar.

3. Select the machine and then click one of the following entries in the action bar:

   • 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

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.
• Changing the time zone on a delivery group might reboot the machines in that delivery group. To avoid this, ensure to change the time zone settings outside of production hours.

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 that 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 left pane.
2. Select a group and then click 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

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 left 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 action bar.
5. If the tag exists, enable the checkbox 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 checkbox 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 left pane.
2. Select a group and then click Edit in the action bar.
3. On the Restart Schedule page, click 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:
     • If you do not want to use natural restart, select Restart all machines at the same time or Restart all machines within a time period.

     • If you want to use natural restart, select Restart all machines after draining all sessions.

       Upon starting a restart schedule that is configured to use natural restart:

       • All idle machines belonging to the delivery group are restarted immediately
       • Each machine belonging to a delivery group with one or more active sessions is 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 window open. Or, click Save 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. You can use this option for machines that are power managed and also for machines that are not power managed.

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

Edit, remove, enable, or disable a restart schedule

1. Select Delivery Groups in the left pane.
2. Select a group and then click Edit in the action bar.
3. On the Restart Schedule page, select the checkbox 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 checkbox.
   • 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 Web Studio.

Scheduled restarts for machines in maintenance mode

Note:

This feature is available only in PowerShell. The option IgnoreMaintenanceMode is supported with Citrix Virtual Apps and Desktops 7 2006 and later.

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.

Enable one-time restart schedule

If you want to enable one-time restart schedule using PowerShell, use the following BrokerCatalogRebootSchedule PowerShell commands to create, modify, and delete a restart schedule:

• Get-BrokerCatalogRebootSchedule
• New-BrokerCatalogRebootSchedule
• Set-BrokerCatalogRebootSchedule
• Remove-BrokerCatalogRebootSchedule
• Rename-BrokerCatalogRebootSchedule

Limitations:

• A catalog reboot schedule associated with a catalog that is without a configured timezone is created but does not start.
• When a catalog reboot schedule is created, then the reboot schedule runs only on the catalog VMs belonging to a delivery group.

Example,

• To create a restart schedule of the VMs in the catalog named BankTellers to begin on Feb 3, 2022, between 2 AM and 4 AM.

   C:\PS> New-BrokerCatalogRebootSchedule -Name BankTellers -CatalogName BankTellers  -StartDate "2022-02-03" -StartTime "02:00" -Enabled $true -RebootDuration 120
   <!--NeedCopy-->
  

• To create a restart schedule of the VMs in the catalog having UID 17 to begin on Feb 3, 2022, between 1 AM and 5 AM. Ten minutes before the restart, each VM is set to display a message box with the title WARNING: Reboot pending, and the message Save your work, in every user session.

   C:\PS> New-BrokerCatalogRebootSchedule -Name 'Update reboot' -CatalogUid 17 -StartDate "2022-02-03" -StartTime "01:00" -Enabled $true -RebootDuration 240 -WarningTitle "WARNING: Reboot pending" -WarningMessage "Save your work" -WarningDuration 10
   <!--NeedCopy-->
  

• To rename the catalog restart the schedule named Old Name to New Name.

  C:\PS> Rename-BrokerCatalogRebootSchedule -Name "Old Name" -NewName "New Name"
  <!--NeedCopy-->
  

• To display all catalog restart schedules with UID 1, and then rename the catalog reboot schedule with the UID 1 to New Name.

  C:\PS> Get-BrokerCatalogRebootSchedule -Uid 1 | Rename-BrokerCatalogRebootSchedule -NewName "New Name" -PassThru
  <!--NeedCopy-->
  

• To set the catalog restart schedule named Accounting to display a message with the title, WARNING: Reboot pending, and the message, Save your work, ten minutes before the restart of each VM. The message appears in every user session on that VM.

  ``` C:\PS> Set-BrokerCatalogRebootSchedule -Name Accounting -WarningMessage “Save your work” -WarningDuration 10 -WarningTitle “WARNING: Reboot pending”

• To display all restart schedules that are disabled, and then enable all disabled restart schedules.

   C:\PS> Get-BrokerCatalogRebootSchedule -Enabled $false | Set-BrokerCatalogRebootSchedule -Enabled $true
  

• To set the catalog restart schedule with UID 17 to display the message Rebooting in %m% minutes fifteen, ten, and five minutes before the restart of each VM.

   C:\PS> Set-BrokerCatalogRebootSchedule 17 -WarningMessage "Rebooting in %m% minutes." -WarningDuration 15 -WarningRepeatInterval 5
  

• To configure the time zone for the catalog named MyCatalog.

   C:\PS> Set-BrokerCatalog -Name "MyCatalog" -TimeZone <TimeZone>
  

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), Web 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 header, 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 left pane.
2. Select a group and then click Edit Delivery Group in the action bar.
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 Save 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”

For more information about the disconnect action in the 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:

• Have a disconnected session.
• Have no pending power actions.
• Belong to a VDI (single session) delivery group that transitions to a different time period.
• Have 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
• Control session reconnection when disconnected from machine in maintenance mode
• Configure session roaming

Log off or disconnect a session

1. Select Delivery Groups in the left pane.
2. Select a delivery group and then select View Machines in the action bar.
3. In the middle pane, select the machine, select View Sessions in the action bar, 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 action bar. 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 action bar. 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. Select Delivery Groups in the left pane.
2. Select a delivery group and then select View Machines in the action bar.
3. In the middle pane, select a machine to which you want to send a message.
4. In the action bar, select View Sessions.
5. In the middle pane, select all sessions and then select Send Message in the action bar.
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 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 must 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 a group and then click Edit Delivery Group in the action bar.

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

   

3. 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 left pane.
2. Select a group and then click Edit Delivery Group 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 version 2106, reconnection was not allowed for single-session pooled desktop sessions that had disconnected from machines in maintenance mode. As of version 2106, 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

Configure session roaming

By default, session roaming is enabled for delivery groups. Sessions roam between client devices with the user. When the user launches a session and then moves to another device, the same session is used and applications are simultaneously available on both devices. You can view the applications on multiple devices. The applications follow, regardless of the device or whether current sessions exist. Often, printers and other resources assigned to the application also follow. Alternatively, you can use PowerShell. For more information, see Session roaming.

Configure session roaming for applications

To configure session roaming for applications, follow these steps:

1. In the console, 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, enable session roaming by selecting the Sessions roam with users as they move between devices checkbox.

   • When enabled, if a user launches an application session and then moves to another device, the same session is used and available on both devices. When disabled, the session no longer roams between devices.

4. Select OK to apply changes and close the window.

Configure session roaming for desktops

To configure session roaming for a desktop, follow these steps:

1. In the console, select Delivery Groups in the left pane.

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

3. On the Desktops page, select the desktop and select Edit.

4. Enable session roaming by selecting the Session roaming checkbox.

• When enabled, if the user launches the desktop and then moves to another device, the same session is used, and applications are available on both devices. When disabled, the session no longer roams between devices.

Select OK to apply changes and close the window.

Applications

View and add applications to a delivery group.

1. In the console, select Delivery Groups in the left pane.
2. Select a group. If this group contains applications, View Applications appears in the action bar.
3. Select View Applications. You are directed to the Applications node where all applications available in this group appear.
4. To add more applications to this group, go to the Delivery Groups node, select the group, and select Add Applications in the action bar.

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