Manage Delivery Groups 编辑

Introduction

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 Applications 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 Delegated Administration for details.

Change user settings in a Delivery Group

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

1. Select Delivery Groups in the Studio navigation pane.
2. Select a group and then select 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.

Add or remove users in a Delivery Group

For detailed information about users, see the Users section in the Create Delivery Groups article.

1. Select Delivery Groups in the Studio navigation pane.
2. Select a group and then select 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. You can also select/clear the check box that enables or disables 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 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:

1. Select Delivery Groups in the Studio navigation pane.
2. Select a Delivery Group, and then select 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.

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 a desktops only type, delete all applications from the group.

1. Select Delivery Groups in the Studio navigation pane.
2. Select a group and then select 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 Studio navigation pane.
2. Select a group and then select Edit Delivery Group in the Actions pane.
3. On the StoreFront page, select or add StoreFront URLs that will be used by the Citrix Receiver that 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 address by selecting Configuration > StoreFront in the Studio navigation pane.

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 the Tags article.

1. Select Delivery Groups in the Studio navigation pane.
2. Select a group and then select 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 or remove the tag restriction entirely 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.

Upgrade a Delivery Group or revert an upgrade

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

Before you start the Delivery Group upgrade:

• If you use Provisioning Services, upgrade the VDA version in the Provisioning Services console.
• Start the machines containing the upgraded VDA so that they can register with a Delivery Controller. This process tells Studio what needs upgrading in the Delivery Group.
• If you must continue to use earlier VDA versions, newer product features may not be available. For more information, see the Upgrade articles.

To upgrade a Delivery Group:

1. Select Delivery Groups in the Studio navigation pane.
2. Select a group and then select Upgrade Delivery Group in the Actions pane. The Upgrade Delivery Group action appears only if Studio detects upgraded VDAs.

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.

Manage Remote PC Access Delivery Groups

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

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

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 Studio navigation pane.
2. Select a group and then select View Machines in the Actions pane.
3. Select the machine and then select one of the following in the Actions pane (some options may not be available, depending on the machine state):
   • Force shut down. Forcibly powers off the machine and refreshes the list of machines.
   • Restart. Requests the operating system to shut down and then start the machine again. If the operating system cannot comply, the machine remains in its current state.
   • Force restart. Forcibly shuts down the operating system and then restarts the machine.
   • Suspend. Pauses the machine without shutting it down, and refreshes the list of machines.
   • Shut down. Requests the operating system to shut down.

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

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.

Power manage machines in a Delivery Group

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:

• Randomly allocated and in use
• Unallocated and unconnected

In Delivery Groups containing static machines, virtual Desktop 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 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 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 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 10 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:

1. Select Delivery Groups in the Studio navigation pane.
2. Select a group, and then select Edit Delivery Group in the Actions pane.
3. On the Power Management page, select Weekdays in the Power manage machines drop-down. By default, weekdays are Monday to Friday.
4. For random Delivery Groups, in Machines to be powered on, select 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 select Suspend. In During off-peak hours > When disconnected, specify the delay before turning off any logged-off machine in the Delivery Group, and select Shutdown. This timer is not available for Delivery Groups with random machines.
7. Select Weekend in the Power manage machines drop-down, 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.

Create a restart schedule for machines in a Delivery Group

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.

