Citrix Virtual Apps and Desktops service

Schedule-based and load-based settings

How Autoscale power manages machines

Autoscale powers machines on and off based on the selected schedule. Autoscale lets you set multiple schedules that include specific days of the week and adjust the number of machines available during those times. If you expect a set of users to consume the machine resources at a specific time on specific days, Autoscale helps provide an optimized experience. Note that those machines will be powered on during the schedule, irrespective of whether there are sessions running on them.

Note:

Autoscale does not support power managing manually provisioned machines and machines in dedicated machine catalogs.

The schedule is based on the time zone of the delivery group. To change the time zone, you can change user settings in a delivery group. For more information, see Manage Delivery Groups.

Autoscale has two default schedules: Weekdays (Monday through Friday) and Weekend (Saturday and Sunday). By default, the Weekdays schedule keeps one machine powered on from 07:00 AM to 06:30 PM during peak times and none during off-peak times; the default capacity buffer is set to 10% during peak and off-peak times. By default, the Weekend schedule keeps no machines powered on.

Note:

Autoscale treats only those machines that are registered with the Site as part of the available capacity in the calculations it makes. “Registered” means that the machine is available for use or already in use. Doing so ensures that only machines that can accept user sessions are included in the capacity for the delivery group.

Schedule-based settings

Autoscale schedule. Lets you add, edit, select, and delete schedules.

Days applied. Highlights the days you applied to the selected schedule. The remaining days are grayed out.

Edit. Lets you assign the machines against each hour or each half hour. You can assign the machines by numbers and by percentages.

Note:

  • This option is available only in the Autoscale user interfaces for RDS and pooled VDI delivery groups.
  • The histogram next to Edit plots the number or percentage of machines that are running in different time slots.
  • You can assign machines against each time slot by clicking Edit above Peak times. Depending on the option you selected from the dropdown in the Machines to start window, you can assign the machines by numbers or by percentages.
  • For RDS delivery groups, you can set the minimum number of running machines separately for each half hour of the day. For pooled VDI delivery groups, you can set the minimum number of running machines separately for each hour of the day.

To define your own schedules, follow the steps below.

  1. Select Edit schedules from the dropdown and then click Add schedule.

  2. In the Edit Autoscale Schedules window, select the days you want to apply to each schedule. You can also delete schedules where applicable.

  3. Click Apply to save the schedules and to return to the Autoscale page.

  4. Select the applicable schedule from the dropdown and set the applicable options for that schedule.

Important:

  • Autoscale does not allow the same day to overlap in different schedules. For example, if you select Monday in schedule2 after selecting Monday in schedule1, Monday is automatically cleared in schedule1.
  • A schedule name is not case sensitive.
  • A schedule name must not be blank or contain only spaces.
  • Autoscale allows blank spaces between characters.
  • A schedule name must not contain the following characters: \ / ; : # . * ? = < > | [ ] ( ) { } “ ‘ `.
  • Autoscale does not support duplicate schedule names. Enter a different name for each schedule.
  • Autoscale does not support empty schedules. This means that schedules without days selected are not saved.

Note:

On the Autoscale page, the days included in the selected schedule are highlighted, while those not included are grayed out.

Load-based settings

Peak times. Lets you define the peak times for the days you applied in the selected schedule. You can do so by right-clicking the horizontal bar graph. After you define the peak times, the remaining, undefined times default to off-peak times. By default, the 7:00 AM to 7:00 PM time slot is defined as peak times for the days included in the selected schedule.

Important:

  • For RDS delivery groups, the peak times bar graph is used for the capacity buffer.
  • For VDI delivery groups, the peak times bar graph is used for the capacity buffer and controls the actions to be triggered after logoff and/or disconnection.
  • In the web-based console, you can define the peak times for the days included in a schedule at a granular level of 30 minutes for both RDS and VDI Delivery Groups. In the legacy console, you can do that only for RDS Delivery Groups. Alternatively, you can use the New-BrokerPowerTimeScheme PowerShell command instead. For more information, see Broker PowerShell SDK commands.

Capacity buffer. Lets you keep a buffer of powered-on machines. A lesser value decreases the cost. A greater value ensures an optimized user experience so that when launching sessions, users do not have to wait for additional machines to power on. By default, the capacity buffer is 10% for peak and off-peak times. If you set the capacity buffer to 0 (zero), users might have to wait for additional machines to power on when launching sessions. Autoscale lets you determine the capacity buffer separately for peak and off-peak times.

