Terminal Services

This module discusses the Terminal Services component built into the Microsoft® Windows® 2000 Server operating system. Topics include:

• What Terminal Services are

• How Terminal Services are deployed, including installation, policy, and security

• Scaling, including building an infrastructure that will support Terminal Services and tools that will help you do it

• Licensing issues and the License Manager

• Running applications with Terminal Services

The simplest way to describe Terminal Services is to compare it with what it is not. In the usual networked PC infrastructure, all the processing is done locally and the data transfers are handled on the back end. Terminal Services, on the other hand, focuses all of the application processing in the server on which it is installed and then shares out the user interface.

From the client's point of view, the processing is done remotely; the only actions handled locally are things like the display, the keyboard, the mouse, and so on. In many ways this is reminiscent of the mainframes and terminals of the 1970s.

However, there are a couple of big differences between that approach and Terminal Services. First, obviously Windows 2000 Terminal Services has a graphical interface, not a character-based interface. So users experience the full richness of Windows 2000. Second, Terminal Services isn't recommended for very thin clients, such as green-screen terminals. (Although many customers do use Terminal Services in this way, on what are called WBTs, or Windows-based terminals.)

Regardless, Terminal Services–based clients are fairly "dumb" devices, self-contained boxes that communicate with the server using RDP (remote desktop protocol). RDP is a T120-based protocol similar to the one used for the Microsoft NetMeeting® conferencing software. While NetMeeting has been optimized for streaming video, Terminal Services has been optimized for desktop presentation.

Terminal Services allows Windows 2000 to support many different usage situations, from a very powerful, "heavy" desktop running Windows 2000 Professional, to a very "light" Terminal Services–based desktop. Some organizations use both; they supply users with the more powerful desktop for the applications that they use every day as well as a Terminal Services–based desktop to supply access to applications used less frequently.

Another common use is retail kiosks. For example, the outdoor outfitter REI runs Terminal Services on the kiosks in its stores and connects the kiosks back to the corporate network.

Terminal Services usage falls into two main categories: application serving and remote administration.

Although Microsoft's original intent in marketing Terminal Services had been application serving, we've found that many customers also use it for a mode of administration. They deploy Terminal Services on a box that administrators can connect to in order to run tools and administer services.

Tools such as Microsoft Management Console (MMC) already let you do remote administration in your services, so what is the value of remote administration through Terminal Services?

For one thing, in some cases this method of remote administration is much more efficient.

Very often one of the first things MMC does is to enumerate a whole list of servers all across the network. If you have a big network, that's a lot of servers. And if you're dialing in over a 28.8-Kbps modem, it can take a long time to enumerate all those servers and send them to you. If you're using Terminal Services, all that enumeration is going over the LAN, not traveling across that thin pipe. Plus, all that's coming to you is the resulting screen, which is really very small.

What's more, MMC and many of these local remote administration tools don't work well across forests, physical plants, or any place where the remote admin tool isn't well connected to the servers.

Terminal Services fixes that. You can dial up to any of these machines and access them as if you were sitting there. So you can use a Terminal Services–based desktop to connect across servers or to multiple locations, and thus administer a much larger pool of servers.

A number of improvements have been made to Terminal Services in Windows 2000.

• Integrated with the Operating System. Now Terminal Services is a built-in part of Windows 2000, rather than a separately licensed product as it was previously under Windows NT® 4.0.

  This integration has several important ramifications. Externally it means that you don't have to buy separate pieces. You don't have to keep track of separate service packs for Terminal Services and Windows 2000. Internally it means the end of the security issues, current level access issues, and other issues associated with having Terminal Services residing on top of the operating system and essentially behaving like an application.

  As a result of this integration, Terminal Services is more efficient, more robust, and more secure.

• Multilingual User Interface. The integration with Windows NT also enables Terminal Services to take advantage of Windows NT features more easily than it was in the past. For example, Windows 2000 allows you to run the language of your choice just by installing the language packs that you want. When a user logs on, the display is presented in the language you chose. So the same Terminal Services–based client can be used for multiple users, even if those users work in different languages.

