In a CAS deployment, itopia offers the Dynamic Uptime feature that will automatically start and stop Session Hosts instances based on the number of active users in the Collection Pool. By only keeping the required number of 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 the following Collection Pool types:

The behavior of Dynamic Uptime is different depending on the Collection Pool type: RDS - Shared Collection Pools leverage Dynamic Uptime Type I, and all remaining Collection Pools leverage Dynamic Uptime Type II.

The following sections and examples will describe each of these features in action.

Dynamic Uptime Type I is used for Collection Pools that leverage Microsoft Remote Desktop Services (RDS) to support multiple concurrent users on each Session Host. In itopia CAS, this scenario is provided by the RDS Shared Collection Pool type.

Dynamic Uptime Type I relies on two user-defined values to perform its functions:

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

In other words, Dynamic Uptime will calculate the number of Session Hosts 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 VM that remain powered on for ESR are not specific Session Hosts. Any Session Host may remain powered on to satisfy the ESR threshold, and any Session Host VM may be powered off if it has no active users and there are enough VMs to satisfy the ESR threshold.

Dynamic Uptime Type II is used for Collection Pools that support a single concurrent user on each Session Host. In itopia CAS, this scenario is provided by the RDS Dedicated, Windows 10 Pooled, and Windows 10 Dedicated Collection Pool types.

Because Dynamic Uptime Type II is intended only for single-session Session Hosts, the service does not account for the number of active users on a Session Host; therefore, the users per host (UPH) threshold is always 1.

For Windows 10 Pooled Collections, administrators can still set an excluded hosts value; this value specifies the minimum number of Windows 10 Session Hosts that will always remain powered on and immediately available for new user connections. For RDS Dedicated and Windows 10 Dedicated Collection Pools, this setting does not apply because users can only connect to their assigned Session Host and, therefore, it is not beneficial to keep unused Session Hosts powered on.

Dynamic Uptime Type II primarily monitors user logoff from Session Hosts; when a user logs off a single-session Session Host, CAS schedules the host for shutdown within the next five minutes.

Dynamic Uptime Type II works in conjunction with the itopia Cloud VDI Portal; when users prepare to access their remote desktop, the Cloud VDI Portal will automatically power on their Session Host (if it is powered off) before allowing them to connect. This behavior is slightly different depending on the type of Collection Pool:

NOTE: It is important that users access their remote desktops using the itopia Cloud VDI Portal each time they log in. For dedicated Collection Pool types, the Cloud VDI Portal ensures that users' Session Hosts are powered on before the user connects; for shared/pooled Collection types, the Cloud VDI Portal ensures that each user is assigned to an unused Session Host when they connect. More information on the itopia Cloud VDI Portal is available in the following article: Connection Options for CAS Deployments.

For both types of Dynamic Uptime, when a Collection Pool is configured to use the CAS Dynamic Uptime feature, the DynamicUptime agent is installed on each Session Host as a Windows service. This service polls the local Session Host 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:

The following scenarios will help illustrate Dynamic Uptime Type I in action. Note that Dynamic Uptime Type II has a direct 1:1 relation between active user sessions and powered-on Session Hosts; this mechanism does not have any examples to illustrate its behavior.

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

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.

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

Company Z uses the 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 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.

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.

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 only 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 host 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 immediately after Scheduled Uptime instructs it to shut down.

For this reason, we do not recommend using Scheduled Uptime on Session Hosts if Dynamic Uptime is enabled. Attempting to use both features on Session Hosts 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 hosts 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.