Introducing Terminal Services Tools

New toolkit yields utilities to create and manage clients

You've given in to the hype and intend to try out Windows 2000 Server Terminal Services, just to find out what all the fuss is about. From the Control Panel Add/Remove Applications applet, you've opened Add/Remove Programs, chosen Windows Setup to install a service, and scrolled down the list of available services to find Terminal Services. Install the service in Application Server mode, reboot, and you're ready to go. Right?

Not quite. Making terminal services work isn't just about installing a service. It's also about installing client-side support, viewing connection information, adding applications, tuning user and connection settings to define the level of control that an administrator has over sessions, and sometimes manipulating those sessions. Terminal Services provides tools for accomplishing all these tasks. Some, if not all, of the tools will be familiar to users of Citrix MetaFrame or WinFrame or Windows NT Server 4.0, Terminal Server Edition (WTS). But if you're trying out terminal services for the first time with Win2K, you might welcome an introduction to the contents of the toolbox. Table 1, page 62, lists Terminal Services' tools, which, unless otherwise stated, are in the Administrative Tools folder.

Prepare to Meet Your Creator
Terminal services won't do you much good until you connect clients to them. Most modern Windows terminals have an installed RDP, but PCs are an exception, and they're the most commonly used terminal-session client. You can use Terminal Services' Client Creator tool to create installation disks for a client, but I don't recommend doing so.

Instead, consider sharing the client installation files. Win2K Server's %systemroot%system32clientstsclientet folder contains a Win32 folder for 32-bit Windows (on Intel) clients such as NT Workstation and Windows 9x and a Win16 folder for 16-bit clients such as Windows 3.x. Share the entire contents of the net folder if you have both 16-bit and 32-bit

Windows clients on your network or only the appropriate subfolder if only one OS is on your network. The files aren't well organized, but if you tunnel to %installation folder%disksdisk1, you'll find a setup.exe program. Run it, and answer the questions to install the RDP client. Alternatively, you can email the contents of the appropriate folder to users and instruct them to run setup.exe.

Go Configure
After you install the client-side RDP software, the client is prepared to connect to Terminal Services, but you might want to do some more work before you let that happen. You can control on a per-connection and per-user basis how long a session can last, how long a session can remain idle before the system disconnects it, how long a session can remain disconnected before the system terminates it, and how someone can take remote control of a user session. You can edit client path and profile information on a per-user basis.

Let's start with the per-connection settings. In Terminal Services Configuration, click Connections to see a list of the connections the terminal server supports. We know that Figure 1 shows a server that supports only Terminal Services because only RDP-Tcp appears in the right pane. If you installed MetaFrame or Direct ICA on the terminal server, those listings would also appear. Right-click RDP-Tcp to open the connection's properties dialog box. You can use this box to edit any connection settings and specify whether the connection settings will override user settings.

The Terminal Services Configuration window also shows a Server Settings folder. Click it to see the window in Figure 2. The right pane lists settings that apply to all terminal server sessions, not just RDP sessions. These settings are only partially useful. For example, you can't switch between Remote Administration mode and Application Server mode without reinstalling Terminal Services. If you try to change this setting from the Server Settings interface, Win2K Server opens the Windows Setup window so that you can repeat the entire Terminal Services setup process. Also, don't bother installing Internet Connector licensing; only anonymous Internet users can connect to the terminal server using that license type. Generally, the default settings (a combination of settings you chose when you installed the service and ones defined for terminal services in general) work pretty well, except that I would turn off Active Desktop unless you absolutely need it—it's a resource hog.

User Preferences
If you want to use different profiles or home directories for terminal server sessions than you do for ordinary network connections, you can define these properties in a user's Properties dialog box, which Figure 3, page 64, shows. If you've set up terminal user accounts on a member server, you can access user account properties from the Local Users and Groups section of the Computer Management tool in the Administrative Tools folder. If user accounts are on a domain controller, you can access user account properties from the Active Directory Users and Computers tool in the Administrative Tools folder. The two dialog boxes look pretty much alike for the purposes of terminal-session settings; they're just in different places. The remote control, encryption, and other connection-related settings work the same way on a per-user basis as they do on a per-connection basis.

By default, any settings you configure on a per-user basis override those defined for the connection type. You use the connection configuration tool described previously to make an RDP connection setting override a user setting, but you must do this on a per-setting basis. No "override all user-specific settings" check box exists.

Administering some connection settings, such as profile information and home directory location, on a per-user basis makes sense. Unfortunately, even though you could manage some settings better on a group basis, Win2K provides no way to do this.

Giving and Taking Away Programs
Presumably, you'll want to run applications on your terminal server. Win2K has two tools for installing programs: the Control Panel Add/Remove Programs applet and the Change User text command. Both utilities put the terminal server in Install mode. The utilities copy some Registry settings to a key in HKEY_LOCAL_MACHINE. The installation program copies the settings to HKEY_CURRENT_USER when a user runs the application while the server is in Execute mode. (You click Finish after you install an application or type

change user /execute

at the command line to put the server in Execute mode.)

Terminal Services doesn't give you much control over the installation process. If you try to run an application's setup.exe routine, a nastygram tells you that you must use Add/Remove Programs and offers you a link to the applet. If you use Add/Remove Programs, Win2K installs the application in multiuser mode.

