Terminal Services License Server High-Availability and Recovery (Part 1)

If you would like to be notified when Michael Burke releases Terminal Services License Server High-Availability and Recovery (Part 2), please sign up to our Real time article update newsletter.

One of the most critical components in any terminal server deployment is the license server. If the license server is not available, users may be denied access to resources. This article will discuss a few different avenues to provide resiliency to your terminal services licensing infrastructure, with this part focusing on high availability.

Challenges with Licensing Services

License server availability is critical for the successful operation of a terminal server environment. However, Microsoft has no built-in mechanisms for providing redundancy for its license servers; the terminal services license service is not cluster-aware so you can’t leverage Microsoft Cluster Services (MSCS) for high-availability. To further complicate the situation, there isn’t a lot of information out there on license server high-availability, and Microsoft’s own documentation on the subject is contradictive.

For instance, in the Microsoft Terminal Services Licensing white paper, Microsoft recommends deploying two license servers but only placing license tokens on one of the servers, allowing the other to only issue temporary CALs. However, in their Terminal Server Licensing FAQs on their web site, they recommend splitting license tokens between deployed license servers. So which one is correct? Well, they both are, depending on your goals for high availability.

Let’s look at the possible cases when a license server is necessary and how availability can affect a client’s ability to connect.

Understanding Where the Vulnerability Lies

The responsibility of license token validation and enforcement falls on the terminal servers in your environment, not the license server. When a client connects, the terminal server will check to see if the client has been issued a valid CAL, and will handle any necessary subsequent communication with the license server on behalf of the client. 

License token enforcement is only in effect when your terminal servers are in per-device mode. Per-user mode terminal servers do not allocate CALs to client; rather they simply check to see if a valid license server exists on the network and if so, will allow the connection. The only weak link here is in the ability to contact a license server. As long as license servers are available, clients will be able to connect.

On the other hand, per-device mode terminal servers do enforce CAL allocation and validation. If a client presents a valid, unexpired CAL to a terminal server upon connection, the terminal server will allow the connection without contacting a license server because the token has been validated by the terminal server itself. Only under the following circumstances will a license server need to be contacted:

• The client has never been issued a CAL for the environment, neither temporary nor permanent
• The client has been already issued a temporary CAL, and is in need of a permanent CAL upgrade
• The client has a permanent CAL that will expire within 7 days, or the CAL has already expired, and needs to be renewed

Of these instances listed above, only two of them will actually prevent a client connection – either the client has never been issued any CAL for the environment, or the issued CAL has expired. Of these two remaining conditions, only one requires access to a license server with available license tokens; temporary CALs can be allocated by any license server. Therefore, there is really only one scenario that you are attempting to protect against – expired CALs.

License Server Modes – Revisited

Further information on license server modes is available in my articles “Terminal Server License Service Discovery, Part 1 and Part 2”, but in review, there are two modes a license server can be in, determined at the time of the service installation.

• Domain/Workgroup Mode
• Enterprise Mode

The mode of the license server determines how it is discovered by terminal servers. Enterprise license servers can always be discovered because the license server location is stored in Active Directory. Domain/Workgroup license server discovery is only reliable if the license server is installed on a domain controller; otherwise terminal servers must rely on a NetBIOS broadcast to locate the license server.

Finally, Windows Server 2003 enterprise mode and domain mode license servers in the same domain will notify each other when CALs are added to their respective databases. This allows license servers to redirect CAL requests to other license servers when they have no available CALs to issue.

Your choices in deploying a redundant terminal services licensing infrastructure will depend on the licensing mode of your terminal servers.

Per-User Mode Terminal Server Deployments

When terminal servers are in per-user mode, the solution is simple. Deploy two activated license servers, placing all license tokens on one license server, and ensure both license servers are discoverable. In fact, it isn’t even functionally required that license tokens be installed on either of the license servers. By placing all license tokens on a single license server, you simplify backup and recovery of the licensing infrastructure.

Figure 1:  Per-User Mode

As shown in Figure 1 – Per-User Mode, two license servers are deployed on the network. In the case of either one failing, the other is available so clients can continue to connect uninterrupted. If the terminal server deployment involved multiple sites, it’s best to place an enterprise license server in each site that contains terminal servers to keep licensing-related WAN traffic to a minimum.