• DCOM Support. Another improvement that stems from integration with Windows 2000 is DCOM support. Now, as part of Windows 2000, Terminal Services supports DCOM activation modes, which provides much more powerful remote computing capabilities.

But Terminal Services doesn't benefit just from the integration with the operating system; a number of improvements have been made to Terminal Services itself.

• License Management. License management is a tool for administering and enforcing Terminal Services Client Access Licenses as users log on.

• Adjustable Scheduling. This feature, which involves issues such as how time slicing is arranged, allows you to select whether your Terminal Services–based server works more like a server or more like a workstation, depending on the purpose of the box. If it's used for remote administration, it should act more like a server. If its purpose is solely to serve productivity applications, it should act more like a workstation. And, because there's a range of functionality in between, you can set up your scheduling accordingly.

• Security Tuning. Because Microsoft wants Terminal Services to run with a great many applications, extensive security tuning has been conducted to help ensure wide compatibility while providing a very secure environment. For example, you know have some added capabilities that help you pick the right level of security for your system.

• MSI Integration. Microsoft Software Installer (MSI) allows you to publish applications to the Terminal Services–based server or out to the clients that are run on the server.

• Remote Administration Mode. Recognizing that many of our customers use Terminal Services for remote administration, Microsoft has created a special mode of operation to support that use.

As mentioned previously, Terminal Services supports two different modes. The traditional application sharing mode was discussed previously. In this mode, a series of clients come in and connect to the server. In application sharing mode, the server runs some fairly heavyweight code that manages the registry, manages multiple spaces for users, tries to separate the applications—all the functionality required to allow application sharing.

In the second mode, remote administration, Terminal Services is not meant to be run on a machine that's serving up applications; it's meant to be run on servers running Microsoft SQL ServerTM, Microsoft Exchange Server, and so on.

The goal of remote administration in Terminal Services, therefore, was to recognize that different kind of use, as well as to recognizes that this machine is being utilized not by end users but rather by one administrator. Now, when this administrator gets paged at 2:00 A.M. because the server is down, she doesn't have to get in the car and drive—she can log on through Terminal Services and check out the situation. In short, remote administration mode tries to address this audience's particular needs.

Because remote administration mode has been optimized for this task, it doesn't include the application sharing code, install mode, application compatibility code, and the like. It has a very low impact on CPU resources and requires very little memory. If nothing is actually running, the connection is idle.

And because this mode isn't meant for application sharing, it is limited to two connections. (As many as three people can be connected: two at each of the remote connections, and one at the console.)

Finally, the client that is used for remote administration can be any of the Terminal Services–based clients: Windows CE, Windows 2000 Professional, Windows 95/98, etc.

Another remote administration improvement is the upgrading of the RDP protocol that Terminal Services uses to communicate. RDP version 5.0 ships with Windows 2000 and is going in new clients as they're released. Some of the features that have been added to RDP 5.0 include:

• Printer Redirection. When a client machine connects through Terminal Services, any printer connected to the client will be recognized, the driver will be installed, and that printer will automatically become the default. To illustrate, imagine you're sitting at your home computer, which is running Windows 2000 Professional and has an HP inkjet printer installed. You can log onto your office network through Terminal Services to analyze a spreadsheet on the network. When you print the spreadsheet, it prints out on the printer sitting right next to you, not the office printer.

• Session Remote Control. This feature allows an administrator to connect to a user's session, see what the user sees, control the mouse and keyboard input, and so on. This is a great help-desk or collaboration feature. It's a very good way to monitor new users.

