Windows terminal server 2003

The main difference with Terminal Server is that multiple users can run their own Windows desktop sessions on the server. So Terminal Server is "multi-user" in the sense that it supports multiple desktop interfaces. Some people like to think of this as a "remote control" environment, except that the Terminal Server can accommodate many users "remote controlling" it at the same time, with each user doing something completely different. In order for Terminal Server to support multiple user sessions, some changes had to be made to it from the regular Microsoft Windows server software.

There are two fundamental differences between a regular Windows Server and one with Terminal Server installed:. Although it seems that the Terminal Server is basically a glorified PCAnywhere system, it's actually a complex system made up of several different components, subsystems, and interfaces. A more complete diagram of the Terminal Server components is shown in Figure 2.

Refer to it as you read through the next few sections describing each component that makes up Windows Terminal Server. You will recall that a key component of any server-based computing environment is a multi-user operating system. In Windows Server , this system is controlled by the kernel. Windows Server needs a way to distance critical operating system components from all the crazy users.

To achieve this, Windows processes operate in one of two modes: user mode or kernel mode. Thinking back to your Windows NT training, you'll remember that a user mode application cannot write directly to the OS memory. Instead, it has full access to its own 4GB memory space. An operating system component called the virtual memory manager which itself runs in kernel mode controls all of this and writes to the system memory on behalf of the user-mode application.

In Terminal Server environments, the separation of user mode and kernel mode applications allows the system to separate and isolate the users. One users' application crash won't take down the whole system.

Of course you're thinking that an application crash can take down a system, however, that's usually tied to device drivers which run in kernel mode. In "standard" i. In multi-user environments like Terminal Server, however, this sharing won't work since requests from different users' sessions could conflict with one another. The kernel on a Terminal Server is consequently multi-session aware; it keeps each user's session separate with isolated processes and memory.

Windows Server makes some changes to the kernel when the Terminal Server component is installed to accomplish this. First, the server places some of the kernel's memory address space into virtual memory. This allows what would be conflicting requests in a single-user environment to be processed properly in the multi-user environment, and for multiple instances of kernel-mode device drivers to be loaded and used by multiple users the reason why one user can technically crash the whole system.

Some system processes are not session-specific, meaning that all users in all sessions will need access to them. These processes are stored in a single global memory area shared by all users.

A side-effect of sharing processes like this in a Terminal Server environment is that sometimes you'll run into processes that are not "session aware. Since there's usually no one in the server room to acknowledge the message, there is the potential to prevent a user's application from continuing.

When you select the server name you can choose to view and manage the Users, Sessions or Processes tab. The green icons indicate that the server is online. If you had to disconnect it, the icons would be gray.

The Users tab allows you to see who is connected, how long they have been connected and the state of their connection. The Sessions tab permits the viewing and control of the terminal server sessions.

You can right click a session and select the status to see the incoming and outgoing data or reset to reset the session. The processes tab shows all the processes that are running and which user they belong to this is a simplified version of the processes tab found on the windows task manager. The image below shows the Terminal Services Manager with an active connection initiated by a user andrew. If you select the RDP-Tcp 12 username option you can view the processes and session information specific to that user.

Note: The 12 number will be different for each session. Any connections that have been setup will be displayed in the connections part of the console. Double click a connection to open the properties page. The server settings section enables you to modify the settings of the server. Double click a setting from the list to bring up the appropriate window and be given the option to make a change. We'll cover them in Chapter Relevant here is the fact that Windows changes the way "classes" are managed in the registry.

In the Windows registry, "classes" and their associated "class IDs" refer the filename associations and data associated with COM objects. Quite simply, it means that with Terminal Server , individual users can each have their own class settings.

This is important for two reasons:. Now you can begin the actual process of installing your applications. Although installing an application on a Terminal Server is similar to installing an application on any standard workstation, adhering to some best practices ensures your application is installed properly:. Many applications used in Terminal Server environments have "workstation" and "server" install modes.

These applications have two components: the server component and the workstation component. Since your Terminal Servers are essentially gigantic shared workstations, you need to perform a "standard" workstation install on your servers.