1. Select Delivery Groups in the Studio navigation pane.
2. Select a group and then select Edit Delivery Group in the Actions pane.
3. On the Restart Schedule page, if you do not want to restart machines in the Delivery Group automatically, select the No radio button and skip to the last step in this procedure. No restart schedule or rollout strategy will be configured. If a schedule was previously configured, this selection cancels it.
4. If you do want to restart machines in the Delivery Group automatically, select the Yes radio button.
5. For Restart frequency, choose either Daily or the day of the week the restarts will occur.
6. For Begin restart at, using a 24-hour clock, specify the time of day to begin the restart.
7. For Restart duration, choose whether all machines should be started at the same time, or the total length of time to begin restarting all machines in the Delivery Group. An internal algorithm determines when each machine is restarted during that interval.
8. In the left Notification drop-down, 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 the Repeat notification drop-down) to repeat the message every five minutes after the initial message. By default, the message is not repeated.
9. Enter the notification text in the Notification message box; 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 will be automatically restarted in %m% minutes.) If you select a repeat notification interval and your message includes the %m% placeholder, the value decrements by five minutes in each repeated message. Unless you chose to restart all machines at the same time, the notification message displays on each machine in the Delivery Group at the appropriate time before the restart, calculated by the internal algorithm.
10. Click Apply to apply any changes you made and keep the window open, or click OK to apply changes and close the window.

You cannot perform an automated power-on or shutdown from Studio, only a restart.

Create multiple restart schedules for machines in a Delivery Group

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.

Schedule overlap:

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

Requirements:

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:

• Delivery Controller version 7.12 (minimum).
  • If you use the latest SDK plug-in with a Controller earlier than 7.12, any new schedules you create will not work as intended.
  • In a mixed site (where some, but not all Controllers have been upgraded), the V2 cmdlets will not work until the database is upgraded and at least one Controller has been upgraded and is being used (by specifying the –adminaddress <controller> parameter with the V2 cmdlets).
  • Best practice: Do not create any new schedules until all Controllers in the site are upgraded.
• PowerShell SDK snap-in provided with XenApp and XenDesktop 7.12 (minimum). After you install or upgrade your components and site, run asnp Citrix.* to load the latest cmdlets.

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

PowerShell cmdlets:

Use the following RebootScheduleV2 cmdlets from the command line to create multiple schedules and use tag restrictions in the schedules.

• New-BrokerRebootScheduleV2 (replaces New-BrokerRebootSchedule)
• Get-BrokerRebootScheduleV2 (replaces Get-BrokerRebootSchedule)
• Set- BrokerRebootScheduleV2 (replaces Set-BrokerRebootSchedule)
• Remove-BrokerRebootScheduleV2 (replaces Remove-BrokerRebootSchedule)
• Rename-BrokerRebootScheduleV2 (new; not a replacement)

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:

• Restrict the schedule to machines that have a specified tag.
• Specify an interval before sending the first warning message, during which no new sessions will be brokered to the affected machines.

Configuration:

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 more information, see Tags.)

1. From Studio, select Delivery Groups in the navigation pane.
2. Select the Delivery Group containing the machines that will be affected by the schedule.
3. Select View Machines and then select the machines where you’ll add a tag.
4. Select Manage Tags in the Actions pane.
5. If the tag already 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 box.

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.

New-BrokerRebootScheduleV2 (replaces New-BrokerRebootSchedule)
Get-BrokerRebootScheduleV2 (replaces Get-BrokerRebootSchedule)
Set- BrokerRebootScheduleV2 (replaces Set-BrokerRebootSchedule)
Remove-BrokerRebootScheduleV2 (replaces Remove-BrokerRebootSchedule)
Rename-BrokerRebootScheduleV2 (new; not a replacement)
New-BrokerRebootScheduleV2 (replaces New-BrokerRebootSchedule)
Get-BrokerRebootScheduleV2 (replaces Get-BrokerRebootSchedule)
Set- BrokerRebootScheduleV2 (replaces Set-BrokerRebootSchedule)
Remove-BrokerRebootScheduleV2 (replaces Remove-BrokerRebootSchedule)
Rename-BrokerRebootScheduleV2 (new; not a replacement)
New-BrokerRebootScheduleV2 (replaces New-BrokerRebootSchedule)
Get-BrokerRebootScheduleV2 (replaces Get-BrokerRebootSchedule)
Set- BrokerRebootScheduleV2 (replaces Set-BrokerRebootSchedule)
Remove-BrokerRebootScheduleV2 (replaces Remove-BrokerRebootSchedule)
Rename-BrokerRebootScheduleV2 (new; not a replacement)