Tools for the Control Freak

One of Windows 2000 Server's (Win2K Server's) new features is Terminal Services. If you've been performing server-based computing for a while, you'll appreciate the availability of a multiuser version of Windows 2000 (Win2K). And if you've been considering how server-based computing might fit into your environment, you'll appreciate RDP's new capabilities, which simplify session management. However, even if you don't intend to use server-based computing, Terminal Services can be useful. With Terminal Services, you can remotely administer one or many Win2K servers from one console—even if that console isn't running Win2K.

The ability to remotely administer a computer is valuable. No matter how well a user describes a problem, diagnosing a symptom or explaining a fix is often simpler if you can see exactly what the user is doing, then walk the user through the necessary steps to resolve the problem. However, if you have a large user base to support, visiting workstations and standing over users' shoulders is time-intensive and impractical. And you need to perform some server management away from the server. Many, but not all, of the snap-ins in Win2K's management console let you choose the server you want to manage. And if some of your servers are running Windows NT 4.0 (i.e., not Win2K), the tools' remote-management capabilities won't help you if you're working from one of the non-Win2K servers. In either case, you're left walking across the office to perform server maintenance. Exercise is a good thing, but you can find better ways to get it than by hurrying back and forth between computers.

Until now, NT hasn't offered remote-administration capability for either servers or user desktops. You can buy third-party packages that let you remotely manage a server or remotely control (shadow, in Citrix's terminology) terminal sessions, but neither capability has been part of the core OS. Win2K still doesn't offer remote administration for end-user desktops, except for desktops in terminal sessions (i.e., you can't use the remote control tools to control a user's desktop unless that desktop is part of a terminal session). However, Win2K now includes tools that let you manipulate the server or user terminal sessions from anywhere on the network—even outside of the office. For remote server management, Win2K offers Terminal Services in Remote Administration mode, which gives you two administrative connections to the server. For managing remote user sessions, the OS offers the Remote Control tool or Shadow command-line utility.

Remote Administration for Servers
Even if you don't plan to introduce Terminal Services to your organization's users, you can still benefit from Terminal Services' remote administration capabilities. One major benefit of terminal server support before Win2K was that it let you remotely manage one or many servers from one console. However, this benefit applied only to servers running Windows NT Server 4.0, Terminal Server Edition (WTS), so you could use it to manage only terminal servers, not all servers. In contrast to WTS's single mode for terminal services, Win2K's Terminal Services features two modes: Application Server mode, for people who need to run an application server; and Remote Administration mode, for people who want an ordinary server (e.g., Web, print, file, mail) but want to manage it remotely.

Managing a server in Remote Administration mode has one distinct advantage over using an ordinary terminal session to manage the same server: You can manage a server that isn't an application server and thus is still optimized for serving typical server requests. When you install Terminal Services on a Win2K server in Application Server mode, the system modifies thread priorities on that server to give foreground applications most of the computing time, thereby making the server more responsive to user needs. Each foreground application in each terminal session has the same priority, so control of the CPU goes to each foreground application in turn. (You can edit this option from the Control Panel System applet: On the Advanced Tab, click Performance Options and specify whether you want to optimize performance for applications or background services. However, I don't recommend changing this setting because applying a setting that doesn't match the kinds of requests that the server gets will affect its performance.) Giving priority to foreground threads is a good idea for a terminal server but not a good idea for a network server that must satisfy all user requests—whether they're running in the foreground or the background. Running Terminal Services in the default Remote Administration mode sets the server to give equal priority to all major tasks, no matter where they're running.

Enabling Terminal Services
The process of enabling Terminal Services in Win2K is straightforward whether you're planning to run it in Application Server mode or Remote Administration mode. To install the service, open the Control Panel Add/Remove Programs applet on the server you want to monitor and choose Add/Remove Windows Components. Win2K lists the services that are available for you to install, as Screen 1 shows. Scroll down the list, and you'll see two services that pertain to Terminal Services: Terminal Services and Terminal Services Licensing. If you're installing Terminal Services for an application server, you'll need to install the licensing service somewhere on the network. (For more information about Win2K Terminal Services licensing, see "Windows 2000 vs. NT Terminal Server Licensing," February 2000.) However, if you're installing the service for remote administration, you don't need the licensing service—Terminal Services in Remote Administration mode comes with two connection licenses, which you can use to log on to the server for administrative purposes.

Pick the services you want, then click Next to choose whether to install Terminal Services in Application Server mode or Remote Administration mode. Win2K copies the appropriate files from your CD-ROM, and you're ready to go.

In case you're wondering, you don't need to load the server with memory to support Terminal Services in Remote Administration mode any more than you usually would. If you're accustomed to assuming that terminal servers require huge amounts of memory and processor speed, that statement might surprise you. Terminal servers are resource-hungry because they support multiple users, all of whom are running applications and storing data in memory. Because each server supports only as many as two Remote Administration terminal connections, and because you're not likely to run user applications on a server, these conditions won't apply. For example, a mail server with Remote Administration enabled needs only the resources you would usually assign to a mail server.

