Remote Desktop Protocol (RDP)

In this part of the chapter, we describe in more detail how the Remote Desktop Client performs session management and other functions.

Session Connection

When a client initiates a session, the TCP/IP transport driver passes the request to the TERMDD program on the Terminal Server. TERMDD then passes the request to RDPWSX, which in turn signals the Terminal Server service to create a thread to handle the incoming session request. In addition, RDPWSX is responsible for initiating session negotiation with the client and capturing all necessary client information, such as compression, encryption level, client version number, and license details. As each client connection is accepted and assigned an idle SessionSpace, a new idle session is created. The session manager also executes the client-server run-time subsystem process (csrss.exe), and a new SessionID is assigned to that process. The CSRSS process then invokes the Windows Logon (winlogon.exe) and the graphic device interface (GDI) module (win32k.sys) to render the initial logon screen information and present it to the particular user SessionID, as shown in Figure 2-3.

Figure 2-3: The connection process in an RDP session

Note

For use under heavy session logon activity, a registry setting can increase the two idle session numbers. The values are contained in the following key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\IdleWinstationCount\.

Network Load Balancing on Session Connections

RDC can utilize Network Load Balancing (NLB), available in Windows Server 2003 Standard, Enterprise, and Datacenter Server Editions, as well as Windows 2000 Advanced Server and Datacenter Server. NLB utilizes a round-robin approach for session connectivity to multiple Terminal Servers. NLB can detect downed servers, thus sending a client to one of the remaining live servers, and effectively eliminating a single point of failure if one server is down. Note though that this service is not the same as Citrix's load balance service, which utilizes server parameters rather than the network round robin that NLB utilizes. It is the opinion of the authors that NLB is not a sufficient tool for load balancing or effective redundancy in an enterprise server farm environment, but it may be sufficient for smaller environments (less than four servers in the farm).

Session Disconnection

When a user disconnects from an active session without logging off, the GDI stops taking commands from the user by stopping all drawing operations from reaching the display driver. A disconnected desktop object is created and represented in the Terminal Services Manager application (Start Menu | Administrative Tools | Terminal Services Manager), as shown in Figure 2-4.

Figure 2-4: The Terminal Services Manager application showing a disconnected session

During the disconnection timeout period, the RDP stack is unloaded, but TERMDD is still active because win32k.sys maintains an active handle to it for keyboard and mouse control. Before the timeout period expires, the user can be reconnected to the same session. The session disconnect process is shown in Figure 2-5.

Figure 2-5: The disconnection process in an RDP session

Session Reconnection

When a user initiates a connection to the same server, a brand-new connection is created. The RDP stack is loaded, and SessionSpace is assigned. The user is presented with a logon screen. Thus far, the process is identical to a new session connection. However, when WINLOGON scans the user ID and determines that the user has a disconnected session, TERMDD is instructed to perform a session reconnection. The user session is then switched back to the disconnected session.

Data Transmission

RDP packets are formed in the presentation layer of the Open System Interconnect (OSI) model. The packets are encrypted and frames packaged according to the requirements of the network protocol. Currently, only TCP/IP is supported by RDP. The RDP data content may include keyboard input and mouse movement coordinates, as well as graphical bitmaps and printer redirection output. The return RDP packet goes in reverse through the same protocol stack, is decrypted, and unwrapped, and the TCP/IP header information is stripped for the specific client session. Some of the data transmission optimization features of RDP include the following:

• Intelligent encoding The redrawing of graphical images can be encoded to tell the client to redraw changes only since the last refresh took place. In other words, only the changes are sent.

• Glyph and bitmap caching A glyph is a graphical representation of a character. The RDP client automatically reserves a minimum of 1.5MB of memory space to cache the required set of glyphs needed in the display of common text. Bitmaps of different sizes are also cached in memory. Whenever a command is issued from the Terminal Server, the client can redraw the required text and bitmaps very quickly by extracting the elements from cache.

• Bulk compression A client-side option optimizinga low-speed connection will turn on bulk compression, which can reduce the packet count by 50 percent.

Image Display