• Clipboard Redirection. This allows a user on a fat client (a Windows-based PC) to cut or copy text and graphics from an application running on that PC and then paste into an application running in the Terminal Services session.

  Clipboard redirection also works with big objects like files and folders when you install an extension available in the Windows 2000 Resource Kit.

  

  Windows CE–based Client. Support for two flavors of Windows CE–based devices has been added to Terminal Services:

  • Support for Windows-based terminals, such as those from Wyse or NCD, comes preinstalled on the machine.

  • Another client runs on the larger H/PC (Handheld PC) devices. Certain problems arise when devices smaller than H/PCs try to run Terminal Services—for example, the logon dialog box doesn't fit on the screen. The Terminal Services product group is working with the Windows CE team to get this to work on some of the smaller portable devices as well.

• Virtual Channel Support. This is a fancy name for enabling developers to use the same pipe that speaks to the server. In a sense, it works like named pipes. The approach is very simple: When a user connects to the server and runs an application that knows about Foo, a DLL within the application just says, "I'm looking for this pipe named Foo," and the application and the pipe talk to each other. This feature would be useful for solutions that send, for example, bar code scans or accessibility devices down the pipe.

By default, all of the Terminal Services components are installed on the server. That's the first part of installation; next Terminal Services needs to be enabled. The first thing Terminal Services asks is whether you want to run in remote administration mode or application serving mode. You don't need anything else that isn't already available after you've installed Windows 2000 Server.

To install Terminal Services, go to Add/Remove Programs under Settings, and under Windows address, Windows components, you'll see a Terminal Services alliance. Here you can add and remove the client creator files. If you don't select this option, you're not installing the client elements on that machine.

There are only three main screens involved in installing Terminal Services.

1. Once you say OK to the previous dialog box, the next dialog box asks whether you want remote administration mode or application serving mode.

2. In the next step, you pick the permissions you want to use with Terminal Services. This steps highlights the finer tunability of Terminal Services referred to previously. Windows 2000 does a good job of making the system more secure through things like locking down the registry. The trade-off is that many legacy applications in installing themselves write to places in the registry that they probably shouldn't be writing to. Therefore, in this step you can decide whether to go with the stronger Windows 2000 security model or the weaker, but more compatible, Windows NT 4.0 model.

3. The last screen is the application warning screen.

   In Terminal Services, applications are set up in install mode. Install mode manages the registry and some other features associated with application installation, mostly to control legacy applications that aren't very strategic about where they put their Reg Keys. Install mode allows the creation of compatibility modes, so that, for example, when one user changes her icons they don't change for other users, or when she sets her screen location, she's not setting it for everyone else.

   The app warning screen displays installed applications that may have associated issues. You'll want to note this set of applications because you probably will have to remove and reinstall them when the Terminal Services installation is complete.

At this point, Terminal Services is installed and ready to roll, although you still have to make sure that your users have access. When setting up Terminal Services in application serving mode, all the users on that computer have logon access by default. If you install remote administration mode, by default only the administrators have access, although that can be changed. Also, if you accept all the defaults in Windows 2000 installation, all the users on a computer are the domain users, so Terminal Services permits all the users to log on.

By default, all domain users can log on to Terminal Services, which is probably appropriate for most cases. This can be changed, however.

One of the ways to change logon access is through the Permissions tab in the Terminal Services configuration program. Here, as in any other security management tool, you can add users and groups and assign or take away whatever permissions you choose.

You can also change logon access on a per-user basis. On the user's system, go to the Security tab, look at its Terminal Services capabilities, and allow or disallow logon.

Session settings also need to be set up. These settings control various aspects of how the server handles client connections to it:

• How long can a user stay logged on?

• How long can a user stay on and not be doing anything?

• Does the server allow disconnected sessions, and if so, for how long?

A disconnected session is a session that is still active although no user is receiving or sending information—there's no user connection involved with it. Some organizations allow it because it can be enormously useful, from the user's standpoint. For instance, disconnected sessions allow a user to be in the middle of composing a Microsoft Word document, then get up and go home. When the user gets home, she can log on to Terminal Services, and the system will connect her in the same session, with the document exactly as she had left it.

