Seamless Windows Session Termination Logic

DAN SHAPPIR on July 29, 2014 | 1666

The Microsoft Terminal Server team recently ran an interesting article on their blog describing the session termination logic when accessing published application via seamless windows . The reason that such special logic is required is that unlike full desktop sessions there is no explicit way for the user to either log off or disconnect RemoteApp sessions. I found this description especially poignant because we faced the exact same problem when we implemented our True Seamless Windows mechanism four years ago. Interestingly, but not so surprisingly, we had came up with a mechanism that is very similar to the one Microsoft now built into Windows Server 2008. Consequently I believe I can provide some insight into the design decisions described in this article.

One of the decisions we needed to make when we implemented our True Seamless Windows functionality was whether to trigger session termination based on processes or visual elements, e.g. windows. Like the Terminal Server team, we chose to rely on the visual elements. Our reason for this decision was the fact that some applications spawn helper processes that never terminate. In such cases, neither would the sessions. Basing session termination on the visual elements guarantees that a session remains active as long as it has something to show and ends when it doesn’t. One problem we had to overcome with this approach is that it is perfectly legal for Windows applications to close or hide all their visual elements in the middle of their operation. An example of such behavior is the Windows Calculator – when you switch from the Standard view to the Scientific view or vice versa, the Calculator first destroys its window before creating a new one. If a session terminated the instant no visual elements were displayed a session hosting only Calculator would end whenever you switched views. Our solution to this problem was to delay session termination after the last visual element is hidden or destroyed, just in case a new one is created. If a new visual element was indeed created within this time period the session termination was canceled. Presumably this is also the main reason for the 20 second delay described in the article.

Another problem with basing session termination on visual elements is that sometimes applications close all their windows before they completely finish their work. For example, an application might take a relatively long time to save its state after it is no longer visible. In such cases the 20 second delay may not be enough. The Terminal Server team addressed this problem by leaving sessions in an indefinite disconnected state rather than actually logging them off. This means such applications have all the time in the world to gracefully terminate. For this reason, if you plan to utilize RemoteApp, I highly recommend that you don’t change the logoff delay to “Immediately” as the 20 second delay might not be long enough. This can result in improper application shutdown and even data loss.

Interestingly the article actually sites a different reason for maintaining the sessions in a disconnected state: performance. Connecting to disconnected sessions is much faster than starting a new session on the same server. This performance gain will occur even when multiple servers are used because the new Session Broker takes disconnected sessions into account when performing load balancing (it is, after all, built on top of the Session Directory),. On the other hand, as the article notes, such disconnected sessions do consume server resources so the article encourages system administrators to determine the optimal logoff delay for their farms. Unfortunately this appears to be one of those configuration options for which administrators may not be properly equipped to select the appropriate value, as I described in my post about the importance of defaults. As a result, I believe many administrators will either leave the setting as is, or instruct such sessions to logoff immediacy – both poor choices.

One reason keeping disconnected sessions around forever is not such a good idea is that it pretty much guarantees that sessions will outlive their usefulness. Just imagine the following scenario: you take down a server for an upgrade because your farm has maxed out its capacity only to find that it is hosting sessions belonging to former employees who left the company months ago! Another reason is that it will essentially invalidate load balancing. The first time a user logs in the new session will be created on the least loaded server. But, from that point on, the user will always be directed to that server because of the existing session. In other words, the initial division of load will remain in effect indefinitely, regardless of how the load varies over time. Yes, I know there are other settings that govern the time limit for disconnected session, as the article explicitly mentions, but that just makes this configuration even more convoluted.

Our approach in PowerTerm WebConnect is somewhat different. When the last visual element is gone we retain the session for an additional 15 minutes rather than just 20 seconds. Since nothing is displayed in the session, the user is generally unaware that it is there. For the same reason, resource consumption for that session is only slightly higher than for a disconnected session. The upside of our approach is that thanks to Session Sharing, when a new application is launched it will open up immediately within the already connected session, much faster than reconnecting to a disconnected session. On the other hand, once these 15 minutes run out, the session is logged off and not just disconnected. The administrator can modify this duration to any appropriate value, but no lower than 30 seconds.

Another interesting difference is that the PowerTerm WebConnect True Seamless Windows feature does allow users to explicitly disconnect or logoff sessions. To perform these operations simply right-click on the taskbar icon of a published applications and select the item “Ericom Software”. In the submenu that opens you have the options to disconnect the session or log it off immediately, as well as some other useful operations such as requesting online assistance for an administrator or Tech Support.

Author | 180 Blog Posts

Dan Shappir

Dan Shappir is responsible for all aspects of product design, software development and maintenance of the Ericom's product lines. | Ericom Software

Recommended Articles