Best Technology Articles

Centrally deploy and manage Windows-based applications.

Remotely administer Windows Server 2003-based computers

If your organization or certain groups within your organization use specialized applications to do their work, it might be beneficial to host the applications with Terminal Server. For example, you might decide to use Terminal Server in the following situations:

• Custom applications. If your line-of-business application is developed in-house or especially for your organization, and it tends to require frequent updating or repair, deploying the application once on a terminal server can simplify administration of the application. This is especially useful if your environment is geographically dispersed or if you are deploying Terminal Server to centrally serve your organization’s branch offices.
  
• Large central data pool. Applications that rely on access to a single data source often run better on a terminal server because large amounts of data do not have to travel across the network to users. Instead, the data processing takes place on the server. Only the keystrokes and display information travel across the network, so you can use lower bandwidth connections. This is especially useful if the users of the data pool are located remotely, for example in a branch office with a slow connection to the database server.
  
• Task workers. In environments where you want workers to access only the application that they need to perform their jobs, you can centralize the administration of these users by using Terminal Server.
  
• IT Admin tools. System administrators can perform tasks that require Enterprise Administrator or Domain Administrator permissions on a terminal server that has the necessary tools installed on it. They can also run their desktop applications on their local computer without these permissions.
  
• Upgrading operating systems. If your organization uses a line-of-business application that is not optimized for your desktop operating system, you can host the application with Terminal Server rather than change operating systems.
  

You can use Terminal Server to host user’s entire desktop environments, so that when users log on, they see their usual desktop environments or desktop environments especially designed for their remote use. In this situation, users can open and close the applications they choose in the same way that they access applications from the Windows desktop on the local computer. You can host the desktop in the situations discussed in the following sections.

Remote users

Client heterogeneity

You can reduce hardware costs by hosting applications with Terminal Server and using thin client devices or older hardware on your user’s desktops.

• Use of thin clients. Windows Powered thin clients (sometimes called Windows-based terminals) offer an alternative to personal computers and traditional “green screen” terminals by enabling easy remote access to productivity and line-of-business applications that are hosted on Windows-based terminal servers.
  
• Extending the life of older hardware. Rather than replacing older hardware that is no longer capable of running new Windows-based applications, you can use that older hardware much like a thin client to access the desktop and applications on the server rather than on the local computer.
  

The Remote Desktop Web Connection is an ActiveX control that provides virtually the same functionality as the executable version of Remote Desktop Connection, but it delivers this functionality over the Web even if the executable version is not installed on the client computer. When hosted in a Web page, the ActiveX Client Control allows a user to log on to a terminal server through a TCP/IP Internet or intranet connection and view a Windows desktop inside Internet Explorer.

The Remote Desktop Web Connection provides an easy way to offer Terminal Server through a URL. Consider using the Remote Desktop Web Connection in the following situations:

• Roaming users. Users who are away from their computers can use Remote Desktop Web Connection to gain secure access to their primary workstations from any computer running Windows and Internet Explorer, provided they can reach the target computers.
  
• Delivery of extranet applications. You can use Remote Desktop Web Connection to allow business partners or customers access to internal applications over the Internet. Users who gain access in this manner do not need to reconfigure their computers, and they do not gain access to your internal network.
  
• Deployment transition. You can deploy the Remote Desktop Web Connection quickly and use it while you are deploying your full Remote Desktop Connection infrastructure.
  

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

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

After creating the console session, the Terminal Server service then calls the Windows Session Manager (SMSS.EXE) to create two idle client sessions, which then await client connections. To create the idle sessions, the Session Manager starts the Client-Server Run-time Subsystem (CSRSS.EXE), and a new SessionID is assigned to that process. The CSRSS process also invokes the WinLogon process (WINLOGON.EXE) and the Windows Manager and GDI kernel module (Win32k.sys) under the newly associated SessionID.

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

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

At this point, the CSRSS process exists under its own SessionID namespace, with its data instantiated per process as necessary. Any processes created from within this SessionID will execute within the SessionSpace of the CSRSS process automatically. This prevents processes with different SessionIDs from accessing another sessions data.

Terminal Server Licensing

Session Directory

Terminal Services is a technology that lets users run Microsoft Windows-based applications on a remote Windows Server 2003-based computer. In a Terminal Server-based computing environment, all application execution and data processing occur on the server. In a load balanced environment, a farm of terminal servers have incoming session connections distributed in a balanced manner across the servers in the farm. The session directory (SD) keeps a list of sessions indexed by user name, and allows a user to reconnect to the terminal server where the user’s disconnected session resides and resume that session.

Terminal Services Physical Structure

Terminal Services Components

Component	Description
Terminal Server	Hosts applications for client computers.
Terminal Server Licensing Service	Issues TS Device CAL token to a requesting terminal server.
Session Directory	Maintains a list of the user names associated with the session IDs connected to the servers in a load balanced Terminal Server cluster.
Remote Desktop Connection	Client software that allows a connection to one remote computer.
Remote Desktops MMC Snap-in	Client software used by administrators to connect to multiple remote computers simultaneously.
Remote Desktop Web Connection	ActiveX RDP Web browser client.

