May 1, 2000 / Focus / Christa Anderson
Using Win2K's Terminal Services to administer
terminal sessions and remote servers
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.
If you choose the View the user's session option, the person
remotely controlling the session won't actually control the session
but will be able to see what the original user is doing. The person
who set up remote control can't use the mouse or keyboard in this
type of remotely controlled session. This option is a helpful
troubleshooting tool if you want to help a user correct a problem
but you don't want to manually interfere. However, I find that
the Interact with the session option is typically more useful
than the View the user's session option.
Remote Control Capabilities
Because you can take remote control of a terminal server session
only from another terminal server session, you need to log on to
a terminal server on the network. The remote control option in the
Terminal Services Manager and the Shadow command-line utility won't
work from the console. (Additionally, you can't shadow the console
from a terminal session. If you need to use the console, just log
on with the appropriate privileges.) After you're in the session,
you can remotely control a user's session in two ways: from the
Terminal Services Manager or from the command line.
To use the GUI, start a terminal server session and log on using
an account with administrative privileges. From within the session,
start the Terminal Services Manager in the Adminstrative Tools
folder. In the window that opens, select a terminal server in
the left pane and switch to the Users tab to display user sessions,
as Screen
4 shows. (The green icons indicate the server
that you're working from.) Find the session you want to shadow,
and choose Remote Control from the Actions menu. (Alternatively,
you can choose this option from the pop-up menu that appears when
you right-click on the connection or from the toolbar button that
resembles a monitor.) A dialog box prompts you for the hot-key
combination you want to use to end remote control of your own
session (so that you can return to the original session). If the
Remote Control option isn't visible, you're probably trying to
take control either of a console session or from a console session.
Again, shadowing works only from an RDP session, even if you must
make an RDP session to the server at which you're sitting.
If you've configured the user session to require user permission
for control, a dialog box will appear on the user's screen, stating
that user X in domain Y has requested permission to control the
session. If the user permits the control, you're in charge of
the session—your session will take over the user's session.
If the user doesn't permit the control or waits longer than about
30 seconds to accept it, an error message informs you that you
didn't receive permission to control the session. The degree of
remote control you have over a user's session depends on the user
account settings you've already set.
The command-line utility that lets you take remote control of
a user session is called Shadow, after the name that WinFrame
and MetaFrame use for remote control. The utility's syntax is
as follows:
shadow {<session name>
| <session ID>} [/SERVER:<server name>] [/v]
To use Shadow, start a Terminal Services session with administrative
privileges. To find the session ID or session name of the user
whose session you want to shadow, open a command prompt and type
query user <username>
or
query session <username>
in which username is the name of the person whose session you
want to control. You can't shadow based on username; therefore,
even if you know the logon name of the person whose session you're
shadowing, you'll need the session ID or session name.
If you're shadowing a session on the terminal server to which
you're logged on, the command syntax for shadowing Session ID
1 is
shadow 1
If that session requires user permission for remote control, you'll
see the following message while your session waits for permission
to take over the remote one:
Your session may appear frozen while the remote control approval
is being negotiated.
Please wait...
After you have permission, you're in the remote session, just
as if you had used Terminal Services Manager.
I recommend using Terminal Services Manager at least once before
trying the command-line utility. The Shadow command doesn't prompt
you for a hot-key combination to end remote control and return
to your session. (The default hot key is Ctrl+*.) Shadow uses
the hot key that you defined for the GUI; you need to create and
memorize that hot-key combination before you can use it with Shadow.
Make sure you know the key combination you'll need to return to
your own session from the shadowed one.
Added Functionality
If you're interested in trying out multiuser Windows, Win2K's Terminal
Services is for you. But Terminal Services means more than just
getting a free copy of WTS to play with. Win2K brings some needed
functionality to the tool—including remote control support—and
also introduces a mode that lets you manage your Win2K servers remotely,
even from a computer that doesn't have Win2K or even NT installed.
If you haven't yet experimented with this Win2K feature, now's the
time to do so.
