Embracing Retro Virtualization: Why an Old Form of Virtualization Is Still One of the Best

Many people mistakenly assume that virtual desktop infrastructure (VDI), which virtualizes a client operating system and makes it available remotely, is a replacement for session virtualization. In fact, both VDI and session virtualization are viable technologies; in some scenarios one makes more sense than the other, and for most organizations both VDI and session virtualization will be used. Session virtualization is by far the more economical of the two technologies. Compared to VDI, it serves more users for each dollar spent while offering the same user experience for most use cases.

As described in Chapter 1, various forms of session virtualization have been around for a very long time. I recall my early days of remotely connecting to a large server that hosted my session along with many other users, and my interaction was achieved through a dumb terminal that simply displayed text sent from the server and then sent back to the server keystrokes I typed in. My interaction with the session was abstracted from where the session was actually running. In the Microsoft world, this type of session virtualization was originally called Terminal Services.

First I want to clarify what a session really is in the Windows world. Think of a session as a collection of processes that are providing services for a single logical entity, such as for a logged-on user, a logon session, or even services running on the operating system. Sessions are isolated from each other, which provides protection for information within the session and gives users a protected workspace even though the actual operating system is shared with other users. Each time users log on, a session is created for them in which they function. Figure 7-1 shows the basic idea of sessions on a Windows server, with session 0 reserved for system services, and sessions 1 and beyond for remote connections. It is obviously still possible to log on to the console of a server, but there is no special reserved session number for a console logon anymore—it just uses the next available session number.

Each interactive logon session on Windows has a number of key processes used to manage the session and maintain the graphical interface. You can view these processes using an application like Task Manager or even using the Windows session virtualization management tools. Figure 7-2 shows a list of processes on a Windows Server 2008 R2 server that is enabled for session virtualization and remotely connects three users: administrator, john, and Cortana. The list of processes is ordered by session ID. The top of the screen shows the last few processes running in session 0 (reserved for the system), which includes wininit.exe, which is used to initially manage the starting of key Windows processes, and smss.exe, which is the session manager, used for starting user sessions. Then, four different session IDs are shown: three for users and one, session 4, used for the console. The console is currently not being used, which is why the only processes associated with it are to enable logon. Take some time to look at all the processes for each of the three user sessions (2, 3, and 5). Notice that for each session, most processes are owned by the user logged on to that session, and those processes include the following:

• explorer.exe (the shell)
• dwm.exe (desktop window manager, responsible for compositing the display)
• rdpclip.exe (remote desktop clipboard management)
• msseces.exe (malware protection provided by Microsoft Security Essentials)
• taskhost.exe (a container process for running a variety of DLLs)

Some sessions have additional processes—for example, session 2 for user john also has WINWORD.EXE because the user is running Word in his session. Notice also that for each session, two processes are running as user SYSTEM, which is the core operating system security context. These processes are winlogon.exe and csrss.exe, which have an instance created for each user session but are maintained by the SYSTEM because they are responsible for the security of the session and the Client/Server Runtime Subsystem, respectively, which are too critical to run as part of the users’ security context.

The concept of enabling multiple interactive user sessions on Windows Server that could be remotely accessed was first introduced as part of Windows NT 4 Terminal Services Edition using the Remote Desktop Protocol (RDP). RDP provides the services to send graphical interface content for the user’s session from the server, where the session actually resides, to the user’s workstation that is accessing the session. RDP also sends the keyboard and mouse input from the user’s workstation to the remote session; and, as I will show, it adds support over time for other types of device, bi-directional audio, and more advanced graphics techniques. This basic RDP access is shown in Figure 7-3.

Microsoft provided client software for a number of platforms that enabled the RDP connection to the Terminal Server and remote connectivity to a client operating system. RDP clients were initially available for Windows NT, Windows 95, Windows 98, and even Windows for Workgroups. In addition to software RDP clients, a number of vendors produced small “thin clients” that could be attached to a monitor, mouse, and keyboard and whose sole purpose was to serve as an RDP client for connectivity to a desktop hosted on a Terminal Server. These thin clients were much cheaper than a normal PC and were useful for certain locations, such as a basic kiosk and particular users—for example, those highly restricted. The key point was that no matter what device a user was using, once they used RDP to connect to a Terminal Server they enjoyed exactly the same processing performance and application availability.

The RDP functionality became a core part of the server operating system with Windows Server 2000 and Windows XP, and in all subsequent versions of Windows. The built-in nature of remote desktop made available both the server-side component, enabling a machine to accept remote desktop connections, and the RDP client, enabling the remote desktop connection to be initiated. Notice that server-side and client-side components are present in both the server and client operating systems.

For servers, the built-in RDP was used in two ways. By default, servers used RDP in a Remote Administration mode, which enabled a server to accept two simultaneous RDP connections that were to be used by administrators to manage a server. This enabled administrators to avoid manually servicing a server console. A server could also be placed in Application Server mode, traditional Terminal Services, which no longer restricted RDP to two simultaneous connections and was designed for user sessions, although licensing had to be in place for users accessing the server on a per-device or per-user basis. In this chapter, I focus on the Application Server mode and the use of RDP for user sessions.

Clients used the included RDP functionality in two ways. First, it provided the Remote Desktop functionality that enabled users to remotely access their desktop from another machine. Second, it formed the foundation for Remote Assistance, which enabled users to request help from someone else who could view the user’s desktop and even take control of it.

