Windows Terminal Services

The Terminal Services Family
Microsoft Windows 2000 and 2003 Terminal Services allow multiple users to log on to a Windows 2000 or Windows 2003 server, have their own desktop environment, and execute programs that stay resident. User logons effectively get their own protected memory space for applications and data. Users can have a Windows desktop and run Windows- based applications without the need to load the applications on their local PC. A server running Terminal Services can host hundreds of concurrent users (the specifics of server sizing will be covered in later chapters). In this chapter, we will use the generic term Terminal Server to refer to a server running Windows 2000 Server or Windows Server 2003 with Terminal Services enabled.

The client computing device used to communicate with the Terminal Server can be a PC or a specially designed terminal made to work with the Terminal Server display protocol. The PC or terminal runs a relatively small program that enables a logon and accepts redirected screen output from the Terminal Server. The Microsoft Terminal Services client program relies on a protocol originally developed for Microsoft's NetMeeting, called Remote Desktop Protocol (RDP). RDP is based on the International Telecommunications Union's (ITU) T.120 protocol. The T.120 protocol is a standard multichannel conferencing protocol that is tuned for enterprise environments and supports session encryption.

Terminal Services History—It Started with Windows NT 4.0 Server, Terminal Server Edition
Microsoft's Windows NT 4.0 Server, TSE, was the implementation of Citrix MultiWin (which will be discussed in Chapter 3) on the Windows NT 4.0 Server platform. Although Windows NT 4.0 is no longer officially supported by Microsoft or Citrix, it is worth discussing the beginnings of Terminal Services technology to further understand where it is today. For those still running Windows NT 4.0 TSE, we strongly recommend upgrading to Windows 2003 (see the upcoming "Windows 2003 Server" section for justification). If support for 16-bit applications is required, NT 4.0 Terminal Services Edition (TSE) is still necessary, as Windows 2000 and 2003 do not effectively support 16-bit applications.

Because of the MultiWin-inspired kernel of TSE, users could log on to virtual Windows NT 4.0 sessions with the same desktop and application look and feel of Windows NT 4.0 Workstation. With TSE, Microsoft created a separate code base for the operating system in order to overcome some of the memory management limitations of Windows NT 4.0 Server and to generally tune it for multiuser access.

Microsoft included their Terminal Server client, which is the client portion of the Remote Desktop Protocol, with TSE. This RDP client supported a variety of Windows desktops over TCP/IP networking, including Windows 95 and 98, Windows CE, Windows NT Workstation, Windows 2000, and Windows XP.

TSE Internals
In order to achieve the multiuser capabilities required in TSE, the Citrix MultiWin technology needed to be integrated into the Windows NT 4.0 Server kernel. This integration meant that several components, services, and drivers were added or modified in the original Windows NT 4.0 Server core operating system. Windows NT 4.0 components such as the Virtual Memory Manager (VMM) and Object Manager (OM) were modified to perform in a multiuser environment.

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

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


The Windows NT 4.0 Terminal Server made all objects required for multiuser capability virtual so that the applications and system programs from different user sessions do not collide. Every object name created within a session is appended with a unique identifier number associated with the individual user session (SessionID) that created it. For example, if a user started an application in the first session on the Terminal Server, the session would be seen as session1 and the application seen as application1, as shown in Figure 2-1.


Figure 2-1: Execution of a multiuser Windows application
The Remote Desktop Protocol was designed to support TCP/IP over LAN or WAN communication links. Due to the multisession nature of the protocol, a special user mode extension (RDPWSX), as depicted in Figure 2-2, is needed to receive all incoming client packets. RDPWSX manages sessions and calls WINLOGON to authenticate them. In addition, RDPWSX will validate the client license with the license server and negotiate client-server encryption keys.


Figure 2-2: An RDP session
Upon successfully establishing a session, the MultiWin subsystem gained control over session management. A virtual session was created by localizing a copy of WIN32K.SYS with all the necessary device drivers. The TERMDD (Terminal Server Device Driver) then provided the run-time environment of a session-specific protocol driver in order to service multiple client session requests. To support the mouse and keyboard commands sent to each session's copy of the WIN32K.SYS subsystem, the RDPWD (Remote Desktop Winstation Driver) was loaded.