The Terminal Services Licensing utility is for keeping tabs on terminal sessions only. I explained how this tool works and how to set it up in "Windows 2000 vs. NT Terminal Server Licensing," February 2000. In brief, you need to run an activated license manager to let people access the terminal server. The licensing tool doesn't need to run on the terminal server itself; you can install it on any Win2K Server system.

Under Your Thumb
Thus far, you've learned how to use Terminal Services tools to create clients, configure connection and user settings, install applications, and license users. Your users are happily typing away in their terminal sessions. But what if something goes wrong? Win2K Server includes Terminal Services Manager (which Figure 4 shows) to help you track who is using the terminal server, what processes they're running, and their connection status.

The left pane shows all the domains in the network and all terminal servers within those domains. (You can use this tool to manage any listed terminal server; you don't need to be physically at the server's console.) The contents of the right pane depend on what you select in the left pane. If you select the entire network or the domain, the right pane displays all current connections to terminal servers (active or disconnected), along with the name of the server hosting each connection. If you select a terminal server, the right pane displays all current connections to that server. If you select a username, the right pane shows all the processes running in that user's context or information about the user session. Notice also that the right pane is tabbed, and the contents of the tabs depend on whether you've selected a domain, server, or user on the left.

A short period of poking around will teach you where to find the information you need. Table 2, page 66 , should also help—it lists some of the information available on the different tabs. More important is discovering what you can do with Terminal Services Manager. Let's look at an example of how to use the management tools to see what is running on the server, send messages to users on the server, terminate remote processes, and close user sessions.

Suppose you want to find out whether anyone is playing TSQuake (a bogus Terminal Services-compliant version of the popular game Quake). From Terminal Services Manager, select the terminal server or domain that you want information about. The right pane displays a tab listing users currently logged on to the terminal server, a tab showing the current active and disconnected sessions, and a tab showing the processes currently running on the terminal server. Everything you need to discover which user and which process identifier (PID) are associated with which session, and how busy that session is, is here.

Click the Processes tab associated with the domain to see a complete list of all processes running in the domain, the server they're running on, the session they're in, and the name of the user who owns that session. This tab also shows the PID, which comes in handy when you need to terminate processes from the command prompt. The only way to identify a specific application instance is by its PID.

After you have your list of people running TSQuake, you can let them know they're caught. You can send a message to one or more individuals, even across domains, from the Terminal Services Manager interface or from the command line. To send a message from Terminal Services Manager, select the terminal server. Then select the people to whom you want to send a message. From the Actions menu, choose Send Message to open the message dialog box. Compose your message, click OK, and the message will instantly pop up on the screen of the individuals you selected.

The Terminator
Gertrude and the other TSQuake players ignore your message. Time to get tough and terminate the application. Every instance of TSQuake that you close will exit immediately, with no warning to the user and no chance to save data.

To terminate one instance of an application from Terminal Services Manager, select the server or domain in the left pane and click the Processes tab in the right pane. All running processes will appear. Select the process you want to terminate, right-click Terminate on the Action menu, and choose End Process (the only option). The selected application instance will end immediately.

Instead of just shutting down an application from the terminal server, you might want to take control of a user session to see exactly what the user is doing. For example, if Gertrude says she didn't mean to run TSQuake but couldn't figure out how to shut it down after she started it, you could take control of her session to troubleshoot the problem. You can perform any action from your remote location that Gertrude can perform locally in the session.

You can take remote control of a terminal server session only from another terminal server session that is using the same display protocol—you can't control ICA sessions from RDP or vice versa. In addition, the remote control option in Terminal Services Manager and the shadow command-line utility won't work from the console. Therefore, to control another session, you must start a terminal server session and log on with administrative privileges. From within the session, start Terminal Services Manager. Select a terminal server in the left pane, then click the Users tab so that user sessions are showing. Find the session you want to shadow, then choose Remote Control from the Actions menu. A dialog box will prompt you for the hot-key combination to use to end remote control of Gertrude's session (so that you can get back to your session).

If you've configured Gertrude's session to require user permission for remote control, a dialog box will appear on the screen, letting Gertrude know that someone has requested permission to control her session. If she permits the control, you're in charge of her session and you can close the application. If she doesn't permit the control, you'll see an error message telling you that you don't have permission to control the session.

If you want to stop an entire terminal session, not just one process within it, you can disconnect or reset the connection. Disconnecting cuts the user off from the session but leaves all applications running and data in memory. Users can reconnect to the session they were disconnected from and be right back where they left off. A reset connection, in contrast, closes all open applications. Disconnected sessions still use some system resources, but not many because Win2K Server eventually pages their unreferenced data to disk and the sessions don't have new user input to process. Reset sessions use no resources.

To disconnect or reset a session from Terminal Services Manager, select the session in the left pane and choose Disconnect or Reset from the Action menu. A message box warns you that the session will be disconnected or reset. Click OK to end the selected session.

This article isn't an exhaustive tutorial about isn't Terminal Services. But if you're just beginning to think about setting up Win2K for server-based computing, it's a good look at the tools that are at your disposal.