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 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.
Default Time Limits Policies
Two Time Limits are predefined: "Default Named Policy" and "Default Concurrent Policy." These policies are assigned by default to non-persistent and persistent 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 signout 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
Policy Name. Enter a name in the "Policy Name" field.
Policy Type. Select "Time Limitsl" 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 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: 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 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 (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.
Interaction with Other Policies
Time Limit policies have similar effects to RDP timeouts that are set per system or via group policies (GPO). These other policies remain in effect. In practice, the policy with the shortest timeout is the one that will take effect.
Workspot recommends not using system/GPO RDP timeouts or setting them longer than the ones in your Time Limit policies. That way, all the time limits that take effect will be reflected in Control's event logs.
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.