Miscellaneous settings

Tip:

When disconnected. Lets you specify how long a disconnected, locked machine remains powered on after session disconnection before it is suspended or shut down. If a time value is specified, the machine is suspended or shut down when the specified disconnection time is elapsed, depending on the actions you configured. By default, no action is assigned to disconnected machines. You can define options separately for peak and off-peak times. To do so, click the down arrow and then select one of the following options from the menu:

  • No action. If selected, the machine after session disconnection remains powered on and Autoscale does not act on it.
  • Suspend. If selected, Autoscale pauses the machine without shutting it down when the specified disconnection time is elapsed.
  • Shut down. If selected, Autoscale shuts down the machine when the specified disconnection time is elapsed.

Note:

This option is available only in the Autoscale user interfaces for pooled and static VDI delivery groups.

When logged off. Lets you specify how long a machine remains powered on after session logoff before it is suspended or shut down. If a time value is specified, the machine is suspended or shut down when the specified logoff time is elapsed, depending on the actions you configured. By default, no action is assigned to logged off machines. You can define options separately for peak and off-peak times. To do so, click the down arrow and then select one of the following options from the menu:

  • No action. If selected, the machine after session logoff remains powered on and Autoscale does not act on it.
  • Suspend. If selected, Autoscale pauses the machine without shutting it down when the specified logoff time is elapsed.
  • Shut down. If selected, Autoscale shuts down the machine when the specified logoff time is elapsed.

Note:

This option is available only in the Autoscale user interface for static VDI delivery groups.

Power-off delay. Lets you specify the minimum number of minutes that must elapse after a machine is powered on before Autoscale powers it off. By default, the power-off delay is 30 minutes. You can set it in a range of 0–60 minutes. For more information, see How power-off delay works

Note:

  • In the legacy console, this option is available only in the Autoscale user interface for RDS delivery groups. In the web-based console, it is available in the Autoscale user interface for both RDS and static VDI delivery groups.
  • To configure the power-off delay for static VDI delivery groups, use the PowerShell SDK. For example: C:\PS> Set-BrokerDesktopGroup "MyDesktop" -PowerOffDelay 15. For static VDI delivery groups, the power-off delay applies to both assigned and unassigned machines.
  • In some scenarios, you might want to configure a time period during which the power-off delay does not take effect to prevent Autoscale from powering off the relevant machines. For example, configure a time period to makes sure that your logoff scripts can complete successfully before machines are powered off. You can use the PowerShell SDK. For example: C:\PS> Set-BrokerDesktopGroup "MyDesktop" -SettlementPeriodBeforeAutoShutdown <TimeSpan>. For more information, see Broker PowerShell SDK commands.

Machine instance cost per hour. Lets you specify the machine instance cost per hour that matches with your cost basis. Machine instance cost per hour is the cost per hour, in US$, of the computing capacity being used. This setting is used to calculate the cost savings of the Autoscale settings above. To view the savings, go to Monitor > Trends > Machine Usage. For more information, see Monitor Autoscale-managed machines.

Note:

Autoscale does not support changing the currency unit for your cost basis.

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.
  • For this enhancement to take effect, you need to enable Autoscale for the applicable delivery group. Otherwise, disconnect power policy actions are not triggered on period transition.

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 this release, Autoscale suspends or powers off the machine when the specified disconnection time elapses, depending on the disconnect action configured for the destination time period.

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

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

Note:

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

In earlier releases, a VDI machine with a session disconnected during peak times remained powered on when it transitioned from peak to off-peak. Starting with this release, 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.

In case 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 (true; enables the previous behavior). By default, the value is 0 (false; triggers disconnect power policy actions on period transition).
    • Path: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\DesktopServer
    • Name: LegacyPeakTransitionDisconnectedBehaviour
    • Type: REG_DWORD
    • Data: 0x00000001 (1)
  • Configure the setting by using the Set-BrokerServiceConfigurationData PowerShell command. For example:
    • PS C:\> Set-BrokerServiceConfigurationData HostingManagement.LegacyPeakTransitionDisconnectedBehaviour -SettingValue $true

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

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

How capacity buffer works