The Terminal Services client has a new name, Remote Desktop Connection. Remote Desktop Connection can be installed and run on any Windows 95, Windows 98, Windows Millennium Edition, or Win32 platform (non-Windows-based clients are supported by the Citrix Metaframe add-on).

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

First, an encryption level is established for the session. The Terminal Server initially supports three encryption levels: low, medium, and high.

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

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

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

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

The Remote Desktops snap-in is ideal for administrators who are remotely administering multiple servers or terminal servers. You can create Remote Desktop connections to multiple terminal servers or to computers running Windows 2000 Server or Windows Server 2003 family operating systems with the Remote Desktops MMC snap-in. A navigable tree display provides easy switching between connections.

Remote Desktop Web Connection provides virtually the same functionality as Remote Desktop Connection, but delivers this functionality over the Web. When embedded in a Web page, Remote Desktop Web Connection can establish a Remote Desktop session with a remote computer, even if Remote Desktop Connection is not installed on the client computer. Remote Desktop Web Connection must be installed on a Web server with Internet Information Services (IIS) and Active Server Pages (ASP) enabled.

The Remote Desktop Web Connection is an ActiveX control that offers full feature parity with the standard Remote Desktop Connection client software offered in Windows XP and the Windows Server 2003 family of operating systems. The Remote Desktop Web Connection, like the Remote Desktop Connection which is installed by default, allows for connectivity to a Terminal Server. When installing the Remote Desktop Web connection on a specified computer the ActiveX control and sample ASP pages are installed. Internet Information Services is the delivery mechanism for the Remote Desktop Web Connection ActiveX control. This ActiveX control launches a Remote Desktop session to a Terminal Server computer from within Internet Explorer.

Remote Desktop Web Connection connects to the Terminal Server as follows:

1. The user opens a Web browser and requests the initial Remote Desktop Web Connection (DHTML) login page.
   
2. The IIS server sends the page, and if this if the first time the client has connected, the user is also prompted to download the Remote Desktop ActiveX Control.
   
3. The user populates the connection information which includes the Terminal Server name.
   
4. The client computer creates a connection directly to the Terminal Server computer by using port 3389.
   

Connection Process

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

Automatic Reconnection adds resilience to the Remote Desktop Connection client is Windows Server 2003. It is designed to recover from temporary connection losses due to network problems. Automatic Reconnection enables disconnected Terminal Services sessions to automatically re-authenticate to a Terminal Server without prompting the user for credentials.

Mobile users can greatly benefit from this feature. For example, with the previous versions of Terminal Server client, a user working with a wireless laptop which momentarily loses connectivity would be disconnected from the session and greeted with the message “The connection was ended because of a network error. Please try connecting to the remote computer again.” Now with Automatic Reconnection, the user resumes the original session without needing to re-enter a password.

Reconnection Process:

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

Terminal Server for Windows Server 2003 (known as Application Server mode in Windows 2000 Server) provides application deployment and management for users on a variety of devices through its application server mode. Each device or user who initiates a session on a terminal server running Windows Server 2003 must be licensed with one of the following:

1. Windows Server 2003 Terminal Server Device Client Access License.
   
2. Windows Server 2003 Terminal Server User Client Access License.
   
3. Windows Server 2003 Terminal Server External Connector.
   

Note that additional licenses might be needed, such as Microsoft or other application, operating system, and Client Access licenses. The licenses in the preceding list are required even if other add-on products are used on top of Windows Server 2003.

The Terminal Services Licensing service is only associated with licensing for a terminal server client. It is not used to license any other application or service, and does not replace or interoperate with the licensing service for any other component, or alter your rights and obligations under any End User License Agreement (EULA). The Terminal Server Licensing service is not a replacement for purchasing a TS CAL.

TS CAL tokens are electronic representations of real licenses, but they are not actual licenses themselves. Therefore if a license token is lost, it does not mean that you have lost an actual license. If you have the documentation to prove that you have bought an actual license, the license token can be re-issued. Conversely, just because you have a license token does not mean that it necessarily maps to an actual legal license.

Terminal Services Licensing is designed to manage these license tokens to allow an administrator to more accurately assess an organization’s licensing requirements. However, there are a few situations in which a license token will not map to an actual license. The administrator should determine if this is the case, and if necessary, purchase extra licenses (but not install the corresponding license tokens) to account for this discrepancy.

All communication during the licensing process occurs between the client and the terminal server, and between the terminal server and the license server. The terminal server client never communicates directly with the license server.

When a client device attempts to connect to a terminal server in Per Device mode, the terminal server determines if the client has a license token. Terminal server clients store license tokens in the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing

If a client has no license token, the terminal server attempts to contact a license server from its list of discovered license servers. If no contact is made, the terminal server restarts the discovery process. If no license server responds, the device can not connect to the terminal server unless it is operating within the terminal server grace period.