But this kind of power has a price. Supporting disconnected sessions opens you up to the possibility of having all users connected all the time. If you need to support 100,000 users, your servers need to support naturally occurring peak loads, not everybody at the same time. Therefore, these session settings allow you to specify, for example, that a user who's been idle for 30 minutes will be disconnected, and that any session that's been disconnected for more than 15 minutes will be logged off.

Obviously, Terminal Services has a user component as well. Once users' Terminal Services–based clients are set up, they follow these steps to start a Terminal Services session:

1. The user logs on to a local computer.

2. From the local computer, the user starts a Terminal Services session.

3. The client is connected to a particular Terminal Services–based server.

4. The user logs on through the usual logon dialog box.

5. The user starts an application.

It's that simple.

There are two ways to install Terminal Services on client machines:

1. One way is to create clients to distribute to users. You can share that folder out or copy it to a share that users can access to install the components themselves.

2. Another way to do it is to copy those folders to CDs or floppy disks, and send those disks to those who need them.

There are also two ways for a user to initiate a Terminal Services session: Terminal Services Client and Client Connection Manager.

Terminal Services Client

The Terminal Services Client is great for one-time or occasional connection to a server.

Client Connection Manager

On the other hand, Client Connection Manager lets the user create and save configurations for that client, which simplifies using the same connections over and over again. Once Terminal Services is installed in the client system, all the components needed to install Client Connection Manager are available in the System applet, found in the Terminal Services Clients section of the Clients area.

A list of all the servers that can be found is presented, and the user can set the configuration for all the desired connections. For example, some may be connecting over slower links, so you'll want to turn off caching.

An important facility of Terminal Services is license management—that is, ensuring that all of the clients are properly licensed and that they've got the necessary Client Access License (CAL). In application sharing mode, the license agreement with Terminal Services stipulates that every machine that connects to the Terminal Services–based server must have a Terminal Services Client Access License.

Terminal Services therefore provides mechanisms to enforce licensing compliance. These mechanisms give you the ability as an administrator to buy the right number of licenses and to manage the licenses properly for your organization.

Note: If the server is configured for remote administration mode, license management does not apply. License Manager and CALs are not necessary.

The three components of license management in Terminal Services are the License Service Cell, Terminal Services itself, and the Clearing House.

• The License Service Cell runs on a domain controller, if you're in a Windows 2000 domain; this is for discoverability reasons. If you're not on a Windows 2000 domain, the license service can run on any workgroup peer. This service pulls down Client Access Licenses from the Clearing House (see below), stores them, and distributes them to clients as needed. The license service has the ability to give 90-day temporary licenses. It will report to the administrator how many temporary licenses it has granted so that when real licenses become available you can backfill the temporary ones.

• Terminal Services requires the license service to be installed. Every time a client connects, Terminal Services looks for a license, and if it doesn't find one, it requests one from the license server. Terminal Services starts looking for the license service as soon as it's installed. It also has a 90-day grace period, so that if it doesn't find a license server, it will continue to run for 90 days. But at the end of 90 days, if no license server has been found, unlicensed clients will not be allowed to log on to Terminal Services.

• The Clearing House activates the license server, which provides a server certificate so that it can be communicated with later. The Clearing House also issues CALs under a variety of licensing programs. It supports the four main Microsoft license-purchasing programs: the Microsoft Select, Enterprise, and Open agreements, and off-the-shelf retail license purchasing. The Clearing House has to be able to connect to the license server in order to register the server and in order to fill it with CALs.

The Terminal Services License Manager supports the four main license-purchasing programs at Microsoft: the Microsoft Select, Enterprise, and Open agreements, and off-the-shelf retail license purchasing.

This tool also supports four different ways to get set up:

• Over the Internet. The Internet connection is a direct connect from the server over the Internet to the Clearing House. This connection does everything for you.

• Over the Web. The Web method is fairly easy because you can cut and paste the required information. This method requires an Internet connection, but not from the server you're administering your license from. It's very easy to do this if you've got an Internet connection from a machine that can administer your domain controller and also connect to the Internet. That connection to the Internet could be temporary, for instance over a dial-up line.