Capacity buffer is used to add spare capacity to the current demand to account for dynamic load increases. There are two scenarios to be aware of:

  • For RDS delivery groups, the capacity buffer is defined as a percentage of the total capacity of the delivery group in terms of load index. For more information about load index, see Load index.

  • For VDI delivery groups, the capacity buffer is defined as a percentage of the total capacity of the delivery group in terms of the number of machines.

Autoscale lets you set the capacity buffer separately for peak and off-peak times. A lesser value in the capacity buffer field decreases the cost because Autoscale powers on less spare capacity. A greater value ensures an optimized user experience so that users do not have to wait for additional machines to power on when launching sessions. By default, the capacity buffer is 10%.

Important:

The capacity buffer results in machines being powered on when the total spare capacity drops to a level below “X” percent of the total capacity of the delivery group. Doing so reserves the required percentage of spare capacity.

How power-off delay works

Use the power-off delay feature to specify the minimum number of minutes that must elapse after a machine is powered on before Autoscale powers it off. Doing so keeps machines from “flip-flopping” on and off during volatile session demands. The power-off delay option is available only in the Autoscale user interface of RDS delivery groups. To configure the power-off delay for static VDI delivery groups, use the PowerShell SDK. For example, suppose you want to set the power-off delay to 15 minutes for a delivery group whose name is “MyDesktop.” Use the Set-BrokerDesktopGroup PowerShell command. For example:

PS C:\> Set-BrokerDesktopGroup "MyDesktop" -PowerOffDelay 15

For static VDI delivery groups, the power-off delay applies to both assigned and unassigned machines.

RDS delivery groups

When are machines powered on?

Important:

If a schedule is selected, Autoscale powers on all machines configured to be powered on in the schedule. Autoscale keeps this specified number of machines powered on during the schedule, irrespective of the load.

When the number of powered-on machines in the delivery group can no longer meet the buffer needed for honoring the buffer capacity in terms of load index, Autoscale powers on extra machines. For example, let’s say your delivery group has 20 machines and 3 machines are scheduled to be powered on as part of schedule-based scaling with a capacity buffer of 20%; eventually 4 machines will be powered on when there is no load. This is because a 4 x 10k load index is needed as a buffer; therefore at least 4 machines need to be powered on. This case might occur during peak times, increased load on machines, new session launches, and when you add new machines to the delivery group. Note that Autoscale powers on only the machines that meet the following criteria:

  • The machines are not in maintenance mode.

  • The hypervisor on which the machines are running is not in maintenance mode.

  • The machines are currently powered off.

  • The machines have no pending power actions.

When are machines powered off?

Important:

  • If a schedule is selected, Autoscale powers off the machines based on the schedule.
  • Autoscale does not power off the machines configured in the schedule to be powered on during the schedule.

When there are more than enough machines to support the targeted number of powered-on machines (including the buffer) for the delivery group, Autoscale powers off extra machines. This case might occur during off-peak times, decreased load on machines, and session logoffs, and when you remove machines from the delivery group. Autoscale powers off only the machines that meet the following criteria:

  • The machines and the hypervisor on which the machines are running are not in maintenance mode.

  • The machines are currently powered on.

  • The machines are registered as available or waiting to register after start-up.

  • The machines have no active sessions.

  • The machines have no pending power actions.

  • The machines satisfy the specified power-off delay. This means that the machines have been powered on for at least “X” minutes, where “X” is the power-off delay specified for the delivery group.

Example scenario

Suppose you have the following scenario:

  • Delivery Group configuration. The delivery group that you want Autoscale to power manage contains 10 machines (M1 to M10).

  • Autoscale configuration

    • Capacity buffer is set to 10%.
    • No machine is included in the selected schedule.

The scenario is executed in the following sequence:

  1. No user logs on.

  2. User sessions increase.

  3. More user sessions start.

  4. User session load decreases because of session termination.

  5. User session load decreases further until the session load is handled only by on-premises resources.

