Virtualizing Sessions

DAN SHAPPIR on July 29, 2014 | 1162

In my previous post I described the Ericom strategy of “competing with a big guy by standing on the shoulders of a giant” (to very loosely paraphrase Sir Isaac Newton.) This is one of the reasons why we are very excited about the upcoming release of Windows Longhorn Terminal Services. Moreover, we are also very appreciative of Microsoft’s stated goal for Longhorn Terminal Services to provide improved platform functionality for ISVs to extend.

All this is not to say that I think Microsoft should rest on its laurels. Quit the contrary. I wish that Microsoft will continue to add features to Terminal Services and will actively promote SBC as the preferred method for managed application access. For this reason when Brian Madden asked for feature suggestions for future versions of Terminal Services I proposed two features that I would love to see Microsoft adding to this platform: Session Virtualization and WPF Remoting. In this post I would like to explain what I mean by Session Virtualization.

While virtualization and SBC are not the same thing, virtualization can certainly complement and augment SBC. Currently virtualization implementations fall into two main categories: hardware virtualization and application virtualization. Of the two hardware virtualization is the better known, and more commonly used: one or more virtual machines run on a single hardware platform, managed by a common Hypervisor. Each of these virtual machines hosts its own OS instance, totally independently of the other virtual machines. In fact, each virtual machine can use a different OS. In the context for SBC this form of virtualization is used to either host Terminal Servers within virtual machines or for VDI. It is not applicable for enhancing the operation of a specific Terminal Server instance.

Application virtualization is about wrapping specific applications within a virtual layer that isolates them from other applications running on top of the same OS instance. On top of the memory and CPU virtualization provided by the OS itself, application virtualization manages access to additional resources such as the file system and the registry. The benefit of this approach is that multiple instances of potentially conflicting applications can be run on top of a single OS instance, such as within multiple sessions hosted by a single Terminal Server. For example, Microsoft is promoting SoftGrid, its own application virtualization solution, as a means to improve Terminal Server usage and application compatibility.

There are also some downsides to application virtualization. One downside is slower application performance as result of the extra level of indirection for accessing resources. Another downside is reduced application interoperability: if two applications are isolated from one another they may be prevented from properly interacting with each other. There is also the increased overhead on the entire system resulting from the virtualization layer surrounding the applications.

While both these virtualization types are eminently useful, I believe there is a missing layer in between them that would be particularly useful for SBC: Session Virtualization. This mode of operation would isolate the sessions from each other, but all applications running within a particular sessions would share the resources and thus be able to properly inter-operate. In addition, since there are fewer sessions than applications, the load on the entire system would be reduced. In the somewhat unlikely event that applications running within the same session would need to be isolated from each other, application virtualization could be applied on top of the session virtualization.

Having each session virtualized means that each session would have its own “view” of the entire file system, not just the user’s personal folders. Likewise each session would have its own “view” of the entire registry, not just HKEY_CURRECT_USER. And similar to profiles, this view could either be preserved between user sessions or reverted to an original clean state when the session ends. All this would ensure that coexisting sessions would not adversely affect each other. In fact, it would be possible to assign users administrative privileges within their own sessions without the risk of them compromising the state of the entire system. So, for example, a user would be able to install a new application and that application would be installed only for that user. In other words, session virtualization would ensure proper segregation between users sharing the same terminal server.

It may be possible to implement session virtualization on top of current OSs much as application virtualization is currently implemented. But ultimately I believe that this feature should be provided by the OS itself. I hope Microsoft is listening …

It is worthwhile to note that some session virtualization support is already built into Windows Vista. For example, a legacy software application that attempts to write to a configuration INI file located in:

C:Program Files<application>Setup.ini

Windows Vista automatically detects that you do not have permission to save to that location. Windows Vista then redirect the operation to:


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