Workspot Control's Time Limit Policies allow you to set idle and other timeouts for your desktop and application pools. This lets you control costs on pools that support power management and the availability of shared resources by allowing idle users to be signed out to make room for active users.
Time Limit policies are mandatory for new desktop pools.
Note: In some cases, parameters that aren’t available for a given deployment, Cloud, or use case are grayed out. In others, they are not shown at all.
Note: Not all Time Limits parameters are implemented with all Cloud types. Where not implemented, the parameters are harmless and do nothing.
Note: Unlike other policies, changes to Time Limits Policies (and Agent Policies) do not take effect until the next time the Workspot Agent restarts on the desktop or server, which happens once every 24 hours and when the virtual machine is rebooted. Control reports the policy without regard to whether it has taken effect anywhere.
Types of Time Limit Parameters
The parameters in a Time Limits policy are divided into two categories: activity timeouts and power management actions.
Activity Timeouts
Activity timeouts are the familiar Remote Desktop timeouts, including:
Idle Timeout. A connection is closed if there has been no keyboard/mouse I/O in the timeout period, but the session continues to run as if nothing has happened.
Disconnected Session Timeout. When this timeout expires on a disconnected session, the disconnected session action is taken. This can take a variety of forms, from doing nothing, taking a power-management action, or signing out the user.
Session Length Timeout. If this timeout is enabled, the user is signed out when the session reaches its maximum allowed length, regardless of their level of inactivity.
Power Management Actions
When power-management options are available, they can be used as follows:
The Disconnected User Timeout can trigger a power-management event on an idle desktop VM: sleep, hibernation, or even shutdown.
Sign-out events can also trigger power-management actions. This includes anything that ends the user’s session, not just manual sign-out. If no user is signed in, a power-management action is often taken at once if not inhibited by other considerations.
Warmup Policies and Server Scaling Policies will start or stop non-persistent desktop VMs or application servers on a schedule to ensure that enough provisioned, running VMs are available.
Interaction with Windows Timeouts
General
Time Limit policies have similar effects to Windows RDP timeouts that are set per system or via group policies (GPO). These Windows policies remain in effect. In practice, the policy with the shortest timeout will take effect, leaving the other one without a chance to do anything.
These Windows policies can be found in the Group Policy Editor under “Remote Desktop Services > Remote Desktop Session Host > Session Time Limits” and in the Registry Editor under “HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.”
Workspot recommends not using system or GPO RDP timeouts or setting them considerably longer than the ones in your Time Limit policies. This way, your Time Limits Policies will have the effects you configured them to have, and their operation will be reported in Control’s Event logs and in Workspot Watch.
Application Servers
Warning: Be careful when setting Remote Desktop Session Host time limits in Windows Group Policies or in individual servers’ registry settings on Application Servers. They can prevent user sessions from reconnecting. This does not apply to Workspot Desktops.
If you set specific Remote Desktop Session Time Limits on your Workspot Application Servers, they can interfere with Workspot.
In the Group Policy Editor, these are two of the “Remote Desktop Services > Remote Desktop Session Host > Session Time Limits” settings:
“Set time limit for active but idle Remote Desktop Services sessions.”
“Set time limit for active Remote Desktop Services sessions.”
If these timeouts are set, users who are disconnected because of them will not be able to reconnect until their login session is terminated remotely.
In the system registry, the corresponding settings are under “HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services”: MaxIdleTime and MaxConnectionTime.
Recommendation: Do not configure these parameters or set them to “Disabled.” If you must set them, set them to a much longer timeout than you use in your Time Limits Policies. That way, Workspot will already have disconnected the session before Windows does.
Default Time Limits Policies
Three Time Limits are predefined: "Default Named Policy," "Default Concurrent Policy," and “Default Cloud Apps Policy.” These policies are assigned by default to non-persistent desktop pools, persistent desktop pools, and Application Server Pools, respectively. Their values and meanings are described below.
Default Named Policy (Persistent Pools)
This is a hardwired policy: none of its fields are editable. To change them, create a new policy, set its fields as desired, and assign it to the appropriate pools.
Note: The contents of this page vary depending on your subscription. For BYOcloud subscriptions, the defaults for “Idle Timeout” and “Sleep After” are shown as “-- Select --” (which means “Never”).
Resource: Desktop Pool.
Pool Type: Named (another term for "persistent").
Idle Timeout: 15 minutes. After 15 minutes of mouse/keyboard inactivity, the Client connection will be closed. The desktop continues to run as if nothing has happened, so if the user reconnects, they continue as before.
Idle Time Action: Disconnect User.
Sleep after Disconnect: 10 minutes. Ten minutes after the connection is closed or interrupted for any reason, the desktop is put to sleep. Like sleep and hibernation in Windows, this is a non-destructive power-saving state. Sleep is currently supported only on GCP pools. Desktops with other Cloud providers run continuously.
Maximum Session Length : "-- Select --" (which means "unlimited").
Sleep Delay for Newly Provisioned Desktops: "--:--" (which means “none”). Newly provisioned desktops are put to sleep as soon as the Workspot Desktop Agent registers the desktop with Control and the desktop enters the "Ready" state. Any additional first-boot tasks that have not yet completed will continue when the user signs in. (A nonzero value would allow these tasks to complete before the user signs in.)
Default Concurrent Policy (Non-Persistent Pools)
Resource: Desktop Pool.
Pool Type: Concurrent (non-persistent) pool.
Idle Timeout 15 minutes. After 15 minutes of mouse/keyboard inactivity, the Client connection will be closed. The desktop continues to run as if nothing has happened, so if the user reconnects, they continue as before.
Idle Time Action: Disconnect User. ("Sign Out" is also available to non-default policies.)
Sign Out After Disconnect: 1 Hour. The user is signed out of the desktop and the desktop is shut down and deleted.
Maximum Session Length: None (unlimited).
Sleep Delay for Newly Provisioned Desktops: "--:--" (which means “none”). Newly provisioned desktops are put to sleep as soon as the Workspot Desktop Agent registers the desktop with Control and the desktop enters the "Ready" state. Any additional first-boot tasks that have not yet completed will continue when the user signs in. (A nonzero value would allow these tasks to complete before the user signs in.)
Default Cloud Apps Policy (Application Server Pools)
Resource: Cloud App Pool.
Pool Type: Concurrent.
Idle Timeout 15 minutes. After 15 minutes of mouse/keyboard inactivity, the Client connection will be closed. The user’s session continues to run as if nothing has happened, so if they reconnect, it continues as before.
Idle Time Action: Disconnect User. ("Sign Out" is also available to non-default policies.)
Sign Out After Disconnect: 1 Hour. The user is signed out of the app and no longer occupies a session slot on the server.
Maximum Session Length: None (unlimited).
Sleep Delay for Newly Provisioned Desktops: Not applicable.
Creating a Time-Limit Policy
Sign into Workspot Control as an Administrator and navigate to "Policies > Add a New Policy."
Fill out the "Add a New Policy" form. The forms are different for persistent and non-persistent target pools.
Policy Page Variations
Customers with Enterprise, Enterprise Plus, and BYOcloud licensing see Time Limits policies with fill-in fields for hours and minutes, as shown above. All other customers see a pull-down menu with different time selections, as shown in the rest of this article.
Creating a Persistent Pool Policy
Policy Name. Enter a name in the "Policy Name" field.
Policy Type. Select "Time Limits" from "Policy Type" dropdown.
Resource. Select "Desktop Pool" as the "Resource."
Pool Usage Type. Select "Named" as the "Pool Usage Type." ("Named" is another term for "persistent pool.")
Idle Timeout. Range: 5-60 minutes. Default: 15 minutes. The TCP connection is closed once the desktop is idle (no keyboard or mouse activity) for this period. The state of the desktop itself is unchanged: the user can reconnect and continue as before. A two-minute warning is given before disconnecting, giving the user time to provide input to keep the connection going. Set the Idle Timeout to a value that causes few user complaints.
Note: With hourly-rate desktops, you are charged for the "Idle Timeout" period, so smaller values save you money.
Idle Time Action. "Disconnect User." This field is not editable.
Sleep after Disconnect. Range: 2-30 minutes. Default: 10 minutes. On platforms that support sleep (currently GCP), the desktop is put to sleep after the session has been disconnected for this period. Sleep puts the desktop into a deep power-saving mode. When a user reconnects to a desktop they experience a brief delay while the desktop wakes, after which they continue working as before. Set this value high enough that users who were disconnected accidentally are not inconvenienced.
Note: With hourly-rate persistent desktops, you are charged for the "Sleep After Disconnect" period, so smaller values save you money.
Maximum Session Length: Defaults to "unlimited" and is not editable.
Sleep Delay for Newly Provisioned Desktops: Range: zero to 24 hours in 15-minute increments. Defaults to zero. This delay allows first-boot tasks to complete before the desktop is put to sleep. It starts counting down when the Workspot Desktop Agent on the newly provisioned desktop registers Control and the desktop enters the "Ready" state. If the "Sleep Delay After Disconnect" timeout is greater, it is used instead.
If the first-boot tasks have not yet completed when the desktop is put to sleep, they will continue when the user signs in.
Note: With hourly-rate desktops, you are charged for the "Sleep Delay for Newly Provisioned Desktops" period, though only once over the lifetime of the desktop, so smaller values save you money.
Press "Add Policy" to save.
Apply the policy to your persistent desktop pools.
Wait up to 24 hours or reboot one or more desktops to test the policy.
Creating a Non-Persistent Pool Policy
Policy Name. Enter a name in the "Policy Name" field.
Policy Type. Select "Time Limits" from "Policy Type" dropdown.
Resource. Select "Desktop Pool" as the "Resource."
Pool Usage Type. Select "Concurrent" as the "Pool Usage Type." ("Concurrent" is another term for "non-persistent pool.")
Idle Timeout. Range: 5-60 minutes plus "None" (meaning never). Default: 15 minutes. The TCP connection is closed once the desktop is idle (no keyboard or mouse activity) for this period. The state of the desktop itself is unchanged: the user can reconnect and continue as before. A two-minute warning is given before disconnecting, giving the user time to provide input to keep the connection going. Set the "Idle Timeout" to a value that causes few user complaints.
Note: With hourly-rate desktops, you are charged for the "Idle Timeout" period, so smaller values save you money.
Idle Time Action. Options: "Disconnect User" and "Sign Out." Default: "Disconnect User." "
Note: "Disconnect User" is the recommended setting. "Sign Out After Disconnect" is the recommended sign-out method.
Sign Out After Disconnect. Range: 5-120 minutes plus "None" (meaning never). Default: 10 minutes. The user is signed out and the desktop is shut down and deallocated. When a user reconnects, they get a fresh desktop. Depending on your Warmup Policies settings, they may experience a delay while their new desktop is provisioned. Set this value high enough that users who were disconnected accidentally are not inconvenienced.
Note: With hourly-rate desktops, you are charged for the "Sign Out After Disconnect" period, so smaller values save you money.
Maximum Session Length (optional): Range: 30 minutes to 24 hours plus "None" (unlimited). This sets the maximum time a user can remain signed into the desktop, preventing sessions from lasting indefinitely. The time limit is measured from when the user signs in. The user is signed out when this limit is reached without being given the option to continue. They are warned of the impending sign-out shortly before it happens.
Sleep Delay for Newly Provisioned Desktops: Not applicable to non-persistent desktops.
Press "Add Policy" to save.
Apply the policy to your non-persistent desktop pools.
Wait up to 24 hours or reboot one or more desktops to test the policy.
Creating a Cloud App Server Pool Policy
An individual user may be running more than one Application on the same Application Server, so the user is not signed out until after they have disconnected from all their applications.
Power management for Application Servers is handled with Server Scaling Policies, which are related to Time Limits Policies only indirectly: a server will not be shut down until its last user has signed out.
To create an Application Server Time Limits Policy:
Policy Name. Enter a name in the "Policy Name" field.
Policy Type. Select "Time Limits" from "Policy Type" dropdown.
Resource. Select "Cloud App Pool" as the "Resource."
Pool Type. Select "Concurrent"
Idle Timeout. Range: 5 minutes to 3 hours plus "None" (meaning never). Default: 15 minutes. The TCP connection is closed once the app is idle (no keyboard or mouse activity) for this period. The state of the app itself is unchanged: the user can reconnect and continue as before. A two-minute warning is given before disconnecting, giving the user time to provide input to keep the connection going. Set the "Idle Timeout" to a value that causes few user complaints.
Note: With hourly-rate servers, you are charged for the "Idle Timeout" period, so smaller values save you money.
Idle Time Action. Options: "Disconnect User" and "Sign Out." Default: "Disconnect User." "
Note: "Disconnect User" is the recommended setting. "Sign Out After Disconnect" is the recommended sign-out method.
Sign Out After Disconnect. Range: 5-120 minutes plus "None" (meaning never). Default: 1 hour. The user is signed out. When a user reconnects, they get a fresh copy of the app. Set this value high enough that users who were disconnected accidentally are not inconvenienced.
Note: With hourly-rate servers, you are charged for the "Sign Out After Disconnect" period, so smaller values save you money.
Maximum Session Length (optional): Range: 30 minutes to 24 hours plus "None" (unlimited). This sets the maximum time a user can remain signed into the desktop, preventing sessions from lasting indefinitely (and occupying user slots indefinitely). The time limit is measured from when the user signs in. The user is signed out when this limit is reached without being given the option to continue. They are warned of the impending signout shortly before it happens.
Sleep Delay for Newly Provisioned Desktops: Not applicable.
Press "Add Policy" to save.
Apply the policy to your application server pools.
Wait up to 24 hours or reboot one or more servers to test the policy.
Editing a Time Limit Policy
On the "Policies" page, click on the policy name to navigate to the Edit Policy page. This is almost identical to the Add Policy page except that you can't change the "Policy Type," "Resource," or "Pool Usage Type" fields.
Applying a Time Limit Policy to a Desktop or App Server Pool
After creating a Time Limits policy, go to the Add/Edit Pools page and select it from the Time Limits Policy pulldown menu.
After applying the policy, wait up to 24 hours or reboot one or more VMs to test it.
Time Limit Policies and Event Logs
Control adds an entry to the event log whenever a user is disconnected or signed out due to a Time Limit policy. If users complain about sessions or connections ending prematurely, check the Events page in Control.
Best Practices
Flat-Rate Pools
If you have more users than non-persistent desktops or user slots in an App Server Pool, setting a session timeout will eject long-idle users in favor of real ones trying to connect. There is no monetary advantage to you if you set the timeouts so short that you receive complaints from users. The defaults are a good starting point.
Usage-Based Pools
Shorter timeouts reduce your costs directly with desktop pools, allowing the VMs to enter a power-management state, and indirectly with App Server Pools, since an idle server can’t be shut down until the last user is signed out. Set the timeouts to values that don't interfere with user productivity.
Batch Jobs
If users need to run long-running batch jobs while the desktop is otherwise idle, set “Pause/Hibernate/Sign Out After Disconnect” to “None.” Use cautiously when you are being billed for uptime.