Per-Device Mode Terminal Server Deployments

For environments that contain terminal servers in per-device mode, you must ensure that license tokens are available at all times to prevent clients from being denied connectivity because of expired CALs.  If you remember from the beginning of this article, Microsoft has references to different methods for providing redundancy in their documentation. All licenses can either be placed exclusively on a single license server, whereby the other license servers would only distribute temporary CALs, or the licenses can be split between available license servers. The choice depends on a few factors.

If your organization’s terminal server deployment is isolated to a single site, one option is to place all license tokens on a single server and let the second license server only hand out temporary CALs (Figure 2). This simplifies the process of backup and recovery because you only need to back up one license server to have a complete archive of all license tokens, but it does leave your environment vulnerable to a license server failure.

Figure 2

To alleviate the potential issue, you can split the license tokens between license servers, as shown in Figure 3.

Figure 3

This design decreases the possibility of a single license server failure preventing users from connecting; however, it doesn’t guarantee it because there is no certainty that the remaining license server will still have available CALs. For example, let’s say you split your CALs 50/50 between two license servers, with both servers containing 50 CALs each. The first server has issued all of its licenses while the second server sill has 10 licenses left. If the second server fails, you are still in the same situation as Figure 2 because the first server can only issue temporary licenses to clients that have not yet connected.

The easiest way around this issue is to keep a certain number of license tokens on the shelf in the event of a failure. If your environment suffers a license server failure and you find yourself in a situation where no licenses are available on the surviving node, you have the option of loading your “spare” license packs on the remaining server. However, this should be a last resort as once CALs are loaded on a license server, they cannot be removed.

Multiple Sites

If your terminal server deployment involves multiple sites, it is recommended to place an enterprise license server in each location that contains terminal servers, as shown in Figure 4, with each license server containing a portion of the total CALs from your organization.  This will prevent terminal servers from traversing the WAN links to obtain licenses, but it will allow terminal servers to leverage a remote site’s enterprise license server in the event of a local license server failure.

Figure 4

This design provides redundant license servers to terminal servers in both sites, while reducing normal WAN traffic for CAL allocation. However, just as before, there is no guarantee of CAL availability on the surviving license server in the event of a failure.

Figure 5 provides a marginally higher level of redundancy by adding a second license server to each site that will issue temporary CALs only. In the event of a license server failure, at the very least temporary CALs can be issued from the local site, while permanent CALs allocation may need to traverse the WAN.

Figure 5

Finally, augmenting Figure 5 by including permanent CALs on the additional site license servers could further improve redundancy, but it comes at the risk of increased management overhead to maintain the license servers. Remember, each additional license server that contains permanent CALs must be regularly backed up.

Recommendations and Best Practices

A fine line must be drawn between the level of redundancy necessary to maintain the environment, and the level of complexity the redundancy inflicts on the environment. The following recommendations and best practices will assist you in ensuring your licensing services infrastructure is resilient enough to withstand a single license server failure.

• Deploy more than one license server in your environment to prevent a single point of failure. Even if they don’t both contain un-issued license tokens, the surviving license server will be able to issue temporary CALs to new clients.
• Discoverability is critical – Leverage enterprise license servers whenever possible or place domain license servers on domain controllers. If necessary, use the LicenseServers registry keys to override discovery.
• For multi-site deployments, place a license server with permanent license tokens installed in each site that contains terminal servers. If one server fails, licenses can be allocated from a remote-site license server.
• As a fallback option, keep some spare license packs on the shelf in the event of a critical failure. If all permanent licenses have been issued and a good portion are due to expire before you can recover the failed server, this can be your safety net.
• Keep accurate counts of license requirements and proactively add additional CALs as needed. You don’t want to be caught in a situation where users are denied access because someone didn’t keep track of licensing needs.
• Backup license servers consistently. If a license server fails, this is the only way to restore the license server without getting the Microsoft Clearinghouse involved.
• Finally, leverage per-user mode terminal servers whenever possible to prevent having to deal with per-device licensing challenges.

Part one covered establishing resiliency in the licensing infrastructure. Part two will focus on recoverability of license server to facilitate rapid restoration in the event of a failed license server.

If you would like to be notified when Michael Burke releases Terminal Services License Server High-Availability and Recovery (Part 2), please sign up to our Real time article update newsletter.