Step 9: Size and Place the Terminal Services Role Services for the Farms

Published: February 25, 2008

 

Terminal Services Session Broker (TS Session Broker), Terminal Services Licensing (TS Licensing), and Terminal Services Gateway (TS Gateway) role services can be shared among multiple farms or can be dedicated to a specific farm. The goal of this step is to optimally place each of these role services and then to determine the number of servers required and how they will be architected.

Note   All of these role services can be run in a virtual machine. However, this should be carefully tested to ensure that adequate performance is delivered.

At the time of writing, there is no available guidance on capacity and performance planning for the TS Session Broker, TS Licensing, or TS Gateway role services. Start by implementing the role services in a small farm, measure the performance, analyze and learn from the results, and adjust the sizing of the role services accordingly.

It may be helpful to take a pragmatic view of the load that is on each of the role services, including Terminal Services Web Access (TS Web Access); this may prove useful in sizing the roles.

Role Service or Function

Frequency of Access, per Session

Other Use

Relative Weight per Session

TS Licensing

0

First time each client accesses a terminal server. When client licenses expire.

Light

TS Session Broker

1

Continuous monitoring of the number of sessions on terminal servers

Light

Redirector

1

 

Light

TS Gateway

Many

 

Normal

TS Web Access

1

 

Light

 

If more accuracy is required, load tests can be performed to determine the number of users that a server can support for each of the Terminal Services role services. Use the same form factor for the initial testing for all three role services. When that initial testing is complete, determine whether role services will reside on shared servers. If they won’t, the form factor may be adjusted to accommodate differences in the demands of the different role services.

Note   A Windows Server 2008 Terminal Services farm can include servers running Windows Server 2003 Terminal Services. However, in a mixed farm like this, TS Session Broker load balancing cannot be used. So if there are applications that must remain on Windows Server 2003, it is recommended that they be in a separate farm.

At the end of this step, the number of Terminal Services role services and their form factor is determined, and the Terminal Services role services are placed in the job aid.

Begin by examining the Active Directory implementation. This should be done first because it has the same implications for all three Terminal Services role services discussed below. The Terminal Services role services can work across domain boundaries, so they may be shared across more than one domain. However, there may be organizational reasons to restrict the scope of the role services to particular domains, and this can be implemented using Group Policy. In that case, a separate Terminal Services role service will need to be instantiated in each domain.

The Terminal Services role services cannot work across an Active Directory forest boundary unless a cross-forest trust is established for that purpose. So if that trust is not in place, plan to implement each of the required Terminal Services role services in each forest. 

Task 1: Design and Place the TS Session Brokers

TS Session Broker provides a load balancing service for incoming user session requests. When a user initiates a connection to a terminal server farm that is load balanced by TS Session Broker, he or she is first connected to a single terminal server. That terminal server then redirects the connection request to the TS Session Broker, which uses a load balancing algorithm to forward the request to the most appropriate terminal server. To decide which server is most appropriate, the algorithm will first determine whether the connecting user already has a session that is running on one of the servers in the farm. If the user does, it will reconnect the user to that session on that server. If the user does not have an existing session, he or she will be connected to the server in the farm that has the fewest sessions. TS Session Broker further balances these connections by taking account of the relative “weights” of the servers that are in the farm.

A TS Session Broker server can be shared across terminal server farms, but it will not distribute user sessions requests across farms; the connecting user can be placed only in the farm that redirected him or her to the TS Session Broker. When a TS Session Broker server is shared between farms, it will operate independently on behalf of each farm.