RDP uses a highly efficient encoding algorithm to encapsulate screen data, similar to the X-Window protocol. Most common or repetitive drawings are sent as a command rather than an actual bitmap. This method greatly reduces the amount of data required to paint a new screen or refresh an old one. Microsoft has published the exact bandwidth requirements to paint a common Windows screen, but lab tests from Mainstream Networks show that RDP 4.0 used up to 40 Kbps on a dial-up connection (with compression). There is a significant improvement in bandwidth utilization on the Windows 2000 version of RDP—version 5.0. These improvements continue with the Remote Desktop Client released with Windows 2003.

RDP updates the screen as follows. A user starts an application, which informs the GDI where and how to draw the application window. The GDI relays the command to the RDP display driver (RDPDD) by way of standard Win32 API calls. This is the same process used in a Windows NT system without Terminal Services, and is similar to the way a print job is rendered. The main API calls sent to RDP include the following:

• TextOut() This call results in the display of text information ona client screen. GDI informs RDP of the location and the glyphs (a graphical representation of a character). RDP tells the client which glyph to cache and which cache entry to use next time the same text is called for.

• PatBlt() Pattern Block Transfer is used by RDP to tell the client how to draw a block of color. This translates into a small command and is the alternative to sending a block of bitmaps and consuming a large amount of bandwidth.

• LineTo() This command allows RDP to tell the client the beginning and ending coordinates of a 3-D beveling line. The line can be used to form boxes. This command can be as small as 6 bytes to complete a line drawing.

Windows 2000 Graphical Enhancements

RDP version 5.0 not only improved the protocol communication efficiency, it also expanded its feature set and offers some of the benefits contained in the ICA protocol.

• Remote control This feature allows an administrator or authorized person to take over the screen, keyboard, and mouse movement of any user session running to the same physical machine.

• Clipboard redirection The RDP version 5.0 protocol synchronizes the server-side application clipboard to the client-side clipboard buffer. This allows applications running on the Terminal Server to cut and paste data to applications running on the client workstation.

• Client printer autocreation Local client COM and LPT ports can be remapped automatically from the server. The local default printer will be created in the Terminal Server session, and print jobs produced by applications running in a server session will be printed on the client's local default printer.

• Bitmap cache Windows 2000 RDP provides additional persistent bitmap cache over version 4.0, which only used RAM cache. Upon successful bitmap transmission, the server instructs the client where to store persistent cache information. When the same data is needed again, only the location coordinate for this bit is sent to the client. This improvement is especially important in low-speed dial-up or wireless WAN connections.

Windows 2000 Terminal Services Client Architecture

Windows 2000 with RDP 5.0

With the introduction of Windows 2000, Microsoft significantly improved the capabilities of the core operation system to have Terminal Services integrated with all server platforms. Enhancements were also made to the RDP client allowing for better performance and additional features. The major advantages to this integration were the availability of standard services packs for Windows and Terminal Services and the requirement for software vendors to address compatibility with the multiuser environment. Between the releases of Windows 2000 Server and Windows Server 2003, Microsoft released Terminal Services Advanced Client (TSAC) which superceded the RDP client that shipped with Windows 2000. The TSAC, is based on the RDP 5.0 feature set, but comes in the form of an ActiveX control. The performance of the TSAC is comparable to the previous client, but offers far more flexibility in its deployment. It can be downloaded and executed within Microsoft Internet Explorer, or any application that can make use of ActiveX controls, such as those written in the Visual Basic or Visual C++ development systems. In addition to the downloadable ActiveX control, it is also available in the form of an MSI (Windows Installer) package, which looks and feels to the end user like the traditional RDP 5.0 client. Finally, the client is also available as an MMC snap-in, for administrators to use to assist with server administration.

Windows 2003 and RDC

Microsoft continues to improve functionality with the release of Windows Server 2003. The additional features of Windows Server 2003 allow integrated detailed control of security in a Terminal Services environment that previously were left to the creativity of the administrator and third-party applications. Remote Desktop Client (RDC) provides for better performance with streaming video, security, and client resource availability, and is now ported to the Mac OS X platform.

RDC using RDP now supports the following four operating system platforms:

