Microsoft Windows NT Server, Terminal Server Edition, version 4.0: An Architectural Overview

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Archived content - No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Abstract

Microsoft® Windows NT® Server, Terminal Server Edition, version 4.0 gives the Windows NT Server operating system the capability to serve the 32-bit Microsoft Windows® operating system-based applications to terminals and terminal emulators running on PC and non-PC desktops. The Terminal Server environment is, by definition, a thin-client architecture where all application processing occurs centrally on the server. Because Terminal Server Clients will be available for many different desktop platforms (Macintosh, UNIX, and others), Terminal Server provides access to 32-bit Windows-based applications from virtually any desktop and provides a bridging technology for organizations that are transitioning to a pure 32-bit desktop environment.

This paper describes the way Windows NT Server, Terminal Server Edition version 4.0 internally operates to provide the multiple interactive 32-bit desktop environment.

Technology Update: What is Windows NT Server 4.0, Terminal Server Edition?

The Microsoft® Windows NT® Server network operating system version 4.0, Terminal Server Edition, is the name for a product that will add Windows® based Terminal support to Windows NT Server and a "super-thin client" to the Windows operating system family product line. This new technology will provide enterprise customers with a compelling new extension to the Windows-based computing environment that combines low total cost of ownership, the familiar 32-bit Windows user interface, and the power and choice of the Windows operating system family.

Terminal Server is an extension of the Windows NT Server 4.0 product line. With a "super-thin client" in the multiuser Windows NT operating system, users can experience the Windows NT desktop operating system and Windows-based applications completely off the server. Windows Terminal Server will provide users access to 16- or 32-bit Windows-based applications from any of the following types of desktops:

A new class of low-cost hardware, commonly referred to as Windows-based terminals, that will be marketed by third-party hardware vendors.
Any existing 32-bit Windows desktop operating system, such as Windows 95 or Microsoft Windows NT Workstation (running the 32-bit Terminal Server client as a window within the local desktop environment).
Older 16-bit Windows-based desktops running the Windows 3.11 operating system (running the 16-bit Terminal Server client as a windows within the local desktop environment).
X-based Terminals, Apple Macintosh, MS-DOS®, Networked Computers, and UNIX-based desktops (via a third-party add-on product).

Product Overview

Windows NT Server, Terminal Server Edition consists of three components—the Windows NT Server multiuser core, the Remote Desktop Protocol (RDP), and the "super-thin" Windows-based client software. Specifically:

Terminal Server – A multiuser server core that provides the ability to host multiple, simultaneous client sessions on Windows NT Server 4.0 and on future versions of Windows NT Server. Terminal Server is capable of directly hosting compatible multiuser client desktops running on a variety of Windows-based and non Windows-based hardware. Standard Windows-based applications do not need modification to run on the Terminal Server, and all standard Windows NT-based management infrastructure and technologies can be used to manage the client desktops. In this way, corporations can take advantage of the rich choice of applications and tools offered by today's Windows environment.
Remote Desktop Protocol (RDP) – A key component of Terminal Server is the protocol that allows a "super-thin client" to communicate with the Terminal Server over the network. This protocol is based on International Telecommunications Union's (ITU) T.120 protocol, an international, standard multichannel conferencing protocol currently used in the Microsoft NetMeeting™ conferencing software product. It is tuned for high-bandwidth enterprise environments and will also support encrypted sessions.

"Super-Thin" Client – The client software that presents, or displays, the familiar 32-bit Windows user interface on a range of desktop hardware:
- New Windows-based terminal devices
- Personal computers running Windows 95, Windows 98, and Windows NT Workstation
- Personal computers running Windows for Workgroups (Windows version 3.11)

Figure 1: How Terminal Server Works

Figure 1: How Terminal Server Works

What Is New in the Architecture of Windows NT Server 4.0, Terminal Server Edition

To achieve the multiuser capabilities required in Windows NT Server 4.0, Terminal Server Edition, components, services, and drivers have been added and or modified to the Windows NT 4.0 core operating system. Windows NT 4.0 components such as the Virtual Memory Manager and Object Manager have been modified to perform in a multiuser environment.1 While these are not the only components modified, they are the most significant and other sub-system additions are detailed in later areas of this paper.

