Terminal Server Walkthrough: Startup, Connection, and Application

This article describes the initialization process of a Terminal Server anddescribes what occurs when a user connects to the server and runs anapplication.
More information

Windows Terminal Server Initialization

As the Windows Terminal Server boots and loads the core operating system,the Terminal Server service (Termsrv.exe) is started and creates listeningstacks (one per protocol and transport pair) that listen for incomingconnections. Each connection is given a unique session identifier or"SessionID" to represent an individual session to the Terminal Server. Eachprocess created within a session is "tagged" with the associated SessionIDto differentiate its namespace from any other connection's namespace.

The console (Terminal Server keyboard, mouse, and video) session is alwaysthe first to load, and is treated as a special-case client connection andassigned SessionID. The console session starts as a normal Windows NTsystem session with the configured Windows NT display, mouse, and keyboarddrivers loaded.

The Terminal Server service then calls the Windows NT Session Manager(Smss.exe) to create two (default = 2) idle client sessions (after creatingthe console session) that await client connections. To create the idlesessions, the Session Manager executes the Windows NT-based client/serverruntime subsystem process (Csrss.exe), and a new SessionID is assigned tothat process. The CSRSS process will also invoke the Winlogon(Winlogon.exe) process and the Win32k.sys (Window Manager and graphicsdevice interface - GDI) kernel module under the newly associated SessionID.The modified Windows NT image loader will recognize this Win32k.sys as aSessionSpace-loadable image by a predefined bit set in the image header. Itwill then relocate the code portion of the image into physical memory, withpointers from the virtual kernel address space for that session, ifWin32k.sys has not already been loaded. By design, it will always attach toa previously loaded image's code (Win32k.sys) if one already exists inmemory. For example, from any active application or session.

The data (or non-shared) section of this image will then be allocated tothe new session from a newly created SessionSpace pageable kernel memorysection. Unlike the console session, Terminal Server Client sessions areconfigured to load separate drivers for the display, keyboard, and mouse.

The new display driver is the Remote Desktop Protocol (RDP) display deviceDriver, Tsharedd.dll. The mouse and keyboard drivers communicate into thestack through the multiple instance stack manager, termdd.sys. Termdd.syswill send the messages for mouse and keyboard activity to and from the RDPdriver, Wdtshare.sys. These drivers allow the RDP client session to beremotely available and interactive. Finally, Terminal Server will alsoinvoke a connection listener thread for the RDP protocol, again managed bythe multiple instance stack manager (Termdd.sys), which listens for RDPclient connections on TCP port number 3389.

At this point, the CSRSS process exists under its own SessionID namespace,with its data instantiated per process as necessary. Any processes createdfrom within this SessionID will execute within the SessionSpace of theCSRSS process automatically. This prevents processes with differentSessionIDs from accessing another session's data.

Client Connection

The RDP client can be installed and run on any Windows-based terminal(based on WinCE), Windows for Workgroups 3.11 running TCP/IP-32b, or theMicrosoft Win32 API-based platform. Non-Windows-based clients are supportedby the Citrix Metaframe add-on. The Windows for Workgroups RDP client'sexecutable file is approximately 70 KB in size, uses a 300 KB working set,and uses 100 KB for display data. The Win32-based client is approximately130 KB in size, uses a 300 KB working set and 100 KB for display data.

The client will initiate a connection to the Terminal Server through TCPport 3389. The Terminal Server RDP listener thread will detect the sessionrequest, and create a new RDP stack instance to handle the new sessionrequest. The listener thread will hand over the incoming session to the newRDP stack instance and continue listening on TCP port 3389 for furtherconnection attempts. Each RDP stack is created as the client sessions areconnected to handle negotiation of session configuration details. The firstdetails will be to establish an encryption level for the session. TheTerminal Server will initially support three encryption levels: low,medium, and high.

Low encryption will encrypt only packets being sent from the client to theTerminal Server. This "input only" encryption is to protect the input ofsensitive data, such as a user's password. Medium encryption will encryptoutgoing packets from the client the same as low-level encryption, but willalso encrypt all display packets being returned to the client from theTerminal Server. This method of encryption secures sensitive data, as ittravels over the network to be displayed on a remote screen. Both low andmedium encryption use the Microsoft-RC4 algorithm (modified RC4 algorithmwith improved performance) with a 40-bit key. High encryption will encryptpackets in both directions, to and from the client, but will use theindustry standard RC4 encryption algorithm, again with a 40-bit key. A non-export version of Windows NT Terminal Server will provide 128-bit high-level RC4 encryption.

A font exchange will occur between the client and server to determine whichcommon system fonts are installed. The client will notify the TerminalServer of all installed system fonts, to enable faster rendering of textduring an RDP session. When the Terminal Server knows what fonts the clienthas available, you can save network bandwidth by passing compressed fontand Unicode character strings, rather than larger bitmaps, to the client.

