Take Control of Your TSCALs!

One of the headaches of managing terminal servers is managing license allocation. Even after you resolve the legal aspects of license management, you must still make sure you give Windows Server 2003 and Windows 2000 Server Terminal Services Client Access Licenses (TSCALs) only to clients that really need them.

Certain changes to Terminal Services licensing in Windows 2003 make TSCAL allocation especially relevant. Per-user licensing is now an option, so you can associate TSCALs with individual users and solve the problem of misallocated licenses. However, the unlimited license pool available in earlier versions of Terminal Services is now gone, making the consequences of unauthorized computers connecting to terminal servers more serious.

Windows Server OSs currently have no way to manually return TSCALs to the licensing pool for allocation to another computer. At best, unused licenses revert to the licensing pool automatically—but slowly, taking up to 3 months to return to the database. At worst, they don't return to the license pool at all. Understanding how Terminal Services licensing works and knowing how to prevent unnecessary allocation of TSCALs can help you better control TSCALs and manage them more effectively.

How TSCALs Work
To control how Terminal Services issues TSCALs, you need a basic grasp of Terminal Services licensing. Licensing has three components: the terminal servers, their license servers, and the Microsoft Clearinghouse—the licensing database that activates all license servers and supplies additional TSCALs to license servers that request them. You need a separate TSCAL for each computer that connects to a server that's running in application server mode, although you don't need TSCALs to use one of the two permitted remote connections to a server that's running in remote administration mode.

When a user initiates a connection to the terminal server, the server checks whether the connecting computer has a license associated with it. If the connecting computer has a license, the terminal server lets the connection continue if the user has domain logon privileges and permission to connect to the terminal server. If the computer has no license, the terminal server discovers the license server—either by broadcasting in workgroups and SAM domains or by polling the domain controllers (DCs) in Active Directory (AD) domains—and requests a license. When the license server has a license to issue, it sends the license to the terminal server, which issues it to the client. The client then presents its license to the terminal server and makes the connection. If the terminal server can't connect to the license server, the terminal server can accept a temporary license from the client. If the client doesn't have a valid temporary or permanent license, the terminal server rejects the connection.

When a client disconnects from the terminal server, the client retains its license—the license doesn't return to a pool. Therefore, if you log on to the terminal server once from your office computer and again from your home computer, you use two separate licenses. You can't manually return these licenses to the license server because they're marked in the license server's database as given to a particular machine, which is identified by a globally unique identifier (GUID).

