Chapter 2: Terminal Server Architecture

This chapter and the next can be logically grouped together as both focus on the architecture of Terminal Server environments. This chapter covers the architectural components of Terminal Server itself. Chapter 3 addresses the architecture of the Terminal Server network environment, including those factors affecting how Terminal Servers are placed on the network and linked together.

We'll first examine how Terminal Services works. Let's take a quick tour of the various pieces and subsystems of a Terminal Server running on Windows Server 2003 and then discuss the decisions that you'll have to make before installation.

How Terminal Server Works

A Terminal Server is basically the same as the regular Windows Server operating system except that in Terminal Server environments, key components have been added or modified to provide support for multiple, simultaneous users.

Microsoft Windows has always been a "multi-user" operating system in the sense that multiple users could be connected to a single server at any given time. However, these users were connected to file services or printer services on the servers. They ran their local Windows interfaces on their local computers, and the server only supported one desktop interface via the local keyboard, mouse, and monitor. The main difference with Terminal Server is that multiple users can run their own Windows desktop sessions on the server. So Terminal Server is "multi-user" in the sense that it supports multiple desktop interfaces. Some people like to think of this as a "remote control" environment, except that the Terminal Server can accommodate many users "remote controlling" it at the same time, with each user doing something completely different.

In order for Terminal Server to support multiple user sessions, some changes had to be made to it from the regular Microsoft Windows server software. There are two fundamental differences between a regular Windows Server and one with Terminal Server installed:

• When Terminal Server is installed on a Windows 2003 server, certain core components of the Windows operating system are modified to support multiple, simultaneous user interfaces. For example, the virtual memory manager and the object manager are modified to support multiple, simultaneous desktop interfaces without getting confused. These are major modifications, requiring you to reboot the system after installing Terminal Server.

• New services and components are added when Terminal Server is installed that allow the server to support multiple user sessions. The most important of these is the "Terminal Server" service. This service, running deep inside the server, is responsible for interfacing the multiple user sessions with the operating system. It's also responsible for functions such as creating sessions, receiving users, and ending sessions.

Terminal Server Components

Although it seems that the Terminal Server is basically a glorified PCAnywhere system, it's actually a complex system made up of several different components, subsystems, and interfaces. A more complete diagram of the Terminal Server components is shown in Figure 2.1. Refer to it as you read through the next few sections describing each component that makes up Windows 2003 Terminal Server.

Figure 2.1: Terminal Server 2003 components

The Windows Server 2003 Kernel

You will recall that a key component of any server-based computing environment is a multi-user operating system. In Windows Server 2003, this system is controlled by the kernel.

Windows Server 2003 needs a way to distance critical operating system components from all the crazy users. To achieve this, Windows processes operate in one of two modes: user mode or kernel mode. Thinking back to your Windows NT training, you'll remember that a user mode application cannot write directly to the OS memory. Instead, it has full access to its own 4GB memory space. An operating system component called the virtual memory manager (which itself runs in kernel mode) controls all of this and writes to the system memory on behalf of the user-mode application.

In Terminal Server environments, the separation of user mode and kernel mode applications allows the system to separate and isolate the users. One users' application crash won't take down the whole system. (Of course you're thinking that an application crash can take down a system, however, that's usually tied to device drivers which run in kernel mode.)

In "standard" (i.e. non-Terminal Server) Windows environments where only a single user logs on interactively, all kernel-mode processes live happily together in one memory area and namespace. In multi-user environments like Terminal Server, however, this sharing won't work since requests from different users' sessions could conflict with one another. The kernel on a Terminal Server is consequently multi-session aware; it keeps each user's session separate with isolated processes and memory. Windows Server 2003 makes some changes to the kernel when the Terminal Server component is installed to accomplish this.

First, the server places some of the kernel's memory address space into virtual memory. This allows what would be conflicting requests in a single-user environment to be processed properly in the multi-user environment, and for multiple instances of kernel-mode device drivers to be loaded and used by multiple users (the reason why one user can technically crash the whole system).

Some system processes are not session-specific, meaning that all users in all sessions will need access to them. These processes are stored in a single (global) memory area shared by all users.

A side-effect of sharing processes like this in a Terminal Server environment is that sometimes you'll run into processes that are not "session aware." One potential (and kind of funny) result can be error messages that are displayed on the server console from applications running within a user's session. Since there's usually no one in the server room to acknowledge the message, there is the potential to prevent a user's application from continuing.

The Terminal Services Service

