In a Remote Desktop Services (RDS) deployment, itopia offers the Dynamic Uptime feature that will automatically start and stop RD Session Host instances based on the number of active users in the RDS environment. By only keeping the required number of RD Session Host servers active, Dynamic Uptime helps reduce GCP compute costs for the Session Host VM instances.

Dynamic Uptime can be enabled and configured for each individual RD Collection Pool, and applies to the RD Collection in each region. The following sections and examples will help illustrate this feature in action.

Term Definitions

In this article, the following terms may be used:

  • Active server - an RD Session Host server that is powered on and accepting new user connections, and has active users
  • Idle server - an RD Session Host server that is powered on and accepting new user connections, but has no active users
  • Draining server - an RD Session Host server that is powered on but not accepting new user connections
  • Stopped server - an RD Session Host server that is powered off

Dynamic Uptime Settings

The Dynamic Uptime feature relies on two user-defined values to perform its functions:

  • The users per host (UPH) threshold defined in the Autoscale settings. This value defines the maximum number of active users that can be simultaneously connected to a single RD Session Host server.
  • The excluded servers per region (ESR) defines the number of RD Session Host servers in each region of the Collection Pool that will not participate in Dynamic Uptime operations. That is, the number of RD Session Host servers that will always remain powered on (unless they are scheduled to be shut down using the Scheduled Uptime feature; more information on the behavior of these two features is provided below).

The ESR setting specifies the number of servers that are powered on in addition to the number of servers that are required for Dynamic Uptime. For example, if a Collection Pool is configured with a ESR value of 2, this means that:

  • The Collection Pool will have 2 RD Session Host servers running at all times, even when there are no active users logged in
  • As soon as the first user logs in to the environment, a Dynamic Uptime event starts a new Session Host server, for a total of 3 hosts
  • When the (UPH + 1) user logs in, a Dynamic Uptime event starts the next Session Host server

In other words, Dynamic Uptime will calculate the number of servers needed for the active user count without including the capacity of the ESR hosts. This can be represented using the following basic formula:

It is important to note that the servers that remain powered on for ESR are not specific servers. Any RD Session Host server may remain powered on to satisfy the ESR threshold, and any RD Session Host may be powered off if it has no active users and there are enough servers to satisfy the ESR threshold.

DynamicUptime Service

When an RD Collection Pool is configured to use the CAS Autoscale feature, the DynamicUptime agent is installed on each RD Session Host server as a Windows service. This service polls the local RD Session Host server every 60 seconds to determine the number of active (i.e. logged-on and connected) user sessions.

If it is the first time the agent has polled the server after a reboot, the number of active users is reported to the itopia CAS backend via TCP/443. On subsequent pollings, the agent will only report to the CAS backend if the number of active sessions has changed. If the number of active user sessions remains unchanged, the agent records the number locally for the next comparison.

For each Collection Pool, the CAS backend executes a function every five minutes that uses the most recent active user count to calculate the number of required servers ( [Active Users / Users Per Host Setting] + Excluded Server Count ). It compares this with the number of active servers (i.e., powered on and accepting new connections) and performs the following:

  • If additional server capacity is required, CAS searches for servers that are powered on but not accepting new connections (i.e. they are draining in anticipation of a shutdown). If a draining server is available, the drain is canceled and the server is permitted to accept new connections, making it an active server; if no draining servers are found, CAS powers on a stopped server.
  • If there is excess server capacity, CAS attempts to find a server with no active users (i.e. an idle server). If an idle server is available, it is powered off and becomes a stopped server; if no idle servers are found, CAS picks an active server and configures it to prevent new user logons, ¬†which makes it a draining server in anticipation of a shutdown.

Example Scenarios

The following scenarios will help illustrate Dynamic Uptime in action.

Scenario 1 - Start of Work Day and End of Work Day

In this scenario, consider the following configuration for a Collection Pool at Company X:

  • 90 users are assigned to the Collection Pool
  • Dynamic Uptime is enabled
  • The Users per Host (UPH) threshold is set to 10
  • The Excluded Servers per Region (ESR) is set to 2

