Jan. 03, 2017
In this article:
This article describes the procedures for managing Delivery Groups. 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.
See the Applications article for information about managing applications in Delivery Groups, including how to add and remove applications in a Delivery Group, and change application properties.
Managing Delivery Groups requires the Delegated Administration permissions of the Delivery Group Administrator built-in role. See the Delegated Administration article for details.
The name of this page may appear as either User Settings or Basic Settings.
The text that StoreFront uses and that users see.
Enable Delivery Group
Whether or not the Delivery Group is enabled.
Enable Secure ICA
Secures communications to and from machines in the Delivery Group using SecureICA, which encrypts the ICA protocol (default level is 128-bit; the level can be changed using the SDK). Citrix recommends using additional encryption methods such as TLS encryption when traversing public networks. Also, SecureICA does not check data integrity.
For detailed information about users, see the Users section in the Create Delivery Groups article.
For Delivery Groups containing physical Desktop 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:
The delivery type indicates what the group can deliver: applications, desktops, or both.
Before changing an application only or desktops and applications type to a desktops only type, delete all applications from the group.
You can also specify StoreFront server address by selecting Configuration > StoreFront in the Studio navigation pane.
Important: Adding, changing, and removing tag restrictions can have unanticipated effects on which desktops are considered for launch. Be sure to review the considerations and cautions in the Tags article.
Upgrade a Delivery Group after you upgrade the VDAs on its machines and the Machine Catalogs containing the machines used in the Delivery Group.
Before you start the Delivery Group upgrade:
To upgrade a Delivery Group:
Before starting the upgrade process, Studio tells 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 selecting Undo in the Actions pane.
If a machine in a Remote PC Access Machine Catalog is not assigned to a user, Studio temporarily assigns the machine to a Delivery Group associated with that Machine Catalog. This temporary assignment enables the machine to be assigned to a user later.
The Delivery Group-to-Machine Catalog association has a priority value. Priority determines which Delivery Group that machine is assigned to when it registers with the system or when a user needs a machine assignment: the lower the value, the higher the priority. If a Remote PC Access Machine Catalog has multiple Delivery Group assignments, the software selects the match with the highest priority. You can set this priority value using the PowerShell SDK.
When first created, Remote PC Access Machine Catalogs are associated with a Delivery Group. This means that machine accounts or Organizational Units added to the catalog later can be added to the Delivery Group. This association can be switched off or on.
To add or remove a Remote PC Access Machine Catalog association with a Delivery Group:
This procedure is not supported for Remote PC Access machines.
For non-force actions, if the machine does not shut down within 10 minutes, it is powered off. If Windows attempts to install updates during the shutdown, there is a risk that the machine will be powered off before the updates finish.
Citrix recommends that you prevent Desktop 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; see the Connections and resources article.
You can power manage only virtual Desktop OS machines, not physical ones (including Remote PC Access machines). Desktop OS machines with GPU capabilities cannot be suspended, so power off operations fail. For Server OS machines, you can create a restart schedule, which is also described in this article.
In Delivery Groups containing pooled machines, virtual Desktop OS machines can be in one of the following states:
In Delivery Groups containing static machines, virtual Desktop OS machines can be:
During normal use, static Delivery Groups typically contain both permanently allocated and unallocated machines. Initially, all machines are unallocated (except for those manually allocated 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 log on. 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 additional standby set of unallocated machines that are turned on when the number of machines in the pool falls below a threshold that 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 examples, machines will suspend automatically outside of office hours if users have been disconnected for at least ten minutes. Random machines or machines with personal vDisks automatically shut down when users log off, unless you configure the ShutdownDesktopsAfterUse Delivery Group property in the SDK.
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.
To power manage virtual Desktop OS machines:
Use the SDK to:
Note: This section describes how to configure a single restart schedule in Studio. Alternatively, you can use PowerShell to configure multiple restart schedules for different subsets of machines in a Delivery Group. See the next section for details.
A restart schedule specifies when to periodically restart all the machines in a Delivery Group.
You cannot perform an automated power-on or shutdown from Studio, only a restart.
You can use PowerShell cmdlets to create multiple restart schedules for machines in a Delivery Group. Each schedule can be configured to affect only those machines in the group that have a specified tag. This tag restriction functionality allows you to easily create different restart schedules for different subsets of machines in one Delivery Group.
For example, let's say you use one Delivery Group for all machines in the company. You want to restart every machine at least once every week (on Sunday night), but the machines used by the accounting team should be restarted daily. You can set up a weekly schedule for all machines, and a daily schedule for just the machines used by the accounting team.
Multiple schedules might overlap. In the example above, the machines used by accounting are affected by both schedules, and might be restarted twice on Sunday.
The scheduling code is designed to avoid restarting the same machine more often than needed, but it cannot be guaranteed. If both schedules coincide precisely in start and duration times, it is more likely that the machines will be restarted only once. However, the more the schedules differ in start and/or duration times, the more likely two restarts will occur. Also, the number of machines affected by the schedules can also influence the chances of an overlap. In the example, the weekly schedule that restarts all machines could initiate restarts significantly faster than the daily schedule (depending on the configured duration for each).
Support for creating multiple restart schedules and using tag restrictions in a restart schedule is currently available only through the PowerShell command line, using RebootScheduleV2 PowerShell cmdlets that are new in XenApp and XenDesktop 7.12. (These are referred to as the "V2" cmdlets throughout this article.)
Using the V2 cmdlets requires:
Studio currently uses earlier V1 RebootSchedule PowerShell cmdlets, and will not display schedules that are created with the V2 cmdlets.
After you create a restart schedule that uses a tag restriction, and then later use Studio to remove the tag from an affected machine during a restart interval (cycle) or add the tag to additional machines during a restart cycle, those changes will not take effect until the next restart cycle. (The changes will not affect the current restart cycle.)
Use the following RebootScheduleV2 cmdlets from the command line to create multiple schedules and use tag restrictions in the schedules.
New (V2) cmdlet
Replaces earlier (V1) cmdlet
For complete cmdlet syntax and parameter descriptions, enter Get-Help –full <cmdlet-name>.
Terminology reminder: In the PowerShell SDK, the DesktopGroup parameter identifies the Delivery Group.
If you're familiar with the Studio interface for creating a restart schedule, all of those parameters are available when using the V2 cmdlet to create or update a schedule. Additionally, you can:
If you configure a restart schedule that uses a tag restriction, you must also add (apply) that tag to the machines that you want the schedule to affect. (For full tag information, see the Tags article.)
After creating and adding (applying) tags, use the –RestrictToTag parameter to specify the tag name when creating or editing the schedule with the V2 cmdlet.
If you created a restart schedule with an earlier XenApp or XenDesktop version
Studio currently uses the V1 RebootSchedule cmdlets. If you have a restart schedule that was created before you upgraded to 7.12 (minimum), you can continue to manage it in Studio with V1 cmdlets, but you cannot use Studio to add a tag restriction to that schedule, or to create additional schedules (because Studio does not support the V2 cmdlets). As long as you use the V1 cmdlets for your existing schedule, Studio will display correct information about the restart schedule.
Alternatively, you can edit your existing schedule from the command line, using the new V2 RebootSchedule cmdlets. When using the new V2 cmdlets, you can use the tag restriction parameters in that schedule, and create additional restart schedules. However, after you use V2 cmdlets to change your existing schedule, Studio will not display complete schedule information (because it recognizes only V1 information). You cannot see whether a tag restriction is used, or the schedule's name and description.
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.
To turn maintenance mode on or off:
Windows Remote Desktop Connection (RDC) settings also affect whether a Server OS machine is in maintenance mode. Maintenance mode is on when any of the following occur:
You can also turn maintenance mode on or off for a connection (which affects the machines that use that connection), or for a Machine Catalog (which affects the machines in that catalog).
You can change the assignments of Desktop OS machines, not Server OS machines or machines created through Provisioning Services.
You can load manage Server 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 Server OS machine is considered for load balancing only when maintenance mode is off.
Server load index: Determines how likely a server delivering Server 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. You specify the load evaluators in load management policy settings.
You can monitor the load index in Director, Studio search, and the SDK.
In Studio, the Server Load Index column is hidden by default. To display it, select a machine, right-select a column heading and then choose Select Column. In the Machine category, select Load Index.
In the SDK, use the Get-BrokerMachine cmdlet. For details, see CTX202150.
A server load index of 10000 indicates that the server is fully loaded. If no other servers are available, users might receive a message that the desktop or application is currently unavailable when they launch a session.
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 versions earlier than 7.5.)
If 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.
Removing a machine deletes it from a Delivery Group but 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.
Keep in mind that machines may contain personal data, so use caution before allocating the machine to another user. You may want to reimage the machine.
You can also remove a machine from a Delivery Group through the connection the machine uses. For details, see the Connections and resources article.
Any changes you make to restrict access to machines in a Delivery Group supersede previous settings, regardless of the method you use. You can:
Restrict access for administrators using Delegated Administration scopes. You can create and assign a scope that permits administrators to access all applications, and another scope that provides access to only certain applications. See the Delegated Administration article for details.
Restrict access for users through SmartAccess policy expressions that filter user connections made through NetScaler Gateway.
Restrict access for users through 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, for a teaching lab on a subnet in the corporate network, to prevent access from that lab to a particular Delivery Group, regardless of who is using the machines in the lab, use the following command: Set-BrokerAccessPolicy -Name VPDesktops_Direct -ExcludedClientIPFilterEnabled $True -
You can use the asterisk (*) wildcard to match all tags that start with the same policy expression. For example, if you add the tag VPDesktops_Direct to one machine and VPDesktops_Test to another, setting the tag in the Set-BrokerAccessPolicy script to VPDesktops_* applies the filter to both machines.
To choose a different master 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), and whether users will be notified of the restart, plus the message they will receive.
You can configure power state timers for Desktop OS machines to automatically handle unused sessions. See the Power manage machines section for details.
These features are supported on Server OS machines only.
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.
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 will cause the unused session to end.
You cannot disable this timeout from Studio, but you can in the SDK (New/Set-BrokerSessionPreLaunch cmdlet). If you disable the timeout, it will not appear in the Studio display for that Delivery Group or in the Edit Delivery Group wizard.
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 Delivery 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 the Controller and servers in maintenance mode are considered fully loaded. An unplanned outage will cause prelaunch and lingering sessions to be ended automatically to free capacity.
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.
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.