Using the following process, decide where TS Session Broker services are needed and in what format, and determine which farm connects to each TS Session Broker server. Place this information in the job aid (Appendix C).

  1. Determine whether the TS Session Broker role service is required. In a terminal server farm that contains more than one server, TS Session Broker is used to reconnect sessions that have been disconnected. It will reconnect the session to the server where the user’s application is running, thereby avoiding the possibility of an orphan session for that user. So for a multi-server farm, the TS Session Broker role service will be required.

    Note   TS Session Broker redirection is supported by RDC 5.2 clients and later.
  2. Determine the demand on the TS Session Broker. At the time of writing, there is no available product guidance on capacity and performance planning for TS Session Broker. Since the TS Session Broker is only used when the user connects to the farm, it can be considered a lightweight service, and its implementation can be designed as such. Start by implementing the role service in a small farm, measure the performance, analyze and learn from the results, and adjust the sizing accordingly.

    If more accuracy is required, establish this with a load test that closely matches the behavior that users will exhibit. The load test must be designed so that the TS Session Broker is the bottleneck, so perform it against a farm in which the terminal servers have ample capacity.

    Select a server form factor for the TS Session Broker, and run a load test against it using a load testing product or live tests. The Windows Server 2003 Deployment Kit provides Terminal Services capacity planning tools—Roboserver (Robosrv.exe) and Roboclient (Robocli.exe)—which include application scripting support. You can use these tools, which are available on the Windows Server 2003 Deployment Kit companion CD, to easily place and manage simulated loads on a server that reflects the typical user’s behavior in disconnecting from, and reconnecting to, sessions with terminal servers in a farm.

    Monitor the performance of the TS Session Broker server, using the guidance in Appendix D to record the load on the CPU, memory, disk IO, and network. Load the server with consistent groups of users in blocks, and increment this over time. Each group should be running a typical set of applications. Monitor the system until the utilization of the processor, memory, disk, or NIC exceeds acceptable limits. When the acceptable limit has been exceeded, subtract a comfortable measure of users from that last test. This reduced number of users is the total number of users per server for the form factor. Consider removing an additional percentage of users to create additional capacity in the server, which is sometimes referred to as buffer or headroom. This number is the users per server capacity value. Record it in the job aid (Appendix C).

    Run four suites of this test:

    • For heavy users, to establish the per-user cost of a heavy user.
    • For normal users, to establish the per-user cost of a normal user.
    • For light users, to establish the per-user cost of a light user.
    • For a mix of users, who represent the expected user population since that population will typically be a mixture of heavy, normal, and light users.

    In each test, add users, and monitor the system until it reaches the acceptable performance threshold. Record in the job aid (Appendix C) how many users of each type the server can hold and the unit cost of each single user. Confirm that the results of the last test, completed with a mix of users, match what would have been expected for that combination of heavy, medium, and light users. Then reduce the current number of users until the utilization falls to an acceptable level, and this is the number of users that the TS Session Broker can support on the selected server form factor.

  3. Determine whether to use dedicated redirectors. To increase session redirection performance in a large terminal server farm, you can configure terminal servers to be dedicated redirectors. These servers will process incoming requests but will not accept user sessions. This can deliver a faster logon experience to the user.

    Re-run the load test with the TS Session Broker and the redirector on separate servers of the chosen form factor. Record the results of this test, and compare them to the previous test to determine whether the separation of the redirector onto a different server increases the number of user sessions that can be supported. If it does, record that number, and weigh that benefit against the additional cost and maintenance overhead that will be incurred by the addition of a server to determine whether to separate the redirector from the TS Session Broker.

  4. Determine the number of servers required. Divide the total number of users that will have sessions with the farm by the number of users that a TS Session Broker server can support in order to determine the number of servers required for TS Session Broker. Complete this process for each farm, and record the value in the job aid (Appendix C).

    If the decision has been made to use dedicated redirectors, use the output from the tests in step 3 to determine the sizing of the dedicated redirector. Divide the total number of users that will connect to the farm by the number of users that the dedicated redirector can support. This is the number of dedicated redirectors required. Complete this process for each farm, and record the value in the job aid (Appendix C).

  5. Decide whether the server(s) that host TS Session Broker can be shared. Now that the resource requirements for a dedicated TS Session Broker service are known for each farm, a decision can be made on whether the TS Session Broker role service can be shared. This can be done in the following ways:
    1. The TS Session Broker server can be shared between farms. In this case, sum the number of users that has been determined for the TS Session Broker server in each farm, and divide by the number of farms. This will produce the number of users that can be supported on each shared TS Session Broker server.

      Divide the total number of users that will have sessions with the farms by the number of users that a TS Session Broker server can support to determine the number of servers required for TS Session Broker. Complete this process for each “shared” farm, and record the value.

    2. The TS Session Broker server can host other Terminal Services role services. Complete all the tasks in this step to determine the number of users that the server form factor can support for each of the role services that will be combined on a server. Then sum the number of users for each role service that will be combined, and divide by the number of shared role services. This will produce the number of users that can be supported on each role-shared server.

      Divide the total number of users that will connect to the farm by the number of users that a role server can support to determine the number of servers required for the roles. Complete this process for each shared server, and record the value.

  6. Determine where to place the TS Session Broker role(s) in the network. The TS Session Broker role service needs to be able to communicate with each terminal server farm whose sessions it manages. Terminal server farms on a high-speed LAN can share the TS Session Broker role service. Conversely, farms separated by WAN connections need a TS Session Broker role service assigned at each location. Place the TS Session Broker role service instances on the job aid, ensuring that every terminal server farm requiring a TS Session Broker role service can connect to one through a high-speed connection.
  7. Determine the fault tolerance requirements of the TS Session Broker servers. The TS Session Broker server provides load balancing for the terminal servers in the farm. It also directs reconnection requests to the server on which a disconnected session had been running. If it is unavailable, these reconnections will not be completed, and orphan sessions will begin to appear on the terminal servers in the farm.

    For this reason, the TS Session Broker role service should be protected from failure by instantiating more than one copy of the role service in an MSCS cluster. This would provide continuity of service in the event of a failure during a session reconnect. Examine the SLAs with users to determine whether the service that an MSCS cluster can deliver is actually required.