See below for details about how Autoscale works in the scenario above.

  • No user load (initial state)
    • One machine (for example, M1) is powered on. The machine is powered on because of the configured capacity buffer. In this case, 10 (number of machines) x 10,000 (load index) x 10% (configured capacity buffer) equals 10,000. Therefore, one machine is powered on.
    • The load index value of the powered-on machine (M1) is at a baseline load (load index equals 0).
  • The first user logs on
    • The session is directed to be hosted on machine M1.
    • The load index of the powered-on machine M1 increases and machine M1 is no longer at a baseline load.
    • Autoscale starts to power on an additional machine (M2) to meet the demand because of the configured capacity buffer.
    • The load index value of machine M2 is at a baseline load.
  • Users increase load
    • The sessions are load-balanced across machines M1 and M2. As a result, the load index of the powered-on machines (M1 and M2) increases.
    • The total spare capacity is still at a level above 10,000 in terms of load index.
    • The load index value of machine M2 is no longer at a baseline load.
  • More user sessions start
    • The sessions are load-balanced across machines (M1 and M2). As a result, the load index of the powered-on machines (M1 and M2) increases further.
    • When the total spare capacity drops to a level below 10,000 in terms of load index, Autoscale starts to power on an additional machine (M3) to meet the demand because of the configured capacity buffer.
    • The load index value of machine M3 is at a baseline load.
  • Even more user sessions start
    • The sessions are load-balanced across machines (M1 to M3). As a result, the load index of the powered-on machines (M1 to M3) increases.
    • The total spare capacity is at a level above 10,000 in terms of load index.
    • The load index value of machine M3 is no longer at a baseline load.
  • User session load decreases because of session termination
    • After users log off their sessions or idle sessions time out, the freed-up capacity on machines M1 to M3 is reused to host sessions started by other users.
    • When the total spare capacity increases to a level above 10,000 in terms of load index, Autoscale puts one of the machines (for example, M3) into drain state. As a result, sessions started by other users are no longer directed to that machine unless new changes occur; for example, end-user load increases again or other machines become least loaded.
  • User session load continues to decrease
    • After all sessions on machine M3 are terminated and the specified power-off delay times out, Autoscale powers off machine M3.
    • After more users terminate their sessions, the freed-up capacity on powered-on machines (M1 and M2) is reused to host sessions started by other users.
    • When the total spare capacity increases to a level above 10,000 in terms of load index, Autoscale puts one of the machines (for example, M2) into drain state. As a result, sessions started by other users are no longer directed to that machine.
  • User session load continues to decrease until there are no sessions
    • After all sessions on machine M2 are terminated and the specified power-off delay times out, Autoscale powers off machine M2.
    • The load index value of the powered-on machine (M1) is at a baseline load. Autoscale does not put machine M1 into drain state because of the configured capacity buffer.

Note:

For RDS delivery groups, all changes to the desktop are lost when users log off sessions. However, if configured, user-specific settings are roamed along with the user profile.

Pooled VDI delivery groups

Capacity buffer is used to accommodate sudden spikes in demand by keeping a buffer of machines powered on based on the total number of machines in the delivery group. By default, the capacity buffer is 10% of the total number of machines in the delivery group.

If the number of machines (including the capacity buffer) exceeds the total number of currently powered-on machines, additional machines are powered on to meet the demand. If the number of machines (including the capacity buffer) is less than the total number of currently powered-on machines, the excess machines are shut down or suspended, depending on the actions you configured.

Example scenario

Suppose you have the following scenario:

  • Delivery Group configuration. The delivery group that you want Autoscale to power manage contains 10 machines (M1 to M10).
  • Autoscale configuration
    • Capacity buffer is set to 10%.
    • No machine is included in the selected schedule.

The scenario is executed in the following sequence:

  1. No user logs on.

  2. User sessions increase.

  3. More user sessions start.

  4. User session load decreases because of session termination.

  5. User session load decreases further until the session load is handled only by on-premises resources.

See below for details about how Autoscale works in the scenario above.

  • No user load (initial state)
    • One machine (M1) is powered on. The machine is powered on because of the configured capacity buffer. In this case, 10 (number of machines) x 10% (configured capacity buffer) equals 1. Therefore, one machine is powered on.
  • A first user logs on
    • The first time a user logs on to use a desktop, the user is assigned a desktop from a pool of desktops hosted on powered-on machines. In this case, the user is assigned a desktop from machine M1.
    • Autoscale starts to power on an additional machine (M2) to meet the demand because of the configured capacity buffer.
  • A second user logs on
    • The user is assigned a desktop from machine M2.
    • Autoscale starts to power on an additional machine (M3) to meet the demand because of the configured capacity buffer.
  • A third user logs on
    • The user is assigned a desktop from machine M3.
    • Autoscale starts to power on an additional machine (M4) to meet the demand because of the configured capacity buffer.
  • A user logs off
    • After a user logs off or the user’s desktop times out, the freed-up capacity (for example, M3) is available as buffer. As a result, Autoscale starts to power off machine M4 because the capacity buffer is configured as 10%.
  • More users log off until there are no users
    • After more users log off, Autoscale powers off machines (for example, M2 or M3).
    • Even though there are no users left, Autoscale does not power off the remaining one machine (for example, M1) because that machine is reserved as a spare capacity.

