Terminal Server s Supporting Servers

Terminal Server's Supporting Servers

Microsoft added several new features to Windows Server 2003 to help make Terminal Server solutions more robust. While the addition of new features is always a positive, it also means that there is more for you to consider when designing your solution.

For example, two Terminal Server features—License Servers and the Session Directory—make heavy use of the network. You will need to understand how they work to design a solution adequate to your network. (And just think, these considerations are in addition to all "other" network services, like messaging, DNS, WINS (hopefully not), authentication, and printing.)

• A Terminal Services License Server maintains a database of Terminal Server Client Access Licenses. This database tracks issued, temporary, and existing Client Access Licenses.

• A Session Directory database maintains a list of the user names and session IDs connected to the servers in a load-balanced Terminal Server farm. This database routes users to the proper server when they reconnect to previously disconnected sessions.

Terminal Services Licensing

If you're familiar with the previous version of Terminal Server in Windows 2000, you know that the Terminal Services Licensing Service had to be installed and maintained on an Active Directory Domain Controller. Fortunately, Windows 2003's license service has been modified to run on any 2003 server. This service and its configuration are discussed in detail in Chapter 4. In the current chapter, we'll touch on its relevance to server location.

To appreciate the impact this sever can have on your Terminal Server availability, remember that each time a user connects to your Terminal Server, a query is submitted to the License service. As a user session is established, the license server is queried to determine if the user or device has a valid Terminal Services CAL. If either does have an existing license, access to the system is granted and the session is started. Without a license or the possibility of being issued one, the user will receive an error message and his session will be terminated. While this system seems simplistic, understand that if the Terminal Server cannot contact the license service it assumes there are no licenses available and disconnects the user's session.

Figure 3.10 is an example of how not to implement the licensing service. In it, two Terminal Server farms at two sites are connected via a WAN link. Each time a user connects to a Terminal Server at Site 1, the license server must confirm the user's license across the WAN link. If that WAN link ever breaks or becomes over-utilized, it's possible that the Terminal Server will stop accepting connections.

Figure 3.10: The wrong way to implement the licensing service.

Figure 3.11 (next page) shows the same scenario, with a license server placed on each side of the WAN link. The Terminal Servers have been configured to communicate with the license Server in their locations. Doing so ensures that users connecting to Terminal Servers in either location will not be affected by a downed WAN link.

Figure 3.11: The proper way to implement the licensing service

When placing a license server, redundancy should be your primary concern. The bandwidth between a license server and a Terminal Server is almost negligible—amounting to only a few packets in each direction. Licensing is covered fully in Chapter 4.

The Session Directory Service

We can examine the Session Directory Service using again the example from above. When a user connects to a load-balanced Terminal Server participating in a session directory, his username is checked against the session directory for the cluster to which he is connecting. If he has an existing disconnected session in the cluster, then he is rerouted to the Terminal Server hosting his disconnected session. This process automatically re-establishes a connection with the original session. In environments with Session Directory in use, the process repeats each time a user establishes a session.

With the Session Directory Service located on the same LAN as the Terminal Server, this query should take no longer than a second or two. However, if the query must travel across a saturated WAN link or a WAN link that has failed, then the process cannot happen at all. While lack of a connection to the Session Directory service will not keep a user from logging on, it can severely degrade the speed of the initial connection.

To prevent this scenario, your Session Directory service should be located at the same location as your Terminal Servers, much like the Terminal Server Licensing Service. Creating a highly available environment for both of these services is discussed in Chapter 7.

Domain Controllers and other Network Services

The previous examples also ring true for domain controller placement. Unfortunately, the placement of your Terminal Servers relative to the domain controllers can be a little more complicated.

Refer to Figure 3.12. The company illustrated has a single Active Directory forest with three down-level domains under a forest root domain. A user from east.company.com and canada.company.com will be accessing a Terminal Server cluster in the corporate office that resides in the west.company.com domain. Each location hosts a domain controller for the root domain and several domain controllers for its respective domain.

Figure 3.12: A single AD forest with three down-level domains

As users access Terminal Server sessions in the west domain, their user credentials will have to be passed to domain controllers within their own domains. The only problem resulting is that the down-level domain controllers for their domains are located only at their sites and not where the Terminal Servers are located. These users will most likely experience slower than necessary authentication and logon times.

If you were to place a domain controller (or multiple domain controllers) from the other domains at the site hosting the Terminal Servers, you would not only realize an increase in performance but would also be creating a solution that is more redundant.

Proper Terminal Server network design heavily relies on proper Active Directory design.