Licensing is probably the most dreaded component of any environment’s implementation. In Terminal Server environments, you must account for both OS licenses and application licenses. Licensing is really no different from non-Terminal Server environments, except that Windows Server 2003 has technical components that force you to comply with your licenses. If you decide to ignore it, you’ll most likely revisit licensing in 120 days when your Terminal Servers stop functioning because they weren’t licensed properly. Terminal Servers running on Windows 2000 were the first to use Microsoft’s new licensing enforcement technology, and Windows 2003 builds on that.

The only thing that changes faster than technology is the licensing of technology. For that reason, it’s important to note that this licensing paper was up-to-date when it was written. However, it’s possible that the details of Microsoft licensing have changed since then. You can find current information on the web at www.microsoft.com/licensing or www.brianmadden.com.

This paper concludes with a look at how third-party applications are licensed in Terminal Server environments.

Terminal Server 2003 Licensing Overview

Before addressing the technical components that will make up your licensing infrastructure, let’s review Microsoft’s licensing policy. Microsoft licenses can be divided into two groups:
Licenses required for each server.
Licenses required for clients.

Terminal Server implementation will require both client and server licenses.

Licenses Required for Each Terminal Server

Microsoft requires one license for each server in a Terminal Services environment. This license, known as a “server license,” is just the standard Windows Server 2003 license—you don’t need anything special to run Terminal Server. It is the same license used for the base server operating system of any Windows 2003 server—whether that server is an Exchange Server, a SQL Server, or a file and print server. However, unlike some Microsoft server applications that require specific server licenses (like Exchange or SQL Server), no additional server licenses are required to use Terminal Server.

