Get Terminal Services Up and Running

When installing this service, there are myriad options available. Be sure you choose wisely.

• By Michael Chacon
• September 01, 2001

As I discussed last month, the licensing considerations for implementing Terminal Services go beyond the normal legal aspects of deploying the software; they have a direct impact on the actual functionality of the service. This is to ensure that you have a clear licensing plan in place before you begin to deploy Terminal Services. That said, I'll explore the basic installation issues and the management tools of Terminal Services with the assumption that the licensing issues described last month have been resolved.

As with other Windows Components, there are at least two ways to get Terminal Services up and running. The most direct way is to open the Control Panel and click on the Add/Remove applet to bring up the installation wizard menu. The other way is to open the Configure Your Server menu option in the Administrative Tools menu under Programs from the Start menu, which brings you to the screen shown in Figure 1.

Figure 1. When you begin the Terminal Services installation process via the Configure Your Server menu option, you can access a wealth of information about the service.

This gives you access to a wealth of information about Terminal Services in an organized format. The screen describes the two basic modes of Terminal Services operation and provides a caution regarding the impact that Terminal Services may have on services already installed and running on the target machine. At the bottom of the page are links giving a detailed overview of how to install and manage Terminal Services.

We're Just Not Compatible
Regardless of the route, you'll ultimately get to the screen seen in Figure 2, where the Windows Components Wizard begins installation. As you can see, both Terminal Services and the Terminal Services Licensing server are available. Microsoft recommends not installing the Terminal Services License server and Terminal Services on the same server.

Compatibility is a consideration at this point, as Terminal Services doesn't always play well with others. For example, it's not allowed to run concurrently with Offline Files. I have Offline Files running and discovered the incompatibility when I selected the Terminal Services checkbox in the Windows Components Wizard.

Figure 2. Installation begins with the Windows Components Wizard. Both Terminal Services and the Terminal Services Licensing server are available.

Figure 3. Once you've solved all compatibility issues, you need to decide if you're going to use Terminal Services to manage the server remotely or run applications for remote clients.

After resolving any incompatible service issues, you next need to decide if you'll use Terminal Services to remotely manage a server or to run applications for remote clients (Figure 3). Keep in mind that you can't do both—it's one or the other. Also notice that the license for Remote Administrative mode is implicitly included in the Windows 2000 Server license. You only need to add a license server if you plan to have remote users running applications.

When you go down the application mode path, you face the same problem as users without special permissions who try to install applications locally. The problem is that installation programs commonly need to write to the registry. At a local machine, you have the option to install a program as the administrator, but even this doesn't completely solve the permission problem. Some applications write to the registry during normal execution as well as during installation. The same problem exists with Terminal Services, so you have the option to install Terminal Services to support previous versions that support this application behavior found in Windows NT 4.0.

As you can see in Figure 4, choosing the backward-compatibility option opens up the registry to all of the remote users. This is a serious security issue that must be considered before you deploy the system to the users. The solution, of course, is to only use applications designed for Win2K, but that isn't always an option, as there is commonly at least one application that requires backward compatibility.

Once you get past this decision, you're confronted with another reason not to install this service on a production server without thoroughly testing it first. As you can see in Figure 5, a startling caution is presented that clarifies the earlier warnings of potential application incompatibility with Terminal Services.

When you enable the Application mode of Terminal Services, you'll need to uninstall the applications on the server that you want to make available and reinstall them using the Add/Remove Programs applet. If you have a machine like the one in Figure 5 that has many applications already installed on it, you should try using a mirrored image of the machine and see what impact Terminal Services has on your applications before installing it on a production box.

Figure 4. If you choose the backward-compatibility option, the registry will be open to all remote users, which presents a serious security issue.

Figure 5. As you continue through the installation, a caution clarifies the earlier warnings of potential application incompatibility.

After Figure 5, you'll be presented with the final screen that gives you one more opportunity to back up the wizard to make any changes. Once you click on the final wizard screen, reboot the server to finish enabling of the service.

Cool New Tools
When the server reboots, you'll have three new menu items in the Administrative Tools menu. The first one is the Create Installation Disk utility. This utility is used to make the client installation disks. There's an option for a 16-bit Windows and a 32-bit Windows client.

Another menu option is the Terminal Services Configuration Manager. You can use this utility to change the various options available for the service by clicking the choices shown in Figure 6. The only change you can't make here is the Terminal Server mode, which must be done from the Add/Remove Windows Components menu. You're notified of this requirement when you click on that option and are presented with a shortcut to the Windows Components Wizard.

Figure 6. The Terminal Services Configuration Manager allows you to change a variety of options that are available for the service.

The final tool and menu option is the Terminal Services Manager, which monitors the users, sessions and applications each Terminal Server is hosting. As you can see in Figure 7, the window provides the familiar two-pane view with the target domains and machines in the left pane and the results of actions in the right pane. Under the Action menu are the various options available to manage the terminal server.

Figure 7. Using the Terminal Services Manager, you can monitor the users, sessions and applications each Terminal Server is hosting.

The Action menu includes a number of options:

• Connect—Enables you to connect to a user's session. You can only be connected to one session at a time, but you can have multiple active sessions and toggle between them.
• Disconnect—Removes a user from a session. However, the session that was running remains active, and any applications continue to run. Thus, if you disconnect and then reconnect from a different location, your session remains intact.
• Remote Control—Allows you to watch or control a user's session, giving a warning before entering the user's session. This is for security reasons.
• Reset—Allows you to end a user's session if it's stopped responding or has other problems. This can cause data loss, so use it as a last resort.
• End Process—Allows you to end a specific application or process without ending the entire session. This can also cause data loss.
• In addition to these functions, the Terminal Services Manager also provides aggregate views of what's occurring on the server or in the domain. To see this information, select the server or domain in the left pane and then select either the Processes, Users or Sessions tab on the right pane. Each tab displays similar as well as specifically related information such as session IDs, process images and users associated with each server.

Best Practices
There are obviously more details you need to know before deploying Terminal Services in a production environment, and I can't cover all of those here. However, the following is a list of Microsoft-recommended best practices for terminal server that are good starts for your exploration of this niche service.

• Don't install Terminal Services on a Domain Controller or other heavily utilized server. Because you're running all processes for the remote users on a Terminal Services server, it will be fully taxed and can't afford to share resources with another service.
• Use NTFS to gain control over each user's data areas. The FAT file system is less secure, possibly giving users access to inappropriate areas of the server.
• Use the specialized tsshutdn command, instead of the normal Shut Down command found on the Start menu, to close Terminal Services. The tsshutdn command issues a warning to users that the server's shutting down, giving them a chance to save their data. The normal shutdown process doesn't provide this courtesy.
• Be sure to keep an eye on your license server, as discussed last month. Remember that terminal server won't run for more than 90 days without an authorized license server.

The Windows 2000 Deployment Planning Guide has a complete chapter on Terminal Services, and you'd be well served by reading it. The key point to remember is to set up terminal server in a lab environment and test the applications you plan to use, then see how they behave in your environment. Terminal Services can play an important role in your enterprise, but it does have some unique, and potentially dangerous, characteristics.