• By Fax. The fax method is fairly easy because it involves filling out a form.

• By Phone. This one is a little arduous because you have to communicate fairly long strings of numbers back and forth over the phone with a phone representative.

The License Manager has a reporting feature that shows what licenses have been distributed, how many are available, and the different kinds.

In planning how to build a Terminal Services environment, there are a number of important considerations:

• How will the environment be used?

• Where will the data reside? How will the data that users access be managed?

• How will you define the policy?

• How big does the installation need to be? How big do you think it will grow to be?

When Terminal Services is being deployed in application serving mode (as opposed to remote administration mode) usage can be divided into a couple of categories:

• Line-of-Business (LOB) Application. For the purpose of this discussion, line-of-business refers to an application that is more or less the focus of the Terminal Services–based client. For these applications the state of the client system is not tremendously important. A good example is a point-of-sale system or a warehouse entry program: A user enters a transaction and then walks away.

• Remote Desktop. Compare this situation to a remote desktop, where a user may run several applications at the same time, so the state of the system is incredibly important.

When the environment is being used for a focused application, you can deploy just that application. That's all the user is exposed to. But when the environment is being used to deploy a remote desktop, you are essentially allowing the user to do anything that a desktop can do, unless you take steps to manage that. For example, with Group Policy and the Active DirectoryTM service, you can specify which icons are displayed and which actions are allowed.

Another tool for application security management is AppSec, which enables you to list just those applications with fully qualified path names that the user is allowed to run. Every time users try to run an executable file, it's compared against that list; if it's not on the list, they can't run it. Because AppSec helps prevent users from running Command.exe and other programs that could jeopardize the system, it is a very powerful tool for locking down the desktop.

Although many different models are evolving, the remote desktop is a popular approach for ASPs today, perhaps because it is currently a lot easier to do than LOB applications. But Microsoft is working on making both of them quite easy to deploy.

The first thing to keep in mind about data storage in a Terminal Services environment is that, in most cases, user data should not be kept on the server running Terminal Services:

1. First, a large system with more than 100 to 200 users is probably going to have more than one server. If data is stored on the server, you have to assign user A to server one, user B to server two, and so on. In a sense, doing this defeats the purpose of the Terminal Services environment, because users can no longer connect to whatever terminal is available, and still get to all their data, policies, and so on.

2. Second, if the data is moved out of the server running Terminal Services, the application environment can be managed differently from the data storage environment. And that makes sense—the application environment should be sharable, while the data storage environment should be very reliable, so it needs backups, etc.

Another issue of data storage is profile management. Terminal Services includes two profile management capabilities:

• The Terminal Services profile points a user to a particular server whenever he or she logs on.

• A roaming profile follows a user throughout the system, regardless of where he or she logs on.

If a user has a Terminal Services profile but no roaming profile, whenever she logs on to a Terminal Services–based server, that path will be used to retrieve and manage her profile. However, when she logs on to a regular workstation, she will just be logged on to the local machine. If the user has a roaming profile, the user profile will always be retrieved from that specified store, no matter what she logged onto. If the user has both types of profiles, the Terminal Services profile applies on servers running Terminal Services and the roaming profile applies everywhere else.

Roaming profiles and Terminal Services profiles can be used together or separately, depending on what seems most appropriate. So you can mix and match those as needed. The profiles are set up through Active Directory and Group Policy snap-ins, which house the profile and the My Documents folder, respectively.

Note: Because of the specific ways in which Terminal Services is deployed and used, it doesn't support clustering in the conventional sense. Instead, Microsoft recommends clustering in the network load balancing sense, where servers are put together in a farm and shared out among users as required. If your data storage method enables that kind of clustering, mechanisms must be in place to allow users to find their data. These mechanisms include roaming profiles or Terminal Services profiles, and home directory management using Active Directory and Group Policy.

This diagram shows a typical deployment. Note that:

• A number of Terminal Services–based servers are all running the same applications for end-user access; the servers use a router or some other method to provide load balancing among them.

