Terminal Services in NT 4.0 Domains

You don't have to scrap your existing NT 4.0 network to benefit from Win2K's Terminal Services

A great deal of Microsoft documentation seems to assume that one Windows 2000 server in a domain means that all servers in the domain are Win2K computers. But unsurprisingly, not everyone running Win2K Server Terminal Services is running it in a completely Win2K environment. As the news editor and a columnist for Application Service Provider UPDATE (formerly Terminal Services UPDATE), I receive a lot of email from people who are considering adding a Win2K Application Server (which includes Terminal Services) to a Windows NT 4.0 domain. To address some of those frequent questions, let's discuss two common headaches: managing user accounts and configuring a license server to function in an NT 4.0 domain. (For more information about how to set up a license server, how to use Terminal Services in Remote Administration mode, and various configuration options' effects, see "Related Articles in Previous Issues.") First, though, I'll answer a few basic Terminal Services questions.

The Basics
Users often ask me four fundamental questions about Terminal Services. Let's look at the answers to those questions before discussing common problems running Terminal Services in an NT 4.0 domain.

Should I upgrade to Terminal Services? The answer to whether you should upgrade from NT Server 4.0, Terminal Server Edition (WTS) to Terminal Services depends on your needs. Terminal Services includes some of the basic functionality that WTS lacks, including support for client-side printer mapping and clipboard mapping between local applications and applications on the Terminal Services system. In addition, Terminal Services uses memory more efficiently by reserving a smaller range of addresses for each terminal session. Microsoft also provides add-ons that extend Terminal Services' functionality. You can use the Microsoft Windows 2000 Server Resource Kit File Copy (rdpclip.exe) and Drive Share (drmapsrv.exe) tools to gain support for copying files between terminal sessions and applications running on the client and for client-side drive mapping. With the Terminal Services Advanced Client (TSAC, which is available for download from Microsoft's Web site and on the Service Pack 1—SP1—CD-ROM), you can run a terminal session within Microsoft Internet Explorer (IE) 5.0.

However, WTS supports DOSKBD, a tool that lets you prevent DOS applications from polling the keyboard for input, which slows the terminal server. Terminal Services doesn't currently support this functionality.

Most WTS users run the software with Citrix MetaFrame. If you're using WTS and the bare-bones features of MetaFrame 1.8, perhaps you can replace WTS and MetaFrame with Terminal Services. However, if you're using MetaFrame for Web-based publishing, a server farm that contains both Windows and UNIX applications, printer-driver management, stress-based load balancing (rather than the location-based load balancing that Win2K Advanced Server supports), or support for non-Windows clients, you'll need to continue using MetaFrame. Although the latest version of MetaFrame, MetaFrame XP, will work with WTS, Citrix recommends that you upgrade to Terminal Services because the company has developed MetaFrame XP for Win2K.

Can Terminal Services exist in an NT 4.0 domain? Win2K servers of any stripe can exist in an NT 4.0 domain. The only catch is that any functionality that depends on Active Directory (AD) won't be present in the NT 4.0 domain because AD is available only if you're using Win2K domain controllers (DCs).

Does Win2K need SP1 or Win2K AS to support Terminal Services? A few people have asked me whether Terminal Services is truly part of Win2K Server. (I suspect all the hype about TSAC might have caused some confusion.) You have the option to install Terminal Services as part of the core OS. You can install Terminal Services as part of an unattended installation, or you can manually install the service after the initial Win2K installation. To perform a manual installation, go to the Control Panel Add/Remove Programs applet and click Add/Remove Windows Components. Win2K will display a list of the available services. Terminal Services and the Terminal Services licensing service will be in this list. You don't need SP1 or Win2K AS to install the service, although using SP1 is still a good idea.

Do you have to install Terminal Services on a DC? You don't have to install Terminal Services on a DC; in fact, if you're using the service in Application Server mode, don't install it on a DC if you can avoid it. A terminal server is busy running applications, so it doesn't need to spend CPU cycles or memory authenticating users. Maintaining user accounts on an NT 4.0 DC raises complications in a terminal server environment, which leads us to the problem of making NT 4.0 user accounts work with Terminal Services sessions.

User Account Management
Terminal Services has account properties (e.g., session timeout settings, whether to disconnect inactive sessions, shadowing settings) that are specific to terminal sessions. NT 4.0 predates Windows terminal services, so terminal-session—specific settings aren't visible in NT 4.0's User Manager for Domains. To configure these settings, you can maintain per-server accounts on the Terminal Services systems or edit NT 4.0 domain accounts to accept terminal-session—specific settings.

