As the news editor for Thin-Client UPDATE, I know that a lot of readers are gearing up for or have already started implementing Windows 2000 Server Terminal Services. Many of you have questions about enabling Terminal Services, connecting clients, authenticating terminal sessions, running applications, and licensing. As it turns out, some parts of Terminal Services can bite even those who have already been working with Windows NT Server 4.0, Terminal Server Edition (TSE). However, once you understand Terminal Services’ new features and how to configure your hardware and software, you can steer clear of the pitfalls.
Enabling Terminal Services
Terminal Services is an integral part of Win2K Server, Win2K Advanced Server (Win2K AS), and Win2K Datacenter Server (Datacenter). Rather than existing as a separate product like the multi-user version of NT 4.0, Terminal Services runs as a service like the Internet Information Service. To install the service, click the Add/Remove Windows Components button in Add/Remove Programs, choose Terminal Services from the list of available components, and follow the prompts in the wizard.
Be aware that some steps in this process can be confusing. First, in addition to installing Terminal Services, you can install Terminal Services Licensing. You don’t have to install both components for each terminal server—in fact, you don’t need to run the license server on a terminal server at all. In purely Win2K domains, the license server service must reside on a domain controller, and in a workgroup or NT 4.0 domain, the license server can be a member server—even the terminal server itself. However, performance can suffer if you make the terminal server a domain controller because the overhead of processing user logons will take CPU cycles from terminal sessions. Therefore, I suggest locating the license server somewhere other than on the terminal server in Win2K domains. (The license server, if it’s not obvious, must be a Win2K server.) However, you don’t need to dedicate a server to issuing Terminal Server Client Access Licenses (TSCALs) because it’s not a heavy-duty process and you only need to issue TSCALs once for each client.
Second, you’ll see the option of installing the terminal server in Remote Administration mode (the default) or in Application Server mode. Remote Administration mode is for ordinary servers that you want to be able to manipulate from a terminal server session, and Application Server mode is for true terminal servers. Be sure you pick the right option; otherwise, you’ll need to reinstall the service to switch modes.
Connecting Clients to Terminal Services
Terminal Services works with PC clients (which encompass most terminal clients), Windows terminals using RDP, and handheld PCs using RDP. With PCs, you need to explicitly install the client. When you install Terminal Services, Win2K adds several management tools to the server’s Administrative Tools folder, including a Client Creator for making client setup disks. However, this tool isn’t very useful. Instead, it’s easier to manipulate the installation files that Win2K stores in the %systemroot%\system32\clients folder when you install Terminal Services. Within the Clients folder are three subfolders: Win32, Win16, and Net. The setup files for Win32 clients (NT and Windows 9x) are in the Win32 folder, and setup files for the Windows for Workgroups (WFW)-compatible client are in the Win16 folder. The Net folder contains copies of the Win16 and Win32 folders so that you can share the Net folder instead of sharing the entire Clients folder. Everything you need to set up the RDP clients is in these folders—just run setup.exe. You can distribute the files in the same way that you’d distribute any client installation files. Start by sharing the folder with the network and run Setup. Then, either email the entire contents of the folder to everyone who will need the RDP client, or distribute the files with SMS or using Group Policy Objects. For local installations, you can also use the automated installation so that the user doesn’t have to interact with the Setup program—perhaps in a logon script that will run automatically. From the command prompt, make sure that you’re in the path for the right version of the Setup files on the terminal server and type
setup /q1
to install the RDP client. This method ensures that when the installation is done, the user has to click OK on the Installation was completed successfully box. To install without any user interaction, go to the command prompt and type
setup /qt
To uninstall the RDP client, type
setup /u /qnt
at the command prompt. Whichever method you choose, installing RDP support on the client computer will create a new program group called Terminal Services Client. This group contains a Client Connection Manager for creating and storing server connection settings and a generic Terminal Services Client tool for browsing for available servers.
Note that the RDP client setup files are only available for Windows clients on the x86 platform. If you plan to support non-Windows desktop computers using RDP, your only option is to use HOB's HOBLink JWT Java-based RDP client, which is available from HOB's English-language Web site and German Web site. HOBLink runs on any computer with a Java Virtual Machine (JVM). The client works well, provides the same capabilities as the native RDP client, and provides a similar interface.
Microsoft has released the Terminal Services Advanced Client (TSAC), a 32-bit Windows-based ActiveX control that lets clients connect to a terminal server from a Web browser that supports ActiveX controls. The company designed TSAC to let you use RDP to connect to applications published into a Web page, although the functionality that TSAC offers is more like MetaFrame’s Application Launching and Embedding (ALE) than it is like NFuse. You can download the new client from Microsoft's Web site.
If you plan to connect Windows terminals, the client you use will depend on how recently you bought the terminals. If you bought your hardware before February 2000, double-check the RDP version on the terminals—you might need to get a flash update from the terminal manufacturer. RDP5 is the Win2K client, while RDP4 is for TSE. You can still connect to Win2K terminal servers with the RDP4 client, but you won’t get all the features of the new client. If you were using TSE with the same clients (PCs or Windows terminals), you need to upgrade the terminal server and the client-side components of the display protocol. Otherwise, the clients can't take advantage of some of Terminal Services' new functionality.
Authenticating Terminal Sessions
In Terminal Services, terminal session authentication is similar to single-user client authentication, with a few differences. If you’ve set up your Win2K or NT servers in a workgroup—all as member servers—each server keeps a list of users who have permission to log on to that computer and the rights and permissions that those users have. So, every time a user connects to a new server, he or she has to log on to it separately. If you set up the servers in a domain, the domain controllers maintain the user authentication database. Once a user logs on to the domain, the user is in, just as they would be if logging onto the domain from a fat client. A user’s domain rights and permissions determine his or her level of network access, but that user doesn’t have to log in again and reauthenticate every time the user needs to connect to a new server.
What if you don’t want people using the same domain resources from their terminal sessions that they might have from regular client logons to the domain? Terminal Services adds a separate layer of security to this scenario: logging on to the domain or to a server does not automatically give a user access to the terminal server. Instead, a separate logon process exists, so the user must reauthenticate as a terminal server user, even if that user logs on with the same account name that he or she used to log on to the domain. This additional step serves the twofold purpose of letting the administrator use different parameters for terminal sessions from those needed for fat-client sessions and helps ensure that not everyone gets automatic access to the terminal server.
You can, however, set up client connections to automatically enter the user's username and password information when the user attempts to connect to the terminal server. When you create a client connection with the Client Connection Manager (which installs when you install the client), you can supply the username and password that you want to use to create that connection. To change the username and password associated with a preconfigured collection of user settings, right-click the saved connection and choose Properties. The username and password information is available from the General tab.
Terminal Services' New Capabilities
Terminal Services supports several new features, including clipboard sharing, printer mapping, and remote control (shadowing) of user sessions. With TSE, you could only get these features with the help of third-party products, such as Citrix MetaFrame or NCD ThinPath Suite. In addition to providing these new features, Terminal Services also supports a remote administration mode. Before you use these new features, though, be sure that you know what you’re getting into because they—especially automatic printer mapping—can lead to complications.
Shared clipboard data. Terminal Services now supports clipboard sharing between applications running on the terminal server and those running on the local computer, for clients logging on from a PC, and from a terminal with locally installed applications. However, it’s important to realize that Terminal Services doesn't really share the clipboard contents in the sense that the data is available on the local machine. Instead, to reserve network bandwidth, the terminal server sends the client a list of potential formats in which the clipboard data can appear. When the client-side clipboard requests that data with a Paste action, only then does the terminal server send the data to the client. As a result, shared clipboard information is not available if someone takes remote control of a terminal server session. Also, if a user ends the terminal session (e.g., disconnects, logs off), the user can no longer paste data created in a remote application to the user’s local documents. Finally, the data is not available in the terminal session if the user ends the session and then reconnects. Many applications ask whether you want to keep data on the clipboard when you close an application, but the terminal client doesn't give you that option. Make sure that users understand that data they've created in a terminal session will no longer be available once they disconnect from the terminal server.
Printer mapping. RDP in Win2K now supports client-side printer mapping to terminal server sessions. With this feature, clients with locally connected printers can use their printers from their terminal sessions. By default, clients use the local printer from their terminal sessions because it becomes the default printer for all applications in that session. For Win32 clients, the printer mapping is automatic. For Win16 and Windows terminal clients, you must manually map the printers.
However, although Terminal Services supports client-side printer mapping, you might not want to use it. When you print a file created in a terminal session to a client-side printer, the terminal server’s print processor handles the job (which means you must install the printer driver on the terminal server). The print processor then sends the rendered print job to the redirected printer port on the client. As a result, a rendered print job is much bigger than the file you’re printing. For example, my colleague Steve Greenberg took a 315KB .pdf file and printed it to a paused NT print queue. The spooled file was 7MB in size. A similar test with a 34KB .jpg file produced a 448KB spool file. Although data passed via display protocols is compressed, that’s still a lot of data to be pushing around on the network, especially if you’re using the same network segment that terminal session clients need to see their remote applications. And if your terminal client connects to the server via a dial-up connection, even a compressed 7MB job takes a while to travel through a 56KBps line. You can use Quality of Service (QoS) to give print jobs a lower priority than terminal server traffic, which will reduce the impact the print job will have on your interactive terminal sessions.
Terminal Services doesn't give users the option to map their printers for a particular session—if you enable mapping, then the printer is connected when the users log on to the terminal server. You can, however, disable printer mapping. To do so on a per-user basis, go to the Environment tab on the user’s Properties sheet and clear the box permitting printer mapping (or just clear the box making the client printer the default, if you prefer). To disable printer mapping for everyone using RDP, start by opening the RDP-TCP properties from the Terminal Services Configuration tool in the Administrative Tools folder. Next, go to the Client Settings tab to disable Windows printer mapping, which is necessary for automatic printer mapping. You will also want to disable COM and LPT port mapping if you want to ensure that clients can't manually map client-side printers.
If you plan to support client-side printer mapping, make sure that you have all the printer drivers you’re going to need installed on the terminal server, and use QoS to keep printer traffic from bungling up other connections. For information on QoS, see "Build a Better Network with QoS," Tao Zhou, November 1998. No matter how you slice it, printing to a client-side printer from a terminal session can be more trouble than it’s worth, so use this capability selectively.
Remote control. Terminal Services lets you control one user’s terminal session from another terminal session—a capability known as shadowing in MetaFrame. To use this feature, the user must either grant permission or have an account preset so that it doesn't require permission (a setting on the user’s Properties sheet). You can also edit the RDP-TCP settings in the Terminal Services Configuration tool to make all RDP sessions automatically accept requests for remote control. The person taking remote control must also have permission to take over the session. Remote control is a good Help Desk tool, letting you either watch what the user is doing on his or her desktop (perhaps while talking the user through some procedure) or taking over control and showing the user how to do whatever you're trying to accomplish. The person controlling the user session can toggle between his or her session and the user session using a key sequence that you choose when you initiate the remote control.
You need to be aware of a few catches when using the remote control feature. First, you can’t remotely control a console session or remotely control from a console session. Second, the two sessions must use the same display protocol (e.g., RDP, ICA). Third, if you've locked the machine running the terminal session that’s remotely controlling another session, the session being controlled might stop accepting user input.
Remote Administration mode versus Application Server mode. Terminal Services runs in either Application Server mode or Remote Administration mode. Application Server mode essentially turns the server into a multi-user Win2K Professional (Win2K Pro) computer in the way it handles memory and prioritizes application execution, which is how TSE worked. Remote Administration mode keeps the server acting like a server in terms of memory management and allocating CPU cycles. This mode allows only two administrative connections, rather than the many connections that Terminal Services allows when the server is in Application Server mode.
Just as you can’t serve applications to users in Remote Administration mode, you can’t use MetaFrame with Terminal Services in Remote Administration mode. If you try to install MetaFrame, the setup program will detect that the server is not in Application Server mode and prompt you to change the mode. Although it might appear that you can switch between the two modes without reinstalling the service, you can't. Toggling the setting in the Server Settings folder of the Terminal Services Configuration tool will only bump you back to the Add/Remove Windows Component section of Add/Remove Programs and make you reinstall the service. Reinstalling the service requires rebooting the server.
Running Applications
A few trouble spots can cause problems when you run applications designed for a single-user environment in a multi-user environment. Not only are single-user applications sometimes not designed to work well on a multi-user OS, NT isn’t used to dealing with the possibility of users running their application suites on several servers.
Most problems have to do with applications that expect to run on one computer and expect to be the only application in the foreground. As a result, these applications might hog resources and assume that one computer equals one user. One especially big problem lies with identifying users by computer identifiers (computer name or IP address) instead of by user logon name. Because applications run on the terminal server and only display on client machines, that data goes to all users or goes to the console.
Another problem has to do with how you configure user profiles, which let users store personal application settings, to work in a terminal server environment. A user can modify his or her profile while the user’s session is active, and the OS saves the profile when the user logs off. Organizations that deploy server-based computing almost always have more than one application server. You can set up static load balancing by assigning users to specific servers, but load balancing is often dynamic. So, when users log on or start applications, they’re assigned to the server that’s least busy—the criteria for least busy depends on how you set up your load balancing, but these criteria can include the amount of available memory and the number of jobs waiting for CPU cycles. In a dynamically load-balanced environment, users might not have an affinity for one server over another. Therefore, if a user connects to several published applications (i.e., not to entire desktops), that user might run one application from one server and another from a different server. If the user then edits his or her profile settings for both applications, one set of applications will be lost.
To get around the problem of configuring user profiles, you can use mandatory profiles or assign machine-specific logons and copy all the profiles to each terminal server. Third-party tools, such as Tricerat’s Desktop Management Services, can help you avoid the issue of profiles altogether. But if you’re using roaming profiles and server farms, you can encounter problems with saving per-user profile changes.
Administrators familiar with TSE might run into unexpected problems when using DOS applications. To improve performance on slow computers, some DOS applications constantly poll the keyboard buffer to see whether any data is waiting. This constant checking consumes a lot of CPU cycles. This resource use wasn’t a problem on the single-tasking computers that DOS applications were originally written for, and not an issue on multi-tasking computers where only one person was using the computer. However, in a multi-user environment, this behavior can bring a terminal server to its knees. TSE and NT 4.0 include a utility called DOSKBD that modifies a program's keyboard polling to improve system performance when you run DOS-based programs. Essentially, DOSKBD puts a DOS application to sleep when it polls the keyboard buffer too often and negatively affects server performance.
The catch—you knew that there was a catch—is that Win2K doesn't include a copy of DOSKBD, and the TSE version of the utility doesn't work with Terminal Services. Microsoft plans to include a Win2K-compatible version of DOSKBD with the Microsoft Windows 2000 Server Resource Kit. However, until then, users who need DOSKBD to keep DOS applications from running away with the CPU have a few options. One such option is David Thomas' Tame, a tool for tuning DOS applications in a Win2K environment. For tuning all applications, you might want to check out StartLow, a free utility from Tricerat and downloadable from the company's Web site. This utility automatically sets the process priority for applications running in terminal sessions to Idle so that they consume only CPU cycles when the CPU isn’t busy doing something else. For most applications, this change doesn’t impact performance.
Licensing Terminal Services
You probably know that Microsoft licenses TSCALs on a per-seat basis. Assuming you’ve activated the license server (i.e., registered with Microsoft), the first time any computer logs on to the terminal server, that computer gets a license in the form of a certificate. The PC then stores that certificate in the HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing\HardwareID Registry key. Whenever the PC attempts to connect to the terminal server, the server demands to see the certificate before allowing the connection. If the client machine can’t produce the certificate, the terminal server makes the client get a license from the terminal services licensing server, which then notes that it gave a license to that particular machine as identified by computer name or IP address.
Notice that the only time the client communicates with the license server is if the client doesn’t have a certificate to show to the terminal server. However, even if the only client machines connecting to your terminal server are running Win2K Pro and thus have already paid for a license, they’re still supposed to get their licenses from the license server. Without a license server, the terminal server can issue only temporary licenses, which supposedly expire after 90 days and no longer let you connect. (In my experience, the licenses don’t stop working after 90 days, but every time I log on, a dialog box tells me that my license has expired. In these instances, I suggest authenticating the license server so that you can get the official license.) The terminal server itself, of course, requires a Win2K Server license.
The Terminal Services licensing model is similar to the TSE licensing model. Win2K Pro computers can draw from an unlimited pool of built-in licenses, much like using NT Workstation clients with TSE. Win98 clients, Windows terminal clients, and now NT Workstation clients all need a per-seat TSCAL. However, one major difference separates licensing Terminal Services from TSE: You must have a working license server. That’s not the bad news. The bad news is that this certificate system doesn’t work properly if you reinstall the client OS, replace a machine, or use Windows-based terminals (WBTs) that don’t follow the Microsoft specification calling for the devices to keep the license in a non-volatile part of memory on the terminal. In addition, it's not always easy to restore the license server backup file to any machine other than the one where the database originated, as you might if the original machine crashes. Although these problems are not insurmountable, you must call the Microsoft license clearinghouse to resolve any of them, as you’ll see below.
The problems with license reclamation affect Windows clients more than non-Windows clients. Notice that Terminal Services stores the certificates on the client computer. If you completely reinstall the client computer OS, you lose that computer’s certificate. You can back up the Registry key where the client stores the license and restore it after reinstalling the client’s OS, but this approach is clumsy. Also, Microsoft isn’t keen on this approach because it’s an easy way to pirate licenses.
On a similar note, a PC can't release its license and return it to the licensing server. If you lease PCs, you lose the licenses that you assigned to those machines when you return the equipment. And if a consultant comes to your office for 1 day, uses his or her laptop to log on to the terminal server, and then leaves, the consultant's laptop takes one of your licenses if the laptop is running an OS other than Win2K Pro—that’s in the license agreement.
You can delete a license on a client computer, but doing so doesn't return the license to the license pool. Microsoft article "How to Transfer Terminal Services CAL from One Computer to Another" details how to perform a one-time transfer of a license to a different computer. However, to transfer a license, you have to call the Microsoft clearinghouse using the telephone numbers in the licensing tool—you can’t perform the transfer over the Web or via email. In my experience, the people at the clearinghouse are quick and responsive, but it’s still a time-consuming process.
Not all of these licensing issues affect all terminals. Most, but not all, WBT OEMs build their devices to Microsoft’s specification and provide an area of non-volatile memory for storing certificates. So, every time you cycle the power on a WBT that was not built to Microsoft’s specification, the hardware forgets that it has a license and asks the license server for another one. If you suspect this is happening, check the license server’s database for multiple entries associated with the terminals’ IP addresses or universally unique identifiers (UUIDs). Again, you can resolve this situation by calling the clearinghouse, explaining what happened, and asking for more licenses to install on the license server.
To back up the license server, you need to back up the System State data and the Lserver directory (which, by default, is in \\winnt\system32\lserver) while the licensing service is running. Restoring the license server to a server with the same SID restores the entire licensing database—licenses you’ve issued and those remaining to be issued. Restoring to a server with a different SID restores a record of only the licenses that you’ve already issued. If you are faced with this situation, look in the event log’s System folder to get the number and type of licenses not restored, and call the Microsoft licensing clearinghouse to have the company reissue the licenses. In other words, you can’t restore the entire database to a different server without help from Microsoft—but you can restore it.
What about MetaFrame and TSCALs? You need TSCALs even if you are connecting to the terminal server via ICA, which means that you need two licenses—one license is per-seat (RDP) and the other is per-connection (ICA). Because non-Windows clients don’t have a Registry where they can store TSCALs, the process works a little differently than it does for Windows clients.
Although a Citrix representative declined to explain how this process works, the license issuing relates to issuing the per-user licenses required to access a MetaFrame server. The MetaFrame licensing server has a mechanism by which it can determine whether it’s already issued a TSCAL to a particular client computer. Theoretically, if you use Symantec’s Ghost to make a copy of Linux that’s using ICA on a different computer, the ghosted copy won’t have a license. Also, if you wipe the disk clean and reinstall the original ghosted image, the machine will still have a license.
Can Win2K Provide a Complete Terminal Services Environment?
With Terminal Services' added features, one big question remains: Can you use Terminal Services on its own? Perhaps. Win2K Terminal Services works well, as long as you don’t need load balancing beyond Win2K AS's session logon load balancing, don't need to support anything but Windows clients, don’t need to push sound to the clients, and don’t mind terminal session windows that don't fit seamlessly into a PC local interface. It also helps if any WAN links you have to work with are high speed (think SONET ring, not 56Kbps dial-up).
Using Terminal Services on its own can simplify some terminal server issues. For example, if users always log on to the same server and run all their applications from the same server, they won’t lose changes to their profiles. However, if users connect to a MetaFrame server farm and run one application from one server and another from somewhere else, effectively opening two copies of their profile and only saving the changes made to the most recently opened one, you can run into problems.
Although supporting Terminal Services can be the right answer for many companies, there are a few points, as I’ve outlined in this article, that you need to watch out for. Terminal Services isn’t new, but it’s new to a lot of people who are now experimenting with it because it’s now part of their core OS. Therefore, using it effectively requires a different way of thinking and demands that you pay attention to some of the ways in which Terminal Services works. Server-based computing can reduce administration costs, but the model is different from client-based computing and the differences can bite.