• Separate from the servers are the domain controllers, where the licensing is handled.

• Another distinct component is the user data storage. The diagram shows this on one machine, but it could be a series of machines, for example, in a storage area network.

• Also separated out is the business environment, the servers running SQL Server, Exchange Server, and the other back-end services.

In a way, the typical deployment is kind of a three-tier environment.

As discussed previously, policy can be used to manage profiles. Policy, particularly the IntelliMirror® management technologies, can also be used to publish applications out of a Terminal Services–based server. Keep in mind, however, that this publishing method is per machine, because IntelliMirror doesn't support the per-user concept within the Terminal Services environment. Although all the general policy statements specify what the user can and can't do, often administrators want to apply different policies to terminals than to regular workstations.

Therefore, Microsoft recommends that you separate your Terminal Services users into an organizational unit, give that OU a certain set of policies, and then use the loop-back feature within Group Policy. Loop back allows you either to merge the machine policy you specified with the user policy, or to use that machine policy instead of the user policy. In this way, you can create an environment that differs according to whether the user is on a workstation or on a Terminal Services–based client.

This variable environment can be useful. For example, some administrators believe that Terminal Services environments provide security advantages to systems set up to allow outside users to call in to the enterprise. An administrator may want to limit what these users have access to, in order to protect mission-critical information, government documents, or what have you. The variable environment can be fairly effective in this way.

An earlier section talked about AppSec, the tool that enhances the security provided by Windows 2000. Beyond this tool, access to databases, files, folders, applications, and so on, is controlled by the Terminal Services configuration and through users' access control lists (ACLs).

When employing these methods, think carefully about system elements you really want to lock down—like the system directory, the registry, and program files—to protect them from user interference in a multiuser environment.

The last consideration in planning a deployment—that is, the size of the installation—is perhaps the most important.

Determining how many servers you need in a Terminal Services environment is a lot like determining how many Web servers you need. It depends on what they're going to do. What kind of experience do you want users to have? What does the network look like? What programs are users going to run? How fast do users type? These things matter a lot in figuring out the size of the installation.

Although the scalability testing that was conducted for Windows 2000 was extensive, it focused on a few user scenarios. The results of the test showed enormous variance—for example, that a standard 500-MHz, four-prop kind of box could handle 125 to about 300 users. And that support depends on what those users are running.

The point is not to go by Microsoft's testing, but rather to conduct your own evaluation. The Windows 2000 Resource Kit delivers the same scalability tools that the Microsoft labs use, so that you can do some planning, build models that you think are right for your situation, and evaluate the results in a way that's most meaningful to you.

There are three parts to these scalability tools:

• SmClient is a plug-in that snaps into the Terminal Services–based client and allows it to be scriptable. It includes constructs that allow the client to send keystrokes, wait for things to come down the pipe, and so on, just as in any kind of scripting environment.

• On top of that lies the RoboClient, which automates the process. Sitting at a console running RoboServer, you can use RoboClient to make the SmClients run these scripts, start at a specific time, type at a certain rate, and so on. Then you can send off all the SmClients and collect statistics about them.

• QueryIdle is very useful in debugging the scripting process because it tells you when a terminal has been sitting idle for a while. Usually an idle period indicates a problem in the script.

Although SmClient can be used for both mouse and keyboard input and output, it should be avoided with mouse output. Because mouse output can be dependent upon the size of the screen, a popup that's come up, or something similar, it's much less predictable and therefore can invalidate your script. Unless you're actually trying to test particular mouse movements, it's much more reliable to go with keyboard strokes.

This testing gleans information like delays between clients.

The Microsoft testing approach is not to see how many clients can be added before the system explodes, but rather to test it until the client experiences degradation.

Microsoft recommends that no more users be added to a server after the client experience drops below 90 percent of what it would be for a single user on that machine. This of course is a guideline, and you can set your degradation target wherever it makes most sense for your environment.