Note:

For pooled VDI delivery groups, all changes to the desktop are lost when users log off sessions. However, if configured, user-specific settings are roamed along with the user profile.

Static VDI delivery groups

Capacity buffer is used to accommodate sudden spikes in demand by keeping a buffer of unassigned machines powered on based on the total number of unassigned machines in the delivery group. By default, the capacity buffer is 10% of the total number of unassigned machines in the delivery group.

Important:

After all machines in the delivery group are assigned, the capacity buffer does not play a role in powering machines on or off.

If the number of machines (including the capacity buffer) exceeds the total number of currently powered-on machines, additional, unassigned machines are powered on to meet the demand. If the number of machines (including the capacity buffer) is less than the total number of currently powered-on machines, excess machines are powered off or suspended, depending on the actions you configured.

For Static VDI delivery groups, Autoscale:

  • Powers assigned machines on during peak times and off during off-peak times only when the AutomaticPowerOnForAssigned property of the applicable VDI delivery group is set to true.
  • Automatically powers on a machine during peak times if it is powered off and the AutomaticPowerOnForAssignedDuringPeak property of the delivery group to which it belongs is set to true.

To understand how capacity buffer works with assigned machines, consider the following:

  • The capacity buffer works only when the delivery group has one or more unassigned machines.
  • If the delivery group has no unassigned machines (all machines in the delivery group are assigned), the capacity buffer does not play a role in powering machines on or off.
  • The AutomaticPowerOnForAssignedDuringPeak property determines whether assigned machines are powered on during peak times. If it is set to true, Autoscale keeps the machines powered on during peak times; Autoscale will also power them on even if they are powered off.

Example scenario

Suppose you have the following scenario:

  • Delivery Group configuration. The delivery group that you want Autoscale to power manage contains 10 machines (M1 to M10).
  • Autoscale configuration
    • Machines M1 to M3 are assigned, and machines M4 to M10 are unassigned.
    • Capacity buffer set to 10% for peak and off-peak times.
    • According to the selected schedule, Autoscale power manages machines between 09:00 AM and 06:00 PM.

See below for details about how Autoscale works in the scenario above.

  • Start of schedule – 09:00 AM
    • Autoscale powers on machines M1 to M3.
    • Autoscale powers on an additional machine (for example, M4) because of the configured capacity buffer. Machine M4 is unassigned.
  • A first user logs on
    • The first time a user logs on to use a desktop, the user is assigned a desktop from a pool of desktops hosted on unassigned powered-on machines. In this case, the user is assigned a desktop from machine M4. Subsequent logons from that user connect to the same desktop that was assigned on first use.
    • Autoscale starts to power on an additional machine (for example, M5) to meet the demand because of the configured capacity buffer.
  • A second user logs on
    • The user is assigned a desktop from the unassigned powered-on machines. In this case, the user is assigned a desktop from machine M5. Subsequent logons from that user connect to the same desktop that was assigned on first use.
    • Autoscale starts to power on an additional machine (for example, M6) to meet the demand because of the configured capacity buffer.
  • Users log off
    • As users log off their desktops or the desktops time out, Autoscale keeps the machines M1 to M5 powered on during 09:00 AM – 06:00 PM. When those users log on the next time, they connect to the same desktop that was assigned on first use.
    • The unassigned machine M6 is waiting to serve a desktop to an incoming, unassigned user.
  • End of schedule – 06:00 PM
    • At 06:00 PM, Autoscale powers off machines M1 to M5.
    • Autoscale keeps the unassigned machine M6 powered on because of the configured capacity buffer. That machine is waiting to serve a desktop to an incoming, unassigned user.
    • In the delivery group, machines M6 to M10 are unassigned machines.
Schedule-based and load-based settings