Direkt zum Hauptbereich

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.

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Office 2013 aktivieren via Kommandozeile

Wie man das neue Microsoft Office 2013 aktiviert via Kommandozeile, das werde ich euch in dem folgenden Beitrag Schritt für Schritt erklären. Gerade in grösseren Systemumgebungen in welchen die Clients und Standard Software automatisiert installiert werden, kann das sehr hilfreich sein und erspart einem viel Arbeit nach der Installation des Clients. Das Ziel sollte sein, möglichst viel zu automatisieren und soweit möglich, wenig noch händisch zu konfigurieren. Da kommt dieser Beitrag sicherlich nicht ungelegen. Die folgenden Befehle könnte man beispielsweise ganz einfach in eine MDT (Microsoft Development Toolkit) Umgebung mit einbeziehen oder auch mit anderer Software benutzen. Wichtig zu wissen ist, dass dies nur dann funktioniert, wenn Microsoft Office 2013 über das Internet aktiviert wird. Hat man einen eigenständigen Aktivierungsserver (KMS), funktioniert dies nicht. Zudem müssen die Befehle alle mit Administrator Rechte ausgeführt werden. Normale Benutzerberechtigungen genügen …

Windows Domain Controller: Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar

Zurzeit häuft sich (warum auch immer) das Problem dass nach einem Neustart eines Windows Domain Controllers bei der Anmeldung die Fehlermeldung „Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar“ kommt und eine Anmeldung so nicht möglich ist Das Problem ist hierbei das der Domain Controller im Active Directory Reperatur Modus (Abgesicherter Modus) startet. Am einfachsten lässt sich dieses Problem folgendermaßen beheben: 1) Anmeldung mit dem DSRM (Directory Services Restore Mode) / Verzeichnisdienstwiederherstellungskennwort Falls die Anmeldung nicht funktioniert kann man einen Workaround wie hier beschrieben durchführen. 2) Systemkonfiguration mittels msconfig.exe aufrufen

WSUS won’t uninstall or re-install

Hat heute ein Problem mit WSUS unter Windows Server 2008 R2 bei einem Kunden. Das Problem - die Clients konnten keinen Verbindung zum WSUS Server herstellen. Die Deinstallation wurde unerwartet beenden mit folgender Fehlermeldung: Attempt to un-install Windows Server Update Services failed with error code 0x80070643. Fatal error during installation  Die Lösung: I don’t like Windows Server Update Services (WSUS), but it’s the free alternative many companies select over the higher cost alternatives like Intune or Systems Center. So, today I had to repair a damaged WSUS installation. Turns out someone uninstalled SQL Server 2005 Express not realizing WSUS was using it. Now firing up the WSUS console just yielded an error complaining about the missing SQL database. So like any good troubleshootin IT guy the first thing I tried was to uninstall WSUS…sadly, however the product would not uninstall or re-install. Here’s how I finally got rid of it: [the problem] WSUS 3.0 SP2 is missing SQL serv…