The Windows NT Object Manager has been modified in Windows NT Server 4.0, Terminal Server Edition to provide the virtualization of objects (for example, mutant, timer, semaphore, process, thread, and so on) so that applications and system programs of different sessions do not collide. Every object name created within a session is appended with a unique identifier number associated with the individual session that created it (SessionID). For example, if a 16-bit application was started in Session 1, the Object Manager would append the object name with the SessionID, "\\application name:1".

The Virtual Memory Manager maps virtual addresses in the process' address space to physical pages in the computer's memory. In Windows NT, a process' address space is divided into two 2 GB-address ranges: "user" (process-specific addresses) and "kernel" (system-specific addresses). For the "user" address space, the Virtual Memory Manager provides an individualized view of the physical memory to each process, ensuring that a thread within a process can access its own memory, but not the memory of other processes.

On the other hand, the "kernel" address space is common for all processes within the system, thus providing a consistent means for accessing kernel services. The fact that all processes share the kernel address space resulted in kernel resource limitations when supporting multiple interactive sessions on a single server. In Windows NT Server 4.0, Terminal Server Edition, these limitations were addressed by creating a special address range in the kernel, called "SessionSpace," that can be mapped on a per-session basis. Each process is associated with a SessionSpace via a SessionID. When a remote user connects to Terminal Server, a new SessionID is generated and all of the processes created for that connection inherit that SessionID and unique session space. Other process groups, with a different SessionID, point to a separate set of memory mapped objects and physical pages at the same virtual address.

A new Windows NT service called "Terminal Server" (termsrv.exe) is the controlling process in the Terminal Server architecture. It is primarily responsible for session management, initiation, and termination of user sessions and session event notification. The Terminal Server service is entirely protocol-independent, so it can function using RDP or a third-party add-on protocol such as Citrix's ICA.

A user mode protocol extension provides assistance to the Terminal Server service. It is the responsibility of this component to provide protocol-specific functions and services, such as licensing, session shadowing, client font enumeration, and so forth. Each Terminal Server protocol (for example, RDP and ICA) will have their own protocol extension, providing a variety of services. For the Terminal Server RDP protocol, this user mode extension is called wsxtshar.dll.

Figure 2: Windows NT Server 4.0, Terminal Server Edition, "SessionSpace"

RDP

Remote Desktop Protocol

Remote Desktop Protocol (RDP) is based on, and is an extension of, the T-120 protocol family standards. A multichannel capable protocol allows for separate virtual channels for carrying serial device communication and presentation data from the server, as well as encrypted client mouse and keyboard data.

Several other capabilities are also part of the T.120 standards definition. Multipoint data delivery, for instance, which allows data from an application to be delivered "real-time," to multiple parties. Multicast-enabled delivery allows for reliable delivery services of data transmissions. It increases the performance for the customer while at the same time reducing the load on the network infrastructure. RDP does not currently implement this feature, but having this as part of the standard on which the protocol is built gives access to this capability for future versions of the Terminal Server product.

One reason that Microsoft decided to implement the RDP for connectivity purposes within the Windows NT Server 4.0, Terminal Server Edition is that it provides a very extensible base from which to build many more capabilities onto. This is because RDP provides up to 64,000 separate channels for data transmission, as well as provisions for multipoint transmission.