You can set up accounts for Terminal Services sessions on the terminal server (i.e., don't make the terminal server a DC, but make the accounts server-specific). Then, if users want to use the terminal server, they can log on to their terminal server account and use that account's session settings and environment variables.

This solution is OK as long as you don't mind maintaining two sets of user accounts—one for regular domain logons and one for terminal sessions; however, this maintenance might become cumbersome. Terminal servers can't share per-server settings, so if you have more than one terminal server, you'll need to duplicate those accounts on each server or assign all users a particular terminal server to use. Both of these options require a lot of administrative work.

An alternative to trying to maintain multiple user accounts is to make the NT 4.0 domain accounts accept terminal-session—specific settings. You can do so using the User Manager tool. (For account management, Win2K uses the Microsoft Management Console—MMC—rather than User Manager. However, Win2K lets you access the User Manager functionality to manage NT 4.0 accounts from Terminal Services.) To run this tool, type

usrmgr

at a command prompt on the Terminal Services system. This command opens the window that Figure 1 shows. (If more than one domain is available, the system will prompt you for the name of the domain.) As you can see, this tool is similar to the WTS User Manager for Domains. You can use Terminal Services' User Manager interface to edit user accounts, configure auditing, and set up trust relationships.

The difference between NT 4.0's User Manager for Domains and Terminal Services' User Manager becomes evident when you double-click a user account to edit it: You'll see that a TS Config button has been added to the row of account management buttons at the bottom of the User Properties dialog box. Click this button to open the User Configuration dialog box, which Figure 2 shows. From this dialog box, you can enable or disable access to the terminal server (access is enabled by default), tune the timeout settings, specify which client-side devices will be available to terminal sessions, tell the terminal server what to do in the case of a broken or timed-out session, and configure ICA shadowing settings. These settings are for mixed-environment client sessions, and Terminal Services applies them as such. For example, the reference to shadowing is for ICA shadowing; if you want to configure RDP shadowing, which Terminal Services supports but WTS doesn't, you must do so on a per-connection basis from the Terminal Services Configuration tool. Settings such as client-drive remapping don't apply if MetaFrame isn't installed because Terminal Services doesn't support those settings without MetaFrame's help.

Be aware that using Terminal Services' User Manager on an NT 4.0 DC can lead to registry bloat. One reader informed me that he performed fairly extensive tests to discover how different methods of creating user accounts affected the size of the SAM. He discovered that creating accounts with Terminal Services' User Manager increased the size of the SAM by as much as 177 percent for 2000 accounts. Even when he didn't provide the terminal-session—specific information for an account, Terminal Services' User Manager set aside space for the information in the registry. Thus, if you have a large user account database and limited registry space, be careful about editing user accounts with Terminal Services' User Manager.

If registry bloat isn't a cause for concern, you can use Terminal Services' User Manager on an NT 4.0 system to set up NT 4.0 domain accounts that accept terminal-session—specific settings. To do so, copy the following files from %systemroot%system32 on the Win2K terminal server to the same directory on an NT 4.0 DC: usrmgr.exe, utildll.dll, winsta.dll, and regapi.dll. These files are also on the WTS CD-ROM. (If you want to keep the original User Manager for Domains on the NT 4.0 DC, rename usrmgr.exe on the DC before you copy Terminal Services' User Manager to the system.)

License Servers in an NT 4.0 Domain
License servers are another consideration when setting up Terminal Services in an NT 4.0 domain. In a purely Win2K environment, license servers must be DCs, whereas in an NT 4.0 domain that includes Terminal Services, the license server can be on a Win2K member server.

When a computer tries to connect to a Terminal Services server, the server checks for the client computer's terminal services client access license (TSCAL). If the client computer doesn't have one, the terminal server attempts to communicate with the license server to obtain a license for the requesting computer. The license server allocates a license, which the client stores in its registry to the client computer, and notes the allocation in its license database. If a terminal server can't find a license server, the terminal server will issue clients temporary licenses that expire after 90 days. After these 90-day licenses expire, the terminal server won't issue a second temporary license and will stop accepting connections.

The process of license discovery works differently in pure Win2K domains than in NT 4.0 domains that include Terminal Services. To discover a license server in a mixed environment, the Terminal Services server broadcasts its request for a license server to the domain. All license servers that hear the request respond, and the terminal server picks one license server at random. However, if the license server is in a different domain, across a trust relationship, the terminal server's broadcast request might not reach the license server, and the terminal server might give up and issue a temporary license. You can't tell from the client side, but if you look in the terminal server's event logs, you'll see event ID 1010 in the System log. If you see this event, check to ensure that WINS or DNS is working. If it is, then the problem is probably that the terminal server can't find the license server in the different domain.

To avoid this problem, you can tell the terminal server explicitly which license server to use. To do so, use regedt32 to open the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTermServiceParameters registry subkey, click Edit, Add Key, and create a value named DefaultLicenseServer of data type REG_SZ. Set this value equal to the name of the license server. You can also use this method to speed the discovery process for a terminal server in a pure Win2K domain that needs to connect with a license server in a different domain.

If It Works, Keep It
Just because you want to gain the benefits of Terminal Services doesn't mean you must scrap an existing network that's meeting your needs. I've addressed some of the questions I receive most often about how to use Terminal Services in an NT 4.0 domain as well as two headaches to be aware of in this scenario. Although Terminal Services won't work exactly as it would in a pure Win2K domain, adding Terminal Services to an NT 4.0 domain is a viable solution for mixed environments and a great way to gain the benefits of Terminal Services without the hassles of a Win2K migration.