Control: Time Limit Policies

Prev Next

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: 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 or when the device is rebooted. Control reports the policy without regard to whether it has taken effect.

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 management parameters are implemented with all Cloud types. Where not implemented, the parameters are harmless and do nothing.

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.

  • Maximum 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 activity.

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 may be 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.

  • Maintenence Policies will launch the desktops in a pool and prevent them from entering a power-managed state until the period ends.

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: With Application Servers, be careful when setting Windows 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.

If you set specific Windows Remote Desktop Session Time Limits on your Workspot Application Servers, they can interfere with Workspot’s Time Limits Policies and power management.

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.

Note: All these Policies vary somewhat with the Workspot subscription, especially the “Idle Timeout” and “Sleep/Signout After Disconnect” values.

Default Named Policy (Persistent Pools)

Note: The “Sleep After Disconnect” value is too short for most Enterprise/Enterprise+ customers. Workaround: Create a new Time Limits Policy with a suitable timeout.

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.

  • 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: Depends on license type. After the connection is closed or interrupted for any reason, the desktop is placed in a power-saving mode: Pause, Hibernation, Shutdown, or (sometimes) None (run continuously).

    • The “shutdown” mode must be specified explicitly on the “Add/Edit Pool” page, since it doesn’t retain the OS state.

    • Control refers to both Pause and Hibernate as “Sleep.”

    • See Power Management: Shutdown and Hibernation.

  • Maximum Session Length : "-- Select --" (which means "unlimited"). 

  • Sleep Delay for Newly Provisioned Desktops: "--:--" (which means “none”). Newly provisioned desktops wait this long after the Workspot Desktop Agent registers the desktop with Control and the desktop enters the "Ready" state before entering a power-managed state. (If a user is waiting to sign in, no power-managed state is entered). Any additional first-boot tasks that have not yet completed will be deferred until the next time a 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 wait this long after the Workspot Desktop Agent registers the desktop with Control and the desktop enters the "Ready" state before entering a power-managed state. (If a user is waiting to sign in, no power-managed state is entered). Any additional first-boot tasks that have not yet completed will be deferred until the next time a 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 and vary with different Workspot subscriptions.

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: varies with subscription type. 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.

  • Idle Time Action. "Disconnect User." This field is not editable.

  • Sleep after Disconnect. Rangevaries wtih subscription type. On platforms that support power management of any kind (Sleep, Hibernate, or even shutdown if specified explicitly on the “Add/Edit Pools” page), the desktop is put to sleep after the session has been disconnected for this period. Sleep puts the desktop into a power-saving mode. When a user reconnects to a desktop they experience a delay while the desktop wakes, after which they continue working as before if Pause or Hibernate were used, or are presented with a newly booted desktop if Shutdown was used. Set this value high enough that users who were disconnected accidentally are not inconvenienced.

  • Maximum Session Length: Defaults to "unlimited" and is not editable.

  • Sleep Delay for Newly Provisioned Desktops: Newly provisioned desktops wait this long after the Workspot Desktop Agent registers the desktop with Control and the desktop enters the "Ready" state before entering a power-managed state. (If a user is waiting to sign in, no power-managed state is entered). Any additional first-boot tasks that have not yet completed will be deferred until the next time a user signs in.

  • 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.")

  • Never Timeout. Shown on some subscription types. Prevents idle disconnects.

  • Idle Timeout. Range: varies with subscription type. 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.

  • Idle Time Action. Options: "Disconnect User" and "Sign Out." Default: "Disconnect User." "

Note: "Disconnect User" is the recommended setting. Use "Sign Out After Disconnect" to end user sessions.

  • Never Sign Out. Shown on some subscription types. Disconnected users are never signed out.

  • Sign Out After Disconnect. Range: varies with subscription type.  The user is signed out and the desktop is enters a power-managed state or is deleted, according to policies set (in some subscription types only) on the “Add/Edit Pool” page and Warmup Policies. Set this value high enough that users who were disconnected accidentally are not inconvenienced.

  • 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 available.

  • 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 settings for idle time limits and user disconnection in a cloud application.

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: Varies with subscription type. 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.

  • Idle Time Action. Options: "Disconnect User" and "Sign Out." Default: "Disconnect User." "

  • Sign Out After Disconnect. RangeVaries with subscription type. 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.

  • 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. See Control:  Desktop Pools for more information.

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

Pools That Run VMs 24/7

If you have more users than non-persistent desktops or user slots in App Server Pools (that is, you can’t accommodate all users at once), setting “Sign Out After Disconnect” or “Maximum Session Length” will eject long-idle users in favor of real ones trying to connect.

Usage-Based Pools

Shorter timeouts reduce your costs directly with desktop pools. Desktops enter a power-management state as soon as the “Sleep After Disconnect” timer expires or the user signs out. Shorter “Sign Out After Disconnect” timeouts also reduce costs indirectly with App Server Pools, since:

  • An idle server can’t be shut down until the last user is signed out.

  • Idle users occupy user slots in the server, meaning that you have to keep more servers running if you retain more idle user sessions.

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.” Consider a separate pool for such uses.

Related Documents