Current transmission activities are only using a single channel (for keyboard, mouse, and video (presentation data). Also, RDP is designed to support many different types of Network topologies (such as ISDN, POTS, and many LAN protocols such as IPX, Netbios, TCP/IP, and so forth.). The current version of RDP only runs over TCP/IP. But based on customer feedback, other protocol support may be added in future versions.

The main reason we chose RDP was because of Microsoft's extensive experience with the t.120 family of protocols (for example, NetMeeting is based on RDP), which was designed for use in multiplatform WAN environments. From that we created a high-performance Windows NT Server-specific implementation. As part of our ongoing design and improvement efforts, we identified numerous protocol enhancements to further leverage the graphical features of the Windows environment.

The activity involved in sending and receiving data through the RDP stack is essentially the same as the seven-layer OSI (open systems interconnection) model standards for common LAN (local area network) networking today. Data from an application or service to be transmitted is passed down through the protocol stacks, sectioned, directed to a channel (MCS), encrypted, wrapped, framed, and packaged onto the network protocol and finally addressed and sent over the wire to the client.

The return data works the same way only in reverse, with the packet being stripped of its address, then unwrapped, decrypted, etc., until the data is presented to the application for use. Key portions of the protocol stack modifications occur between the 4th and 7th layers, where the data is encrypted, wrapped and framed, directed to a channel, and prioritized.

RDPDD (a Microsoft Win32® application programming interface display driver) captures the Windows user interface and translates it into a form that is readily converted by RDPWD into the RDP protocol. A layer in RDPWD packages presentation data for transmission on a specific channel of the T.120 MCS protocol. This layer directly communicates with whichever transport driver is currently loaded (tdtcp.sys = TCP/IP) for ultimate transmission on the network.

Conversely, RDP encoded mouse/keyboard packets from the client are delivered by tdtcp to RDPWD, which unwraps the multichannel data and then transfers it to the appropriate consumer. One interesting aspect of the stack architecture is that RDPWD appears as both a mouse and keyboard device driver to win32k.sys, allowing highly efficient (and transparent) remote input devices. All components are kernel mode drivers and, therefore, none of this activity requires any user/kernel mode transitions.

MCS is part of RDPWD. There is a protocol-specific DLL (dynamic-link library), which the terminal server service (termsrv.exe) uses to perform session management. For RDP, it is called rdpwsx.dll. This component does implement a very thin GCC layer, which sits on top of the MCSMUX. The sole function of the MCSMUX is to provide user mode connectivity to the MCS portion of RDPWD via an input/output completion port. It also masks the multisession nature of the stack from the GCC component.

Each Terminal Server protocol (currently, only RDP and ICA are supported) will have a protocol stack instance loaded (a listener stack awaiting a connection request). The Terminal Server device driver coordinates and manages the RDP protocol activity and is made up of smaller components, an RDP driver (rdpwd.sys) for UI (user interface) transfer, compression, encryption, framing, etc, and a transport driver (tdtcp.sys) to package the protocol onto the underlying network protocol, TCP/IP.

RDP was developed to be entirely independent of its underlying transport stack, in this case tdtcp.sys. RDP being completely independent of its transport stack means that we can add other transport drivers for other network protocols as customers request them, with little or no significant changes to the foundational parts of the protocol. These are key elements to the performance and extendibility of RDP on the network.

One of the key points for application developers is that in using RDP, Microsoft has abstracted away the complexities of dealing with the Protocol stack. By having application developers simply write clean, well-designed 32-bit applications, then the RDP stack implemented by the Terminal Server and its client connections takes care of the rest.

Figure 3: Windows Terminal Server Components

Figure 3: Windows Terminal Server Components

Walk-through of the Terminal Server Start-up

To assist in understanding how this new operating system operates, we walk through the initialization process of a Terminal Server and describe what occurs when a user connects to the server and runs an application.

Terminal Server Initialization

As Windows NT Server 4.0, Terminal Server Edition boots and loads the core operating system, the Terminal Server service (termsrv.exe ) is started and begins waiting for session connections. Each connection is given a unique session identifier or "SessionID" to represent an individual session to the Terminal Server, and each process created within a session is "tagged" with the associated SessionID to differentiate its namespace from other session namespaces.

The console (Terminal Server keyboard, mouse, and video) session is always the first to load and is treated as a special-case client connection and assigned SessionID0. The console session starts as a normal Windows NT system session, with the configured Windows NT display, mouse, and keyboard drivers loaded.

The Terminal Server service then calls the Windows NT Session Manager (SMSS.EXE) to create two (default = 2) idle client sessions (after creating the console session) awaiting client connections. To create the idle sessions, the Session Manager executes the Windows NT client server run-time subsystem process (CSRSS.EXE), and a new SessionID is assigned to that process. The CSRSS process also invokes the Winlogon (WINLOGON.EXE) process and the Win32k.sys (Window Manager and GDI) kernel module under the newly associated SessionID.

The modified Windows NT image loader recognizes this Win32k.sys as a SessionSpace loadable image by a predefined bit set in the image header. It then relocates the code portion of the image into physical memory with pointers from the virtual kernel address space for that session if Win32k.sys has not already been loaded. By design, it always attaches to a previously loaded image's code (Win32k.sys) if one already exists in memory (that is, from any active application or session). The data (or non-shared) section of this image is then allocated to the new session from a newly created SessionSpace pageable kernel memory section.

Unlike the console session, Terminal Server client sessions are configured to load separate drivers for the display, keyboard, and mouse. The new display driver is the Remote Desktop Protocol (RDP) display device driver (rdpdd.dll), and the mouse and keyboard drivers are replaced with the RDP driver rdpwd.sys. These drivers allow the RDP client session to be both available and interactive, remotely. Finally, Terminal Server also invokes a connection listener thread for the RDP protocol (Termdd.sys), which listens for RDP client connections on a TCP port.

At this point, the CSRSS process exists under its own SessionID namespace, with its data instantiated per process as necessary. Any processes created from within this SessionID execute within the SessionSpace of the CSRSS process automatically. This prevents processes with different SessionID's from accessing another session's data (Figure 4).

Figure 4: Windows NT Server 4.0, Terminal Server Edition Initialization Architecture

Client Connection

The RDP client can be installed and run on any Windows-based terminal (based on the Microsoft Window CE operating system), Windows for Workgroups, or Win32 platform (non-Windows-based clients are supported by the Citrix Metaframe add-on). The WFW RDP client is approximately 70K in size (.exe) and uses a 300K working set and 100K for display data. The Win32 client is approximately 130K in size and uses a 300K working set and 100K for display data.

The client initiates a connection to the Terminal Server through the TCP port. The Terminal Server RDP listener thread detects the session request and creates a new RDP stack instance to handle the new session request. The listener thread hands over the incoming session to the new RDP stack instance and continues listening on the TCP port for further connection attempts. Each RDP stack is created as the client sessions are connected to handle negotiation of session configuration details.

The first details determined are to establish an encryption level for the session. The Terminal Server initially supports three encryption levels—low, medium, and high.

Low encryption encrypts only packets being sent from the client to the Terminal Server. This "input only" encryption is to protect the input of sensitive data like a user's password. Medium encryption encrypts outgoing packets from the client the same as low-level encryption, but also encrypts all display packets being returned to the client from the Terminal Server. This method of encryption secures sensitive data as it travels over the network to be displayed on a remote screen. Both low and medium encryption use the RC4 algorithm with a 40-bit key. High encryption encrypts packets in both directions, to and from the client, but uses the industry standard, non-exportable 128-bit high-level encryption.

All clients will, by default, reserve 1.5 MB of RAM memory for a bitmap cache used to cache bitmaps, such as icons, toolbars, cursors, etc, but is not used to hold unicode strings. The cache is overwritten using a Least Recently Used (LRU) algorithm. The Terminal Server also contains buffers (Cache) to enable controlled passing of screen refreshes to clients, rather than a constant bitstream.

When user interaction at the client is high (specifically meaning they are touching the keyboard or mouse; it is not directly related to the amount of graphical output), the buffer is flushed at approximately 20 times per second. During idle time or when there is no user interaction, the buffer is slowed to only flush 10 times per second. If the graphics are intensive, no timer is used and the flush rate is as fast as the server fills up buffers. This last point is important since most of the time output is never "pushed," based on a timer. Most of the time, the timer is used to push out the last bit of data and is then NOT restarted. The server remains idle when nothing is going on.

At this point, prior to any logon being presented to the end user, the licensing details are negotiated. First, the client consumes a Windows NT Server Client access license. Second, a Windows NT desktop license is verified on the machine that is connecting, and if no license can be validated, a connectivity license is provided to a non-Windows NT Workstation client to allow connection to the Terminal Server.

After session details have been negotiated, the server RDP stack instance, for this connection, is mapped to an existing idle Win32k user session, and the user is prompted with the Windows NT logon screen. If autologon is configured, the encrypted user name and password is passed to the Terminal Server and logon proceeds. If no idle Win32k sessions currently exist, the Terminal Server service calls the Session Manager (SMSS) to create a new user space for the new session. Much of the Win32k user session is using shared code and does load noticeably faster after one instance has previously loaded.

After the user types her or his user name and password, packets are sent encrypted to the Terminal Server. The Winlogon process performs the necessary account authentication to ensure that the user has privilege to log on and then passes the user's domain and user name to the Terminal Server service, which maintains a domain/user name, SessionID list. If a SessionID is already associated with this user, they are remapped into the existing namespace, and the previous session stack is reloaded. Otherwise, the connection proceeds as normal and the Terminal Server service creates a new domain/user name, SessionID mapping. If for some reason more than one session is active for this user, the list of sessions is displayed and the user decides which one to make the reconnection.

Figure 5: Windows NT Server 4.0, Terminal Server Edition architecture with one currently active client session

Running an Application

After user logon, the desktop (or application if in single app mode) is displayed for the user. When the user selects a 32-bit application to run, the mouse commands are passed to the Terminal Server, which launches the selected application into a new virtual memory space. This new address space inherits the user attributes of the csrss process that created it. In other words, once smss exits, the session exists in the context of some particular user. All processes created within that process inherit the user rights of the user who logged on.

All processes on the Terminal Server share code in kernel and user modes wherever possible. To achieve the sharing of code between processes, the Windows NT Virtual Memory (VM) manager uses copy-on-write page protection. When multiple processes want to read and write the same memory contents, the VM manager assigns copy-on-write page protection to the memory region. All processes, regardless of session, use the same memory contents until a write operation is performed. At that time, the VM manager copies the physical page frame to another location, updates the process' virtual address to point to the new page location, and now marks the page as read/write. Copy-on-write is extremely useful and efficient for applications running on a Terminal Server.

When a Win32-based application such as Microsoft Word is loaded into physical memory by one process (Session), it is marked as copy-on-write. When new processes (Sessions) also invoke Word, because the application is already loaded in memory, the image loader just points the new processes (Sessions) to the existing copy. When buffers and user-specific data is required (that is, saving to a file), the necessary pages are copied into a new physical memory location and marked as read/write for the individual process (Session). The VM manager protects this memory space from other processes. Most of an application, however, is shareable code and only has a single instance of code in physical memory no matter how many times it is run.

It is preferable (although not necessary) to run 32-bit applications in a Terminal Server environment. 32-bit applications (Win32) allow sharing of code and run more efficiently in a multiuser environment. Windows NT allows 16-bit applications (Win16) to run in a Win32-based environment by creating a virtual DOS machine (VDM) for each Win16-based application to execute. All 16-bit output is translated into Win32 calls, which perform the necessary actions.

Because Win16 applications are executing within their own VDM, code cannot be shared between applications in multiple sessions. Translation between Win16 and Win32 calls also consumes system resources. Running Win16-based applications in a Terminal Server environment can potentially consume up to 40 percent more resources than a comparable Win32-based application.

Session Disconnect/ User Logoff

Session Disconnect

If a user decides to disconnect the session, the processes and all virtual memory space remain and are paged off to the physical disk if physical memory is required for other processes. Because the Terminal Server keeps a mapping of domain/user name and SessionID, when the same user reconnects, the existing session is loaded and made available again. An additional benefit of RDP is that of being able to change session screen resolutions, depending on what the user requests for the session. For example, let's say a user had previously connected to a Terminal Server session at 800 x 600 resolution and disconnected. If the user then moves to a different computer that only supports 640 x 480 resolution and reconnects to the existing session, the desktop is redrawn to support the new resolution.

User Logoff

Logoff is typically very simple to implement. Once a user logs off from the session, all processes associated with the SessionID are terminated and any memory allocated to the session is released. Of course, if the user was running a 32-bit application like Microsoft Word and logged off from the session, the application would remain in memory until the very last user exited from the application.

Appendix A

The Windows NT 4.0 architecture merges the best attributes of a layered operating system with those of a client/server or "microkernel" operating system.2

The Windows NT operating system can be divided into two sections, the user mode (Windows NT-protected subsystems) and kernel mode (Windows NT executive).

Privileged or kernel mode is a highly privileged mode of operation in which the code has direct access to all hardware and memory in the system, including that of user mode processes. Application threads must be switched to privileged mode to run in operating system code. Applications call privileged-mode operating system services for essential functions such as drawing windows, receiving information about user keyboard and mouse input, and checking security.

User mode is the processing mode in which all applications run. User mode is a less privileged processor mode with code running only in its own address space and no direct access to hardware. Processes running in user mode must call operating system functions to switch their threads to privileged mode to use operating system services.

Figure 6: Windows NT 4.0 Architecture

The Windows NT executive is the kernel mode portion of the Windows NT operating system. The executive is made up of a series of components that provide a variety of functions and system services to subsystems and other executive components.

The function of each of the executive components is outlined in the following pages.

Microkernel

The efficiency of an operating system typically depends on the operation of the microkernel or kernel. It is the kernel's responsibility to control how the operating system uses its processor(s) and to ensure that it is used effectively. The kernel typically controls process thread scheduling and dispatching, detects and responds to interrupts and exceptions, synchronizes the running of multiple processors, and provides system robustness in case of power failure.

I/O Manager

The I/O (input/output) Manager co-ordinates and manages all input and output for Windows NT, primarily managing communication between other I/O drivers by providing a common interface that they can call. The I/O Manager typically controls access to: cache manager, which handles caching of frequently used files in memory for the entire I/O system; file system drivers, which allow support for multiple file systems such as FAT, FAT32, and NTFS; hardware device drivers, which allow support for peripheral devices such as printers, disks, and mice; and network drivers, which allow support for network redirectors, protocols, and network adapters.

Object Manager

Object Manager is the part of the Windows NT Executive that creates, manages, and deletes objects. Objects are software components that consist of a data type, attributes, and a set of operations the object performs.

Object Manager also provides uniform rules for retaining, naming, and setting the security of objects and creates object handles. An object handle consists of access control information and a pointer to the object. Processes use object handles to manipulate Windows NT objects.

Security Reference Monitor

The Security Reference Monitor enforces security policies. It provides services to both kernel and user modes to ensure the users and processes attempting access to an object have the necessary permissions. This component also generates audit messages when appropriate.

Process Manager

The Process Manager is the part of the Windows NT Executive that manages two types of objects—process objects and thread objects. A process is defined as an address space, a set of objects (resources) visible to the process, and a set of threads that run in the context of the process. A thread is the most basic schedulable entity in the system. It has its own set of registers, its own kernel stack, a thread environment block, and user stack in the address space of its process.

The Process Manager provides a standard set of services for creating and using threads and processes in the context of a particular subsystem environment.

Local Procedure Call (LPC) Facility

Applications and protected subsystems have a client/server relationship. The subsystems provide services that applications can use. Applications communicate with subsystems by passing messages via the Windows NT executive's local procedure call (LPC) mechanism. The message passing process is hidden from the applications by function stubs provided in special dynamic-link libraries.

Virtual Memory Manager

The Virtual Memory Manager maps virtual addresses in the process' address space to physical pages in the computer's memory. The Virtual Memory Manager hides the physical organization of memory from the process' threads to ensure that the thread can access its own memory, but not the memory of other processes.

The Virtual Memory Manager allocates memory in two phases for efficiency: reserving it, then committing it. Committed memory is part of the paging file, the disk file used to write pages to physical memory. Reserved memory is held until needed, then committed. The act of reserving memory maintains a contiguous virtual address space for a process, which is then consumed as needed.

Figure 7: Virtual Memory Management

The Virtual Memory Manager allocates to each process a unique protected set of virtual addresses available to the process' threads. Each process has a separate address space, so a thread in one process cannot view or modify the memory of another process without authorization. This address space appears to be 4 gigabytes (GB) in size, with 2 GB reserved for program storage and 2 GB reserved for system storage.

Windows Manager and Graphics Device Interface (GDI)

The Windows Manager is the part of the Windows NT Executive that creates the familiar screen interface. The Graphics Device Interface (GDI), also called the graphics engine, consists of functions in Win32k.sys that display graphics on the computer monitor and printers. It is implemented by the same component as Window Manager.

Applications call the standard USER functions to create windows and buttons on the display. Windows Manager communicates these requests to GDI, which passes them to the graphics display drivers where they are formatted for the display device.

The Windows Manager notifies applications when changes occur in the user's interaction with the interface, such as movement or resizing of windows, cursor movement, and icon selection.

Prior to Windows NT 4.0, the Windows Manager was the USER component of the Win32 subsystem and ran in a protected process in user mode. With Windows NT 4.0, they were moved into the Windows NT Executive to run in kernel mode. This change was designed to speed up graphics calls and reduce the memory requirements of interprocess communication.

For More Information

For more information and the latest articles on Terminal Server, check out Microsoft TechNet and the Terminal Server Web site at https://www.microsoft.com/ntserver/ProductInfo/terminal/default.asp.

For the latest information on Microsoft Windows NT Server 4.0, check out Microsoft TechNet and our World Wide Web site at https://www.microsoft.com/ntserver.

1 For more information about the core architecture of Windows NT Server 4.0, See Appendix A, at the end of this document.

2 For a complete discussion on Windows NT architecture, see Inside NT by Helen Custer.