Terminal Services also has a client component, and you'll need to install the client on each computer that you'll use for remote administration. Although installing Terminal Services creates a Terminal Services Client Creator (located in the Administrative Tools group), I find this tool frustrating because it creates only 3.5" disks and the installation files require two disks (or three disks if you need the client program for 16-bit Windows). I recommend that you share the folder that contains the client files (i.e., %systemroot%\system32\clients\tsclient\net) with the network. The \net folder contains the Win32 and Win16 folders. Run setup.exe in the appropriate folder to install the client and add its icon to your Programs folder. Notice that the \net folder supports only Win32 and Win16 clients. A Linux-based client is now available in some Windows terminals (although I haven't found one available for download), and a Java-based RDP client is available at http://www.hob.de/www_us/produkte/connect/jwt.htm. However, these clients are still rough around the edges, and their creators have based the protocols on the RDP 4 display protocol in WTS, not on RDP 5 in Win2K. In general, if you plan simply to perform remote administration, you'll probably be working from a Windows client.

Using Remote Administration
If you're not familiar with Terminal Services, the simplest way to connect to a server you're administering is to open the Terminal Services client in the folder of the same name. If you don't see the name of the server you're looking for in the list of available servers, type its name (or IP address) into the dialog box that appears. Click Connect, and use the Typical Domain Logon dialog box to log on to the server.

The only differences between ordinary terminal sessions and remote administration sessions are as follows: In Remote Administration mode, you get only as many as two connections to a server and you must log on with administrative privileges to the server's domain. After you're logged on, you can do anything on the server that you have permission to do, including shutting down the server. (If you haven't used Terminal Services before, be careful when shutting down a remote server. The logoff options Shut Down and Restart mean exactly that; they don't mean "Log off this session.")

Just because you can remotely administer Win2K terminal servers doesn't mean you always should. Administrative utilities that require frequent graphical updates don't work well with terminal sessions. Generally speaking, avoid applications that require such visual updates (e.g., status bars)—or use the command-line versions of those applications. For example, the graphical version of Microsoft Backup includes an animation of papers shuffling from one folder to another. This animation is fine for local display but looks jerky when you view it through a terminal session. If you can't run the utility from the command prompt, try minimizing the utility while it's working so that the screen updates don't need to show animations. If you have server tools that depend on color depth greater than 256 colors (which works fine for Win2K's native tools) or sound, you'll find Terminal Services inadequate. At press time, terminal sessions don't support more than 256 colors, and Win2K's display protocol (i.e., the pipeline that transmits application output to the terminal client, as well as mouse and keyboard input to the terminal server) doesn't support sound.

One utility that you should never run from a terminal session is the Performance Monitor component of System Monitor. First, running Performance Monitor minimized is pointless because the utility's purpose is to give you visual clues about what is going on with the computer you're monitoring. (However, setting up some kind of event logging is fine.) Second, running Performance Monitor from a terminal session produces little benefit; when you run an application from a terminal session, you're still running the application on the terminal server—Performance Monitor is simply displaying output on the remote computer, not running the program there. Generally, you'll want to run Performance Monitor across the network from another server's instance of Performance Monitor so that you can evaluate system stress without adding the stress that the monitoring tool creates.

Remote Control of Terminal Sessions
When you need to troubleshoot, the ability to take remote control of a user's terminal session is very handy. Rather than try to talk someone through a series of commands, you can take over the user's session, manipulating it from your session while also displaying your actions to the user. The user whose session you're controlling can watch you manipulate his or her screen, and the user maintains the ability to use the mouse. You can also use remote control to spoof a user's identity to install an application for one user.

If you're familiar with Terminal Services, you probably know about Citrix's session shadowing and Microsoft's remote control—in other words, the ability to take over one terminal session from another terminal session and either manipulate the original session or see what the owner of the original terminal session is doing. This ability is a very useful troubleshooting and training tool.

To define the settings for the type of remote control you want to take, go to Active Directory Users and Computers on the domain controller and select the Remote control tab of a user's Properties sheet, as Screen 2 shows. (The same settings are available from the RDP Properties sheet in the Terminal Services Configuration tool.) If you edit the settings on a per-user basis, the options you choose apply only to a particular user. If you edit the settings on a per-display protocol basis, the options apply to all users of that display protocol.

First, you must specify whether you want to enable remote control of the session. (By default, you can take control of any session, no matter what rights the session's user has.) You also need to specify whether the user must explicitly permit the takeover before the remote control can begin. If you select the Require user's permission check box, the user who originated the session will see a message box stating that user X of Y domain is attempting to control the session; the user can accept or refuse the control, as Screen 3 shows. If the user refuses the remote control connection or doesn't grant permission within about 30 seconds, you won't be able to control the session, even from an account with administrative privileges.

The final option on the Remote control tab determines the level of control you have over a user's session. You'll find that the Interact with the session option is most useful for troubleshooting purposes—you can show the user how to do something or simply perform the task while the user watches. Choosing this option means that both the original user and the person with remote control over the session can send mouse clicks and keystrokes to the terminal server for interpretation. The terminal session displays graphical output on both the original session and the remote control view of the session.

   Previous  [1]  2  Next