Company X offers flexible scheduling: users can work an eight-hour day from 7AM until 3PM, 8AM until 4PM, or 9AM until 5PM. Employees at Company X use the flexible scheduling fairly evenly, with about 1/3 of users in each schedule. Thus, the number of Session Hosts for Company X would resemble the following:

At the end of the day, users begin logging out of their sessions, and the process works in reverse:

In this scenario, Dynamic Uptime simply serves as a convenient alternative to Scheduled Uptime, allowing servers to power on based on demand and to remain powered on only as long as needed.

Scenario 2 - Sporadic Use throughout the Day

In this scenario, consider the following configuration for a Collection Pool at Company Z:

  • 100 users are assigned to the Collection Pool
  • Dynamic Uptime is enabled
  • The Users per Host (UPH) threshold is set to 25
  • The Excluded Servers per Region (ESR) is set to 2

Company Z uses the RD Collection Pool only to provide a legacy application via RemoteApp that is accessed throughout the day by a large number of users, but for only a short period of time.

Company Z has configured 2 RD Session Hosts to be excluded (i.e., ESR is set to 2), to serve as a "buffer" if a large number of users log in at once and additional hosts need to be powered on quickly. In this example, Server 1 and Server 2 are considered the initial ESR servers, because Dynamic Update kept them powered on even after all users had logged off (i.e., they were the last servers to reach 0 active users).

When the first user logs in to either of these servers, the first "dynamic" server is started and accepts new connections. When the 26th user (UPH + 1) logs in, the next dynamic server is started.

As additional users log in, they are distributed across all available Session Host servers, including the "ESR" servers. When an individual server reaches the UPH threshold-- in this case, 25 active connections-- it is excluded from accepting new connections.

As the peak usage period elapses, users begin logging out of the environment. The servers that first reached the UPH threshold are typically the first to reach 0 active users and are shut down by the Dynamic Uptime service. The remaining servers continue to accept users that may log in, but when a server reaches 0 active users it may be shut down by the service. When the number of powered-on servers is equal to the ESR value, the remaining servers will not be shut down.

This is represented in the table below.

Enabling Dynamic Uptime

Dynamic Uptime can be configured when you first create a new Collection Pool. You simply enable the toggle for Dynamic Uptime and specify the number of Excluded servers (per region). When the Collection Pool is provisioned, Dynamic Uptime will be enabled.

To enable Dynamic Uptime on an existing Collection Pool, you must first power on all User Session Servers in the Collection Pool and then enable the feature in the Collection Pool settings. CAS will install the DynamicUptime service on the servers and begin monitoring them; a reboot is not required, but servers may be powered off if the Dynamic Uptime thresholds are met.

Dynamic Uptime and Scheduled Uptime

CAS also provides the Scheduled Uptime feature for starting and stopping VM instances based on a configurable schedule. As the name implies, Scheduled Uptime allows an administrator to define when to start and stop servers based on a schedule; the schedule can target a subset of servers and can be configured for unique times each day of the week. Unlike Dynamic Uptime, Scheduled Uptime can be applied to all servers in a CAS deployment, not just RD Session Hosts.

Scheduled Uptime is a useful feature for specific use cases. If, for example, an organization has offices around the world, Scheduled Uptime can help shut down unnecessary infrastructure in each region during off-peak times, which can significantly reduce GCP Compute costs.

Scheduled Uptime and Dynamic Uptime do not coordinate their actions. If a server is scheduled to shut down at a certain time, it will do so regardless of whether the server is needed to maintain the UPH defined in Dynamic Uptime; similarly, Dynamic Uptime may power on a Session Host server immediately after Scheduled Uptime instructs it to shut down.

For this reason, we do not recommend using Scheduled Uptime on RD Session Host servers if Dynamic Uptime is enabled. Attempting to use both features on RD Session Host servers may lead to unpredictable and unexpected results, and you may not get the costs-savings that could be achieved by using either feature separately. The end-user experience may also be impacted by sessions being terminated as servers are shut down according to their schedule. You may continue to use Scheduled Uptime for other server roles, such as RD Gateway servers and Domain Controllers.

Did this answer your question?