"The Terminal Services Service" refers to a regular Windows service (Start | Administrative Tools | Services) called "Terminal Services." In the real world, people usually refer to it as the "Terminal Service," and they use the term "Terminal Server" when referring to a Windows Server that's running the Terminal Service.

If the multi-user kernel is the foundation of server-based computing in Windows Server 2003, the Terminal Service is the cornerstone. This service (loaded via termserv.dll) is loaded right after the kernel comes online. After the server's console (keyboard, video and mouse drivers) is loaded, the Terminal Service initiates the Session Manager subsystem (smss.exe) responsible for managing and tracking all user sessions on the server.

Terminal Server Sessions

A new session is created each time a user logs onto Terminal Server. A session essentially consists of a virtual desktop from which the user can run applications and with which he can interact just as with a workstation. A server session should not be confused with the server console, since a session is not a remote control of the console but actually a new desktop separate from the console.

Each time a user connects to a Terminal Server and creates this "virtual desktop," a unique session ID number is created to differentiate the user (and therefore the user's processes) from all other sessions and users. Session IDs also enable the server to keep memory separate for each user's session. When a user logs off from a Terminal Services client, the session that was being used is deleted and the processes and memory that were launched and used by that session are removed. Each Terminal Server tracks its own Session IDs and handles the task of issuing, tracking, and removing them.

Since server sessions are "virtual" (and memory and processes are kept separate between sessions), an application crash or lockup in one session should not affect any other user sessions, even if other users are using the same application.

However, the key phrase here is "should not" affect other users. Even though user sessions are separate on a server, they still share server resources and certain segments of code. If one user invokes a process that causes the server to blue screen, this will obviously have an effect on the other users. On the other hand, simple occurrences like an application hanging on a timed out request or Microsoft Word crashing when a user opens a corrupt document will not be seen by the other users (within their own sessions) on the system.

Session States

Since a session is really a user's desktop, there are times that a session can be in various different states, much like a normal workstation. For example, if a user walks away from their workstation for a period of time, the workstation does not turn off. Rather, it is merely idle, waiting for user input. Terminal server sessions behave much the same, and can be in one of a number of different states depending on the user's activity (or inactivity), connectivity between the client and server, and session time out settings.

Figure 2.2: Each Terminal Server maintains many separate user sessions

All user sessions on a Terminal Server must be in one of the following six states:

• Active is a live and active user. The user is interacting with the Terminal Server session and has not had a period of inactivity or a network disconnect from the server. This is the "normal" state of a session.

• Idle is the state a session goes into when there is no input from the user for a specified period of time.

• Disconnected sessions occur when the processes and programs of a "live" session are running but no RDC client is connected. (If you skipped the first chapter, "RDC Client" is the new name for the RDP Client.) The common cause is a network disconnection or when a user clicks the "X" in the upper right corner of their RDC client software. A user can reconnect to his disconnected session to bring it back to an "active" state (and to pick up with his work right where he left off). Think of a disconnected session like a locked workstation, except that the user can "unlock" his workstation from any computer in the building.

• Connnected sessions are in a state in which a client device is connected to a server session, but no user is logged on, much like the CTRL+ALT+DEL prompt on a workstation.

• Down is a temporary state in which a session is being terminated and processes within the session are being killed. Down is the final state of a session before it ends.

• Listen is a state only seen on listener ports that are ready to accept inbound connections. This state does not apply to regular sessions. Rather, it applies to the processes running on the server that wait for (listen for) new session connection requests.

In most environments, administrators configure sessions with various timeouts. You can limit the amount of time that a single session can be open, or you can automatically convert an idle session to a disconnected session. Timeouts help to limit the amount of time the server spends executing processes for users that really are not working on the server. We'll cover the exact techniques and strategies for configuring these later in this book.

Connection Ports and Listeners

Every user's RDP session connects to the Terminal Server through a connection port. A connection port (commonly referred to only as a "connection") is a virtual port on the server associated with a specific network card and protocol combination.

One Terminal Server connection port is automatically created when the Terminal Server component is installed. By default, it allows any user in the "remote desktop users" group to connect to Terminal Server sessions on the server via any network card. However, even though the default connection port works with any network card with TCP/IP installed, Terminal Server connection ports are really network card-specific. You can configure a server with multiple network cards to have multiple Terminal Server connection ports—one for each card. In fact, each connection can have entirely different properties and permissions.

Figure 2.3: A Terminal Server with multiple connection ports

Terminal Server connections and their associated listeners can be configured in two places. The first is via the Terminal Services Configuration (TSC) MMC snap-in. You can use the TSC to configure options for RDP-based Terminal Server connections, such as settings, permissions, and over which network card a connection is valid. The second way to configure Terminal Server connections is via an Active Directory Group Policy Object (GPO) within a Windows 2003 domain. This functionality lets you assign connections for multiple servers contained with an OU in Active Directory.

Listeners

Each Terminal Server connection port has a subcomponent called a "listener." The listener component "listens" on a specific network card and protocol combination for which the connection port is configured. When a user wants to establish a new session on the server, they use their RDC client software to contact the server. The server's listener picks up the client request and forwards it on to the session manager. The listener then goes back to listening for more connection requests.

Virtual Channels

As we discussed previously, Microsoft's RDP protocol running on TCP/IP is the actual protocol that connects users to server sessions. We also mentioned that this protocol can support more than just pure virtual desktops. RDP allows remote session audio from the server to be channeled to the client device's speakers. It also allows for devices plugged into the client's serial ports to appear as if they're plugged into the server. These "extras" are available via RDP's virtual channels. A virtual channel is simply a mechanism to move data back and forth between a Terminal Server session and a client. By default, the RDP protocol on Terminal Server 2003 contains several virtual channels.

• Audio: Sound events generated on the server session are redirected through the RDP protocol to the RDC client device, where they are played on the client's speakers.

• Client Drives: Local disk drives on the client device are made available to the server, so that users can access both server drives and their local client device drives within their remote sessions.

• Printers: Printers available to the client device before a session is launched on a Terminal Server are made available to users from within their server sessions. Users can then print to their standard Windows printers, including printers directly attached to their client devices.

• Serial Ports: The serial port virtual channel allows devices plugged-in to a client device's serial port to be accessed via its remote Terminal Server sessions.

• Windows Clipboard: In order to integrate local applications with remote Terminal Server sessions, the Windows clipboard virtual channel synchronizes the contents of the remote Terminal Server clipboard with the contents of the client device's clipboard. Users can seamlessly cut and paste between local and remote applications.

If default virtual channels don't meet your needs, MSDN and the Windows Server 2003 SDKs contain information on writing your own custom virtual channels. A virtual channel is a combination of two components—a client-side component and a server-side component. Both can send and receive data via the virtual channel, allowing for one- or two-way communication. Virtual channels can also be RDP independent, which means that you can customize to your environment without upgrading or changing the actual client or server software.

Why all the focus on virtual channels? Although this is not a developer's book and you'll probably never develop your own virtual channel, it's critical that you understand how they work. Just about every third-party add-on product for Terminal Server makes use of virtual channels. Understanding how virtual channels work will help you troubleshoot the third-party products that you'll undoubtedly come across in your Terminal Server career.

With that said, let's take a final look at the architecture of a virtual channel. Refer to Figure 2.4.

Figure 2.4: Terminal Server 2003's virtual channel architecture

The server-side virtual channel component is usually an executable running on the Terminal Server. This component must be a user-mode component, since the server uses the session ID to determine which client-side session it should transmit to and receive data from.

The client-side virtual channel component is usually a DLL provided by Microsoft, the third-party software vendor, or custom-written by your developers. The DLL must be loaded on the client computer when the RDC client program is launched and begins the connection to the server. In most cases this is scripted or done programmatically at the client level.

How all these Components Fit Together

Now that you understand each of the various Terminal Server components, let's see how they all fit together. Follow the process that takes place as a client connection is made, referring to Figure 2.5.

Figure 2.5: A new session is established

1. Before anything happens, the listeners on the Terminal Server watch certain network cards, IP address, and TCP port combinations for inbound requests to start sessions.

2. A user decides to use a remote application, so she launches her RDC client and requests a connection to "server1." Her RDC client checks to see what virtual channel DLLs are installed.

3. In this environment, the name "server1" refers to IP address 192.168.14.42 (which happens to be NIC #1 in this server). The user's RDC client sends a session connection request to 192.168.14.42.

4. The server's listener picks up the request and hands it off to the session manager. As the session manager takes over, the listener resumes listening for more sessions.

5. The server negotiates with the requesting client for its encryption level and virtual channel capabilities.

6. The user is then authenticated to the domain and her rights are checked for access to the connection.

7. The Microsoft licenses are verified. The server client access license is verified first, and then the Terminal Server client access license is verified. (Licensing is detailed in Chapter 4.)

8. At this point, the user session is ready to begin. The logon scripts run and the desktop is loaded.

In Windows Server 2003, a listener port is associated with a "connection." In fact, the two terms are almost interchangeable. You configure properties for a connection, and the connection's listener port is modified appropriately.

Now that we've covered all of the components that make up a Windows 2003 Terminal Server, turn to the requirements.