Some features (as described in require the “Enterprise” edition of Windows Server 2003. For those you would need an Enterprise version of a Windows Server 2003 license for your server.

Microsoft Terminal Server Client Access Licenses

Before you get too excited about the fact that you don’t need a special server license to run Terminal Services, remember that you’ll need a client license for everyone that connects to a Windows 2003 Terminal Server.

Prior to Windows Server 2003, a Terminal Server Client Access License (TS CAL) was required for every computer device that connected to a Terminal Server. This licensing system is known as “per device” licensing. Microsoft defined one “device” as a unique piece of hardware used to access a server. If you had two computers and you accessed the same server from each of them, you had two different devices and needed a separate “per device” license for each. Such was the case even if you never used both devices at the same time. Naturally this method of licensing elicited numerous complaints.

In Windows Server 2003, Microsoft added a second TS CAL option. This “per user” client licensing option allows you to purchase one license for each user account. A user can then access a Terminal Server from multiple client devices using one license. “Per user” TS CALs are associated with user accounts, so two users cannot share a license even if they never log on at the same time. If two users share the same physical computer, then it might be preferable to employ the “per device” license option discussed in the previous paragraph.

Microsoft also offers an “external connector” Terminal Server client access license that you buy for a server and lets you connect an unlimited number of non-employees to the server.
Let’s look at the three different Terminal Server client license options.

Option 1. Terminal Server “Device” Client Access License

Terminal Services licensing has traditionally been handled by the Terminal Server device Client Access License (TS Device CAL). One license is assigned to each specific client device. Each unique client device that accesses a Terminal Server requires a single TS Device CAL.

What is this license good for? If your environment has workstations that are used by a multiple users, as in round-the-clock environments such as factory floors, call centers, and nursing stations, this license is the most effective since your users could share a single TS Device CAL.

Option 2. Terminal Server “User” Client Access License

A Terminal Server user Client Access License (TS User CAL) is assigned to a user account. It then “follows” that user no matter which server he logs on to and no matter which client device he logs on from.

This license is ideal for mobile workers that roam from location to location while using Terminal Servers to access their applications. Also, if your users use multiple client devices (perhaps their work PC and home PC), this model may save your company significant licensing dollars.

Option 3. External Connector License

A challenge to using per-user and per-device CALs is the fact that they have to be assigned to a specific user account or a specific client device. While adequate for employees of the company that bought the license, what happens if a company wants to extend its Terminal Server environment to business partners where the names of users and client devices wouldn’t be known? What happens if a company wants to extend an application via a Terminal Server to the Internet? Technically following the Microsoft terms, you would need to buy a license for each unique user or computer that connected to your server.

Clearly this is not feasible. To address this challenge, Microsoft introduced the External Connector License (ECL), designed to be used when systems are extended to external parties, including business partners and the public.

ECLs are available for all new Microsoft products (except products that are licensed on a per-processor basis since per-processor licenses already account for unlimited users and client devices). In Terminal Server 2003 environments, ECLs provide a simple way to buy “concurrent” user licenses for those who need to connect to your server. If you wanted to open up a server to trading partners, you would buy a Terminal Server ECL.

At this point you might be wondering why you can’t just buy ECLs and forget all this per-user and per-device garbage. Microsoft has strict rules governing the use of ECLs, and users of the TS ECLs cannot be employees of the organization that bought the license.

Microsoft Windows Server Client Access Licenses

Now that you understand the difference between the three Terminal Server-specific CALs, you need to know that each client device also needs a standard Windows Server 2003 CAL. To legally access a Windows 2003 Terminal Server, each client seat requires each of the following licenses:
Windows Server 2003 Client Access License.
Windows Server 2003 Terminal Server Client Access License.

License 1. Windows Server Client Access License (Server CAL)

Any user needs this Windows Server CAL to access a Windows 2003 server. This license provides the “basic” access rights that allow users to store files, print, and be part of an Active Directory. If you have a unified Active Directory with 5000 users, then you’ll have 5000 Windows Server CALs.

License 2. Windows Server 2003 Terminal Server Client Access License (TS CAL)

We discussed the TS CAL (either per-device, per-user, or External Connector License)  in the previous section. It builds upon the regular Windows Server CAL, adding the legal right for users to access a “remote control” session on a Terminal Server.

If you have a 5000-user Active Directory environment with a few Terminal Servers that provide applications for 300 users, then you’ll need 5000 Windows Server CALs and 300 Terminal Server CALs.

Special Licensing Scenarios

Prior to Windows Server 2003, there were special license rules for specific situations. Microsoft has changed the way these situations are handled with the introduction of Windows Server 2003.

TS CAL Requirements when Connecting to a Terminal Server from Windows XP

Prior to Windows Server 2003, client workstations that ran Windows NT, 2000, or XP Professional had the right to obtain a “free” TS CAL. The only requirement was to purchase a TS CAL for client devices that ran an operating system lower than the Terminal Server operating system. For example, Windows 2000 Professional workstations did not require purchase of a TS CAL to connect to a Windows 2000 Terminal Server since Windows 2000 client devices had the right to obtain a free Windows 2000 TS CAL. Also, since these licenses were backwards compatible, the Windows 2000 TS CAL would also apply if you were using a Windows XP Professional client to connect to a Windows 2000 Terminal Server.

Since Windows XP was released over a year before Windows Server 2003, many people bought Windows XP Professional with the assumption that it would include a “free” Windows Server 2003 TS CAL. However, with the release of Windows 2003, Microsoft removed the “free” TS CAL license that was built-in to Windows XP Professional. Unfortunately, this announcement came well after many organizations bought multiple copies of Windows XP assuming that its free TS CAL would work with Windows 2003 Terminal Servers.

Negative response to this announcement prompted Microsoft grant a free Windows 2003 TS CAL  to anyone who owned a Windows XP Professional license on April 23, 2003 (the day before the release of Windows Server 2003.Does your copy of Windows XP come with a free Windows Server 2003 TS CAL? If you bought it before April 24, 2003, then it does. If you bought if after that it does not, and you’ll have to buy a Windows 2003 TS CAL. (If you had TS CALs that were enrolled in Microsoft Enterprise Agreements or Software Assurance, then you automatically qualified for the Windows 2003 TS CAL upgrade.)

Interestingly, the added TS CAL costs of Terminal Server on Windows Server 2003 has upset some companies so much that they are claiming it as the sole reason that they will keep their Terminal Servers running on Windows 2000.

The Work-at-Home TS CAL

Microsoft licensing agreements also used to provide “work-at-home” licenses for Terminal Servers. These were additional, cheap TS CALs for users that used an office computer to access Terminal Servers and then went home and accessed Terminal Servers from a home PC. With the advent of Windows 2003’s new per-user TS CAL, the work-at-home license is no longer an option.

Similar to TS CALs, any prior work-at-home licenses that are enrolled in an Enterprise Agreement or Software Assurance may be upgraded to current licenses.

Windows 2003 Terminal Server Licensing Components

Windows NT Server 4.0 Terminal Server Edition used the “honor system” for tracking licenses. While you were legally supposed to purchase the correct licenses, there was nothing technically stopping you from connecting more users than you paid for. While the honor system worked well for system administrators and thieves, it has not worked as well for Microsoft shareholders.

As alluded to in the opening sentences of this paper, this system changed when Windows 2000 was released. In Terminal Services for Windows 2000, a Microsoft “Terminal Services Licensing Service” is required to run on one or more servers on your network. This Terminal Services licensing service is responsible for monitoring, distributing, and enforcing TS CAL usage. Microsoft implemented this licensing service as a “service to their customers” who were “deeply concerned that they might accidentally forget to pay for a license or two, every once in awhile.” In Terminal Server environments running on Windows 2000 platforms, this licensing service infrastructure guarantees that there be no “accidentally forgetting” to purchase all the needed licenses.

Windows 2003 Terminal Servers also make use of licensing servers—although the exact manner depends upon for which of three licensing options a server is configured (per device, per user, or the external connector license).

In Windows 2003 environments, there are four main technical components that make up the Terminal Services licensing infrastructure:
Terminal Services licensing servers.
The Microsoft license clearinghouse.
Windows 2000/2003 Terminal Servers.
Licenses.

Figure 1. Microsoft licensing components

Let’s take a look at the licensing–related roles of each component.

Terminal Services License Server

The Terminal Services license server is a standard Windows 2003 server with the “Terminal Server Licensing Service” installed. This license server stores digital certificates for TS CALs that are distributed to client devices. Like Windows 2000 environments, a Windows 2003 license server is responsible for issuing licenses and tracking their use.

Microsoft License Clearinghouse

TS license servers and TS client access licenses must be activated be Microsoft before they can be used. The Microsoft license clearinghouse is a large Internet-based certificate authority that authorizes and activates these licenses and servers. Microsoft does this to ensure that no TS CALs are stolen, copied, or pirated (which is why more and more Microsoft software requires activation after you input your license codes).

A TS license server will function before it’s activated via the Microsoft clearinghouse, however, an unactivated license server will only pass out temporary TS CALs that expire after 90 days. In order for a license server to distribute permanent licenses, it must be activated.

Terminal Server

Windows 2003 Terminal Servers understand that client devices must be licensed. To that end, when you enable Terminal Services, the server immediately begins trying to locate a licensing server. It then communicates with the licensing server to ensure that client devices are licensed properly.

Each Terminal Server must be configured to use per-user, per-device, or external connector licenses.

Licenses

The license service that runs on a Windows 2003 server keeps track of seven different types of licenses. These include four types of licenses for Windows 2003 Terminal Servers and three types (for backward compatibility) for Windows 2000 Terminal Servers. The seven types of Windows 2003 client licenses include:
Windows Server 2003 TS Device CALs. This license is the per-device CAL that is issued to unique client hardware devices. It allows the client device to access Windows 2000 and 2003 Terminal Servers.
Windows Server 2003 TS User CALs. This is the per user CAL that’s assigned to unique user accounts. This license allows a user to access Windows 2000 and 2003 Terminal Servers. If the client device has a valid TS Device CAL, then this TS User CAL is not needed, and vice versa.
Windows Server 2003 TS External Connector Licenses. When assigned to a Terminal Server, this ECL license allows unlimited non-employee connections. When this ECL is used, TS Device CALs and TS User CALs are not needed.
Windows 2000 TS CALs. These are per-device licenses for devices connecting to Terminal Servers running Windows 2000. 
Windows 2000 TS Internet Connector Licenses. These licenses are essentially the Windows 2000 version of the Windows 2003 TS ECL. When assigned to a Windows 2000 Terminal Server, this license allows 200 simultaneous connections. These connections must be made by non-employees, across the Internet, via anonymous user accounts.
Windows 2000 Built-in Licenses. These built-in licenses are used for Windows 2000 and Windows XP workstations that are connecting to Windows 2000-based Terminal Servers. Remember from the previous section that Windows 2003 Terminal Servers do not support the use of built-in licenses. (Which is why even if your Windows XP workstations qualify for “free” Windows 2003 TS CALs, you have to obtain TS Devices CALs from Microsoft—they’re not automatically built in.)
Temporary Licenses. If a licensing server ever runs out of activated licenses, it will issue temporary licenses to any client devices requesting per-device TS CALs (applicable to Windows 2000 or 2003-based Terminal Servers). The number of temporary TS CALs a licensing server can grant is unlimited, although the temporary CALs themselves expire after 90 days and cannot extended.

The Terminal Services Licensing Service

As you’re starting to see, the Windows 2003’s Terminal Server licensing environment is extremely complex. It’s probably also fairly obvious that the licensing service plays a central role. In Windows 2003, this service builds on the licensing functionality that was available in Windows 2000.

TS Licensing Service Installation Considerations

The TS licensing service is separate from the actual Terminal Server components that allow users to run remote sessions.

In Windows 2003 Terminal Server environments, the TS licensing service must be installed on a Windows 2003 server. That server can be any server in your environment that has a trust path to your Terminal Servers. (i.e. same domain, or trusted domain, or trusted forest, etc.) The license service does NOT have to be a server that’s running Terminal Server. Most companies install the TS licensing service on a standard Windows 2003 file and print server.

The TS licensing service can be installed on any Windows 2003 server. It does not have to be in-stalled on a domain controller. Furthermore, this installation can be done at the time of the OS installation or at any time after that via the Control Panel (Control Panel | Add Remove Pro-grams | Windows Components | Terminal Services Licensing Service).

There is no need to build a dedicated licensing server. The TS licensing service can run on any Windows 2003 server without adversely affecting performance. It adds very little CPU or memory overhead, and its hard disk requirements are negligible. The average memory usage is less than 10MB when active, and the license database will grow in increments of only 5 MB for every 6,000 license tokens issued. The license server does not require Internet access.

TS Licensing Service Scope

As part of the licensing service setup, the installation routine asks if you want to set up the license server for your “Enterprise” or “Domain or Workgroup.” The option chosen here (called the “scope”) dictates how the license server communicates with your Terminal Servers and lets you control which Terminal Servers can receive licenses from your licensing server. You can configure your license server so that it provides licenses for either:
An entire Active Directory site. (Enterprise licensing server)
An entire domain or workgroup. (Domain/workgroup licensing server).

Enterprise Scope

If you choose the “Enterprise” installation option, your licensing server will respond to a license request from any Terminal Server in the same Active Directory site. If Terminal Servers from multiple domains exist in that Active Directory site, the license server will provide licenses for all of them.

This option requires that your Terminal Servers be part of an Active Directory domain. When the licensing service starts, it registers itself with a domain controller and creates a “TS-Licensing” object in the directory, allowing Terminal Servers from any domain to query a domain controller to locate the license server.

Domain / Workgroup Scope

Choosing the “Your domain or workgroup” option causes the license server to behave differently, depending on whether it’s part of an Active Directory domain.

In AD environments, this choice causes your licensing servers to only respond to license requests from Terminal Servers in the same Active Directory domain. If an Active Directory domain crosses multiple Active Directory sites, the licensing server will fulfill requests from multiple sites. This option is useful in situations where there are multiple business units partitioned into different domains on the same network. A license server from one domain won’t give licenses to clients connecting to Terminal Servers from a different domain.

In non-AD environments, choosing this option means that your license server will not attempt to register itself with a domain controller, and your Terminal Servers will have to find your license servers on their own. (More on this later.)

TS Licensing Server Activation

After the TS licensing service is installed on a server, it must be activated by the Microsoft clearinghouse via the Terminal Services Licensing tool. This activation gives the license server the digital certificate it will use to accept and activate TS CALs.

The license server activation is fairly straightforward (Start | Programs | Administrative Tools | Terminal Services Licensing | Right-click on server | Activate). Activation can be accomplished directly via the Internet or via a web page, fax, or telephone call. If you run the licensing tool on a computer other than the license server, the computer that you are using must have access to the Internet—not the license server.

You must install a TS licensing server within 120 days of using Terminal Services on a Windows 2003 server. (This was increased from 90 days with Windows 2000.) If a Windows 2003 Terminal Server can’t find a license server after it’s been used for 120 days, the Terminal Server will refuse connections to clients without valid TS CALs.

How Terminal Servers find Licensing Servers

Since you can install the licensing service on any Windows 2003 server in your environment, the real fun begins when you try to get your Terminal Servers to talk to your license server(s). Merely installing a license server on your network does not necessarily mean that your Terminal Servers will be able to find it.

License server “discovery” is the technical term for the process by which Terminal Servers locate and connect to licensing servers. As soon as the Terminal Server role is added to a Windows 2003 server, the server immediately begins the discovery process. License server discovery can happen in a number of ways, depending on which of the following environments the Terminal Server finds itself in:
No domain (workgroup mode).
Windows NT 4.0 domain.
Active Directory domain, with the TS license servers operating in domain mode.
Active Directory domain, with the TS license servers operating in enterprise mode.

Hard-Coding Preferred License Servers
Regardless of which of these four situations a Terminal Server is in, you always have the option of manually specifying a license server or servers that each Terminal Server should get licenses from. You can manually configure any Terminal Server to get licenses from any license server—there’s no need to stay within domain, subnet, location, or site boundaries.

You can configure a Terminal Server to use a specific license server via the Terminal Server’s registry. Be careful though, because this registry edit is not like most others. In this case, rather than specifying a new registry value and then entering data, you have to create a new registry key (or “folder”). To do this, browse to the following registry location:

HKLMSYSTEMControlSetServicesTermServiceParameters

Add a new key called “LicenseServers.” Underneath the new LicenseServers key, create another key with the NetBIOS name of the license server that you want this Terminal Server to use. You don’t need to add any values or data under this new key.

Add multiple keys for multiple servers if you wish, although the Terminal Server will only communicate with one license server at a time. Once you’re done, reboot the server for it to take affect.

As you’ll see, this manual process is needed in situations where the Terminal Servers cannot automatically “discover” the license servers. It’s also useful if you want to override the default license server that a Terminal Server discovers.

Discovery in Windows NT 4 Domains or Workgroup Environments
In non-Active Directory environments, a Terminal Server first looks to the LicenseServer registry location to see if any license servers have been manually specified.

If the registry key is empty or if the server or servers specified there cannot be contacted, the Ter-minal Server performs a NetBIOS broadcast to attempt to locate a license server. (NetBIOS broadcasts are not routable, so only license servers on the same subnet as the Terminal Server making the broadcast will respond.) If multiple license servers respond, the Terminal Server re-members their names and chooses which it will use exclusively.

Once the Terminal Server picks a license server, the Terminal Server periodically verifies that it exists. (See Figure 2.) If the license server ever fails to respond to the verification poll from the Ter-minal Server, the Terminal Server attempts to connect to one of the other license servers that responded to the original NetBIOS process. If no connection can be made to a license server, the Terminal Server attempts to find a new license server by starting the entire discovery process over again.

Figure 2  Terminal Servers periodically verify that they can contact license servers
Environment    Once contact, license server is verified after xxx minutes of no activity    If not found, discovery process repeats every:
NT 4 domain or workgroup    120 min    15 min
Domain Mode    120 min    15 min
Enterprise Mode    60 min    60 min

 
Discovery in Active Directory Environments
When a Terminal Server is a member of an Active Directory domain, the license server discovery process is entirely different.

First, the Terminal Server attempts to contact the license server (or servers) specified in its LicenseServers registry key. If a license server is discovered at any point through this process, the remainder of the discovery process is aborted.
If that attempt fails, the server next looks for an enterprise scope licensing server by performing an LDAP query for the following object in its Active Directory site:
LDAP://CN=TS-Enterprise-License-Server,CN=, CN=sites,CN=configuration,DC=,DC=com
If that attempt also fails, the Terminal Server begins querying every domain controller in the site, looking for “enterprise scope” licensing servers.
If the Terminal Server still has not found a license server, it will query every other domain controller (outside of its site) to see if any are configured as a domain scope license server.
One thing that you might have noticed about this discovery process is that domain scope license servers must be installed on domain controllers in order for your Terminal Servers to discover them. Domain scope license servers do not register themselves with other domain controllers and Terminal Servers only query domain controllers to see if they are license servers.

There’s nothing wrong with installing a domain scope license server on a non-domain controller. Just be aware than you’ll need to manually configure the registries of your Terminal Servers to find those license servers. Enterprise scope license servers are not affected, since they register themselves with the domain controllers, even when not installed on a domain controller.

If a Terminal Server does not find a license server via this discovery process, the whole process is started over once every hour.

If license servers are found, the Terminal Server keeps a list of them in its registry. Enterprise li-censing servers are stored in the HKLMSoftwareMicrosoftMSLicensingParameters EnterpriseServerMulti registry location, and domain licensing servers are stored in the HKLMSoftwareMicrosoftMSLicensingParametersDomainLicenseServerMulti registry location. By storing these server names in the registry, a Terminal Server is able to quickly pick a new license server if its primary choice is not available. Once a license server is found, the Terminal Server will only start the discovery process over again if it can’t connect to any of the servers in the registry.

Troubleshooting License Server Discovery
You are likely to run into situations in which one of your Terminal Servers cannot find a license server and the reason is not apparent. Fortunately, the Windows Server 2003 Resource Kit in-cludes a Terminal Server License Server viewer tool, LSVIEW.EXE. LSVIEW is a GUI-based tool that is run on a Terminal Server. It provides you with the names and types of each license server that it can discover.

Figure 3. Microsoft license server discovery process

The Terminal Server 2003 Licensing Process
Let’s take a look now at how the entire licensing process works. The exact process that takes place is different depending on whether the Terminal Server is configured to use device-based or user-based TS CALs.

Terminal Servers Configured for Device-Based TS CALs
When a Terminal Server is configured to use TS Device CALs (Start | Administrative Tools | Ter-minal Services Configuration | Server Settings | Licensing), each client device needs to have its own license.
Terminal Server CALs are purchased and installed into the license database on the (pre-viously activated) TS Licensing Server.
The TS CALs are activated via the Microsoft License clearinghouse. The activated li-censes remain on the license server, waiting for assignment to client devices.
A user makes an RDP connection to the Terminal Server.
Since the Terminal Server is in per device licensing mode, the Terminal Server checks for the device’s TS CAL (in the form of a digital certificate).
If the client device does not present a valid TS CAL, the Terminal Server connects to the license server to obtain one.
If the license server does not have any more TS CALs, it will route the Terminal Server to another license server that does have available TS CALs (if known).
The license server sends the Terminal Server a digital certificate for a temporary 90-day TS CAL.
The Terminal Server passes this certificate down to the client.
The user’s credentials are validated. If the user successfully authenticates, the Terminal Server contacts the license server a second time. This time around, the Terminal Server informs the license server that the TS CAL that was sent to the client should be marked as “valid.” If the user did not successfully authenticate, (i.e. the connection was from an inappropriate user), the Terminal Server will not contact the license server, and the li-cense that was sent out will not be marked “valid.”
The next time that client device connects, it presents its 90-day temporary TS CAL to the Terminal Server.
The Terminal Server contacts the license server. Since the licensing server marked the CAL as valid the first time the user authenticated, the client device’s temporary CAL is up-graded to a full CAL. If, for some reason, all of the license servers have depleted their in-ventories of TS CALs, the client device keeps its temporary 90-day TS CAL certificate. As long as the 90-day certificate has not expired, the client device can still connect, even with no available licenses on any license servers.

An unlicensed client device will always be granted a temporary 90-day TS CAL at the time of its first connection. Only after successful authentication and a second logon is the temporary TS CAL upgraded to a full TS CAL. This two–stage licensing process is used to ensure that TS CALs are only assigned to authenticated users. Previously (before hotfix 287687 or Windows 2000 Ser-vice Pack 3) any user that connected was assigned a full TS CAL, even if he did not belong on the system. The full TS CAL certificate was granted at connection time, before the logon screen even popped up. If a user thought, “Oops, I don’t belong on this system!” it was too late—his client device had already received a full TS CAL certificate, even if the administrator never meant for him to access the system. This circumstance often led to license servers running out of TS CALs.

During this process, if the license server does not respond to the Terminal Server, the Terminal Server will try to connect to one of the other license servers from the list of servers it maintains in the registry that was built as a result of the license server discovery process. If it can’t connect to any of them, it will start the license server discovery process again.
If a client device does not have a TS CAL and the Terminal Server cannot contact a license server, the user’s session will be denied. The only exception to this is for new Terminal Servers. In Win-dows 2003, you have a 120-day “grace period” during which a Terminal Server will function even if it cannot contact a license server. However, 121 days after you install Terminal Services onto a Windows 2003 server, that server must be able to contact a licensing server or no new users will be able to connect. All of this action takes place a soon as the connection is made—before the user even authenticates!

TS CAL License Certificate Storage on Client Devices
As mentioned earlier, when a client device receives a TS Device CAL from a Terminal Server, it receives it in the form of a digital certificate from a license server. For this reason you must acti-vate the license server with the Microsoft clearinghouse (which is just a certificate authority). The digital certificate is an actual certificate copied to the client device (even with Windows CE). Once a client device connects to a Terminal Server, a TS CAL digital certificate is transferred from the license server to the client device. The license server loses one of its licenses from its in-ventory, and the client device has the digital certificate that it can present to any Terminal Server on future connections.

The digital certificate is stored in different locations depending on the operating system. On 32-bit Windows platforms, the TS CAL digital certificate is stored in the registry at HKLMSoftwareMicrosoftMSLicensingStoreLicense00x.

Anyone who has been in the computer industry for more than five minutes can probably spot a potential flaw in this plan. Client devices tend to break. Windows-based terminals have their ROMs reflashed. Operating systems are reinstalled on workstations. PCs are reimaged. Whenever this happens, the TS CAL digital certificate stored on the client device is lost forever. The TS CAL doesn’t exist on the license server after it’s transferred to a client device. When that client connects back to a Terminal Server, it has no digital certificate to present. The server thinks that it has no license, and instructs the license server to issue a new TS CAL in the form of a new digital certificate. In effect, that one client device ends up consuming two TS CALs—the old one that was lost and the new one that was just issued. If the client device were reset again, a third TS CAL would be used.

In Windows 2003 (and Windows 2000 SP3), when a Terminal Server requests a TS CAL from the license server for a client device, a full TS CAL certificate is granted with an expiration date randomly selected between 52 and 89 days from the current date. The license server keeps track of the expiration date and it is also embedded into the digital certificate that represents the actual license passed down to the client device.

Every time the client device connects to a Terminal Server, it presents its TS CAL certificate to the server. The server checks not only whether the client device has a valid certificate, but also the expiration date of that certificate. If the expiration date of the certificate is within 7 days of the current date, the Terminal Server connects to the license server to renew the license for another random period of 52 to 89 days.

The license server also tracks the expiration date of TS CALs. If for some reason the client’s CAL is never renewed and expires, the license server returns that TS CAL to the inventory of available unused licenses. If a client device with a TS CAL were to blow up or be rebuilt, the license server would automatically add the TS CAL back into its available license pool after it expired (a maxi-mum of 89 days).

If the Terminal Server is not able to obtain a TS CAL renewal when the client device’s TS CAL certificate expires after the 52 to 89 days, the client is denied access. A temporary 90-day certifi-cate cannot replace a full certificate that has expired, but this shouldn’t ever be a problem for you (unless you don’t have enough TS CALs).

Someone at Microsoft deserves an award for the fact that the temporary TS CALs are valid for 90 days and the full TS CALs are valid for a maximum of 89 days—conveniently one day less than the temporary licenses. Consider the following scenario:

Assume that a client device successfully authenticates to a Terminal Server and is granted a full TS CAL certificate that was (worst case) randomly selected to expire at the 89 day maximum. When it passes down the certificate, the license server decrements its total TS CAL license count by one, also noting that particular certificate’s expiration date. Now, assume that a catastrophic event oc-curs at the client, causing its local operating system to be reinstalled and its local TS CAL certifi-cate to be lost. When that client authenticates to a Terminal Server, the Terminal Server will request a new TS CAL certificate from the license server and the license server (again) decrements its TS CAL inventory by one. At this point there have been two TS CAL licenses given out to that one client, but the first one will never be renewed because the certificate was lost when the client was rebuilt. After 89 days (the randomly selected duration of the first certificate), the first TS CAL is returned to the pool by the license server.

The administrator in this situation probably bought just enough TS CALs to cover the exact number of client devices. He did not buy extras to cover the 52 – 89 day period during which one client device had two CALs assigned. By purchasing the exact amount of TS CALs, the li-cense server would not have any more TS CALs to give out when the client device asked for the new TS CAL certificate after the first was lost. In this case, the license server would grant a tem-porary 90-day TS CAL certificate to the client device because the client device appears to the server as a brand new machine.

Because the temporary TS CAL certificate is always valid at least one day longer then the full CAL certificate (90 days versus a maximum of 89 days), the old, lost full TS CAL will always be returned to the inventory on the license server at least one day before the temporary TS CAL cer-tificate would expire. For example, after day 88, the client device’s temporary TS CAL certificate will expire in 2 days, but the license server is tracking the expiration of the full TS CAL that was originally granted for 89 days. That full TS CAL only has 1 day left before it expires. The following day, when the client device’s temporary TS CAL certificate has only 1 day remaining, the license server will add the original TS CAL back in its inventory pool, making it available to grant to the client as a permanent license for another random period of 52 – 89 days.

True geeks will enjoy tracing the entire licensing flow in Windows 2003 Terminal Server envi-ronments in Figure 4.

Multiple License Timeframes Explained
Throughout this license distribution and acquisition process, we have discussed two different li-cense timeframes. While both are related to Windows 2003 Terminal Services licensing, they are actually completely different.
A Windows 2003 Terminal Server will work without a license server for 120 days.
If a license server runs out of TS CALs (licenses), it will issue 90-day temporary ones.

The first item relates to the presence of a license server. If a Terminal Server cannot locate a li-cense server, it will still allow unlicensed client devices to log on. The Terminal Server itself does not grant 90-day temporary licenses if it cannot find a license server. Instead, if a license server cannot be located, the Terminal Server simply “looks the other way” for 120 days. After the grace period ends, unlicensed client device connections are refused. This 120-day countdown begins the first time a Terminal Services client device connects to the server.
From a legal standpoint, you must have a valid TS CAL for each client device that connects to a Terminal Server, even during the first 120 days. The 120-day threshold is not a free evaluation period. Rather, it gives you a chance to set up your Terminal Server environment and get the bugs worked out before you activate your license server.

The second item relates to the license server itself. If, over the course of business, a TS licensing server runs out of licenses, it will begin to grant 90-day temporary license certificates to client devices. Unlike Windows 2000, Windows 2003 license servers do not have to be activated to hand out 90-day temporary TS CALs.

Figure 4. The Terminal Server 2003 Device-Based TS CAL Licensing Process

These temporary licenses can only be replaced by full TS CAL licenses—they cannot be replaced by additional temporary licenses. There is no limit to the number of temporary licenses that a li-cense server can grant. Also, the 90-day timer for the expiration of the TS CALs is client specific, meaning that different temporary licenses can expire on different days—even if they were all granted by the same license server.

Terminal Servers configured for User-Based CALs
Everything discussed in the previous section is applicable only when Terminal Servers are config-ured in “per device” licensing mode. When a user connects to a Terminal Server configured in “per user” licensing mode, a different process takes place.
When Terminal Services is installed on a Windows 2003 server, the server verifies that it can find (via the discovery process outlined previously) a license server.
There is no Step Two.

That’s right. All this TS CAL digital certificate, temp license, transfer mumbo-jumbo only applies when Terminal Servers are configured for “per device” licenses. With per user licenses, all you have to do is make sure that the Terminal Server can find a license server. (The license server doesn’t even have to be activated!) Other than periodically verifying that it exists, there’s no com-munication between a “per user” configured Terminal Server and a license server.
How did this come to be? When Windows 2003 was in beta testing, Microsoft was planning to offer a “per processor” licensing model. At the last minute (with Release Candidate 2), Microsoft changed its mind and decided to go with a “per user” option instead. This decision was a popular move on Microsoft’s part. The only problem was that it was so late in the game that Microsoft didn’t have time to build the “per user” technical license compliance infrastructure (although you can bet we’ll see it in future versions of Windows).

Designing your Licensing Server Environment
Now that we’ve reviewed the details of how licensing works, let’s look at some of the issues affect the design of your TS licensing servers.
Selecting which Terminal Servers can access which license servers.
Licensing Terminal Servers in mixed Windows 2000 and Windows 2003 environments.

Enforcing which Terminal Servers are Authorized to Receive Licenses
A new feature of Windows 2003 allows you to specify security permissions for your license servers. That is, you can specify which Terminal Servers are authorized to pass out licenses from a specific license server.

This feature is useful to organizations that manage licensing by business unit or specific users groups, since it can prevent one department from “stealing” another department’s licenses.
You must first enable this security feature via a policy applied to the license server (Computer Configuration | Administrative Templates | Windows Components | Terminal Services | Licens-ing). Once this functionality is enabled, a local group called “Terminal Services Computers” is created on the license server. The License Server will only respond to license requests from servers (or global groups containing servers) whose computer accounts are a member of this group.

When this policy is enabled on a license server that’s also a domain controller, the group that’s created is a domain local group (since domain controllers don’t have local groups). Therefore, if you really plan on managing your licenses by department, it’s probably not the best idea to install the licensing service on a domain controller.

If you want to manage licenses by business unit, it’s usually easiest to install the license server in “domain or workgroup mode” onto a server that’s “owned” by that business unit. Then, activate the License Server Security via Group Policy. Once this policy is applied, add the Business Unit’s Terminal Servers into the local License Server Security Group, ensuring that only authorized Terminal Servers can receive Terminal Service CALs. This is also a good way to prevent other de-partments or even rogue Terminal Servers from accessing your license service and using up CALs.

Licensing in Mixed Windows 2000 / 2003 Environments

If you’re migrating from Windows 2000 or if you’re running a 2000/2003 mixed environment, there are a few licensing issues to consider when planning your design.

Preventing TS CAL License Upgrades
Since it’s possible for a single Windows 2003-based license server to distribute both Windows 2000 and Windows 2003 TS CALs, you need to give some special thought to environments where both are used.

Your Windows 2000 Terminal Servers communicates with your Windows 2003 license server and request licenses from it, and your Windows 2003 license server mimics a Windows 2000 license server.

Because Microsoft licenses are backwards-compatible, the Windows 2003 license server can technically issue either a Windows 2000 or 2003 TS CAL for clients wanting to connect to a Windows 2000 Terminal Server.

The license server will always try to provide the exact match for the version of the license. But what happens when a client device requires a TS CAL to connect to a Windows 2000 Terminal Server and the license server only had 2003 TS CALs available? Should the license server “waste” a 2003 CAL on the Windows 2000 server, or should it provide a 90-day temporary 2003 license? If the client already had a temporary CAL, should the server “upgrade” it to a 2003 permanent TS CAL, or should it deny the user’s connection?

The desired outcome of this situation depends upon your business environment. You can specify which behavior you want your licensing server to follow. This functionality is controlled via the “Prevent License Upgrade” policy (Group Policy | Computer Configuration | Administrative Templates | Windows Components | Terminal Services | Licensing).

As the name implies, enabling this policy prohibits a licensing server from ever using a Windows 2003 TS CAL for a Windows 2000 environment. Chapter 6 in out book Terminal Services for Windows Server 2003: Advanced Technical Design Guide explains how policies are used and implemented in Terminal Server environments.

Upgrading a Windows 2000 Licensing Server
If you have an existing Windows 2000 license server, it’s possible to upgrade it to Windows 2003 while preserving the existing license database. During the upgrade from 2000 to 2003, the license service that was installed will be upgraded and the database content will be migrated into the new license database. After the upgrade to Windows 2003, you’ll need to reactivate your license server, just as if you had installed a new license server. This can be accomplished by using the “Reactivate Server” option from the action menu in the Terminal Services Licensing Manager.

Managing your TS Licensing Servers

Once your environment grows to become a Terminal Server powerhouse serving thousands of customers with hundreds of servers, you’ll need a few tools to ensure that everything is going according to plan with regards to licensing.
Managing Windows 2003 Terminal Services license servers should not take much of your time. There are only a few tasks you’ll need to know about:
Adding new licenses to the license pool.
Administering the license server.
Reporting on license usage.
Troubleshooting client device license acquisition.

Adding Licenses to a TS License Server
All newly–purchased Terminal Server Client Access Licenses must be installed into a TS license server database. Since Windows Server 2003 also supports Windows 2000 licenses, you can also install your Windows 2000 TS CALs onto a 2003 server. (These licenses cannot be used for Windows 2003 Terminal Servers, but at least you’ll be able to centrally manage all your licenses.)

TS CALs are purchased just like any Microsoft license. Traditionally, if you bought a Client Access License pack, that pack only contained a license agreement—nothing more than a piece of paper. Now when you buy a TS CAL license pack, it comes with a 25-character license code. This code must be entered into the TS Licensing Wizard for the TS licensing servers. If you buy licenses through a volume license agreement such as Select or an Enterprise Agreement, then you’ll need to enter that agreement number into the Licensing Wizard when you add the licenses.

After the licenses have been installed, you must activate them. Licenses are activated via the same three methods you use to activate the license server (Internet, web, or phone). Once activated, the licenses are ready to be distributed to client devices. Clients that previously received the 90-day temporary licenses will be upgraded to full licenses the next time they connect.

In some situations, adding or removing licenses to a license server will cause that server to notify other license servers.
A domain scope license server will notify other license servers within the same domain.
An enterprise scope license server will notify other license servers in its Active Directory site.
An enterprise scope license server will notify other license servers in its domain.

In all of these cases, adding or removing licenses to a Windows 2000 or Windows 2003 license server will cause the server to notify the appropriate Windows 2003 license servers as mentioned. A Windows 2003 license server will not notify a Windows 2000 license server.
As outlined earlier in this paper, this notification allows the license servers to redirect client requests to other license servers should the first server run out of licenses.

Remotely Administering License Servers
The TS licensing service is mainly a “set it and forget it” kind of service. Theoretically, it only needs to be administered when new licenses are purchased or old licenses are removed.
However, there are times when it would be convenient to administer TS licensing servers remotely. For technical reasons, the TS Licensing Tool cannot be run via a remote Terminal Services session. However, this tool can be executed locally on any Windows 2003 computer and used to connect back to one or more TS license servers. To do this, copy the licmgr.exe and the lrwizdll.dll files from the system32 directory of the TS licensing server to the system32 directory of the computer you would like to use. Run licmgr.exe to use the tool.
As was mentioned previously, running the tool in this manner can be helpful when activating TS licensing servers or TS CAL packs. During the activation, the machine running the TS Licensing Tool needs access to the Internet—not the actual license server itself. This method works well in scenarios in which the Terminal Servers are not connected to the Internet but there are certain administrator workstations connected to the Internet and the internal network.
Maintaining TS license servers is simple. One TS licensing console can connect to all of the license servers in your environment, facilitating centralized administration.

Reporting on License Usage
The Terminal Server License Reporting tool, lsreport.exe, from the Windows Server 2003 Resource Kit can be used to view and analyze the data contained within the licensing server database. This tool outputs the information in the database into a tab-delimited format that allows you to create reports of who is using your licenses. Run “lsreport /?” from a command prompt for a list of options.

Uncovering Client Device TS CAL Details
The Terminal Server Client License Test tool, TSCTST.EXE, is a command-line client-side tool that displays information about a client device’s local TS CAL. Also included in the Windows Server 2003 Resource Kit, it provides the following information about a license:
Issuer
Scope
Issued to computer
Issued to user
License ID
Type and Version
Valid From
Expiration date

By using the “/A” switch, the following additional information is displayed:
Server certificate version
Licensed product version
Hardware ID
Client platform ID
Company name

This tool is used from the command line of a client device. It’s useful when you need to locate information about the TS CAL certificate that’s stored locally on that device.

Application Licensing

All this work on the Terminal Server licensing might almost make you forget that you have to properly license your applications as well. While the purpose of this book is to focus on Terminal Server, there are some common threads worth pointing out regarding application licensing.
Because there are so many different ways that applications can be licensed, it’s impossible go into specifics here. However, in almost all cases, the application usage license is tied in some way to the number of users or client devices. Most application licenses are not linked to the number of times the application is installed because the application vendors don’t want you to buy one copy of the application for each Terminal Server that you have and then make that application available to hundreds of users per server. Most applications today have licensing agreements that fall into one of two categories:
Per Named User. One license for each user that could execute the application.
Per Concurrent User. One license for each concurrent copy of the application that is executed.

Enforcing Named User Application Licenses
Applications that are licensed “per named user” require that you have a license for each user that could access the application. If you have 100 users with access to an application but no more than 10 ever connect at the same time, you still need to purchase 100 application licenses. Most Microsoft applications are licensed this way, in addition to many expensive line-of-business applications.

The key to properly enforcing per named user application licenses is permitting or preventing users from being able to access the applications. An easy way to do this is to create a domain group with all the user accounts of the users that will need to access the application. Then, add these users to the Remote Desktop users group on the Terminal Server hosting the application so that only members of that domain group can use it. This can also be done by setting NTFS permissions on the executable if users that don’t use this application connect to the same Terminal Server.

Another option is to create a Software Restriction Policy to restrict that application to only a certain group of users. This policy could be applied in the Group Policy at the OU level for a large number of Terminal Servers.

By restricting access to the application itself, you guarantee that only appropriate users will ever use the application. When it comes time to pay for your application licenses, all you have to do is count the number of users that are in your application group and buy that number of licenses.

Enforcing Concurrent User Application Licenses
Applications whose licenses are based on the number of concurrent users only require that an application license is purchased for each concurrent connection. If you have 100 users that have access to an application but no more than 10 ever connect at the same time, you only need to purchase 10 licenses. Your company’s accountants will appreciate applications that are based on concurrency. You will probably not appreciate them because they are harder to enforce from a technical standpoint. Within Terminal Server, there are two ways to enforce concurrent users:
Limit the number of connections on the Terminal Server hosting the application. This can be done in the Terminal Server Configuration utility by editing the RDP connection properties.
Create a batch file that writes to a flag file before an application is launched. That batch file can be configured to check the flag file to see how many other instances of the application are running. For environments in which applications are executed across more than one server, the flag file can be stored on a network drive. When users quit the application, the flag file is updated to reflect the user change. The only problem with this (other than the complexity of writing the scripts in the first place) is that the flag file is not updated if users do not exit the application properly.

Hardware Dongles in Terminal Server Environments

The only additional item worth mentioning about application licensing relates to applications that require a hardware key. If you have an application that requires a hardware key, or “dongle,” it probably won’t work on a Terminal Server. Microsoft has intentionally disabled this functionality because the sole purpose of a hardware key is to prevent multiple users from using an application, and Terminal Services’ sole purpose is to allow multiple users to use an application.

If your hardware key vendor did not use the standard Microsoft APIs when writing the application, the hardware key may work on a Terminal Server. If this is the case for your application you must ensure that its use in a Terminal Server environment is acceptable from a licensing standpoint