Windows Insider
Get Terminal Services Up and Running
When installing this service, there are myriad options available. Be sure you choose wisely.
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.