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.
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.
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.
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.
By default, RemoteApp sessions will remain in a disconnected state indefinitely.
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:
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.
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.
PingBack from http://www.artofbam.com/wordpress/?p=3497
Further analysis of this mechanism here:
Hey, is the TS RemoteApp server going to be available on Vista as well by SP1? Please include it.
The TS RemoteApp server is a Terminal Server only feature and will not be available on Windows Vista even with Service Pack 1.
"there is no explicit way for the user to either log off or disconnect a RemoteApp session"
However, the Ctrl+Alt+End keystroke presents the Ctrl+Alt+Del dialog with options to logoff, change password, lock screen etc.
Hi, we have the following Problem with RemoteApp
Everytime a user opens a second remote application, he receives an error
Your Remote Desktop session has ended.
Another user connected to the remote computer, so your connection was
lost. Try connecting again, or contact technical support for
I know a work-around is to turn off Restrict Terminal Services users to a single remote session. But that brings in usability and perfomance issues, so we don't want to do that.
Anybody a Idea/Solution for that?
I need the opposite! I have a TS Server Win2008R2 and several RemoteAPPs with timeous defined. But ini one circustance i need a specific user with a specific RemoteApp with No Timeout, a infinet timeout..
how can i achive that?
I have the following situation:-
1 x RDS Gateway / RDWeb / RDCB on 1 server
3 x RDS Session Hosts
When a user uses logs into RDWeb Access remotely with Windows 7 or XP SP3 with RDC7 and opens an application, if the user signs out from the RDWeb Access page without exiting the application the RDWeb Access page closes and also the application window. The application is still running on the RDS Session Host so if the user re-connects the application is still open.
This is good and how I would expect things to work.
However if the client PC is an XP PC and is running RDC 6 if an application is running and the user signs out of the RDWeb page the application remains open and usable on the PC.
If the user was in an Internet Cafe for instance and the user forgot to close the application and relied on Signing Out of the RDWeb page this could pose a major security risk.
Is this a known 'feature' or has this been 'cured' in a hotfix etc.
I know I can specify within a GPO to get the RemoteApp to exit on disconnection of the user but I would like the RemoteApp to exit without having to do this.
As i read in KB Article -:
When all active application windows and all user-launched notification area icons are closed, the session remains active for 20 more seconds.
I have requirement to increase this 20 seconds time to 1 hours. is there any way to increase this time.
At now path is diffirent in 2008:
User Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Session time limits\
There is Mic redirection issues ,
below are the steps to overcome,