• The Win32 platform, which includes Windows XP, Windows 2000, Windows NT, Windows 95, 98, and Windows Millennium (available for download at http://www.microsoft.com/windowsxp/remotedesktop/)

• The Win16 platform, which includes Windows and Windows for Workgroups 3.11

• The WinCE platform, which includes many new thin-client devices with WinCE running as the embedded operating system

• A Macintosh Remote Desktop Client (RDC) for MAC OS X (available for download at http://www.microsoft.com/mac/download/misc/rdc.asp)

Microsoft's design goals for RDC are to minimize bandwidth utilization, minimize memory usage, and speed up screen transmission. RDC represents a striking improvement over both RDP version 4.0 and RDP version 5.0 in both speed and features.

Table 2-2 shows a comparison of some of the major features of RDP and RDC.

Table 2-2: RDP Version 5.0 vs. RDC

Feature	Description	RDP 5.0	RDC for Windows 2003 and Windows XP
Clients	32-bit clients for Windows 95, 98, NT, 2000 and 2003	Yes	Yes
	16-bit client for Windows 3.11	Yes	Yes
	Windows CE-based clients	Yes	Yes
	Browser client	With TSAC	With TSAC
Transport protocol	TCP/IP	Yes	Yes
Audio	System beeps	Yes	Yes
Print stream compression	Compression of print jobs executed in a Terminal Services session	No	Yes
Terminal Services: slow link performance optimizations	Improved performance of high latency and slow throughput connections	No	Yes
Local printer redirection	Print to client-attached printer	Yes	Yes
Local drive mapping	Local client drive access from session	Yes	Yes
Cut and paste	Cut and paste between server session and client session	Yes	Yes
Remote control	Remote viewing and control of a session	Yes	Yes
Bitmap caching	Bitmap caching in memory	Yes	Yes
	Bitmap caching to disk	Yes	Yes
Time zone redirection	Remote client clock shows correct time, regardless of whether client is in different time zone from Terminal Server	No	Yes
Macintosh client	Client for Mac OS X	No	Yes
Preconfigured client	Predefined client with IP address, server name, and connection information	Yes	Yes

RDP Client Software Architecture

The RDP client software is installed on the server under the directory %systemroot%\system32\clients\tsclient. The client disk creator program under Start | program | Administrative tools | Terminal Server Client Creator will make the necessary disk set for distribution to client PCs.

When the Terminal Server client starts, the user interface calls the core API to set up a session with a server name or IP address. The default TCP/IP port is set to 3389. The security layer in turn calls the network layer to set up a socket with the goal of establishing a connection to the server. Once the TCP/IP connection is set up, the security layer starts to negotiate an encryption level with the server. Then the core protocol will negotiate bitmap cache, printer, and COM port redirection. Upon successful negotiation, an active session is launched, and the user is presented with the Windows logon screen. It is important to note that if the traffic is passing through a firewall, port 3389 must be open outbound from the client and inbound to the server.

Client Caching Client cache is negotiated during session setup. By default, 1.5MB of RAM is set aside for bitmap caching. In addition, the RDC sets up persistent caching to improve communication speed over slow links. When a bitmap is to be sent to the client, the RDP device driver (RDPDD) compresses the bitmap image, then sends the bitmap across the network. RDPDD also instructs the client regarding which cache cell to store the bitmap in. When the client requests the same bitmap again, the server simply sends the cache cell reference number to the client.

The RDP client employs yet another technique to make use of screen cache in a remote control session. Windows drop-down menus make up much of the display. Most frequently used menus are cached in RAM when activated for the first time. Additional clicking on the same menu display will retrieve the screen cache from RAM rather then retrieving it over the network.

Remote Desktop Client Encryption RDC supports three levels of encryption: low, medium, and high. Low-level encryption uses a 40-bit algorithm on client data being sent to the server. Medium-level encryption uses a 56-bit algorithm to encrypt data flow in both directions. Finally, high-level encryption uses a 128-bit RC4 two-way algorithm on both client and server. Terminal Services configuration on the server determines the lowest level of encryption allowed. For example, if the server enforces high-level 128-bit encryption, then only a 128-bit encryption client can connect to the server. However, if the server only requires 40-bit encryption, then 128-bit, 56-bit and 40-bit clients are all able to connect.

Remote Desktop Client Remote Control Microsoft introduced remote control first in RDP version 5.0 with Windows 2000, and has continued to enhance it with RDC and Windows Server 2003. Remote control allows administrators to view and take control of another user's session running on the same server. By setting special permissions in the Terminal Services Configuration/Connections (TSCC), help desk personnel can use the remote control feature to assist users by taking over their screen. To use the Terminal Services Manager (Start Menu | Administrative Tools | Terminal Services Manager), highlight the desired user, and click the Remote Control option. The screen resolution and color depth of the shadowing session needs to be equal to, or higher than, the shadowed session.

Tip

Remote control in Windows Server 2003, unlike in Windows 2000, can now take over the server console session.

In a shadowed session connection, TERMDD establishes a shadow pipe in which RDP packets are sent to both the shadowing and the shadowed sessions, as shown in Figure 2-6. In this way, input is accepted from both sessions, and results are returned to both sessions.

Figure 2-6: Remote Desktop Client remote control process

Note

If an administrator wants to remotely control a session from the server console, an RDP virtual session must be launched first, using the Terminal Services server as the "client." From inside the virtual client session, the administrator can then take remote control of a session.

Remote Desktop Client Session Administration The Terminal Services Configuration/Connections (TSCC) program can be used to control inactivity timeouts (when no activity is seen from the keyboard or mouse for a set amount of time). The same interface can also automatically reset a disconnected session when the disconnect timeout value expires. By default, these two values are not set. This means no timeout will be triggered when a user leaves the client session unattended or the session is otherwise disconnected. For security reasons, and to conserve server resources, we strongly recommend that a reasonable value be set for both of these parameters, as shown in Figure 2-7. A new feature with the Remote Desktop Client is session directory, which, when used in conjunction with the Network Load Balancing on a Terminal Server farm, allows users to reconnect to the specific disconnected session they've left within a farm, rather than just being directed to the next available server when they reconnect.

Figure 2-7: Setting timeout values for RDP sessions

Note

The systemwide session control in Figure 2-7 has the Active session timeout set for Never, the disconnection timeout set for 30 minutes, and the idle timeout set for two hours. These settings should be sufficient for most disconnect situations. Any adjustments of these values should be made according to company policy and user behavior. Generally, we do not recommend setting an active session timeout, as this will disconnect users who may be working.

For the settings in Figure 2-7, if a session detects no keyboard or mouse input for two hours, the session is disconnected. In this case, a user needs to log on to the system again to connect to the suspended session, and no data loss is likely. If a user fails to log on within 30 minutes after the two-hour inactivity timeout however, the system will reset the disconnected session, and any data not saved will be lost.

New Features for Terminal Services in Windows Server 2003

The Terminal Services component of Microsoft Windows Server 2003 builds on the solid foundation provided by the application server mode in Windows 2000 Terminal Services, and includes the new client and protocol capabilities of Windows XP.

Table 2-3 lists the new features and benefits provided by Windows Server 2003.

Table 2-3: Windows Server 2003 New Features and Benefits

Terminal Services licensing model and management improvements	Support has been added for the new user-based license model (device-based licensing and a hybrid approach utilizing both user- and device-based licensing are also supported). Additionally, improvements have been made to the Terminal Services License Manager Wizard, including a new Internet connection method for activating licenses, new error messages, and a new method for handling reactivation of upgraded Windows 2000 license Terminal Services.
Printers	All printers installed on the client are visible to the server—including network printers. With Windows 2000 Terminal Services, only locally connected printers were redirected. Redirected printers are given names that are easier to read. For example, users might see "printername on printserver (from clientname) in session 9"; whereas in Windows 2000, they would have seen "_printserver_printername/clientname/Session 9." Printer redirection also works when connecting to Windows 2000-based servers. Printer driver mapping has been enhanced to provide better matching in near-miss cases. When a driver match cannot be made, the Trusted Driver Path lets you specify other standard printer drivers that you sanction on your Terminal Servers. The print stream is compressed for better slow-link performance between a server and client.
Client error messages	More than 40 new client error messages make it easier to diagnose client connection problems.
Security enhancements	The Terminal Server access model now conforms better to Windows server management paradigms.
Software restriction policies	Software restriction policies in Windows Server 2003 enable administrators to use group policies to simplify locking down Terminal Servers (and any other Windows Server 2003-based computer) by only allowing certain programs to be run by specified users. This built-in Windows feature replaces the AppSec (Application Security) tool used in previous versions of Terminal Services.
Session directory	Terminal servers can be organized into "farms." This configuration allows clusters of load-balanced computers to appear to their users as a fault-tolerant service. The new Session Directory feature in Terminal Services allows users to reconnect to the specific disconnected session they've left within a farm, rather than just being directed to the next available server when they reconnect. Session Directory can use the Windows Network Load Balancing Service, or a third-party load balancer, and the service can run on any Windows Server 2003-based computer. However, members of the Terminal Server farm must be running Windows Server 2003, Enterprise Edition.
FIPS compliance	An additional encryption level, labeled "FIPS Compliant," has been added to Terminal Server in Windows Server 2003. This level of security encrypts data sent from the client to the server, and from the server to the client, with the Federal Information Processing Standard (FIPS) encryption algorithms using Microsoft cryptographic modules. This new level of encryption is designed to provide compliance for organizations that require systems to be compliant with FIPS 140–1 (1994) and FIPS 140–2 (2001) standards for Security Requirements for Cryptographic Modules.
128-bit encryption	By default, connections to Terminal Servers are secured by 128-bit, bi-directional RC4 encryption—when used with a client that supports 128-bit. (RDC is 128-bit by default.) It is possible to connect with older clients using encryption lower than 128-bit, unless it is specified that only high-encryption clients are allowed.
Single session policy	Configuring the single session policy lets an administrator limit users to a single session, regardless of whether it is active or not—even across a farm of servers.
Terminal Services Manager	An improved Terminal Services Manager allows for easier management of larger arrays of servers, by reducing automatic server enumeration. This gives direct access to arbitrary servers by name, and provides for a list of favorite servers.
Slow link performance optimizations	Terminal Services optimized slow-link performance allows terminal client users to specify, via their user interface, the type of connection that exists between the client computer and the server. Based on this selection, Terminal Server dynamically adjusts desktop features to deliver the best possible user experience over the chosen network connection speed. This improves the remote desktop user experience over a variety of network connection speeds. The four options for network connection speeds are modem (56 Kbps, 28.8 Kbps), broadband (128 Kbps to 1.5 Mbps), LAN (10 Mbps or higher), and custom. The custom setting allows users maximum flexibility over what desktop features are disabled. These optimizations apply only when the user is connected remotely at sub-LAN connection speeds. At all other times, the computer has the full-featured desktop functionality. Clients running the following operating systems may utilize this feature: Windows XP, Windows 2000, Windows 95, Windows 98, Windows Me, and Windows CE.
Time zone redirection	This feature allows a remote desktop session's time zone to be specified by the client computer's time zone. For example, an IT administrator who has deployed Terminal Services for a particular group of users located in several locations around the world can use Group Policy and Windows Management Instrumentation (WMI) on the server to turn on time zone redirection. This allows end users of Terminal Services to utilize their computer's local time zone rather than the time zone of the Terminal Services server. Clients currently capable of time zone redirection include Windows XP and Windows CE (Version 5.1).
Smart card sign-on	A smart card that contains Windows logon credentials can provide those credentials to a Windows Server 2003 remote session for logon. This feature requires a client OS that can recognize the smart card first: Windows 2000, Windows XP, and Windows CE .NET.
Ports	Client serial ports can be mounted to the server. This enables a variety of hardware on the client computer to be accessed by software on the server.
File system	Client drives, including network drives, are mounted inside the server session. This lets users open or save files on their own computers' disk drives, in addition to opening and saving files on the server.
Integration with Active Directory Services Interface	This feature provides the ability to script Terminal Services user configuration settings using the Active Directory Services Interface (ADSI). For instance, an IT administrator who upgrades a domain from Windows NT 4.0 to Windows Server 2003 can use ADSI to script the creation of user accounts within Active Directory and copy all user properties, including Terminal Services user configuration information.