Windows NT Terminal Server and Citrix MetaFrame

\ \ Chapter 3: Terminal Server Architecture\ Architectural Differences Between Terminal Server and NT Server 4.0\ Before you get into the details of both NT Server 4.0 and Terminal Server 4.0 architecture, spend a moment learning the differences between the two. The fundamental difference is that Terminal Server architecture supports multiple sessions or desktops running at the same time, whereas NT Server 4.0 supports only one - the console. Each session running on Terminal Server must be isolated from the actions of all other sessions. Terminal Server handles this need by assigning each new session a unique Session ID. The Session ID is used to keep track of and keep separate each session's resources.\ Although many components of the NT Server 4.0 architecture have been modified in Terminal Server, the three most significant components that have changed are the Object Manager, Win 32 subsystem, and the Virtual Memory Manager.\ Differences in the Object Manager\ The Object Manager is responsible for creating, managing, and deleting operating system and application objects. In the multiuser environment of Terminal Server each session must keep its objects separate from those of the other sessions. To keep them separate, Terminal Server appends the Session ID onto the end of each object that is created within the session.\ Using the query object Terminal Server command, you can actually see this process in action. The query object command shows you a list of all current objects on the system. The list is usually rather long so you may need to dump it to a text file (query object > objects.txt).\ The following output shows two of the many objects in the object list. Note the :1 and 0 that have been appended to the object names. These are the Session IDs of the sessions that these objects belong to. Had Terminal Server not kept these identical object names unique, using the Session ID number, they could not have been created.\ C:> query object\ .....\ \\BaseNamedObjects\\NDDEAgent:1    Semaphore\ \\BaseNamedObjects\\NDDEAgent:0    Semaphore\ ......\ \ Differences in the Win 32 Subsystem\ The Win 32 subsystem mainly handles graphical display requests and other Win 32 API calls for applications running on Terminal Server. On NT Server 4.0, a single instance of this subsystem is created, when the server is first booted, by the Session Manager (smss.exe). This instance handles the graphical display of the NT Server console desktop. Because Terminal Server must keep track of multiple desktops simultaneously, each session created on it must be assigned its own Win 32 subsystem.\ As with the Object Manager, Terminal Server distinguishes the processes running in the different Win 32 subsystems using the Session ID. In this way, Terminal Server is able to keep all of the desktops running on it separate.\ Creating the Separate Win 32 Subsystems\ Much like NT Server 4.0, when Terminal Server first boots, the Session Manager (smss.exe) starts a Win 32 subsystem for the console. Under Terminal Server, the console is always assigned Session ID 0. After the console processes are started, the Terminal Server service (termsrv.exe) instructs the Session Manager to start up two idle instances of the Win 32 subsystem to wait for client connections.\ By going into the Task Manager on your Terminal Server (Ctrl+Alt+Del, Task Manager) and selecting the Processes tab, you can actually view the instances of the Win 32 subsystem that have been loaded (see Figure 3.1). The key user mode process in the Win32 subsystem is the Client Server Run-Time Subsystem process (csrss.exe). The CSRSS handles some of the non-graphical Win 32 API functions. Every instance of CSRSS also starts an instance of the WINLOGON process (winlogon.exe), which is responsible for the initial handling of the client logon. Note in Figure 3.1 that there are multiple instances of the CSRSS and WINLOGON processes and that each is assigned its own Session ID (ID column).\ Differences in the Windows Manager and Graphics Device Interface\ The Windows Manager and Graphics Device Interface (GDI) are the kernel mode portions of the Win 32 subsystem responsible for windows management and the handling of Win 32 API graphics calls. They both run as part of the win32k.sys system file. Because they are both part of the Win 32 subsystem, there is a separate instance of them running for every session.\ The main difference between NT Server 4.0 and Terminal Server is with the GDI. Under NT Server 4.0, the GDI interacts directly with the video display driver for the server console. Suppose you are running Microsoft Paint at the server console. When you draw something in Paint, the Paint program makes a Win 32 API call to display what you are drawing onto the screen. This API call is eventually passed to the GDI. The GDI then instructs the video driver what to display by using standard video driver interface commands.\ Although this technique works fine for server console display on Terminal Server, it does not work for remote terminal sessions. On Terminal Server, the GDI display commands must be packaged and sent across the network for display on the remote terminals. Terminal Server and MetaFrame both handle this through virtual display drivers. Both the RDP and ICA protocols have their own virtual display driver. Each remote session on Terminal Server runs its own instance of one of these drivers. The driver captures the video driver interface commands from the GDI. These commands are packaged up by the protocol and sent across the wire for display on the remote client.\ Differences in the Virtual Memory Manager\ The final major difference between NT Server 4.0 and Terminal Server 4.0 is in the Virtual Memory Manager. The Virtual Memory Manager maps virtual addresses used by processes into actual physical locations in the computer's memory. Each process running on Terminal Server is given up to a 2GB virtual address space within which to work. Because each process's space is kept track of separately, this NT Server 4.0 architectural convention works well with Terminal Server.\ The difference occurs within the 2GB virtual address space used by the operating system itself. Because all processes running on server need access to certain areas of this operating system memory, the processes would conflict in a multiuser environment. The main culprit is actually the kernel mode component (win32k.sys) of the Win 32 subsystem. NT Server 4.0 was designed to run only one instance of this subsystem, which it loaded into the operating system memory space so that processes running on the console could have access to it. Because the arrangement of much of the operating system memory space was fixed, Terminal Server had to use a special technique to run multiple instances of the Win 32 subsystem.\ To solve this problem, Terminal Server assigns each session its own virtual Session Space. Any memory calls to the Win 32 subsystem memory range by a particular session are redirected to that session's Session Space by Terminal Server. This redirection keeps each session's Win 32 subsystem memory separate from that of the other sessions.\ Windows NT Design Goals\ For those who want to know more about Terminal Server architecture, you will note that this section starts at the beginning, with the development of the operating system it is based on. The design goals of the NT operating system are a large part of the reason why NT was originally chosen by Citrix for its multiuser product WinFrame, and why Terminal Server, which evolved from WinFrame, is possible.\ When the development team for Windows NT was first formed in 1989, its mission was to design an operating system to meet the following design goals:\ These design goals were met by using a highly modular architecture. The next section shows how Terminal Server takes advantage of this modularity to work within a multiuser environment....

IOverview of Terminal Server and MetaFrame1Introducing NT Thin Clients32Planning for Terminal Server153Terminal Server Architecture254Terminal Server and MetaFrame41IIInstallation, Configuration, and Administration5Installing Terminal Server and MetaFrame516Creating the Connections777Creating Users and Groups in Terminal Server958Using Logon Scripts1159Installing Clients13310Installing Applications on Terminal Server15911Securing the Server18712Administering the Desktop and Server20713Measuring Performance233IIIReal-World Terminal Server and MetaFrame Solutions14Terminal Server and Remote Access25915Terminal Server and NetWare27916Terminal Server and the Internet29517Terminal Server and Wide Area Networks30718MetaFrame and UNIX Clients32519MetaFrame and Macintosh33920Application Publishing and Load Balancing with MetaFrame349IVAppendixesAThe History of Terminal Server359BWindows-Based Terminal Manufacturers363CDisaster Recovery Kit365DTerminal Server Resources369Index371