Windows Server 2003 Terminal Services is configured after installation and, if necessary, during operation using a specific tool: Terminal Services configuration. This tool allows you to modify the parameters for connections and server settings.
Note? |
Terminal Services settings have a relatively high priority level and can overwrite the corresponding client or user account options. Only Group Policies have a higher priority level than Terminal Services configuration. The hierarchy (descending) is clear: Group Policies—Terminal Services configuration—User configuration—Client configuration. User configuration and client configuration details are discussed in the following pages. |
However, before we introduce you in detail to Terminal Services configuration, it is important that you understand the meaning of Connection and User session in terms of terminal servers.
Note? |
Unlike many other administration tools, Terminal Services Configuration is explained in great detail in this book because it is central to the administration of a terminal server. Furthermore, this tool can serve a vital role in explaining the basic mechanisms of terminal servers. |
A connection between the client user session and the terminal server can basically be realized at three different points in the system. The selected settings must be valid for a type of protocol, an individual user, or an individual client. There are special tools for each of these tasks.
This configuration affects all users who connect from network clients to a Windows terminal server over a specific connection (in this case, Microsoft RDP 5.2). The corresponding tool is Terminal Services configuration. Only an administrator on the Terminal Services Machine has access to this tool. It is also possible to copy certain options from the individual configurations for users or clients.
Important? |
Even if Terminal Services configuration appears to be the strongest way to set parameters for Terminal Services connections, there is one authority with a higher priority level: Group Policies! |
This configuration affects an individual user account and is performed by the administrator through user administration. It is important to keep in mind that the corresponding options were added for local user-specific components of computer administration with Terminal Services installed and user administration on the domain level.
Moreover, these user-specific settings are active only if they were approved during the configuration of the connection-specific settings. If they were not approved, the connection-specific settings overwrite the user-specific settings. Terminal Services configuration is therefore stronger than user administration.
This configuration applies to an individual client and can be performed on the client hardware or the client software. The client user might even have permission to select setting options. These client-specific settings are active only if they were approved during the configuration of the connection-specific settings. If they were not shared, only the connection-specific settings apply. User administration is therefore stronger than client configuration.
Every user of a terminal server is assigned his or her own session. Each session has its own life span that is independent of all other activities on the server. The following paragraphs describe the different phases of the life of a user session.
When Terminal Services is started, it first initializes two user sessions in idle mode. A monitoring thread is launched and waits for a connection request via a certain TCP/IP port. As soon as a user connects to the terminal server through his or her client, the connection request is immediately accepted and forwarded to the kernel driver of the appropriate protocol (for example, RDP). The kernel driver transmits the request to Terminal Services. Terminal Services initializes a special thread to handle the request.
This new thread handles the negotiation between server and client regarding cache size, compression, encryption, client version number, license details, and virtual channels. If the connection is successful, it is assigned to one of the idle sessions. Then the session space is initialized (Csrss, WinLogon, and kernel driver) and a new idle session is generated. Finally, the user is authenticated by means of an interactive dialog box or automatic forwarding of the identification information on the client. As soon as the user is identified, he or she can start the interactive session.
The user can terminate the connection between client and terminal server without logging off. The connection can also be terminated when a predefined time limit is reached. The session’s graphical image and user processes are stored on the server just before disconnecting. Therefore, the user can reconnect to the session on the terminal server and resume work. The IDs of disconnected sessions and the corresponding user IDs are stored in memory. They can be reused at any time on reconnection.
From a technical perspective, only the RDP and TCP/IP drivers are removed from memory when a connection is terminated without logging off. The kernel element of the 32-bit subsystem handles interrupting all graphical output to the system driver. This means that the session becomes invisible until the user reconnects or on reaching the predefined time limit for automatic removal of the disconnected session from memory.
The applications that were open when the session was disconnected continue to run without interruption. For instance, an FTP client can continue downloading a document from the Internet without a problem in a separate user session, even though the user is no longer connected interactively.
When a user requests a new connection to the terminal server after disconnecting, a new session is generated. The logon screen prompts the user for authentication if the user ID was not automatically transmitted. If the system detects a separate session for this user from the logon ID and password, the user is reconnected to that session. The required drivers are loaded and the graphical subsystem is invoked to display the current session contents.
If configured to do so, disconnecting and reconnecting can also be used on the server side for unstable network connections. If a client loses the connection to the server, the server detects the interrupted data flow and saves the session for a preset period. Even if a client is accidentally switched off, no data is lost to the user. When the client is switched on again and the user logs on to the terminal server, the user is reconnected to the previous session.
Of course, a user can log off a terminal server session, that is, terminate the session. The result is the same as logging off the local Windows XP or Windows Server 2003 console. All resources that the session was using are released on the server.
After launching the Terminal Services Configuration tool under Start\Administrative Tools, you will see two menu items in both panels: Connections and Server Settings. If you select Connections in the left panel, the right panel displays the protocols installed. If Windows Server 2003 with Terminal Services is installed with no add-on products, you will see only Microsoft RDP 5.2.
Note? |
To modify all settings in Terminal Services configuration, you must be logged on as a user with administrative rights. If you installed Citrix MetaFrame XP Presentation Server on your terminal server, you will see several protocols in Terminal Services configuration. You can find a detailed description and scope of Citrix MetaFrame XP Presentation Server starting in Chapter 9. |
Right-click the mouse to open the Connections context menu. The following options are displayed:
Create New Connection A wizard helps you set up a new connection. You need to enter the type of connection (for example, RDP 5.2), data encryption, remote monitoring options, type of transmission (for example, TCP), and network adapter. To set up a new connection, at least one of the parameters for connection type and transmission type, or for the network adapter, must differ from those for an already existing connection.
View Adjusts the MMC console to the user’s preferences. Adds or removes columns, sets the view to display large icons, small icons, lists, or details.
Refresh Redraws the graphical user interface to display changes in values.
Export List Saves the names of the Connections columns in a text file.
Help Displays Help information related to the MMC console and Terminal Services Configuration.
You initiate the setup of a new connection in Terminal Services configuration using the context menu of the Connections option on the console tree (that is, in the right panel) or via the Action\Create New Connection menu item. This will start the connection wizard for Terminal Services.
By selecting a connection protocol in the right panel of Terminal Services configuration and opening its context menu, you can enter several global settings. One of them is especially important: the deactivation option under the All Tasks menu item. This option prohibits any other user from logging on to the terminal server using the connection protocol you selected. It is often needed to begin maintenance work on the server.
When you select Properties for the connection protocol, the right panel displays a dialog box with eight tabs. These tabs allow you to configure the connection parameters.
The first tab is labeled General. Use this tab to enter an optional comment to describe the connection, the degree of encryption, and the standard authentication method you selected. The transport protocol to transmit data streams over RDP 5.2 is always TCP/IP and cannot be modified. The RDP 5.2 connection type is also a default value that cannot be changed.
For the server, you can choose between four degrees of encryption for data transmission between server and client for RDP 5.2.
Low All data sent from the client to the server is protected with 56-bit encryption. Data sent from the server to the client is not encrypted.
Client-compatible All data transferred both from client to server and server to client is protected using the maximum encryption supported by the client. The client thus determines the degree of encryption. However, this could allow unencrypted data to pass through the network, depending on the client configuration.
High All data sent from the client to the server and vice versa is protected by an encryption using the maximum encryption supported by the server. For a standard terminal server, this is 128 bits. International clients that do not support this encryption cannot connect to the server.
FIPS-conform All data exchanged between client and server is verified according to Federal Information Processing Standard 140-1.
Note? |
In some countries, the law limits the level of encryption; for example, the level might be limited to 64 bit. Therefore, the specific language versions of Windows Server 2003 Terminal Services do not support higher encryption in these countries. Clients that must request a higher encryption cannot connect to the language-specific terminal servers with lower degrees of encryption. |
If you activate the Use standard Windows authentication option, you cannot use any third-party security components for user authentication. In this case, Microsoft GINA-DLL is used exclusively.
Note? |
In many countries, encryption under the Windows NT 4.0 Terminal Server Edition was limited to 40 bits on all levels. If you use older-generation RDP clients, they might support only 40-bit encryption keys. If the degree of encryption is set to client-compatible, Windows Server 2003 Terminal Services will automatically adjust the encryption downward. |
In production environments, you use this tab only to adapt the level of encryption to the corresponding requirements. Other options are usually not as important here.
The Logon settings are configured under another tab. On the client, you enter the logon information (including the password, if required) into the fields under the corresponding radio buttons. The data is passed on to the server at logon. Be careful not to confuse this with the single sign-on solution in which the information the user enters at logon is automatically used to establish a session on the client. Even though this option is convenient for logging on to a terminal server session, it does present security problems. Furthermore, not all clients support this option.
Alternatively, you can input a user name, domain, and password for logging on to the terminal server. This enables an automatic logon, too, and is valid for all user sessions requesting a connection over this type of protocol. In many environments, however, there might still be security concerns regarding user access. Nonetheless, this is a very powerful option that allows anonymous users to access a terminal server running noncritical applications, for example, information terminals in a department store.
You can make both logon options more secure by requiring the user to enter the password manually. To activate this option, select Always request password option. This prevents the stored password from being used, no matter where it resides (client side or server side). Regardless of the logon option, users will be required to enter their password each time they log on to the terminal server, thus significantly increasing security.
In production environments, always select this option button, unless the user is authenticated in a special secured environment that is safe for password transmission.
The configuration of sessions on this tab sets the timeout limits for Terminal Services and determines the reconnection settings. The timeout limits are set using three counters. You have the choice of three predefined settings:
End a disconnected session This counter sets the maximum time a disconnected user session remains in memory. When the interval specified is completed, the session is ended; that is, the session is physically removed from memory, the user’s applications are terminated, and the user is logged off. Terminal Services configuration allows you to set the value for the protocol in question (only RDP in the default installation) only if you select Override user settings. In this case, the setting you define here overrides the corresponding setting in the terminal server-specific expansions for local users and groups or users and computers in the Active Directory directory service. In this way, the terminal server administrator can set a generally valid standard for the behavior of Terminal Services for separate sessions.
Active session limit This counter sets the maximum duration of a user session. When the time is up, the session is either disconnected or ended, depending on the settings specified in the following paragraph. To set the active session limit value, you also need to override the user settings.
Idle session limit With this counter, you set the time that a user can remain inactive. If this time limit is exceeded, the session is either disconnected or ended, depending on the settings described in the following section. This is yet another value that you can set only if you override the user settings.
Setting session limits does involve a certain amount of risk. For instance, if the idle session limit is set to 60 minutes, a session might be disconnected or ended when the user is simply on an extended lunch break. In the worst case scenario, data might be lost. On the other hand, setting a time limit is sometimes the only way to prevent inactive users from wasting server resources.
The following settings relate to system behavior when the session limit is reached or the connection is broken. Selecting Override user settings combined with Maximum Idle Time overwrites the settings in the terminal server-specific settings for local users and groups or users and computers in the Active Directory. Thus, the configuration settings chosen here turns an individual user request into a generally binding system behavior preset by the terminal server administrator.
When the session limit is reached or the connection is broken (for example, by switching off a client), there are two options:
Disconnect from session The network connection is interrupted but the session remains stored in terminal server memory. This applies to all open applications and the corresponding user data.
End session The user session is completely removed from memory. Unsaved application data is lost if the user did not save it and no automated backup processes were activated.
On closer examination, one combination of settings seems completely useless at first: A disconnected session is ended after 10 minutes, yet the session also ends when the session limit is reached. Can a disconnected session remain in memory? The answer is yes. A user can explicitly ask the client to disconnect from a session. This disconnection does not result from a session limit or an interrupted network connection. In this case, the 10-minute time limit is valid for the disconnected session until it is ended, if the user does not reconnect to it.
A disconnected session can be reestablished by any client under the RDP protocol. The user account and the corresponding password are essential to establish a new connection. This option is particularly helpful if the terminal server is protected by an uninterruptible power supply, but the clients are not. In this case, a short power failure does not result in the loss of user data or application statuses. The user can then continue working with his or her session from any client.
This setting cannot be changed under the RDP protocol. Other protocols might allow limiting reconnections to the previous client. Therefore, this configuration option does appear in the dialog box. Here, too, selecting Override user settings overwrites the corresponding setting in the terminal server-specific expansions for local users and groups, or for users and computers in the Active Directory.
Note? |
If the user is allowed to reestablish the connection to a disconnected session from the same client only, this can result in problems if the physical client fails. Even if an identically configured client replaces the original client, the user will not be able to use his or her session again. |
In production environments, the time limits for user sessions are usually set in this tab and can overwrite previously set, different user settings. In particular, this applies to ending a disconnected session after several minutes or hours and after the idle session limit. Therefore, it is strongly recommended that these values be thought through and communicated to users well in advance. When sessions disappear without sufficient warning, users often reject the technology, unjustifiably. It is not the technology that creates the problem, but the organization or, in some cases, the communication involved.
The Entering two strings in the tab Environment enables the configuration of an exclusive program that is started automatically upon user logon. An entry at the Program path and file name specifies the program desired. The Start in prompt determines the default directory allocated to the program.
When a user logs on, the program inside a full-screen session window is displayed instead of the normal desktop. When the user ends the program, the terminal server session is terminated, too. This leads to a basic form of environment where only one application is able to run.
This option becomes active only if the Override settings from user profile and Remote Desktop Connection or from Terminal Services client option were activated. This overwrites the corresponding setting in the terminal server-specific settings for local users and groups or users and computers in the Active Directory, including the client side as well. In this instance, too, the Terminal Services configuration takes precedence over the user or client-specific settings.
Important? |
In general, specifying a start program does not prevent the user from running another program. Some desktop functions could still be misused behind the active application. For a strict single-application environment, the terminal server administrator needs to add further security settings. |
Note? |
Problems that arise when starting the program over the network might indicate improper timing. For example, the terminal server might be trying to start a program before a required network drive in a logon script is connected. Figure 2-19: Configuring environment settings. |
The options in this tab are usually not modified in production environments. In general, a different technology is used to display individual applications. We will describe this technology in detail later in this book.
The Remote Control tab allows a user session to be “mirrored” on another client. This function is for administrative tasks, for example, help desk tasks. The remote control configuration allows you to use user-specific default settings, as well as to fully deactivate and configure the following settings:
Use remote control with default user settings means that the user settings of a local user or in the Active Directory are used to determine the following options.
Do not allow remote control prohibits the takeover of a user session thus configured.
Under Use remote control with the following settings in the dialog box, the administrator can determine if a user must approve of remote control when the administrator assumes control over a session. Additionally, it is possible to define whether the remote session can be viewed only under remote control, or if the administrator can also interact with the session by assuming control of the keyboard and the mouse.
Figure 2-20: Configuration of remote control, where the user must give his or her permission, and the remote session can only be viewed.
Note? |
Labor-law restrictions in some countries prohibit monitoring users without their knowledge. It is therefore mandatory to obtain the user’s permission. For this reason, remote control behavior in production environments is usually preconfigured under this tab and not under user settings. |
Client settings allow an administrator access to several options related to the integration of client resources in the user session. Integrating these options supports the intuitive assumption by the user that he or she can continue to use local resources even though the application on the screen is physically running on a remote server. Furthermore, this reduces the time it takes a user to become familiar with the system. For example, during a Terminal Services session, a user can issue the print command without first having to correctly allocate the appropriate resources.
In principle, the following options can be preconfigured for a connection protocol such as RDP 5.2. The first three options can also be defined through the user settings.
Connect client drives at logon At logon, this option displays the local client drives as network drives in the corresponding terminal server session. These network drives are labeled \\TSCLIENT\A, \\TSCLIENT \C, or \\TSCLIENT \D. This option is activated by default.
Connect client printers at logon At logon, this option displays the local client printers as network printers in the corresponding terminal server session. This option is activated by default.
Default to main client printer This option determines whether a print job is forwarded automatically to the terminal server default printer or to the main client printer. This option is activated by default, which sends the print job automatically to the default client printer.
Limit maximum color depth With this option you determine whether you want to limit the maximum color depth for a terminal server client using this connection. If this option is active, you can select 8-bit, 15-bit, 16-bit, or 24-bit. The default setting is preconfigured to 16-bit.
Printer connections will take the most time because numerous driver combinations can apply. The other interfaces are a bit easier to integrate, although you can always disable them again as well.
The following options can be disabled regardless of how you initiated the connection to the client drives or printers, that is, either via the options described earlier or via the user settings in the system tool Computer Management.
Drive mapping If you check this box (that is, you disable it), you will not be able to connect to the local client drives from a Terminal Services session. You can also override the Connect client drives at the logon option described earlier. This option is disabled by default, that is, you will connect to the client drives at logon.
Windows printer mapping If you check this box (that is, you disable it), you will not be able to automatically connect to the client printers at logon. However, you can still manually initiate a connection to a client printer from a Terminal Services session if the LPT or COM port options are enabled. This option is disabled by default, that is, you will connect to the client printers at logon.
LPT port mapping If you check this box (that is, you disable it), the list of available printers will not include any client printer connected via the LPT port. This option is disabled by default, that is, you can manually integrate all printers that are connected via the LPT port on the client. When you log on again, printers you mapped manually will be restored only if Windows printer mapping is enabled.
COM port mapping If you check this box (that is, you disable it), the list of available printers for Terminal Services sessions will not include any client printer connected via the COM port. This option is disabled by default, that is, you can manually integrate all printers that are connected via the COM port on the client. When you log on again, printers you mapped manually will be restored only if Windows printer mapping is enabled.
Clipboard mapping If you check this box (that is, you disable it), no data exchange between terminal server and terminal server client is possible via the clipboard. This option is disabled by default, that is, the clipboard does allow data exchange.
Audio mapping If you check this box (that is, you disable it), it is not possible to transmit audio data streams from terminal server to terminal server client. This option is enabled by default, that is, system sounds and other audio signals of the user session will not be transmitted to the client.
Important? |
LPT and COM mapping support only the connection of printers via the respective ports. Other local client devices, such as serial bar code readers, cannot be contacted using RDP 5.2. The network bandwidth required can be heavily influenced by the combination of client and server clipboards and the client printer mapping. For instance, when you copy a large graphic from an application running on the client and place it into an application running on the server, all the data on the clipboard must be transmitted via the network. Printer mapping is another critical issue, because a print job of several megabytes can put quite a load on a narrowband WAN connection for some time. This, of course, affects the operating speed of the clients connected via remote access server (RAS). |
The configuration options are very comprehensive. Therefore, it is easy to make mistakes. Please make sure that you determine in advance the options you need for productive operations in the target environment.
On the next tab, you select one or more network adapters to allocate to the connection protocol. Allocating a certain network adapter to a protocol can make a lot of sense in some environments. This is especially true for complex networks in which clients are connected via LAN and WAN lines.
The tab provides an additional configuration option: the number of possible connections. That number can be unlimited or clearly limited to a certain quantity of simultaneous RDP connections over the network adapter selected. In this way, you can determine the number of network connections and thus the RDP bandwidth used for one network adapter. The remaining bandwidth can then be reserved for other services. See Figure 2-22.
Note? |
The maximum number of connections is not linked to the license configuration. Licenses are monitored using an independent tool. |
When it comes to user access, security plays a major role on a terminal server. For this reason, the Permissions tab provides access to the security settings of individual protocols.
Permissions control what a user or a group may or may not do. Only an administrator can modify the standard access types: Guest access, User Access, and Full Control. They are listed in Table 2.5.
Permission |
No Access |
Guest Access |
User Access |
Full Control |
---|---|---|---|---|
Request information on the session |
No |
No |
Yes |
Yes |
Set information or connection parameters |
No |
No |
No |
Yes |
Use remote monitoring |
No |
No |
No |
Yes |
Log on to server |
No |
Yes |
Yes |
Yes |
Log off sessions |
No |
No |
No |
Yes |
Send messages |
No |
No |
Yes |
Yes |
Connect to forced-off sessions |
No |
No |
Yes |
Yes |
Disconnect a session |
No |
No |
No |
Yes |
Use virtual channels |
No |
No |
No |
Yes |
Access to Terminal Services or starting a Terminal Services session is usually regulated by Remote Desktop Users, a particular user group. New users who are to work on the terminal server are therefore added to this group. You should not modify this permission structure without a good reason to do so.
Tip? |
Use the Advanced button to configure how you want to monitor the selected connection protocol in the Event Viewer. |
Important? |
Before you can use Terminal Services, the server must be released under Control Panel\System\Remote\Remote Desktop. Normally, this happens automatically during the installation of a terminal server. Furthermore, users who access Terminal Services must have a valid (not blank) password. |
Fundamental changes to the runtime environment can be performed through the Terminal Services Configuration server settings.
Delete temporary folders on exit Determines whether the directories for temporary files are deleted upon ending the session or not. This option is enabled by default to save resources on the terminal server.
Use temporary folders per session Each user has a personal directory for temporary files, or all users access one common temporary directory. By default, each user has a personal temporary folder.
Licensing You can choose between licensing per device or per user. The former requires a license for each client computer that connects to the terminal server. The latter requires a license for each user who connects to the terminal server. The license per device option is active by default. Licensing per user is not currently supported.
Active Desktop You can enable or disable use of the Active Desktop. The option to support Active Desktop is disabled by default.
Permission Compatibility The Full Security option for running applications is compatible with Windows 2000 and Windows Server 2003. However, this prevents older applications from being executed (for example, SAPGui 4.6x or Microsoft Access 97). Therefore, the Relaxed Security permission compatibility setting offers reduced security control and provides full access for all users to the registry and system directories. The Full Security option is enabled by default.
Restrict each user to one session If this option is selected, there can be only one session per user. This way, you can save resources on the terminal server and reconnection to existing sessions is easier. Each user is restricted to one session by default.
Session Directory This option allows integration of an instance that centrally manages the directory of a user session, which enables reconnecting to a session even in server farms. This option is disabled by default.
Figure 2-24: Terminal Services configuration server settings.