Windows Terminal Services provides the multiuser capabilities that form the foundation of the material discussed in this book. This chapter takes a look at this architecture, including its history, how it is integrated into both the Windows server and the supported clients, and the new features that have been added to Windows Terminal Services since the initial Windows NT 4.0, Terminal Server Edition release, Microsoft’s first official release of a Terminal Server product.
Conceptually, the idea behind Terminal Services is simple and will be familiar to anyone with experience accessing graphical environments such as X Windows, where most (if not all) application processing happens on a remote server, and only the visual input and output are handled on the client device. Terminal Services brings this same functionality to the Windows environment.
Windows Terminal Services lets multiple users simultaneously access applications that perform 100 percent of their processing on the centralized Terminal Server. Figure 1.1 shows a rather trivial yet effective example of this, with a Windows 2003 Terminal Services desktop session being accessed from within a Windows 2000 Professional desktop.
NOTE:
When hearing about Terminal Services, many people immediately jump to the conclusion that this product provides remote access capabilities similar to remote presentation products such as VNC or pcAnywhere. While visually they appear to perform the same task, there is one fundamental difference. Terminal Services lets multiple users simultaneously establish their own distinct Windows session on a single Terminal Server, and load and run applications completely independent of other users also running on that same server. Products such as VNC or pcAnywhere let you remotely access the local desktop on a PC or server but do not provide the same robust, multiuser support.
Application serving, server-based computing, and thin-client computing are all terms that have been used at one time or another to describe the use of Terminal Services to provide remote application support to users. On a Terminal Server you would find applications such as these:
Microsoft Office (Word, Excel, Outlook, and so on)
Mozilla Web browser
Lotus Notes
Because Terminal Servers provide access to traditional desktop applications, they are commonly referred to as application servers.
The direct opposite of an application server is the traditional Windows server that supports standard or extended server system features such as
File and print services
Web services (Internet Information Server, Apache)
Collaboration services (Microsoft Exchange, Lotus Notes)
Database management services (Microsoft SQL Server, Oracle)
TIP:
In the past, a standard Windows file server was sometimes called an application server if it contained application files that users accessed from across the network. This obviously differs from a Terminal Server in that the client still runs the application locally; only the application files are located on the central server. In this book, I use the term application server to refer only to Windows Terminal Server.
The fact that an application server and a standard Windows server are visually almost identical can have both a positive and a negative impact on your implementation and production management. On the plus side, the similarities let a skilled Windows administrator get up to speed quickly on how to install and maintain many of the Terminal Server components. This commonality can also have a negative side, however, as these skilled (and sometimes not so skilled) administrators may make assumptions about the configuration or operation of Terminal Server that are perfectly correct for a regular Windows server but not for a Terminal Server.
Before we continue this discussion and look more closely at the components that make up Windows Terminal Services, let us take a moment to review the history behind Terminal Server.
Although Microsoft Windows Terminal Server has only been in existence since 1998, the technology behind it is not nearly so new. The Citrix MultiWin technology that was incorporated into Terminal Server was first conceived in the late 1980s by Ed Iacobucci. Iacobucci worked for IBM from 1978 to 1989, spending most of that time in the personal computer division, designing and architecting operating systems. When Microsoft and IBM set out to develop OS/2, Iacobucci was head of the joint design team. During this time, Iacobucci envisioned a way to let different types of computers on a network run OS/2 even though they weren’t built to do so. The idea of MultiWin was born.
At the time, neither IBM nor Microsoft was interested in Iacobucci’s idea, so he left to form Citrix Systems in 1989. Citrix developed the proposed technology (known as MultiView), and it worked. The problem with Citrix’s new product was that it was based on OS/2, and the future of OS/2 was looking dim. In the fall of 1991, with Citrix on the verge of going under, Iacobucci turned to Microsoft. He was interested in rebuilding Citrix’s technology based on Windows NT.
At the time, Windows NT’s penetration into the market was slight, and Microsoft was confident that if Citrix could deliver this proposed product, it would help expand NT’s market. Microsoft was interested enough to not only grant Citrix license to the NT source code required to make this work, but also to acquire a 6 percent stake in the company. In August 1995, Citrix shipped WinFrame, the first true application server version of Windows NT.
NOTE:
Many of the most popular features of Windows Server 2003 Terminal Services, including local client printer and drive access, were originally developed and available with the WinFrame product.
In 1996, Citrix began working on WinFrame 2.0, which was to be the next major upgrade, based on the Windows NT 4.0 architecture. By early 1997, Citrix had WinFrame 2.0 well into beta. At that time, with NT sales booming, and fearing the possible fragmentation of NT into a UNIX-type operating system, Microsoft decided it was time to reclaim sole ownership of Windows NT. In February 1997, Microsoft informed Citrix that it was considering developing its own multiuser version of Windows NT. Shortly thereafter, Citrix made a public announcement explaining Microsoft’s new position. The day after this announcement, Citrix’s stock value lost 60 percent.
Over the next several months, during a time of intense negotiations between the two companies, the future of WinFrame remained uncertain until May, when Microsoft and Citrix came to an agreement. Much of the reasoning behind the agreement was Microsoft’s desire to quickly become a player in the thin-client industry, something it had little chance of achieving if required to develop a new product from scratch.
Through this agreement, Microsoft licensed the MultiWin technology from Citrix to incorporate into future versions of Windows while letting Citrix continue development on its current WinFrame 1.x product and provide future extensions (Citrix MetaFrame Presentation Server) to Microsoft’s Terminal Server product.
In July 1998, Microsoft shipped Windows NT Server 4.0, Terminal Server Edition, its first thin-client operating system. This was a special version of Windows NT Server 4.0, with the multiuser changes incorporated into it. While it looked exactly like regular NT 4.0, it was architecturally different and required its own special service pack and hotfix releases. Regular NT 4.0 fixes would not work with this special version, and very often the equivalent patch was weeks (even months) behind the standard NT server release.
With the release of Windows 2000 in February 2000, Microsoft consolidated the multiuser features of Terminal Server into its core server operating system, making these features available as services that could be installed on any Windows 2000 Server product. By merging this functionality, Microsoft made a huge leap forward in simplifying both the maintenance and availability of its thin-client product.
Now, with the release of Windows Server 2003, these multiuser features have been further enhanced, providing even more advanced and robust Terminal Server functionality.
The most obvious difference between a standard Windows server and an application server is the multiuser support. Until the introduction of WinFrame, and later Terminal Server, “logging on” to a Windows server meant one of three things:
Logging on at the local console—. An administrator or user is logging on using a keyboard, mouse, and monitor directly connected to the computer.
Remotely accessing a server resource—. A user accesses a resource on that server, such as a file or printer, the server’s registry, or an extended server system service (Web server, database, or the like).
Remotely accessing the local console—. A user accesses the console remotely using a tool such as pcAnywhere, VNC, or the SMS Remove Control feature. In this case, you’re either the only person logged on to the console (albeit remotely), or you’re controlling the session of the person who is physically logged on at that console.
While multiple users can access a resource simultaneously (a Web server, for example), a standard Windows server can have only one person with an interactive console logged on at a time, as shown in Figure 1.2. This has been the standard operating behavior not only on Windows servers but also on Windows desktop systems and other PC-based operating systems, such as MacOS or OS/2.
The introduction of server-based computing has ended the restriction that the console user is the only user with an interactive logon. Now there can be 2, 10, 50, or more users logged on concurrently in addition to the console user (see Figure 1.3).
Figure 1.3. Terminal Server supports multiple interactive client sessions in addition to the console logon.
For Windows to support multiple concurrent interactive sessions, changes had to be made to a number of the underlying Windows operating system components to be able to manage each concurrent user’s session. While the first release of Windows Terminal Services required the creation and maintenance of a completely separate operating system with Windows NT 4.0, Terminal Server Edition, these changes have been tightly incorporated into the base Windows Server 2003 and 2000 operating systems and are present whether or not Terminal Services are being used. Let’s take a brief look at the following major areas of change:
Windows 2003 Server and Windows 2000 Server both let you implement Terminal Services in one of two modes. The first is Terminal Server mode (called Application Server mode in Windows 2000), which provides the true Terminal Server features discussed in this book. This configuration must be specifically selected in order to be enabled on a Windows server. The other implementation mode is a special management mode known as Remote Desktop for Administration (Remote Administration mode in Windows 2000). This administration mode is installed by default on all Windows 2003 servers but must be explicitly enabled before it can be used (see Figure 1.4). On a Windows 2000 server, this component must be added through Add/Remove Windows Components.
Figure 1.4. Remote Desktop for Administration can be enabled on any Windows 2003 server from under the Remote tab of System Properties.
As the name implies, Remote Administration is designed to let an administrator access any Windows server, even those not designated as true Terminal Servers, using a Terminal Services client strictly for administrative purposes. In addition to the console session, Remote Administration allows two concurrent client logons, without requiring any special Terminal Services licensing.
When Remote Administration is enabled, there is no change in the tuning or configuration of the server as there is when the Terminal Server mode is selected. All applications installed on the server prior to enabling Remote Administration are not affected in any way.
Enabling Remote Administration lets anyone with the Remote Desktop Protocol (RDP) client (Microsoft’s Terminal Server client, discussed shortly) access a logon screen for the server. Because of this, you will need to ensure that good password practices are being enforced in your organization to prevent someone from guessing a password that would let them access the server.
TIP:
Windows Server 2003 provides an enhancement to the Remote Administration feature, letting you remotely access the local console session (session 0) on a server and not just a remote desktop session. An overview of the RDP client is discussed later in this chapter, while detailed information on the installation of the client software is discussed in Chapter 19, “RDP Client Installation and Configuration.”
Probably the most obvious area of change is how the server handles each user session’s graphical interface. With multiple interactive users, the Terminal Server needs to be able to differentiate the graphics data from each user session. The local (or console) session on a Terminal Server is exactly the same as on a regular Windows server. It contains the two standard windowstation objects (winsta0, Service-0x0-3e7$) and the standard desktop objects (default and winlogon) associated with winsta0.
The interactive windowstation (winsta0) contains a clipboard, a group of desktop objects, and the keyboard, mouse, and display device. This windowstation handles input from the user. The special windowstation 0x0-3e7$ is a noninteractive windowstation and is associated with the noninteractive services that use the LocalSystem account. One or more desktop objects are contained within a windowstation. A desktop object has a display area that contains windows, menus, and other user interface components. Only one desktop at a time can be active for a windowstation.
Remote Terminal Server sessions contain only the winsta0, windowstation, and three desktop objects: default, winlogon, and Disconnect. Disconnect is a special desktop that’s made active when a user disconnects his or her Terminal Server session. Remote sessions don’t require the Service-0x0-3e7$ windowstation, because all system services run under the local console context.
NOTE:
When a user’s session is disconnected, the link between the server and the client is terminated, but the session itself remains active on the server. A disconnected session will continue to process any running tasks, and if the user logs back on to that server, they will automatically be reconnected to that session.
All operating system resources in Windows are represented by objects. The Object Manager, located in the NT Executive, is responsible for creating, modifying, and deleting these objects. Objects exist within what’s called an object namespace. On a Terminal Services–enabled server, each interactive user session is assigned its own private object namespace, known as a user’s local namespace. This allows multiple instances of the same application running on a server to create named objects that won’t conflict with each other. Objects in one user’s namespace are differentiated from the objects in another namespace by the unique name they are given. When creating a named object for a specific session, the Object Manager will append the user’s unique session ID to the object name. An application cannot see objects in another user’s namespace.
In addition to multiple user namespaces is the system global namespace. This namespace is visible to all sessions on the Terminal Server. Any services and all applications running on the local console execute within the system global namespace. Figure 1.5 depicts the multiple namespaces that exist in a Windows 2003 or 2000 Terminal Server.
TIP:
The context (user or system global) within which an application or one of its components operates can be controlled using the REGISTER command. For a complete description of this command, see Appendix A, “Terminal Server Command Reference.”
Just as with other components of Terminal Server, the Process Manager has been modified to recognize process and thread objects on a per-session basis. In addition, Microsoft has modified how Terminal Server handles task scheduling and prioritization as compared to a regular Windows server. On a regular server, the process scheduler allocates longer time slices to better support the background applications that typically run on a Windows server. These applications usually have very low user interaction on the console. On a Terminal Server, process scheduling is more like a Windows desktop operating system (Windows 2000 or XP Professional) in that user interaction and foreground tasks are more responsive. The time slices on a Terminal Server are much shorter than those on a regular Windows server. Thread priorities have been modified to maximize user responsiveness. Normally, new processes on Windows are assigned a lower priority than foreground tasks, but because multiple foreground processes exist on a Terminal Server, all starting processes have the same priority as foreground tasks. These changes in process priority and scheduling are what make Terminal Server a poor host of standard server services such as SQL Server or a domain controller.
Process and thread management changes are discussed in more detail in Chapter 11, “Terminal Services Configuration and Tuning.”
Every process on a regular Windows server is assigned a virtual address space that’s divided between the kernel and user address space. The kernel space is shared between all processes, and each process receives its own user space. User mode threads can access only the user space; kernel mode threads can access both the user and the kernel space. Within the kernel address space are the Windows subsystems and associated drivers. When multiple interactive Terminal Server sessions try to access this single kernel space, they introduce kernel-sharing issues. To resolve this problem, Terminal Server has introduced a new type of address space called the session address space. The session address space contains a private copy of the kernel space that’s used by all processes within a session. This lets each session have its own Win32 kernel (also known as WIN32K.SYS, which contains the Windows Manager and Graphics Device Interface [GDI], display, and printer drivers).
In addition to the architectural changes just discussed, modifications to some of the standard Win32 API calls had to be made in order to more easily handle multiple interactive users accessing an application. Traditionally, Windows applications have been developed with the assumption that only one user at a time was running the application interactively on a computer. Many of these programs make improper use of configuration files in the Windows system root or in the system registry. Multiple users simultaneously accessing this information from a single location often introduce application conflicts.
Terminal Server attempts to deal with this problem by introducing a special method of registry and INI file monitoring so that changes made during an application installation can be properly recorded and reproduced for each user who runs the application. Installing an application using the Add or Remove Programs tool found in the Control Panel activates this special monitoring feature. When applications are installed on a Terminal Server in this fashion, the server is placed into install mode, so it can properly monitor and record system changes. If the application is not installed in this fashion, the server remains in what is known as execute mode, and any system changes made during the installation will be properly configured for only the person who installed the application. Figure 1.6 shows the Add or Remove Programs tool for Windows Server 2003.
TIP:
A server can also be switched between install and execute mode from a command prompt using the CHANGE USER command. Details on this command are available in Appendix A, and a complete discussion of application installation and configuration is given in Chapter 21, “Application Integration.”
To support multiple interactive user sessions, a Terminal Server will usually have more substantial hardware requirements than the equivalent Windows server would need to support the same number of users through the traditional client/server scenario (file and print, SQL Server, or Web server, for example).
One thing that all Windows administrators learn is a standard set of guidelines for various Windows server hardware configurations. Many of the common server setups, such as a file and print server or a Web server, have minimum recommendations for a certain number of users. Table 1.1 shows a sample configuration for a Windows file server, an Internet Information Server (IIS) 6.0, and an Exchange 2003 server, all sized to handle 200 or more concurrent users.
Also common to these servers are hardware redundancy and other fault-tolerance features to maximize the availability of the server. For standard Windows servers, resources are sized based on the average (or better yet, the maximum) number of concurrent user requests that the server will need to process. Print, mailbox access, and Web page access requests are all examples. The user makes the request and then waits for the server to return the required information.
The hardware sizing for Terminal Server differs greatly from the preceding scenario. Because all users are accessing the server through interactive sessions, the server must be able to provide immediate feedback to any applications that users are currently running. This requires greater processor and RAM resources than those required by a standard Windows server. Table 1.2 shows a typical Terminal Server configuration to support 100+ average concurrent users. An average user typically is someone who runs 3–6 applications simultaneously. These usually consist of a mail program, Word processor, and one or more line-of-business applications such as a host emulator or a client/server application. One or more applications may be 16-bit or DOS applications.
NOTE:
Please note that the configuration shown in Table 1.2 is just one example of a possible Terminal Server configuration to support 100 concurrent users and should not be taken as a representation of adequate hardware sizing under all circumstances. The results and requirements of this configuration may vary greatly depending on what environment the server must run in. Different applications react in different ways in a Terminal Server environment and may introduce significant load when simultaneously run by multiple users. Before deciding on a particular server size, it is always worthwhile to test out the configuration to ensure it will meet the needs of the business.
For a complete discussion of hardware requirements for Terminal Server, see Chapter 6, “Terminal Server Hardware Planning.”
Compare the configuration in Table 1.2 to that of the standard servers in Table 1.1; none of those setups really comes close to the necessary requirements for 100+ concurrent Terminal Server users. Based on the memory configurations alone from Table 1.1, all three configurations would have insufficient memory to support the proposed user load.
In Chapter 6, I discuss in more detail the process of sizing a Terminal Server’s hardware.
Remote Desktop Protocol (RDP) is Microsoft’s distributed presentation services protocol, which controls the transmission of display and user input between the client and the Terminal Server. RDP has been adapted from the T.120 set of standards to meet the specific needs of the Terminal Server environment and continues to be updated with new features to improve the user’s server-based computing experience. The following sections discuss the features available with RDP 5.0, which ships with Windows 2000 Terminal Services, and RDP 5.2, which ships with Windows Server 2003 Terminal Services. I begin by outlining the overall behavior of the RDP protocol.
The transfer of RDP information between the server and the client can be broken down into two main components:
Graphical data transmission
Mouse/keyboard data transmission
All graphical information that would normally be displayed on the console needs to be encoded and transmitted to the Terminal Server client so it can be displayed on the user’s local desktop. As described in the earlier section “Virtual Memory Management,” each user session has its own session address space that contains its own Win32 kernel and display and printer drivers. Each of these sessions uses a special RDP display driver that’s responsible for receiving display commands from the GDI (just as a normal driver would) and passing this information to the kernel-mode Terminal Server device driver (termdd.sys). This driver encodes the input as RDP data and passes it on to the transport layer to be sent to the client. On reception, at the client, the RDP data is decoded and the display updated accordingly. Figure 1.7 illustrates the flow of graphical data between the server and the client.
Every time a user generates an input message (keyboard or mouse), the information is captured by the RDP client, encoded as RDP data, and sent to the server. When input data is received by the Terminal Server device driver on the server, it’s decoded and the actual mouse and keyboard input is sent to the Win32 kernel in the user’s session address space, where it’s processed as normal input. Figure 1.8 shows the flow of input data between the client and the server.
The actual RDP client application has continued to evolve since it was first introduced with Windows NT 4.0, Terminal Server Edition. Currently, three types of RDP clients are available:
Terminal Services Client (RDP 5.0)—. This is one of the two RDP 5.0 clients that ships with Windows 2000 and provides a simple interface for connecting to a Windows Terminal Server. Primarily, the Terminal Services client (TSC) is used as a simple tool for establishing a connection to a Terminal Server. When TSC is launched, a dialog box appears (Figure 1.9), with the lower half of the dialog box listing all the Terminal Servers found in the current domain. To establish a connection, select one of the servers, choose the resolution size, and click the Connect button. The Server drop-down list shows a history of the servers you’ve previously connected to. If the server you want isn’t in the list, you can type the name in the text box. Having the appropriate name service (DNS or WINS) configured in your environment ensures that all the valid Terminal Servers are displayed. Little configuration is involved in the TSC, and on its own it’s not a very useful application to deploy to end users.
Client Connection Manager (RDP 5.0)—. This is the main RDP 5.0 client, and it provides a management tool for creating, configuring, and storing connections to different Terminal Servers. Figure 1.10 shows an example of what the main Client Connection Manager (CCM) application window looks like. The CCM lets you configure additional settings for the client that are not available with the Terminal Services client. Options include shortcut creation, saving connection configuration information, defining a specific application to launch from the Terminal Server, and even storing the user ID, password, and domain information to automate the user’s logon process.
Remote Desktop Connection (RDP 5.1 and higher)—. Originally introduced with RDP 5.1 and Windows XP, the Remote Desktop Connection application is the new RDP client interface being used with RDP versions 5.1 and higher. The latest version, 5.2, ships with Windows Server 2003. Figure 1.11 demonstrates the new interface given to the RDP client. In addition to supporting all the features available with the Client Connection Manager, the latest Remote Desktop Connection application supports additional features, which I discuss briefly in the “RDP Client Integration Features” section of this chapter. The Remote Desktop Connection application is fully backward compatible with all versions of Windows Terminal Server. Any client options selected in the RDC not supported by the host Terminal Server are simply ignored.
To ensure that data is transmitted securely between the client and the server, three encryption levels are available, from which you can choose based on your security requirements. All levels are encrypted using the RC4 encryption algorithm.
Low security—. Only data sent from the client to the server is encrypted; data from the server to the client is not encrypted. The encryption key is 56-bit for both Windows 2003 and 2000.
Medium security—. Uses the same encryption level as the low-security option, except that data is now encrypted in both directions, from the server to the client and from the client to the server.
High security—. The high-security option encrypts data in both directions, using a 128-bit encryption key.
As mentioned, each new Windows Terminal Server release has introduced new client integration features that enhance the user’s computing experience. Table 1.3 summarizes the features supported by the RDP 5.x clients, and what version of Windows Terminal Server is required to enable the feature. The latest RDP client (5.2) can be used to connect to older Terminal Servers (Windows NT 4.0, Terminal Server Edition; or Windows 2000 Terminal Server).
Table 1.3. RDP 5.x Features and Required Server Version
Feature | RDP Version | Terminal Server Version | Description | ||
|---|---|---|---|---|---|
5.1 | 5.2 | ||||
Local/remote clipboard integration | X | X | X | Both | Allows clipboard contents to be cut and pasted seamlessly back and forth between the active Terminal Server session and the user’s local desktop. |
Local/remote file copy and paste integration | X | X | Windows 2003 only | Allows the cut and pasting of entire file objects back and forth between the active session and the local desktop. | |
Local client printer redirection | X | X | X | Both | Printers that are configured on a local client can be made available automatically from within the user’s Terminal Server session. |
Network client printer redirection | X | Both | This allows for access to locally mapped network printers on the client desktop. | ||
Session remote control | X | X | X | Both | Session remote control is the capacity for one person to remotely view and even control another user’s active session. |
Persistent bitmap cache | X | X | X | Both | The persistent bitmap cache is stored on disk so that it can be reused the next time a session is started. Version 4.0 allowed only in-memory caching. |
Connection bar | X | X | Both | This allows you to still easily minimize a full-screen session without having to toggle the session between full screen and windowed using the Ctrl+Alt+Break key combination. | |
Automatic session reconnect | X | Both | If a network disruption causes your connection to a Terminal Server to be lost, the Remote Desktop Connection client will automatically attempt to reestablish that connection. If the connection cannot be reestablished, then after about one minute the client will give up and an error message will appear saying the connection has been lost. | ||
Client drive redirection | X | Windows 2003 only | The automatic redirection of a client’s local and network drives so they are accessible from within the Terminal Server session. | ||
Client serial port redirection | X | Windows 2003 only | Redirection of the local serial ports. | ||
Client audio redirection | X | Windows 2003 only | Audio is redirected from the Terminal Server session to the local client for output. | ||
Smart card sign-on | X | Windows 2003 only | The user is able to provide their smart card to a local reader attached to their PC and have those credentials transmitted and authenticated on the Terminal Server. | ||
X | Both Client must be running WinNT, 2000, XP, or 2003. Windows 98 or 95 operating systems don’t support this feature. | Introduces support for the Alt+Tab and other Windows key combinations within the Terminal Server session. | |||
Client time zone support | X | Windows 2003 only | Client time zone support lets the RDP client provide its own local time zone information to a Windows 2003 Terminal Server so that the server can automatically configure the user’s session to reflect the same time zone information. A Terminal Server can support any number of users located in different time zones, and this feature lets the user maintain proper time and date information within his or her own session. | ||
Direct Terminal Server console access | X | Windows 2003 only | This feature allows for the creation of a direct connection to the console and not a Terminal Server session. Applications that require direct console access will function within this special remote session. This feature is dependent on having a Windows 2003 Terminal Server. | ||
More detailed information on each of these supported features is discussed in Chapter 5, “Client Hardware and Software Planning.”
Table 1.4 summarizes the native Microsoft RDP client versions and the operating systems they support.
Table 1.4. RDP Client Versions and Their Supported Operating Systems
Operating System | RDP Client Version Supported | Notes |
|---|---|---|
Windows 2003, XP, 2000, client are ME, 98, and NT 4.0 | RDP 5.0 and higher | All versions of the RDP supported on all 32-bit versions of Windows, NT 4.0 or higher. |
Windows 95 | RDP 5.0 or 5.1 only | Microsoft does not officially support the RDP 5.2 (or newer) client on Windows 95. |
Windows for Workgroups 3.11 | RDP 5.0 only | Microsoft no longer supports this version of Windows with the new RDP client. Only the client that originally ships with Windows 2000 is available for the 16-bit version of Windows. |
Macintosh OS X | Mac OS X RDP Client 1.0.2 | This is currently the only RDP client that Microsoft produces for a non-Windows operating system. |
Pocket PC 2002 | PPC 2002 client | This special RDP client is designed specifically to run on Pocket PC 2002. It will not run on older versions of Pocket PC. |
Windows CE | Handheld and CE-based terminals running CE 3.0 and CE.NET | Special versions of the RDP client can either be installed on a Windows CE client or come embedded with the CE operating system. |
In addition to the RDP clients supplied by Microsoft, there exist clients created by other vendors to run on client operating systems not natively supported by Microsoft. Many of these clients support only a small subset of the functions available through the Microsoft RDP clients. Currently the only non-Windows operating system supported by Microsoft is Apple’s Mac OS X. Table 1.5 lists some third-party RDP clients that are available.
Table 1.5. Examples of Third-Party RDP Clients That Are Available
Host Operating System Supported | Description |
|---|---|
Platform-independent, Java-based client | HOBLink JWT, version 3.1, is a pure, Java-based RDP client that supports Windows 2003 Terminal Server features such as
HOBLink also provides a number of additional features to extend the usefulness of Terminal Server to a Java-based client. HOBLink is developed by the German-based company HOB, and the client is available from http://www.hob.de/www_us. |
Linux and DOS | Terminal-Services.net provides a commercial RDP client that runs on Linux and another that runs on DOS. The Linux-based client called LinRDP is fully compatible with the new RDP features available in the RDP 5.2 client and Windows 2003 Terminal Server:
Evaluation versions of both clients are available for download from the Web site at http://www.terminal-services.net. |
UNIX OpenSource | An Open Source version of the RDP client is available from RDesktop.Org. Unlike the other two clients, this one provides only barebones connectivity at this time but is an option for those users who wish to have basic access from a Linux or UNIX desktop. Full source code is provided with this client. |
Terminal Services alone would be of little use without the ability to scale the environment to support users across more than one Terminal Server. Distributing concurrent user load across multiple Terminal Servers helps to mitigate the impact a server failure has on the environment and simplifies the task of growing the environment in the future to accommodate the growth requirements of your changing business. Microsoft provides scalability through Network Load Balancing (NLB), which is available with Windows 2000 (Advanced Server or Datacenter Server) and with all versions of Windows Server 2003.
Microsoft’s NLB is a component of Windows Clustering that allows for multiple servers to provide TCP/IP-based services to users through one or more IP addresses (cluster IP addresses). This setup improves both the availability and scalability of a particular service by allowing multiple servers to be grouped together and operate conceptually as a single entity. The primary use for NLB is to provide redundancy for Web-based services such as Web or FTP servers, but it can also be used to provide redundancy in a Terminal Server environment.
Once NLB has been configured for all participating Terminal Servers, then the RDP clients are configured to simply connect to the cluster IP or cluster hostname instead of a specific server. The connection is then routed to the appropriate Terminal Server in the cluster and serviced accordingly.
NLB runs as a network driver on the server and is completely transparent to the TCP/IP networking stack. Each Terminal Server that will participate in the NLB cluster is configured to enable this network driver. When implementing Windows 2000 Terminal Server, NLB must be configured on each individual Terminal Server that will participate in the NLB cluster.
Windows Server 2003 includes a new utility called the Network Load Balancing Manager, which can be found under Administrative Tools on the Start menu. This tool allows all aspects of an NLB cluster to be configured from a single point instead of having to configure options on each individual cluster member. Figure 1.12 shows the Network Load Balancing Manager with two Windows 2003 Terminal Servers in a test cluster.
TIP:
A user’s Terminal Server session information is not maintained across multiple servers, as the term clustering might suggest. If a user is on a server that fails, his or her session and any information currently open within that session will be lost, and the user will have to log on to an alternate server in the cluster.
In Chapter 22, “Server Operations and Support,” I look in detail at the steps required to configure NLB to function in your Terminal Server environment.
Windows Server 2003 introduces a new cluster component called Terminal Services Session Directory, which can be used to further enhance the functionality of a load-balancing solution such as NLB by enabling support for reconnecting a user to a disconnected session within the load-balanced Terminal Server environment. Without such functionality, when a user disconnects an active Terminal Server session within a clustered environment it is likely that when the user reconnects, particularly from a different client, that user will be presented with a new Terminal Server session instead of reconnecting to their existing one.
TIP:
Some third-party load-balancing tools such as WTS Gateway Pro provide their own session management components and do not require the use of Session Directory.
Figure 1.13 shows the components that exist when Terminal Services Session Directory has been implemented with Microsoft NLB. The following steps summarize how Session Directory integrates with a load-balancing solution to provide session accessibility.
The user contacts the Terminal Server cluster and is directed to Server A.
Server A contacts the server running the Session Directory service. This server queries its database to determine if this user already has an active but disconnected session in the cluster.
If no connection exists, then Server A continues the logon process and creates a new session for the user.
If the user does have an existing session (Server C, for example), then the logon process is handed off to Server C, where the user is reconnected to their existing session.
In addition to the standard administrative tools found on a Windows server, Terminal Server provides more tools for supporting the multiuser environment. The following tools provide Terminal Server–specific support features.
Terminal Services Client Creator—. Available only on Windows 2000, this utility lets you create client-installation diskettes for the Win32 or Win16 RDP 5.0 client.
Terminal Services Configuration—. Used to manage Terminal Server connection types, their transports, and their properties.
Terminal Services Manager—. Used to manage all active Terminal Servers, users, sessions, and processes.
Terminal Services Licensing—. Used to monitor and update Terminal Services licensing support.
On a Windows 2000 Terminal Server, you have the option of using the Terminal Services Client Creator utility to generate installation diskettes for either the Win32 or the Win16 RDP 5.0 client. Figure 1.14 shows the main Client Creator dialog box. Use of the Client Creator tool is discussed in Chapter 19.
Before a user can connect to a Terminal Server, the connections must be properly configured on the server. This is done using the Terminal Services Configuration tool, where you create the desired connection types and their associated network transports. Figure 1.15 shows a Windows 2003 Terminal Services Configuration application with the RDP connection type and the TCP transport. Properties such as access security, minimum encryption level, connection timeout options, or remote control options can be set for a connection type and will affect all users who access the server through the connection type. Currently, Terminal Server supports only two connection types, Microsoft RDP and Citrix ICA. When a Windows Server is configured as a Terminal Server, the RDP transport is automatically created with the default configuration. Connection security and proper configuration are discussed in Chapters 16, “Terminal Server Security,” and 19, “RDP Client Installation and Configuration,” respectively.
The Terminal Services Manager is used to manage users, sessions, and processes on each Terminal Server from a single management console. Figure 1.16 shows a typical Terminal Services Manager session. Tasks such as remote control, which was discussed earlier in the “RDP Client Integration Features” section, are initiated from within this tool.
The management window is divided into two panels. The left panel contains a list of domains, Terminal Servers, and Terminal Server sessions on the network. The right panel contains a number of tabs with information pertaining to the object currently selected in the left panel. Notice the two idle RDP sessions in the left panel. The server initializes these sessions so that they’re available immediately when a user connects to the server. This helps to speed up the client connection process.
The Terminal Services Licensing application is used to manage the Terminal Server licensing service. To run one or more Windows Servers in Terminal Server mode (Application Server mode in Windows 2000), you must have at least one license server running in your environment. A license server manages the licenses that are issued to clients when they connect to a Terminal Server. A client must have a valid Terminal Services client access license to log on to a Terminal Server. Figure 1.17 shows this utility. In Chapter 8, “Server Installation and Management Planning,” I talk about planning the deployment of Terminal Services licensing, while in Chapter 12, “Licensing Service Installation and Configuration,” I look specifically at the task of deploying a license server for your implementation.
In order to utilize Terminal Services in your environment, you will be required to ensure that you have the appropriate server and client access licenses available. The following server and client access licenses are required:
A Windows server license for each instance of Windows 2000 or Windows 2003 that you will be running in your environment.
A Windows client access license (CAL) for each user or device that will be connecting to the Terminal Server. In Windows 2000 only the per-device license is supported, which grants one license for each device that is connecting. Windows Server 2003 introduces a per-user license, which allows for licensing of a user regardless of the device they are connecting from.
A Windows Terminal Server client access license (TSCAL) for each user or device that will be connecting to a Windows Server and creating a Terminal Services session. This license is required in addition to the standard Windows CAL. Once again, Windows Server 2003 allows the TSCAL to be licensed either per-device or per-user, whatever is more appropriate for your environment.
Terminal Server client access license–compliance is enforced through use of a Terminal Services License Service, a special service that is required to run on a Windows Server in your environment. Whenever one or more Windows Servers are configured to run as Terminal Servers (Application Server mode in Windows 2000), a server running the Terminal Services licensing service is also required. A Windows server running Remote Desktop for Administration (Remote Administration mode in Windows 2000) does not require a license server.
A Windows Terminal Server will function without the existence of a Licensing Server for a specified grace period before remote connections will be denied. Even after the grace period has expired, logons directly from the console (not using a remote console session) will still be allowed. The grace period durations are as follows:
Windows 2000 Server to 90 days
Windows Server 2003 to 120 days
When a License Server does exist, until it is activated, it will issue only temporary TSCALS to the requesting clients, which are good for only 90 days. If a permanent license is not issued to the client within that time frame, the temporary license will expire and the client will no longer be able to connect to the server. The licensing server itself is activated through a Microsoft Clearinghouse, either electronically or over the phone. Details on this process are discussed in Chapter 12.
In the next chapter I provide an overview of Citrix’s MetaFrame Presentation Server, an add-on component that provides a vast array of features and functionality specifically suited to deploying large-scale enterprise Terminal Server environments both through traditional Windows-based clients and through a Web browser.
The remainder of this book delves much deeper into all aspects of a Terminal Server project, either with or without MetaFrame, including planning, testing, and, of course, implementation.