Although RDP with Terminal Services was available as part of Windows Server 2000 and 2003, it was not widely used; instead, it became the foundation on which other solutions were built. The most widely adopted solutions based on Terminal Services came from Citrix, which offered several such products—in particular, XenApp, which added capabilities such as application publishing (described below) and an enhanced protocol with better capabilities and less bandwidth requirement. The Citrix solutions were very widely used, but it’s all good for Microsoft, as in order to use Citrix XenApp solutions, licenses for Terminal Services must be purchased because XenApp uses Terminal Services. Citrix is a key partner with Microsoft for remote desktop technologies of all kinds.

Windows Server 2008 made some major changes to Terminal Services, adding a number of key capabilities that made the built-in remote desktop capability a viable solution for many organizations that previously required Citrix. That is not to say Citrix is no longer required; each company must determine its own needs and then ascertain whether the built-in Microsoft solutions will meet those or whether a partner solution from someone like Citrix or Quest should be considered. The major changes to Windows Server 2008 include the following:

• Application Publishing: Also known as Remote Programs and RemoteApp, this capability enables publishing an application to a remote user instead of an entire desktop. Normally with remote desktop, when a connection is made a window is opened that displays a complete desktop from the remote server—with Start, taskbar, system tray, and so on. With application publishing, the only window that opens is for that specific application, such as Word. The application is still running on the remote server, but it integrates seamlessly with the user’s local desktop, including system tray integration. This is a much better and less confusing experience for the user. Figure 7-4 shows this exact scenario, with Word running on a remote server on my main Windows 8 desktop on the right. Notice that the remote instance of Word has a different window style (theme) compared to the native Windows 8 Word instance, and Task Manager shows that instead of running winword.exe, the remote Word’s local process is the RDP client. For a detailed demonstration, see http://www.savilltech.com/videos/TSRemoteApps/tsremoteappslrg.wmv.

• Web Portal: Terminal Services (TS) Web Access provides a website that can be accessed to view a list of all sessions and remote applications that are available, providing fast access for users. The same web portal can also be used with RemoteApp and Desktop Connection, which was a new Windows 7 feature that enabled remote applications and desktops to be published to users’ Start menus through a subscription model, providing users with very easy access to remote services.

• Terminal Services (TS) Gateway: This provides the capability to encapsulate RDP traffic in HTTPS packets, allowing RDP to pass through firewalls that had exceptions for port 443 (HTTPS) and avoiding the need for firewall exceptions for RDP traffic (port 3389) or the use of virtual private network (VPN) technologies to establish secure connections. This is explained in a video at http://www.savilltech.com/videos/tsgateway/tsgateway800600.wmv.
• Driverless printing: Prior to Windows Server 2008, printing was a major problem with RDP. To print to a printer that was local to the client device, the correct printer driver had to be installed on the Terminal Server because when a print was performed, the rendering of the document for the printer was performed on the Terminal Server and then sent over the RDP connection to the client for actual printing. If the print driver was wrong, a corrupted print output would occur or even crash the operating system. Windows Server 2008 introduced TS Easy Print, which enables printing without a driver being installed on the Terminal Server. The new process works by rendering the print job to an XML Paper Specification (XPS) file and then sending the XPS file over RDP to the client, which then renders the XPS for the printer using the local printer driver. This avoids any issues with printer drivers on the Terminal Server. TS Easy Print enables the advanced printer features of the local printer by asking the local client to display any printer property dialogs over RDP when printer properties are opened in a remote session. For a demo of this technology, see http://www.savilltech.com/videos/tseasyprint/tseasyprint800600.wmv.

There were other changes as well, which I cover later in this chapter along with more detail on the Web Portal and TS Gateway technologies. The Remote Desktop Protocol itself has also gone through a large number of changes, including support for RemoteFX with Windows Server 2012 for session virtualization.

A key point to remember about session virtualization and Terminal Services is that although the user is connecting to a server operating system, from an aesthetic and functional perspective the user’s session looks identical to one running on a client operating system. Microsoft client and server operating systems are built on a shared codebase that is then customized for the different priorities of the client vs. server operating system. If an application runs on a client operating system, then it should run on the equivalent version of the server operating system. In terms of equivalence, the following can be used:

• Windows XP = Windows Server 2003
• Windows Vista = Windows Server 2008
• Windows 7 = Windows Server 2008 R2
• Windows 8 = Windows Server 2012

There will be some exceptions. Some applications won’t handle multiple instances of the application running at the same time on a single operating system instance even when running in different sessions, possibly because of some interaction with an installed service. Some client/server applications will struggle when running on a Terminal Server because all the user sessions on a Terminal Server will have the same IP address, the IP address of the Terminal Server, which might confuse the server end when trying to differentiate clients communicating with the same address/port. Consider also that the users are sharing a common operating system, so one user cannot reboot without shutting down everyone else’s session; nor should a user be able to customize the operating system, as this would change the operating system for everyone on the Terminal Server.

Session virtualization on a Terminal Server is best used for task workers who do not need to customize or reboot the operating system and who run a fixed set of applications such as line-of-business applications, Office, and Internet Explorer, which will all work without issue in a session virtualization environment.

Another big shift with Windows Server 2008 is how session virtualization is used. In the past, users wanted the remote server to provide an entire desktop in which they ran a number of applications; and while a session desktop is still required in some scenarios, in most cases users just want to access a specific application remotely. This change is the result of the shift in devices used by clients and how they are used. If a user is on an iPad, a full desktop is hard to interact with; but presenting only the window of an application to the user provides a much easier interface. Even for users on full desktops, having remote applications seamlessly integrated with their local desktop provides a better experience. This focus on application publishing rather than entire desktops is seen in Windows 8, where publishing applications is the default.