Record these decisions in the job aid.

Task 2: Design and Place the Terminal Services License Servers

There are two types of Terminal Services client access licenses (TS CALs):

  1. TS Per Device CALs. When Per Device licensing mode is used and a client computer or device connects to a terminal server for the first time, the client computer or device is issued a temporary license by default. When a client computer or device connects to a terminal server for the second time, if the license server is activated and enough TS Per Device CALs are available, the license server issues the client computer or device a permanent TS Per Device CAL.
  2. TS Per User CALs. A TS Per User CAL gives one user the right to access a terminal server from an unlimited number of client computers or devices. When the client or device connects to the terminal server, Active Directory is contacted to determine whether the user has a Terminal Services client access license (TS CAL). If the user does not have a TS CAL, the TS Licensing role service is called to provide a license to associate with that client in Active Directory.

    TS Per User CALs are not enforced by TS Licensing. As a result, client connections can occur regardless of the number of TS Per User CALs installed on the license server.

    Note   This does not absolve administrators from the Microsoft Software License Terms requirements to have a valid TS Per User CAL for each user. Failure to have a TS Per User CAL for each user, if Per User licensing mode is being used, is a violation of the license terms.

The TS Licensing role service can be shared across terminal server farms. If it is shared across terminal server farms, it will provide TS CALs to clients connecting to any of those farms from its pool of TS CALs.