When a license server responds, the terminal server requests a temporary token for the device because this is the first time the device has connected to a terminal server. The terminal server then pushes this temporary token to the device. After a user has provided valid credentials resulting in a successful logon, the terminal server instructs the license server to mark the issued temporary token as validated.

The next time a user attempts to connect to a terminal server in Per Device mode from this device, the terminal server requests a Windows Server 2003 TS Device CAL token for this device. If the license server has available TS Device CAL tokens, the license server removes one token from the available pool, marks it as issued to the device, logs the device name, the user name of the device, and the date issued, and then pushes this TS Device CAL token to the device.

If the license server has no TS Device CAL tokens, it will first look to any other license server in its domain, workgroup, or site. License servers maintain information about where other accessible license servers exist, and if they have license tokens. If another license server is accessible that does have inventory, the first license server will request a license token from the second license server and deliver it to the terminal server, which then passes the token to the client device. If there are no available TS Device CAL tokens, the device will continue to connect with the temporary token.

Temporary tokens allow devices to connect for 90 days, and will then expire. TS Device CALs, while representing perpetual licenses, are set to expire 52-89 days from the date they are issued. The terminal server always attempts to renew these tokens 7 days prior to their expiration. The purpose of this system is to recover TS Device CAL tokens that are lost due to events such as hardware failure or operating system reinstallation.

Client License Distribution Per User

Client License Distribution for External Connector

Terminal Server Licensing operates between several components as shown in the previous figure, including the Terminal Server Licensing-enabled license server, the Microsoft Certificate Authority and License Clearinghouse, one or more terminal servers, and terminal server clients. A single license server can support multiple terminal servers. There can be one or more license servers in a domain, or throughout a site.

The Microsoft Clearinghouse is the facility Microsoft maintains to activate license servers and to issue client license key packs to license servers. A client license key pack is a digital representation of a group of client access license tokens. The Microsoft Clearinghouse is accessed through the Terminal Services Licensing administrative tool. It can be reached directly over the Internet, through a Web page, or by phone.

A license server is a computer on which Terminal Server Licensing is installed. A license server stores all TS CALs license tokens that have been installed for a group of terminal servers and tracks the license tokens that have been issued. One license server can serve many terminal servers simultaneously. A terminal server must be able to connect to an activated license server in order for permanent license tokens to be issued to client devices. A license server that has been installed but not activated will only issue temporary license tokens.

A terminal server is a computer on which the Terminal Server service is installed. It provides clients access to Windows-based applications running entirely on the server and supports multiple client sessions on the server. As clients connect to a terminal server, the terminal server determines if the client needs a license token, requests a license token from a license server, and then delivers that license token to the client.

1. An incoming connection to the cluster is load balanced to one node, which provides the logon prompt.
   
2. When the user logs on to the Terminal Server cluster, the Terminal Server receiving the initial client logon request sends the user name to the Session Directory server.
   
3. The Session Directory server checks the user name against its database and sends the result to the requesting server. The Session Directory database is a jet database containing a list of sessions indexed by user name.
   
4. If the user has no disconnected sessions, the log on process continues at the server hosting the initial connection.
   
5. If the user has a disconnected session on another serer, the initial hosting server sends the client information necessary for the client to continue authentication against the server hosting the disconnected session. The transition from one server to the other is transparent to the user.
   
6. When the user logs on to the disconnected session, the Session Directory is updated.
   

The Terminal Server Session Directory database is updated and queried by the Terminal Servers whenever users log on, log off, or disconnect from a session.

Note

• The Session Directory redirection feature is dependent on the version of the Remote Desktop Connection client used. The Remote Desktop client released with Windows XP is the minimum level necessary to function properly with Session Directory. Windows 2000 and Windows NT 4.0 Terminal Server clients are not Session Directory-aware, so client sessions will not be redirected to a disconnected session when that session is on an alternate node.
  

Session Directory exists to solve a problem for Terminal Server clusters. These clusters can be load balanced using various solutions. This section discusses some general practices for any solution in use for load balancing. Here are some general considerations for Terminal Server clusters:

Consider splitting network traffic between two network adapters: one for Terminal Services connections and the other for access to other network resources and infrastructure. This allows for network access to the server in case the adapter bound to the cluster becomes unavailable.

For easier administration, place all load-balanced Terminal Servers into an Organizational Unit (OU) and apply Group Policy settings to that OU.

Home directories and other user data storage will need to be configured in such a way that the users can easily access their data no matter which server they are logged into.

Network Load Balancing (NLB) was previously installed by adding it as a service to a network connection and then configuring that network component on each node individually. NLB Manager in Windows Server 2003 is a new centralized snap-in added to provide easier configuration and maintenance for NLB configurations.

Although it is still possible to configure an NLB cluster by modifying network connection properties directly, the best practice is to use NLB Manager. In addition, the use of both NLB Manager and modifying network properties to configure an NLB cluster is not recommended.

Administering Windows Server 2003 family operating systems remotely