By default, all clients reserve 1.5 MB of memory for a bitmap cache that isused to cache bitmaps, such as icons, toolbars, cursors, and so on, but isnot used to hold Unicode strings. The cache is tunable (through a registrykey) and overwritten using a Least Recently Used (LRU) algorithm. TheTerminal Server also contains buffers to enable flow-controlled passing ofscreen refreshes to clients, rather than a constant bitstream. When userinteraction at the client is high, the buffer is flushed at approximately20 times per second. During idle time, or when there is no userinteraction, the buffer is slowed to only flush 10 times per second. Youcan tune all these numbers through the registry.

After session details have been negotiated, the server RDP stack instancefor this connection will be mapped to an existing idle Win32k user session,and the user will be prompted with the Windows NT logon screen. Ifautologon is configured, the encrypted username and password will be passedto the Terminal Server, and logon will proceed. If no idle Win32k sessionscurrently exist, the Terminal Server service will call the Session Manager(SMSS) to create a new user space for the new session. Much of the Win32kuser session is utilizing shared code and will load noticeably faster afterone instance has previously loaded.

After the user types a username and password, packets are sent encrypted tothe Terminal Server. The Winlogon process then performs the necessaryaccount authentication to ensure that the user has privilege to log on andpasses the user's domain and username to the Terminal Server service, whichmaintains a domain/username SessionID list. If a SessionID is alreadyassociated with this user (for example, a disconnected session exists), thecurrently active session stack is simply attached to the old session. Thetemporary Win32 session used for the initial logon is then deleted.Otherwise the connection proceeds as normal and the Terminal Server servicecreates a new domain/username SessionID mapping. If for some reason morethan one session is active for this user, the list of sessions is displayedand the user decides which one to select for reconnection.

Running an Application

After user logon, the desktop (or application if in single-applicationmode) is displayed for the user. When the user selects a 32-bit applicationto run, the mouse commands are passed to the Terminal Server, whichlaunches the selected application into a new virtual memory space (2-GBapplication, 2-GB kernel). All processes on the Terminal Server will sharecode in kernel and user modes wherever possible. To achieve the sharing ofcode between processes, the Windows NT Virtual Memory (VM) manager usescopy-on-write page protection. When multiple processes want to read andwrite the same memory contents, the VM manager will assign copy-on-writepage protection to the memory region. The processes (Sessions) will use thesame memory contents until a write operation is performed, at which timethe VM manager will copy the physical page frame to another location,update the process's virtual address to point to the new page location andnow mark the page as read/write. Copy-on-write is extremely useful andefficient for applications running on a Terminal Server.

When a Win32-based application such as Microsoft Word is loaded intophysical memory by one process (Session) it is marked as copy-on-write.When new processes (Sessions) also invoke Word, the image loader will justpoint the new processes (Sessions) to the existing copy because theapplication is already loaded in memory. When buffers and user-specificdata is required (for example, saving to a file), the necessary pages willbe copied into a new physical memory location and marked as read/write forthe individual process (Session). The VM manager will protect this memoryspace from other processes. Most of an application, however, is shareablecode and will only have a single instance of code in physical memory nomatter how many times it is run.

It is preferable (although not necessary) to run 32-bit applications in aTerminal Server environment. The 32-bit applications (Win32) will allowsharing of code and run more efficiently in multi-user sessions. Windows NTallows 16-bit applications (Win16) to run in a Win32 environment bycreating a virtual MS-DOS-based computer (VDM) for each Win16 applicationto execute. All 16-bit output is translated into Win32 calls, which performthe necessary actions. Because Win16 apps are executing within their ownVDM, code cannot be shared between applications in multiple sessions.Translation between Win16 and Win32 calls also consumes system resources.Running Win16 applications in a Terminal Server environment can potentiallyconsume twice the resources than a comparable Win32-based application will.

Session Disconnect and User Logoff

Session Disconnect

If a user decides to disconnect the session, the processes and all virtualmemory space will remain and be paged off to the physical disk, if physicalmemory is required for other processes. Because the Terminal Server keeps amapping of domain/username and its associated SessionID, when the same userreconnects, the existing session will be loaded and made available again.An additional benefit of RDP is that it is able to change session screenresolutions, depending on what the user requests for the session. Forexample, suppose a user had previously connected to a Terminal Serversession at 800 x 600 resolution and disconnected. If the user then moves toa different computer that supports only 640 x 480 resolution, andreconnects to the existing session, the desktop will be redrawn to supportthe new resolution.

User Logoff

Logoff is typically very simple to implement. After a user logs off fromthe session, all processes associated with the SessionID are terminated,and any memory allocated to the session is released. If the user is runninga 32-bit application such as Microsoft Word, and logs off from the session,the code of the application itself would remain in memory until the verylast user exited from the application.

Article ID: 186572 - Last Review: 06/22/2014 18:59:00 - Revision: 3.0

  • kbinfo KB186572