The infrastructure of the testing system looks a lot like this. It's a simplified Terminal Services environment, with connections to all the necessary back-end servers. You can run multiple clients per client machine to simulate a much larger load than the number of clients would indicate. Finally, a control server sitting on top activates everything and records the results for you.

This chart shows the numbers that Microsoft has been seeing in testing Windows 2000 Terminal Services. The results are divided by the type of worker:

• Structured task workers type fairly fast and tend to do one thing at a time. They open an application, type a document, close the application, open a spreadsheet, work in the spreadsheet, and then close it, and so on.

• Knowledge workers, on the other hand, tend to have four or five applications open at once. They switch back and forth between open applications and don't generally open and close applications much. They may not type as fast as task workers, but they put more memory demands on the system.

• A data entry worker uses very focused applications such as point-of-sale solutions. Another category not shown here is that of focused data entry worker. This type of worker doesn't see the whole desktop, just the application. The numbers for focused data entry workers go a little bit higher than those for data entry workers.

When considering application compatibility in a Terminal Services environment, there are two key questions: "What applications will run under Terminal Services?" and "What's the best way to install them?"

• Applications that are well behaved run just fine. A "well-behaved" application pays attention to the difference between per-user and per-machine modes, whereas applications that are not well behaved do things like write per-user parameters into HKLM, the local machine registry, as opposed to HKCU, the user registry.

  Badly behaved applications do things such as keeping user files in common locations instead of per-user locations. They assume that the person who installed the application is the person who's going to run the application and therefore has the same permissions and so on.

• There are two ways to get into install mode. One is through the change user install, and the other is through Add/Remove Programs. (Of course, this only applies in application sharing mode; in remote administration mode, none of the sharing code is running, so no install mode is available.)

• A new feature in Windows 2000 helps protect against installation mistakes. If you try to install an application but you're not in Add/Remove Programs or not using Change User Install, a popup warns you to try the installation again using one of these tools.

Change User Install is done through the command line; when you're done, you have to go back and do Change User Execute to get back into regular operational mode.

However, Microsoft recommends that you use Add/Remove Programs rather than Change User Install whenever possible. Today the two methods are fairly equivalent, but in future versions a lot more will be done automatically through Add/Remove Programs. You'll be better positioned in the future if you get into the habit now.

This installation method won't work with all applications, however, especially the older ones. For many of these applications Microsoft has created two kinds of application compatibility scripts:

• Logon scripts are run each time the user logs on. They do things like map drives, or remap files to different locations. These scripts make modifications "under the covers" so that the application runs as it normally does, but when it thinks it's putting everything into the Temp directory, it's actually going into a specified data directory.

• Installation scripts are usually run right after the program is installed for the purpose of cleaning up registries, moving files around, creating new directories, and so on.

So far there are about 20 or 30 scripts, and more will be added in the Terminal Services area in the Windows Update Corporate Catalog.

In the future Microsoft expects that the scripts will be needed less and less, as applications are written to be more Terminal Services–aware, as opposed to just compatible. Microsoft Office 2000 is a great example of a Terminal Services–aware application, one that not only runs in Terminal Services mode, but also provides a great user experience in that mode. For example:

• When Office is installed for Terminal Services, it uses a much simpler startup splash screen. All the interface elements have to travel over a pipe—often a narrow pipe—so a flashy bitmap for the splash screen slows application startup without adding much value.

• Office has also modified its Office Assistant feature (aka, the dancing paperclip) for Terminal Services users. In a Terminal Services environment, the animated Office Assistant eats up bandwidth every time it dances around or makes noises. Office 2000 wants to give Terminal Services users the capabilities of that agent—the help and natural language functionality that it provides—so on Terminal Services, instead of installing dancing paper clips, Office installs something called a "still agent."

How does Office know that it's being installed on Terminal Services? Very simply, when Setup starts, it asks the operating system if Terminal Services is running. If it is, the Setup program notifies you that need to install in this special way, by using something called a transform.

A wealth of information about Terminal Services is available on the Microsoft Web site.