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_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters 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.
End of Article