Win2K Server Terminal Services allocates TSCALs to computers, not to users or connections. Citrix MetaFrame XP, add-on software that enhances terminal server management and some client capabilities, is licensed per connection. (Yes, you do need both TSCALs and ICA per-connection licenses to access a terminal server that's running MetaFrame.) Allocating TSCALs to computers has its good and bad points. The benefit is that many people can use the same computer to access a terminal server and legally use the same TSCAL to do it. The drawback is that each computer that connects to a terminal server needs a TSCAL, whether it obtains that TSCAL from an unlimited license pool or from the license server. No client OS has a built-in TSCAL. Remember: After a TSCAL is assigned to a computer, you can't manually return that license to the license pool. This limitation has become both less and more of a problem with Windows 2003, which supports per-user TSCALs but no longer has an unlimited TSCAL license pool for Windows XP clients. (For more information about how licensing works and some specific licensing scenarios, see http://www.termservhub.com/other_resources/definitive_qa.php.)

Envisioning the loss of TSCALs to machines that have no use for them, you might decide to edit user accounts to restrict their access to the terminal server by unchecking the Allow Logon to Terminal Server box. This setting (found in the account properties on the Terminal Services Profile tab) sets you on the right track but doesn't necessarily stop the loss of TSCALs because the permission works on a per-user basis but the licensing works on a per-machine basis. Win2K Server Terminal Services and the default licensing for Windows 2003 Terminal Services issue TSCALs to computers, not users. If an authorized user logs on to a terminal server from a computer that has no TSCAL, the connecting computer uses up a TSCAL in the process.

Strategies for Taking Control
You can control access to terminal servers from both ends: from the server and from clients. Your objective is to prevent unauthorized machines from obtaining licenses and prevent terminal servers from handing out licenses they shouldn't. Use the following strategies to take control of TSCALs:

These strategies require some work but can save you money and hassles with licensing.

Allocate Licenses Only to Permitted Users
Although it's an imperfect solution, if you run Win2K Server, you can limit Terminal Services license allocation by installing SP3 or later (or SP2 with the licensing hotfix described in "Reclaim Unused TSCALs"). The new functionality prevents Terminal Services from allocating licenses to a client until the server authenticates the user to the session. If your users typically work from the same computer every day, installing the service pack or hotfix can help prevent unnecessary TSCAL allocation. Applying the service pack or hotfix also lets unused licenses slowly return to the licensing database for reallocation. The hotfix doesn't help you with already-allocated licenses, but it prevents future license "leakage" from terminal servers on which it's installed.

Restrict Access to the License Server
An annoying aspect of Terminal Services licensing is that a license server issues a license to any terminal server that requests one. If you have iron control over which servers run Terminal Services, blanket license issuance is a minor problem. However, if you can't control the creation of unauthorized terminal servers, you might find your server allocating licenses to people you never intended to have them and over whom you have no control. This lack of control is especially frustrating for domains that have servers in multiple locations and local site administrators because the person controlling the license server might not have control over the member servers at remote sites. Windows 2003 (but not Win2K, unfortunately) lets you use Group Policy to restrict terminal server access. Figure 1 shows a policy for the License Server Security Group, which you access from the Microsoft Management Console (MMC) Group Policy snap-in by navigating to Computer Configuration, Administrative Templates, Windows Components, Terminal Services, Licensing. By default, any terminal server can obtain licenses from the domain license servers. By enabling this policy, you can create a licensing security group of which terminal servers must be a member before they can get TSCALs from the license server.

To create a security group to restrict terminal server access to the license server, set the License Server Security Group setting to Enabled. Enabling this setting creates a local security group called Terminal Services Computers, which is initially empty. After you enable the policy, the Terminal Services license server grants licenses from the selected domain only to servers in this group, so you should add servers to the group as soon as possible.

Because Terminal Services Computers is a local group, you'll find managing the terminal servers easier if you put them in a global group and put the global group in the Terminal Services Computers group. Remember: Global groups go into local groups, not the other way around. Terminal servers that aren't members of the Terminal Services Computers group can't access a license server and thus can issue only temporary licenses. When the license server is a DC, Terminal Services Computers is a domain local group.

Prevent Users from Installing Remote Desktop Connection
Remote Desktop Connection is freely available for download from Microsoft's Web site and is easy to install. If you run Win2K Professional or earlier on the desktop, the only way to prevent users from installing Remote Desktop Connection is to ensure that they can't install their own software. In other words, if you don't want users to install Remote Desktop Connection, you must make sure they aren't members of their own local Administrators or Power Users group.

Prevent Users from Running Remote Desktop Connection
For Windows 2003 servers and DCs, you can use software restriction policies to prevent users from running Remote Desktop Connection. To prevent execution of Remote Desktop Connection, edit the domain security policy to add Remote Desktop Connection to the list of prohibited applications. To do so, use an account with administrative privileges to log on to a DC. Put all the computers that shouldn't run Remote Desktop Connection in an organizational unit (OU), then use the MMC Group Policy Object Editor snap-in to lock down Remote Desktop Connection for those computers. Navigate to Computer Configuration, Windows Settings, Security Settings, then right-click Additional Rules and choose New Hash Rule from the context menu to open the dialog box that Figure 2 shows. In the dialog box, browse for the application you want to deny—in this case, mstsc.exe. Although the Path rule might seem the better choice for restricting execution of Remote Desktop Connection, if the executable file that a software restriction policy restricts is moved to a new location, its software restriction policy no longer applies. A hash rule generates a hash algorithm based on the file's unique attributes, such as its size and when it was created. Thus, it doesn't matter whether users with access to the system32 subfolder move mstsc.exe, the executable for the Remote Desktop Connection program; they still can't run it.

Notice that you're editing the computer configuration, not the user configuration. You don't care whether users who are authorized to log on to the terminal server run Remote Desktop Connection; you just want to keep them from running the program on a computer to which you don't want to allocate a TSCAL. The catch, of course, is that this restriction applies only to computers that can recognize it (i.e., Windows 2003 servers and XP workstations), but that's better than nothing.

A user who tries to run Remote Desktop Connection after you've locked it down will see a message like the one Figure 3 shows. Note that the hash rule setting prevents anyone from running Remote Desktop Connection from the computer for any reason—even for remote administration purposes or to access a remote XP computer. You don't have an "only run Remote Desktop Connection if it won't allocate a TSCAL to this computer" setting.

Using this software restriction policy, however, doesn't remove the Remote Desktop Connection icon from the Start menu (although the user will see the option to remove the icon if it's on the Start menu) or Accessories folder. Thus, you must either delete the icon or be prepared for Help desk calls about it.

If you don't use Windows 2003 DCs but run XP on the desktop, you can edit the software restriction policy locally by using the MMC Local Security Policy snap-in. Because administrators can change the policy, editing it locally works better for users who aren't local administrators for their computers. You must reboot the computer for the policy to take effect.

If you run Win2K Server but don't use Win2K DCs and desktops, you can use Win2K Server Group Policy to prevent execution of Remote Desktop Connection, but it's less effective than a software restriction policy. A software restriction policy prevents the application from running regardless of how it's launched (e.g., from the Run command, from the command line, from Windows Explorer); group policies that restrict application execution apply only to applications that run from Windows Explorer. To prevent access to applications, you must also prevent access to the command prompt, Run, and Task Manager, which contains Run. Additionally, you can't prevent access to Run or Task Manager for computers—only for users—or disable backdoors in applications (such as Microsoft Word's Web toolbar, which lets you browse for executables).

Restrict Terminal Server Usage
Terminal Services licensing is a complicated nuisance, and the fact that you can't manually reclaim accidentally allocated TSCALs makes it more of one. The good news is that you now have some methods to prevent rogue client computers or terminal servers from dispensing TSCALs to one and all.