Using the following process, plan the capacity of the license server so that it can deal with the request rate for new TS CALs. Then decide where TS Licensing services are needed and in what format, and determine which farm connects to each TS Licensing server. Place this information in the job aid (Appendix C).

  1. Determine the demand on the TS Licensing server. At the time of writing, there is no available guidance on capacity and performance planning for TS Licensing. Since TS Licensing is used when the user connects to the farm, it can be considered a lightweight service and its implementation can be designed as such. Start by implementing the role service in a small farm, measure the performance, analyze and learn from the results, and adjust the sizing of the role service in the next farm accordingly.

    If more precision is required, perform a load test that closely matches the behavior that users will exhibit. This load test must be designed so that the TS Licensing role service is the bottleneck, so perform it against a farm in which the terminal servers and other Terminal Services role services have ample capacity.

    Select a server form factor for TS Licensing and run a load test against it using a load testing product or live tests. The Windows Server 2003 Deployment Kit provides Terminal Services capacity planning tools—Roboserver (Robosrv.exe) and Roboclient (Robocli.exe—which include application scripting support. You can use these tools, which are available on the Windows Server 2003 Deployment Kit companion CD, to easily place and manage simulated loads on a server that reflects the typical user’s behavior in disconnecting from, and reconnecting to, sessions with terminal servers in a farm.

    Monitor the performance of the TS Licensing server, using the guidance in Appendix D to record the load on the CPU, memory, disk IO, and network. Load the server with consistent groups of unlicensed users in blocks, and increment this over time. Each group should be running a typical set of applications. Monitor the system until the utilization of the processor, memory, disk, or NIC exceeds acceptable limits. When the acceptable limit has been exceeded, subtract a comfortable measure of users from that last test. This reduced number of users is the total number of users per server for the form factor. Consider removing an additional percentage of users to create additional capacity in the server, which is sometimes referred to as buffer or headroom. This number is the users per server capacity value. Record it in the job aid (Appendix C).

  2. Determine the number of servers required. Divide the total number of users or devices that will have sessions with the farm by the number of users that a TS Licensing server can support to determine the number of servers required for TS Licensing. Complete this process for each farm, and record the value.
  3. Decide whether the server(s) that host TS Licensing can be shared. Now that the resource requirements for a dedicated license server are known for each farm, a decision can be made on whether the TS Licensing role service can be shared. This can be done in the following ways:
    1. The TS Licensing server can be shared between farms. In this case, sum the number of users that has been determined for the TS Licensing server in each farm, and divide by the number of farms. This will produce the number of users that can be supported on each shared TS Licensing server.

      Divide the total number of users that will have sessions with the farms by the number of users that a shared TS Licensing server can support to determine the number of servers required for TS Licensing. Complete this process for each “shared” farm, and record the value.

    2. The TS Licensing server can host other Terminal Services role services. Complete all the tasks in this step to determine the number of users that the server form factor can support for each of the role services that will be combined on a server. Take the lowest of these numbers; that is the number of users that can be supported on each role-shared server.

      Divide the total number of users that will connect to the farm by the number of users that a role-shared server can support to determine the number of servers required for the roles. Complete this process for each shared server, and record the value.

      The TS Licensing server can host services other than Terminal Services roles, such as a file server. Because of the possibly variable nature of those services, this scenario will require a load test in combination with the TS Licensing role service with which it will be hosted. Proceed as in step 2 above, and then divide the total number of users who will connect with the combined service (TS Licensing and the other services) by the number of users that the shared server can support, to determine the number of servers required.

  4. Determine where to place the TS Licensing role(s) in the network. TS Licensing needs to be able to communicate with each terminal server farm whose licenses it manages. Terminal server farms on a high-speed LAN can share TS Licensing services. Conversely, farms separated by WAN distances need TS Licensing services assigned at each location.

    If there are areas where terminal server licenses will be procured and administered by different entities (for example, if Research and Development have a separate support group from Engineering), it may be necessary to place additional TS Licensing roles for each of these organizational groups.

  5. Determine the fault tolerance requirements of TS Licensing. If TS Licensing is unavailable, new clients and clients whose licenses have expired can be denied access to the terminal servers. To reduce the possibility of this occurring, place two TS Licensing servers with half of the licenses installed on each server. Then publish both of the servers in Active Directory.

Record these decisions in the job aid.

Task 3: Design and Place the Terminal Services Gateway Servers

External users can connect from an unsecured location to a terminal server farm in the following ways:

  • Through a Virtual Private Network (VPN) that extends the secure zone out to the user and provides access to all corporate applications. In this case, the user is authenticated on the network when the VPN is established.
  • Connecting to TS Gateway over the RDP protocol. This provides an encrypted connection but requires that the RDP port (3389) is open in the firewall.
  • Connecting to TS Gateway over RDP that is encapsulated in HTTPs. This provides easy Network Address Translation (NAT) and firewall traversal without requiring the RDP port (3389) to be open to the Internet.

When an external client connects to the Terminal Services environment through TS Gateway, TS Gateway acts as a security broker, performing client authentication by calling back-end services. It accepts the connection and authenticates the client through Terminal Services connection authorization policies (TS CAPs) and resource authorization policies (TS RAPs) that are called from Active Directory. It may also call Network Access Protection to test the client’s health. Figure 4 illustrates these connections.

Once authorized, the client tells the TS Gateway service which terminal server it wants to connect to. The TS Gateway service makes the connection to the requested server or terminal server farm through the firewall. The terminal server then performs a Windows authentication challenge with the user. If the user passes authentication, the Terminal Services session can begin.

Moving parts - Gateway 1 29 08.bmp

Figure 4. How TS Gateway enables access to the Terminal Services environment for external clients

TS Gateway can also be used to broker authentication within the corporate network if business requirements necessitate.

TS Gateway works with the RDC client to deliver these capabilities and requires RDC client 6.0 or later.

Using the following process, decide where TS Gateway role services are needed and in what format, and determine which farm connects to each TS Gateway:

  1. Determine whether the TS Gateway role service is required. First determine whether clients will connect to the terminal server farm from outside a firewall. If they will, determine whether those clients are able to connect to the farm using a VPN network connection. If a VPN network connection is not available or is not appropriate because it exposes the entire internal network to the clients, TS Gateway can be deployed to provide them access to the terminal server farm.

    If clients will not connect to the farm from outside a firewall, TS Gateway is not required.

  2. Determine the required security model and the location to place the TS Gateway role. The TS Gateway role can be placed either outside or inside the secure network, and this determines the security model:
    • Place the TS Gateway outside the secure network in a screened subnet or perimeter network. In this case, the client connects to the TS Gateway from the Internet over TLS/SSL through port 443 of the TS Gateway server.

      This is the simplest possible configuration for TS Gateway and requires the fewest servers. The downside of this configuration is that it requires that TS Gateway be a member of the Active Directory domain, and so the domain must be extended into the perimeter network. Also, port 3389, the default RDP port, will need to be opened behind TS Gateway.

    • Place the TS Gateway inside the secure network. In this case, ISA server or a dedicated SSL terminator is needed to remove SSL encryption.

      Port 443 will be open on the external firewall, and either port 443 or port 80 will be on the internal firewall. Active Directory is not exposed, nor is port 3389. The ISA server also adds another level of protection as a layer 7 firewall by monitoring the packets bound for the TS Gateway and can shut down a suspicious connection.

      Decide whether the TS Gateway will be placed inside or outside the firewall.

      The TS Gateway can also be configured to request that clients supply statements of health to the Network Access Protection (NAP) service hosted on the Network Policy Server (NPS). If the client passes the health check policies, it is allowed to complete the connection. If it does not have the proper health levels, it is required to update before connecting.

      Determine whether security policy requires NAP to be implemented.

      TS Gateway performs a critical part of the client logon process, and as such it needs to be able to communicate with the terminal server farm and with the Active Directory domain at LAN speeds. Place the TS Gateway role service so that it has high speed connections to the domain server and the farm.

  1. Determine the demand on the TS Gateway. At the time of writing, there is no available guidance on capacity and performance planning for TS Gateway. Start by implementing the role service in a small farm, measure the performance, analyze and learn from the results, and adjust the sizing of the role service accordingly.
  2. Alternatively, if more precision is required, a load test can be performed that closely matches the behavior that users will exhibit. This load test must be designed so that the TS Gateway is the bottleneck, so perform it against a farm in which the terminal servers and other role services have ample capacity.
  3. Select a server form factor for the TS Gateway, and run a load test against it that reflects the typical user’s behavior in connecting to the terminal server farm.
  4. Select a server form factor for the TS Gateway, and run a load test against it using a load testing product or live tests. The Windows Server 2003 Deployment Kit provides Terminal Services capacity planning tools—Roboserver (Robosrv.exe) and Roboclient (Robocli.exe)—which include application scripting support. You can use these tools, which are available on the Windows Server 2003 Deployment Kit companion CD, to easily place and manage simulated loads on a server that reflects the typical user’s behavior in disconnecting from, and reconnecting to, sessions with terminal servers in a farm.
  5. Monitor the performance of the TS Gateway server, using the guidance in Appendix D to record the load on the CPU, memory, disk IO, and network. Load the server with consistent groups of users in blocks, and increment this over time. Each group should be running a typical set of applications. Monitor the system until the utilization of the processor, memory, disk, or NIC exceeds acceptable limits. When the acceptable limit has been exceeded, subtract a comfortable measure of users from that last test. This reduced number of users is the total number of users per server for the form factor. Consider removing an additional percentage of users to create additional capacity in the server, which is sometimes referred to as buffer or headroom. This number is the users per server capacity value. Record it in the job aid (Appendix C).

    Run four suites of this test:

    1. For heavy users, to establish the per-user cost of a heavy user.
    2. For normal users, to establish the per-user cost of a normal user.
    3. For light users, to establish the per-user cost of a light user.
    4. For a mix of users, who represents the expected user population since that population will typically be a mixture of heavy, normal, and light users.

    In each test, add users, and monitor the system until it reaches the acceptable performance threshold. Record in the job aid (Appendix C) how many users of each type the server can hold and the unit cost of each single user. Confirm that the results of the last test, completed with a mix of users, match what would have been expected for that combination of heavy, medium, and light users. Then reduce the current number of users until the utilization falls to an acceptable level; this is the number of users that the TS Session Broker can support on the selected server form factor.

  6. Determine the number of servers required. Divide the total number of users that will connect to the farm by the number of users that a TS Gateway server can support to determine the number of servers required for TS Gateway. Complete this process for each farm, and record the value.
  7. Decide whether the server(s) that host TS Gateway can be shared. Now that the resource requirements for a dedicated TS Gateway service are known for each farm, a decision can be made on whether the TS Gateway role service can be shared. This can be done in the following ways:
    1. The TS Gateway server can be shared between farms. In this case, sum the number of users that has been determined for the TS Gateway server in each farm, and divide by the number of farms. This will produce the number of users that can be supported on each shared TS Gateway server.

      Divide the total number of users that will have sessions with the farms by the number of users that a shared TS Gateway server can support to determine the number of servers required for TS Gateway. Complete this process for each “shared” farm, and record the value.

    2. The TS Gateway server can host other Terminal Services role services. Complete all the tasks in this step to determine the number of users that the server form factor can support for each of the role services that will be combined on a server. Take the lowest of these numbers; that is the number of users that can be supported on each role-shared server.

      Divide the total number of users that will connect to the farm by the number of users that a role-shared server can support to determine the number of servers required for the roles. Complete this process for each shared server, and record the value.

    3. The TS Gateway server can host other services, such as a file server. Because of the possibly variable nature of the other workloads, this scenario will require a load test in combination with the TS Gateway role service(s) with which it will be hosted. Proceed as in step 2 above, and then divide the total number of users that will connect with the combined service (TS Gateway and the other services) by the number of users that the shared server can support to determine the number of servers required.
  8. Determine the fault tolerance requirements of the TS Gateway. If the TS Gateway service is unavailable, external clients will not be able to connect to the farm. To reduce the possibility of this occurring, plan to implement a fault tolerance solution using more than one TS Gateway, and load balance the traffic across those TS Gateways. There are two ways to do this:
    1. Implement a hardware load balancer. A wide variety of solutions are available, and they deliver very high performance.
    2. Implement Windows Network Load Balancing. This is implemented with ISA server and is relatively easy to set up.

      Note   The TS Gateway role service cannot be implemented in an MSCS cluster.

Record these decisions in the job aid (Appendix C).

Decision Summary

The role servers that can service multiple farms have been designed, sized, and placed for the Terminal Services implementation. Re-examine the design to ensure that every terminal server farm and every user can access the role services they require.

Of the role services addressed in this step, only TS Licensing can be shared with earlier versions of Windows Terminal Services. So a migration from Windows Server 2003 Terminal Services to Windows Server 2008 Terminal Services will involve building a new environment to deliver the terminal server function from the farm, as well as the role services.

Additional Reading

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.

Download

Get the IPD Windows Server 2008 Terminal Services guide

Solution Accelerators Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions