Terminal Services RemoteApp™ Session Termination Logic

Terminal Services RemoteApp™ Session Termination Logic

There are several heuristics and session time limit Group Policy settings that dictate the lifetime of a RemoteApp session. The main difference in behavior between a RemoteApp session and a regular full desktop session is that there is no explicit way for the user to either log off or disconnect a RemoteApp session.

The procedure for when to end a RemoteApp session involves two stages. In the first stage, heuristics are applied to determine whether the session needs to be disconnected. If the session needs to be disconnected, stage two is triggered. In stage two, Group Policy settings are used to decide if and when to log off the disconnected RemoteApp session.

Stage I: When should the RemoteApp session be disconnected?

Several factors are considered in deciding when to disconnect a RemoteApp session. The session disconnection is triggered when all RemoteApp windows and user launched system tray icons are closed. The following flow chart shows the decision-making process. Each step is discussed in detail below.

1. A RemoteApp session remains active as long as there is at least one visible or active window in that session.
- The active window could be in any of the window states (minimized, maximized or restored).

- The active window could belong to an application that was either started directly or indirectly as a RemoteApp program.

Scenario: A user double-clicks the Remote Outlook icon to start Microsoft® Office Outlook®. [Outlook is the directly started application]. The user then opens an e-mail with a Word attachment and opens the document. This starts Word in the session. [Word is the indirectly started application]. The session will remain active until both the Outlook and Word windows are closed.

2. A RemoteApp session remains active as long as there is at least one notification area (system tray) icon of an application that was started directly or indirectly by the user.

Scenario: A user double-clicks the Remote Microsoft Office Communicator icon. After the application is started, the remote notification area icon for Communicator is also shown in the client’s notification area. Even if the main window of Communicator is closed, the application is still running in the background. The session will remain active.

Note that a remote notification area icon that is not explicitly started by the user is not taken into consideration as part of decision 2.

Scenario: A user double-clicks the Remote Outlook icon to start Outlook. As part of the logon script, the antivirus software client also starts and appears in the notification area. If the remote Outlook window is closed by the user, the remote notification area icon that belongs to the antivirus program is ignored because it was not started (either directly or indirectly) by the user.

3. If the answers to decision 1 and decision 2 are both “No,” there are no RemoteApp programs running in the session. At this point, there is a 20 second wait, in case the user wants to start another RemoteApp program on the same server, or if the recently closed RemoteApp program displays any messages upon closure. If the user chooses not to start any more remote programs in this period, the RemoteApp session will be disconnected and the client process (mstsc.exe) will exit.

Stage II – Setting the time delay for the logoff from a disconnected RemoteApp session

You can use the Session Time Limits policy settings for Terminal Services sessions to set the time limit for RemoteApp sessions. Typically, administrators use these policy settings for scalability reasons.

New Group Policy setting—RemoteApp session logoff delay

There is a new policy setting introduced in Windows Server 2008 that allows for the administrator to set the time delay for the logoff from a disconnected RemoteApp session. As it is much faster to connect to a disconnected session as opposed to starting a new session, you can use this policy setting to provide a faster startup times when a user launches a new RemoteApp on the same server. Based on server performance, an administrator must determine a time limit that provides the best user experience, while not overwhelming server resources by permitting these "no remote program running" RemoteApp sessions to remain in a disconnected state.

What is the default setting for the “Set time limit for logoff of RemoteApp sessions” policy setting?

By default, RemoteApp sessions will remain in a disconnected state indefinitely.

Where are the session time limit policy settings located?

To locate the session time limit policy settings, follow these steps:

1. Log on to the terminal server as an administrator.

2. Start the Local Group Policy Editor. To do this, click Start, click Run, type gpedit.msc, and then click OK.

3. Locate the following node:

Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Session Time Limits

Note: The policy settings are also located under User Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Session Time Limits

4. The new policy—Set time limit for logoff of RemoteApp sessions—is shown in the following figure:

How do I enable the time limit for logoff delay?

To enable the “Set time limit for logoff of RemoteApp sessions” policy setting, follow these steps:

1. In the right pane of the Local Group Policy Editor, double-click Set time limit for logoff of RemoteApp sessions.

2. Click Enabled.

3. In the RemoteApp session logoff delay list, select the desired time for logoff delay, and then click OK.

4. At a command prompt, type gpupdate, and then press ENTER to force the policy to refresh immediately on the local computer.

After the policy setting is enabled, disconnected RemoteApp sessions will be logged off after the configured time delay.

Scenario: Consider a typical work day where a user closes their RemoteApp programs when they leave work at 5:00 P.M. When they return to work at 8:00 A.M. the following day, they start their RemoteApp programs again. Assume that the administrator has chosen 18 hours as the time limit for RemoteApp session logoff. When the user returns in the morning and restarts their programs, the remote programs will start quickly. Even if the user logs on after 19 hours, there is no possibility for data loss because there are no remote programs running in the session. Unlike existing session time limit policies, there is no threat of data loss because the policy setting applies only to RemoteApp sessions that have no remote programs running that were started by the user. Therefore, you should configure this new policy setting with the goal of providing the better user experience.

Is there any possibility of conflict between the RemoteApp logoff policy setting and other session limit policy settings?

We recommend that you set other session limit policy settings that end the session to a time limit that is higher than the RemoteApp logoff delay policy setting. If this is not the case, there is a possibility for conflict.

Scenario: Extending the scenario mentioned earlier, assume that the administrator has also set the “Set time limit for disconnected sessions” policy setting to two days. When a user leaves work at 5:00 P.M. on Friday, by the time that they return to work at 8:00 A.M. on Monday, their session would be logged off. In this manner, the administrator can choose to log off the disconnected sessions that are taking up server resources. If the administrator decides to end the session in 12 hours instead of two days, the RemoteApp logoff policy setting that was set for 18 hours has no effect. After 12 hours, the session will be logged off.