The console session was always the first to load, and was assigned a special client connection ID of 0. The console session launched at system startup with the system-configured Windows NT display, mouse, and keyboard drivers loaded. The Terminal Server service contacted the Windows NT session manager (SMSS.EXE) and loaded the RDP user mode protocol extension RDPWSX to create two idle client sessions right after the creation of the console session. These two idle sessions listened on TCP service port 3389 for RDP protocol packets from the client.

Code Sharing Terminal Server also implemented memory code sharing (also known as Copy on-Write Page Protection). This feature allowed one copy of executable code, such as Microsoft Word, to be loaded into physical memory, and to have multiple users run the same copy of the program code. If a user loaded a private copy of a Word document, a separate memory space would be set aside and marked as read/write under the protection of Virtual Memory Manager. No other process could access this private memory space. This was extremely useful and efficient when a large number of users were using the same programs.

Note Code sharing cannot be utilized in 16-bit applications, since they need to run inside a separate DOS VDM (Virtual Dos Machine). For this reason, approximately 20 percent more memory is used by 16-bit and DOS applications than by comparable 32-bit applications. In order to properly size the RAM requirement in TSE, a live functional test should be conducted to observe the total working set of memory consumed by a specific application, because many 32-bit applications contain 16-bit code.


Windows 2000 Terminal Services
In Windows 2000 Terminal Services, SessionSpace remains. The layout on the memory map has been modified to further tune the system and enable a common layout for all Windows 2000 systems, whether or not Terminal Services has been installed. The main modification is that SessionSpace has been reduced to 60MB and starts at the memory address location A0000000. Moving SessionSpace up to A0000000 allows all system drivers (win32k.sys), video drivers, and printer drivers to be loaded in a common virtual address location, whether they are accessed through a Terminal Services session or on a session without Terminal Services. Microsoft redesigned the memory mapping to eliminate the need for a separate version of the operating system to support Terminal Services, as was necessary with Windows NT 4.0 Server and TSE. Among other obvious advantages, service packs for Terminal Services no longer lag behind those for the base operating system as they did with TSE.

