You can also manage machines in a Machine Catalog; see the Manage Machine Catalogs article.
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 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:
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.
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.
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.