Terminal Services – Seamless Windows Session Termination Logic
“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 feature Microsoft calls RemoteApp). 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.”
To learn more please read the entire article at its source: ERICOM Guy: Seamless Windows Session Termination Logic