A new Windows 2000 service, appropriately called Terminal Services (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 ICA from Citrix.

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 session protocol (for example, RDP and ICA) has its own protocol extension, providing a variety of services.

Note For RDP, this user mode extension is called wsxtshar.dll.


Windows 2003 Server
Windows Server 2003 is now the flagship product for Terminal Services. Packaged with the release of Windows Server 2003 is a new client connection program. The new Terminal Services client, first released with Windows XP, is called Remote Desktop Connection (RDC) and provides substantial improvements over previous releases, including greater functionality through a simplified user interface. RDC can also be used to connect to a Windows XP Professional-based computer running Remote Desktop, and can be used to connect to previous versions of Terminal Services (Windows NT 4—Terminal Server Edition and Windows 2000 Server). RDC utilizes a new version of RDP and a new licensing model that provides for user and device licensing of Terminal Services and NT CAL's rather than just device licensing that had been required (see the "Licensing" section later in this chapter). This licensing change represents a tremendous win for all Windows SBC environments, as it dramatically reduces the costs for environments where users have more than one device they connect from. For example, under the Windows 2000 licensing model, if a user connected to a Terminal Services server or farm from a laptop, desktop, and home computer, Microsoft required the user's organization to purchase three Windows Terminal Services client access licenses and three Windows 2000 Server client access licenses for this one user. Under the new per-user licensing, the organization will only need to purchase one license for that user.

Windows 2003 Editions Comparison
Windows Server 2003 comes in six releases and four named editions; Standard, Enterprise, Datacenter, and Web. The Web edition will run on small-footprint servers. As the name implies, this edition is for web servers only—systems running IIS 6.0 and web applications. This edition will make an excellent and cost-effective platform for web services such as MetaFrame Web Interface and MetaFrame Secure Access Manager, as discussed in Chapter 16.

The Standard edition is the general-purpose version intended for traditional Windows Server tasks such as file and print serving, security, and Terminal Services. This is the server upon which a Citrix MetaFrame XP installation is most likely to be based.

The Enterprise edition is a "hardened" version of the operating system. Microsoft has added a number of features to this edition to increase its value as an application server platform. We envision that this server will be used for three potential purposes: large Terminal Services Farms, clustering, transaction processing, or server consolidation.

Finally, the Datacenter edition is the "big iron" version of the operating system. It is designed for the most demanding application and availability requirements where hardware cost is not a concern. This version requires a minimum of eight CPUs in a system and can run on systems containing up to 32 CPUs. System administrators who covet the chance to work on a Windows "mainframe" will be running this.

As mentioned, there are actually six releases. The additional two are the 64-bit versions of the Enterprise and Datacenter editions designed for the Intel Itanium processor. Because of the emphasis by the Microsoft SQL Server team on 64-bit computing, these releases will be targeted at high-volume database or transaction processing applications, but not much else.

Table 2-1 compares the features of the four named editions.

Table 2-1: Windows 2003 Editions Comparison Feature
Standard Edition
Enterprise Edition
Datacenter Edition
Web Edition

Scalability

64-bit support for Intel Itanium-based computers
+
+

Hot add memory [1], [2]
+
+

Non-Uniform Memory Access (NUMA)[2]
+
+

Datacenter program
+

Maximum RAM Support

2GB
+
+
+
+

4GB
+
+
+

32GB
+
+

64GB [3]
1/2
+

512GB [4]
1/2

Maximum Symmetric Multiprocessing Support (SMP)

2-way
+
+
+
+

4-way
+
+
+

8-way
+
+

32-way
+

64-way
+

Directory Services

Active Directory
+
+
+
1/2

Metadirectory Services (MMS)
+
+

support

Security Services

Internet connection firewall
+
+
+

Public Key Infrastructure, certificate services, and smart cards
1/2
+
+
1/2

Terminal Services

Remote Desktop for Administration
+
+
+
+

Terminal Server
+
+
+


Terminal Server Session Directory
+
+

Clustering Technologies

Network load balancing
+
+
+
+

Cluster service
+
+

Communications and Networking Services

Virtual private network (VPN) support
+
+
+
1/2

Internet Authentication Service (IAS)
+
+
+

Network bridge
+
+
+

Internet Connection Sharing (ICS)
+
+

IPv6
+
+
+
+

File and Print Services

Distributed File System (Dfs)
+
+
+
+

Encrypting File System (EFS)
+
+
+
+

Shadow Copy Restore
+
+
+
+

Removable and remote storage
+
+
+

Fax service
+
+
+

Services for Macintosh
+
+
+

Management Services

IntelliMirror
+
+
+
1/2

Group policy results
+
+
+
1/2

Windows Management Instrumentation (WMI) command line
+
+
+
+

Remote OS installation
+
+
+
+

Remote Installation Services (RIS)
+
+
+

Windows System Resource Manager (WSRM)
+
+


.NET Application Services

.NET Framework[1]
+
+
+
+

Internet Information Services (IIS) 6.0
+
+
+
+

ASP.NET[1]
+
+
+
+

Enterprise UDDI services
+
+
+

Multimedia Services

Windows Media Services
+
+
+

Key: + = Feature included 1/2 = Feature partially supported

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.

Terminal Services in the Enterprise
In this part of the chapter, we discuss some issues that will likely be encountered when adding Terminal Services to an enterprise organization.

Domain Considerations
The standard principles for installing a Terminal Server apply equally to Windows 2000 and Windows 2003 Terminal Services. If Active Directory is installed on the network, simply join the Active Directory domain. There is no longer a primary domain controller (PDC) or backup domain controller (BDC) in Active Directory setup. For legacy support, a PDC Emulator will be created in the Windows 2000 domain controller when a Windows NT Domain client attempts to log on. Therefore, it is possible to mix TSE servers with Windows 2000 and Windows 2003 servers running Terminal Services.


Migrating to Windows Server 2000 or Windows 2003 Server from an Existing Windows NT 4.0 PDC
If a Windows 2003 server is installed in an existing network that employs backup domain controllers, the new Windows 2003 server operates as a "mixed mode" domain controller. In this case, the Windows 2003 DC will be migrated first to Active Directory and will emulate a Windows NT 4.0 PDC. The old PDC-to-BDC security database synchronization will continue until all BDCs are migrated to Active Directory and "mixed mode" has been switched to "native mode."

Application Considerations
Most applications are written to run on a single-session platform such as Windows 95, 98, or Windows NT Workstation with a single user. Terminal Services requires significant changes to be made to the kernel and operating system to accommodate multiuser access. Because of these changes, both programmers and administrators must fully understand the issues and possible solutions in order to configure the system so that single-session applications can be executed in a multisession environment. We discuss some of the problems and possible solutions in this section.

Terminal Services makes special demands on how an application is written and how the application uses the Windows NT operating system. The Windows NT Registry is used by many programs to store variables during an installation, changes while the program executes, and changes that normally occur when users with differing logons access the application. On a typical Windows 2000 Professional workstation, an application may put data into the HKEY_LOCAL_MACHINE registry hive, assuming only one user will access the application at a time. On Terminal Server, this could prove disastrous, as changes to this registry hive would affect all users of this Terminal Server, not just the user executing the application making the change.

Many problems occur with applications that store local data constructs in global locations. In addition to separating global and local information in the registry, global and local file-based data constructs should also be maintained separately. For example, user preference files should not be stored in a main system directory (/%systemroot%) or program directory (\Program Files). Instead, preference files or other user-specific local data should be stored in the user's home directory or a user-specified directory. This consideration also applies to temporary files used to store interim information (such as cached data) or to pass data on to another application. User-specific temporary files must also be stored on a per-user basis.

Some specific issues that may cause an application to fail in a multiuser environment include

Incorrect registry entries Many applications write a global INI file to the system root for user-specific information. Thus, when one user changes or opens the INI file, other users may not be able to access the same file. Some applications add shortcuts to only the installer's menu during installation; because of this, other users may not see the shortcut. Still, many applications point the data files, temporary files, or cache files to the same location for all users. In this situation, only one user can run the application at a time.

Changed object name An object created in a session is named differently. The application may not be able to find the object using the expected name or location.

Incorrect file and object rights access An application normally locates libraries and executables in the Windows NT %SystemRoot% directory. Multiple users accessing the same file may create file-locking problems.

The following are some other application problems and issues to be aware of within a multiuser Terminal Services environment:

Do not assume the computer name, MAC address, or IP address equates to a single user. In the traditional distributed Windows client-server architecture, one user is logged on to one computer at a time. Thus, the computer name or Internet Protocol (IP) address assigned to either a desktop or server computer equates to one user. In the Terminal Services environment, the application can only see the IP or NetBIOS address of the server. Applications that use the computer name or IP address for licensing, or as a means of identifying an iteration of the application on the network will not work properly in the Terminal Services environment because the server's computer name or IP address can equate to many different desktops or users.

MS-DOS and 16-bit Windows applications require more RAM than native 32-bit Windows applications and may not execute at all in Windows 2000 Server or Windows Server 2003. Windows runs an emulation layer called the Virtual DOS Machine (VDM) as a process on the 32-bit operating system. Although this memory requirement may not show up as performance degradation on a high-powered desktop computer running the latest Windows operating system with 64MB of RAM, it may easily show up on a system running Terminal Services due to the multiplier effect of many user sessions.

Multiuser Application Issues
You may encounter several possible issues when running applications under Terminal Services that were not designed to run in a multiuser environment. Some of the most important issues are summarized here. We will discuss these and other application-related issues in more detail in Chapter 13.

Application Compatibility Scripts
Many of the issues discussed so far have been addressed by the creation of application compatibility scripts. After installing an application, an administrator is required to run the corresponding script to resolve the issues mentioned. Windows 2000 shipped with 27 native Application Compatibility Scripts, and since then scores of software manufacturers have created additional scripts to provide users with fixes for their software in a multiuser environment. At the time of this writing, Windows 2003 only has four scripts in the Application Compatibility Scripts folder. Since Microsoft requires an application be multiuser compatible before it can be certified for Windows 2003, our assumption at this time is that a large majority of application vendors have simply included the scripts in their install process, thus alleviating the need for scripts. Obviously there will be some stragglers, so the need for Application Compatibility Scripts will continue for the foreseeable future. Application compatibility scripts are located in the %SystemRoot%\Application Compatibility Scripts\Install folder.

DOS and 16-Bit Windows Programs
After over eight years of Microsoft operating system support for 32-bit applications, it seems logical that all application vendors would have completed their software porting to take advantage of the speed, stability and interface changes. Win32 allows code sharing and thus runs more efficiently in a multiuser environment. If additional users need to access the same Win32 application code, a pointer is created that shares the same code from the original copy loaded in the kernel and user modes. Code sharing cuts down the total amount of memory usage when multiplying a large number of sessions. On the other hand, 16-bit Windows and DOS applications need to run in their own VDM, and so no code sharing is possible. Also, Win16 applications often require 16- to 32-bit conversion programs ("thunking" and "context switching") that increase resource utilization even further. Even with all of these obvious advantages, and nearly ten years to get it done, there are still a few poorly run software vendors who have not ported their software to a 32-bit code. We highly recommend running only 32-bit Windows applications whenever possible, even if it requires a large investment in moving to another vendor. Because Windows 2000 and 2003 are not well suited for DOS or 16-bit application support (although there are some instances where it works), if 16-bit or DOS applications are required, consider dedicating a Windows NT 4.0 TSE server to those applications, while building the rest of the farm around Windows Server 2003.

Effective Use of the Registry
In a multiuser environment, applications should store common information pertaining to systemwide operation in the HKEY_LOCAL_MACHINE section of the registry. Such information includes the path used to load application components, and what components are needed during execution. User-specific information, such as the locations of custom dictionaries (custom.dic) and user templates (normal.dot), should be stored in HKEY_CURRENT_USER. Some applications incorrectly store information meant to be user specific in HKEY_LOCAL_MACHINE.

Application compatibility scripts, Group Policies, and user profiles can all address an unused drive letter to the home directory of each user. REG.INI then changes pointers to this drive to each user's home directory environment variable. In this way, each user gets her own copy of an initialization file.

Tip A utility in the Exchange Server Resource Kit, named profgen.exe, resolves common pointer issues arising from users trying to open the same e-mail post office box when a mandatory profile is used. This utility can be useful when enabling many users running Terminal Services to access the same Exchange server.


Application Install and Execute Modes
During installation, an application writes user-specific keys to the Administrator's HKEY_CURRENT_USER registry hive. Information such as Document Path and Autosave Path are missing from other users' HKEY_CURRENT_USER keys because they did not install the application. These keys are crucial in successfully using the application. Terminal Services provides a global Install mode to address this situation. During installation, the system is placed under Install mode by entering the command Change User /Install at the command prompt or by using Add/Remove Programs from the Control Panel. All user-specific keys generated by the application under the software hive are shadowed by a key hive in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNt\CurrentVersion\TerminalServer\Install.

This key hive is appropriately called the shadow key. Once installation is completed, the system can be switched back to normal execution mode by entering the command Change User /Execute at the command prompt. In the Execute mode of operation, the shadow key information is written back into each user's software key hive when the system finds that the keys are missing.

The same command addresses missing INI and DLL files in the case of 16-bit applications. These files are copied into each user's Windows directory (normally, %homedrive%\%homepath%\windows). This also applies to 32-bit applications if they use INI files. The %homedrive% and %homepath% variables are both solved when running chkroot.cmd and are replaced simply by %rootdrive%. The files that are copied to C:\WTSRV and C:\WINNT are copied to %rootdrive%\windows when a new user logs in.

User-Specific Application Data
Some settings, such as DocumentPath in the HKEY_CURRENT_USER Microsoft Word subkey, may only be created the first time the application is run. Therefore, the installer must execute the application in global Installation mode right after finishing the initial installation. By doing this, the system will generate these values and record them in the shadow key so that they can later be copied into each user's HKEY_CURRENT_USER registry hive.

Note Logging in as a user and changing settings in an application can cause problems for any user running that application. Making a change while logged in as a normal user on a production machine to store a user's name and initials would cause all future users to see that user's name and initials when they edit documents. Thus it is important to find where these paths are stored and to script or add them to the shadow INSTALL key mentioned earlier so that all users only get the changes the administrator wants them to have.


Sometimes an application creates a path pointer to a common location for all users. For example, the Microsoft Office 97 installation program sets a document template pointer to C:\Program Files\Microsoft Office\Template. When multiple users try to update or open the same file, errors will occur. To address this situation, the administrator needs to search the registry and change the pointer to each user's home folder, such as H:\Office 97\Template, then create the correct directory structure for each user in the logon script %SystemRoot%\System32\usrlogn2.cmd. This file is called by the usrlogon.cmd (if this file does not exist, create it using a text editor) and add the following simple statement to accomplish this task:

IF NOT EXIST H:\OFFICE 97\TEMPLATE MD H:\OFFICE 97\TEMPLATE


Note Most of the Microsoft Office installation issues discussed here have been resolved with Office 2000 and XP, or are easily resolved with the Office Resource Kit. These discussions still serve as an example of how to resolve similar problems with other applications.


A similar problem occurs when all users are directed to use the same cache files. The cache file pointer is set to a common location, such as C:\Temp\Cache. When multiple users attempt to write to the same location, the application will often halt, corrupt the cache, or simply crash the server. Again, the solution is to change the pointer in HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER, then create the corresponding directory structure in each user's home directory to support an individual application cache.

File Security
Applications often store files in the system root directory. Security is normally set to Read-Only for regular users. When a user attempts to write to a file stored in this directory, execution of the application may fail. You can track down the particular file and reassign security to it by using the FILEMON utility (this freeware utility is available from Sysinternals at http://www.sysinternals.com). A better method is to relocate the file to each user's Windows directory.

Registry Security
Many issues arise due to registry security and incorrect use of the registry by legacy applications. REGMON is another tool available at the Sysinternals web site that administrators can use to track down registry keys that have the wrong security.

Application COM/DCOM Objects
The same application may create identical objects for multiple sessions. To separate the same object created by different sessions, a logon ID is appended to each object name. Session objects created in this way are called user global objects and are only visible inside the session in which they were created. If an object is created from the console, there will be no logon ID appended to the object name. This type of object is called a system global object. Because of this distinction, application objects to be used for multiple sessions should be generated as system global objects and installed from the console instead of a user session.

Note Always install software from the console because of the issues mentioned earlier that arise from running applications in a session.


Memory Utilization
Some applications do not return memory to the system upon exit. This situation is exacer-bated in a multiuser environment, and is difficult to track down when a large number of applications and users are involved. Although a nightly reboot with Windows 2000 or Windows 2003 should not be required if the applications are well written, real-world environments typically have at least one rogue application that is poorly authored. Many SBC environments implement a cyclical reboot program in order to clear memory and prevent memory leaks from causing erratic performance and server crashing. The frequency of the reboot depends on how active the memory utilization is. Citrix MetaFrame XPe has a reboot tool, and many of the resource web sites we list in the appendixes have example scripts as well.

DCOM Compliance
Most programs use traditional Open Database Connections (ODBC) to access network objects, such as a data source in a SQL database. To allow a common interface for communication between all system programs (objects) across a network, Microsoft developed the Distributed Component Object Model (DCOM).

In order to be certified by Microsoft as Windows 2000 or Windows 2003 compatible, an application must support DCOM. This ensures that software components can communicate and share functions over a network in an efficient and reusable manner. TSE inherited a subset of DCOM functionality from Windows NT 4.0. Therefore, some applications written for Windows NT 4.0 may not function properly under TSE's multiuser environment. Microsoft has addressed this issue in Windows 2000. All DCOM activation modes are fully supported, as shown in the following:
Run as Activator Local activation is the same whether Terminal Services is enabled or not. The server is activated on the same session as the activator.

Remote Activation When DCOM is activated remotely, the process is launched in a WindowStation with a special SessionID =0, not a session corresponding to the user. This modification preserves the implementation activity of a remote call.

Run as Named User The application is configured in the registry to run as a specified user. Local and remote activation of DCOM behaves in the same way.

Run as Windows NT-Based Service The application is configured to run as a service. This type of service is not tied to any session.

Run as Interactive User The application is configured to run in the security context of the user.

Licensing
Be sure to read all the way through this section, because the "Windows Server 2003 Licensing" section contains some great news that alleviates much of the licensing pain that SBC users have encountered.

In addition to the basic server operating system license required for every installed server, both Terminal Server RDP clients and Citrix ICA clients require two licenses to connect to a Terminal Server session. The first license is the standard Microsoft Client Access License (CAL) for accessing Windows NT files and print services.

The second license required to enable a client connection is a Windows Terminal Services License (TS CAL). If the session client is running on a computer with Windows 2000 Professional or Windows XP Professional when connecting to a Windows 2000 Server farm, it is not necessary to purchase a TS CAL for that client device or user. The server has a "built-in" pool of licenses it can provide to those client machines running Windows 2000 Pro or Windows XP Pro. In the case of Windows Server 2003, there is no "built-in" TS CAL pool. Owners of Windows XP Professional desktop licenses are eligible for free TS CALs, however. (Talk with your licensing provider to receive the free licenses as soon as possible since this offer from Microsoft is limited.) Although Windows NT 4.0 TSE does not enforce licensing, both Windows 2000 Server and Windows Server 2003 arduously enforce licensing of the TS CAL.

Note There is a special provision for an Internet Connector in Windows 2000. This license mode allows 200 anonymous, concurrent users to access Terminal Services on a single server. However, the End User License Agreement specifically states that anyone affiliated with the owner of the license cannot use it (in other words, vendors, customers, employees, contractors, and so on cannot use the license). This rule makes the license restrictive to the point of being useless. Fortunately, the Internet Connector is being replaced as described in the upcoming "Windows Server 2003 Licensing" section.


Windows 2000 Licensing
Windows 2000 enforces the use of the Terminal Services CAL. During any attempt to connect to a session, both the standard CAL and the TS CAL will be checked. If either license is missing or invalid, the connection is refused. If the connection is granted, a temporary or permanent TS CAL is assigned.

Note In a Windows NT Domain with Windows 2000 or Windows Server 2003 member Terminal Servers, Terminal Services licensing must be installed on a Windows 2000 or Windows Server 2003 member. When upgrading the Domain to Windows 2000 Server or Windows Server 2003 Active Directory, licensing must be reinstalled on a Domain Controller (DC). Failing to install Terminal Services licensing and the license codes on the new DC will cause a loss of terminal service capabilities (no license server available).


Windows 2000 Server comes with a license services server that tracks and allocates TS CAL licenses to clients at connection time. The license server needs to be installed on a Windows 2000 server and activated through Microsoft License Clearing House via a web browser, the telephone, or a process called Automatic Activation. When a client requests a connection to a Windows 2000 server, the request is forwarded to the central license server for validation. The license server uses the username and computer name to check for an existing license. If none is available, a new license will be issued to the client, and the connection is completed. If the license pool is exhausted, the connection is refused. A temporary license can be enabled that will expire after 90 days.

The significant issue with this licensing is that if a user connects one time from any device (a trade show kiosk, for example), a TS CAL is allocated (although it is not legitimate from the standpoint of the Microsoft Server 2000 licensing agreement to provide a license to a machine not owned by the person using it). Due to this execution of the licensing, the unclear license language, and technical problems (Microsoft provides no licensing option to deal with devices that aren't owned by the company whose user is using it), many customers found themselves continuously running out of TS licenses. In July of 2002, Microsoft responded to strong user feedback regarding the TS license execution by changing the licensing model slightly (via a hotfix patch) to allow the license server to expire leases after 90 days. To install this patch, install the Service Pack 2 Security Rollup package, or Service Pack 3 to your license server and all Terminal Servers in your environment.

Tip After installing Service Pack 2 Security Rollup or Service Pack 3, uninstall and reinstall all TS licenses and reactivate them in order to complete this fix.


Licensing and Terminal Services Execution Modes
Windows 2000 Terminal Services can be installed in two different modes. The remote administration mode does not require a TS CAL. The purpose of this mode is to allow administrators to do server maintenance remotely. Therefore, certain restrictions apply to running in this mode. Only two concurrent client sessions are permitted. Server application compatibility services are also disabled, such as the global install mode. The Application Server mode is the mode utilized for Terminal Services in a server-based computing environment. This mode is not restricted like the remote administration mode and requires the TS CALs as discussed earlier.

Windows Server 2003 Licensing
Probably the single most significant reason to move from Windows 2000 Server to Windows Server 2003 across the corporate environment is the new licensing options. Although the execution of the license server is identical to Windows 2000, the licensing choices are dramatically improved. Following are the changes made to licensing with Windows Server 2003:

Windows Server 2003 provides a 120-day grace period for renewals as opposed to 90 days with Windows 2000 Server.

Windows Server 2003 supports a new license option—Per User licensing, as well as the Per Seat licensing supported in Windows 2000 Server (Microsoft has renamed it in Windows 2003 to Per Device). Additionally, a hybrid may be used (some licenses may be allocated per device and some per user). The Per User licensing will work best for environments where users have multiple devices that connect to the Terminal Servers (that is, a single user connects from a desktop, laptop, CE device, home PC, trade show kiosk, and so on). The Per Device licensing works best for environments where multiple users share the same device (manufacturing floors, hospitals, 24/7 offices, and so on). Note that with this change the temporary fix we discussed earlier in this section, allowing Windows 2000 to expire the leases every 90 days, has been eliminated.

The Internet Connector License noted earlier is replaced in Windows 2003 with an External Connector (EC) license called the Terminal Server External Connector (TS-EC) to address the need previously mentioned: to enable external users to access a company's Terminal Servers, without the need to purchase individual TS CALs for them or their devices. An example of an external user is a person who is not an employee of the company or its affiliates. The EC allows organizations to effectively provide Windows and TS CALs for entities not owned by them—for example, e-business customers or supplier partners—in order to give those entities access to their networks and terminal servers. The EC may be the best solution when business partners or customers need access to a server or group of servers. This may be the best solution when a small number of business partners or customers need access to a server or group of servers. This license mode allows 200 anonymous, concurrent users to access Terminal Services.

Licensing and Terminal Services Execution Modes
Unlike Windows 2000 Server, which had a dual mode Terminal Services component, Windows Server 2003 separates the remote administration and Terminal Services functionality into separate configurable components. Remote Desktop for Administration is enabled through a check box on the system Control Panel's Remote tab. Terminal Services is enabled by adding the "Terminal Server" component using the Windows Components portion of the Add/Remove Programs Wizard.

In addition to the two virtual sessions available in Windows Server 2003 Terminal Services remote administration functionality, an administrator can also remotely connect to the console of a server. A significant outcome to this change is that applications that would not work in a virtual session before, because they kept interacting with "session 0," will now work remotely. To connect to the console, administrators can choose one of the following methods:

Use the Remote Desktop Microsoft Management Console (MMC) snap-in.

Run the Remote Desktop Connection (mstsc.exe) program with the /console switch.

Create Remote Desktop Web Connection pages that set the ConnectToServerConsole property.