If there's ever a situation in which you don't know which installation options to choose for an application when you're installing it on a Terminal Server, choose the options that you would use if you were installing the application onto a standard user's workstation. For example, some applications have a "thin client" mode of installation. At first this might seem like the perfect installation option to use on a Terminal Server.

But for a lot of applications the "thin client" mode of installation indicates that the bulk of the application's client files have been preinstalled onto a file share somewhere, and that the local workstation install only needs to contain user configuration information. If your application offers it, there's nothing wrong with using this type of "thin client" installation option on your Terminal Server, but you shouldn't automatically use it just because you're using Terminal Services.

Again, the bottom line is that you should install your application with the same options as if you were performing a standard end user workstation install. Microsoft well, technically Citrix had to do quite a bit of engineering and redeveloping of many Windows components to allow multiple users to be simultaneously logged on "locally" to servers in Terminal Server environments. Even with the work that was done to the OS, the vendors who create software applications don't always take Terminal Server environments into consideration when writing their applications.

When Terminal Server first came out in , just about every application in existence didn't quite work right when installed on it. To combat that, Microsoft and the other vendors created application compatibility scripts that "fixed" applications to work on multi-user servers. These scripts were nothing more than batch files that ran to change certain application settings file locations, registry entries, etc.

Fortunately, much has changed in six years, and these application compatibility scripts are largely a relic of the past. Terminal Server only ships with scripts for three applications as compared to dozens in previous versions of Windows. However, even though Microsoft has decided it doesn't need to support many legacy applications, you might not be as fortunate in your own situation. We won't take the time here to detail exactly how Windows uses the few remaining out-of-the-box application compatibility scripts, but it is important that you have at least a basic knowledge of how they work in case you need to design your own for the occasional misbehaving application.

Most application compatibility scripts are used in pairs. The first script is typically executed by an administrator just after an application is installed. The second is run once for each user, usually as part of a logon script. Let's consider a sample application. We'll use Lotus Notes, since it is widely familiar and is was? Once Notes was installed on the Terminal Server, you had to run the first application compatibility script.

This script made several changes to Notes. Disables or enables remote assistance on this computer. Default value of the compatibility flag for applications. Each user can be limited to one session to save server resources or facilitate session recovery.

Change this value using the Restrict each user to one session server setting in Terminal Services configuration. Sessions started in the background are assigned to new users. The default value for this setting is 0.

For application servers, you can select different values, which might reduce login times for new user sessions. Each user session receives its own temporary directory. Possible values for this setting are 0 or 1. Change this value using the Use per session directory server setting in Terminal Services configuration. Indicates whether the session directory for this server is active.

Indicates whether the server advertises itself as the terminal server. Indicates whether the system is running in application compatibility mode. In addition to individual values, this path holds several subkeys that, in turn, contain keys and values for Terminal Services configuration. In Table 6. They play a key role in configuring the RDP protocol and user sessions. Because some keys might exist in several hives, they should be explained in more detail. It is impossible to list and explain all keys in this book, so the following tables show only a selection of the most important configuration options.

They can be found in one or more of these registry hives:. All default Terminal Services configuration settings, for example, automatic logon data, time limits, initial program, etc. Adjusts the specific commands for the prompt: Change logon , Change port , Change user , Change winsta , Query appserver , Query process , Query session , Query user , Query winsta , Reset session , and Reset winsta.

Table 6. Flags are binary values that make a statement true 1 or false 0. Inherit the setting on the terminal server to reset the connection when the connection was ended from another source. Inherit the setting on the terminal server to start an initial program upon logon from another source. Inherit on the terminal server the maximum time after which disconnected sessions are ended from another source. Inherit the setting on the terminal server whether a new connection can be made only from the same client from another source.

Inherit the setting on the terminal server, whether the session is ended upon reaching a session limit or upon disconnection from another source. If you do not set this flag, the session will be simply disconnected. You can reconnect from the same client only as you did previously.

This value becomes effective only if you set the fInheritReconnectSame flag. The session ends when a session limit is reached or the connection is broken.