Placement of Terminal Servers

As you'll see throughout this book, quite of bit of behind-the-scenes communication takes place in Terminal Server environments. To understand where to best locate your Terminal Servers, consider the communication that takes place between physical servers on the network.

Figure 3.1: Terminal Server network communication

The key here is to determine where the servers should be located in relation to the data and users. Consider the environment in Figure 3.2 consisting of two office locations. Let's assume that users from both offices need to access a database-driven application housed in the main office.

Figure 3.2: Users in two offices need access to the same database application

This company's IT department has decided to use Terminal Server to ease application deployment and get the best possible performance for remote users. The company is faced with two choices when it comes to the location of the Terminal Server for the remote users—they can either put the Terminal Server at the remote office with the users, or at the main office with the database.

While both choices would allow the company to manage the users' applications, putting the server near the database will yield the best performance. (See Figure 3.3 on the next page.) The network traffic between the database and the client application running on the Terminal Server is much heavier than the RDP user session traffic between the Terminal Server and the user. By placing the Terminal Server at the main office, the database client software installed on the Terminal Server is located near the database itself. Application performance is excellent due to this close proximity, and only RDP session traffic need cross the expensive, slow WAN link.

Figure 3.3: A Terminal Server at the main office

Now consider the other possible server placement option for this company. If the Terminal Server was located at the remote office (as in Figure 3.4 on the facing page), heavy database traffic would still have to cross the WAN while light, efficient RDP session traffic would be confined the remote office's local LAN, where bandwidth is plentiful. Putting the server at the remote office would not benefit application performance from an end user's point-of-view since the level of database traffic on the WAN is no different than if they weren't using Terminal Server.

Figure 3.4: Terminal Server placement at the remote office

As this simple example shows, it's desirable to place the Terminal Server close to the data source rather than close to the users. Microsoft's RDP protocol is designed to work over slow WAN links. Heavy application data traffic flowing between the Terminal Server and the data server remains on a local LAN.

Why should you care about server placement?

As shown in the previous example, the placement of your Terminal Servers will directly impact:

• Users' session performance

• Network bandwidth usage

• Server management

Users' Session Performance

Performance of the users' sessions depends not only on the network speed between the user and the Terminal Server, but also on the speed between the Terminal Server and the data the user needs. It does no good to put a Terminal Server on the same LAN link as a user if that server must access files that are located across a 56K connection.

Performance must be balanced with the network latency between the user and the server. Users won't want to use Terminal Server applications with a two-second delay from the time they hit a key until the time the character appears on the screen.

Network Bandwidth Usage

Network bandwidth usage is directly affected by the location of the Terminal Server. Average RPD user sessions require only about 31KB per second. Many n-tier business applications (such as Baan, SAP, and PeopleSoft) require much more. If your Terminal Server is on the wrong side of the network you won't save any bandwidth by using it.

Server Management

Ultimately, someone (maybe you?) is going to need to maintain and manage the Terminal Servers. It's usually much easier for administrators to maintain them if the application servers and the Terminal Servers are both at the same physical location.

What are the server placement options?

Even after examining the complexities that arise when deciding where to put your Terminal Servers, there are really only two possible options:

• Distribute the servers throughout your environment, balancing some near each data source.

• Put all Terminal Servers in the same place, in one big datacenter.

As with all decisions, option point has distinct advantages and disadvantages that must be considered when designing the final solution.

Option 1. Terminal Servers Placed in many Locations

You may need to put multiple Terminal Servers in multiple different locations if your users need to access data that is stored in different locations. Doing so ensures that users' application sessions are close to the data they need.

In this situation, a user would simply connect to multiple Terminal Servers in order to access his data (see Figure 3.5 on the facing page). An added benefit here is that there is not one single point of failure, since losing access to one data center only affects some applications.

Figure 3.5: Multiple Terminal Servers provide fast access to data

The downside to having Terminal Servers in multiple locations is that your overall environment becomes more complex. Servers must be managed in several physical locations. User will have to access multiple servers through different connections. It is inevitable that some data will only exist in one place, and that users will need to access it from every Terminal Server regardless of its location. (Windows roaming profiles are a good example.) Lastly, a multi-server Terminal Server environment requires that each of the servers communicate with the required backend services like Terminal Services Licensing and the Session Directory. When all Terminal Servers are located on the same LAN, managing these services is easy since everything is centralized. However, when Terminal Servers span multiple physical locations connected by WAN links, this communication must be managed or the backend services must be deployed to the WAN sites also. (More information on planning for an enterprise deployment is found in Chapter 14.)

As you can see in Figure 3.5, there are several advantages and disadvantages to placing Terminal Servers in multiple locations throughout your environment.

Advantages of Placing Servers in Multiple Locations

• Users' Terminal Server sessions are always close to their data.

• Efficient use of WAN bandwidth.

• Local departments can own, control, and manage their own servers.

• Increased redundancy.

Disadvantages of Placing Servers in Multiple Locations

• More complex environment.

• Users may need to connect to multiple Terminal Servers in order to use all their applications.

• Your servers might require additional local (onsite) administrators because they are not all in the same building.

Option 2. All Terminal Servers in one Central Location

Instead of sprinkling Terminal Servers throughout your environment, you could put all of your servers in one datacenter (see Figure 3.6). After all, providing remote access to Windows applications is what Terminal Server is designed to do in the first place.

Figure 3.6: All Terminal Servers in one datacenter

Having one central datacenter contain all of your Terminal Servers is easy to administer, but causes other issues to arise.

Any users that need to access data outside of the datacenter where the Terminal Servers are located must do it via a WAN link. While the performance of the RDP session between a user and Terminal Server won't be a problem, significant performance problems could exist within the application sessions themselves due to potential great WAN distance between the Terminal Server and the user's data.

Plus, different applications handle data latency in different ways, but your users will become frustrated if they have to wait a long time to open or save files. Additionally, WAN bandwidth might be wasted with users forced to connect to all Terminal Server applications via the WAN.

Advantages of Placing all Terminal Servers in one Location

• Simple environment to administer and support.

• Users can connect to one Terminal Server to run all of their applications.

• Terminal Servers are all in the same physical location.

Disadvantages of Placing all Terminal Servers in one Location

• Access to data may be slow if the data is located across a WAN.

• WAN bandwidth may be wasted because users would be forced to connect to a remote server for any Terminal Server application.

• No option for local Terminal Server (local control, local speed, etc.)

• Single point of failure.

As you can see, the location and placement of your Terminal Servers will directly impact many aspects of your environment. While some aspects of the design will be easy, others will require some deliberation and thorough planning (and lots of meetings).

Considerations when Choosing Server Locations

The previous example showed that the data location directly affects the placement of the Terminal Server. However, in the real world, there is more to consider, including:

• Where are the users?

• Where is the data?

• How much and what type of data is each user going to need?

• How many different applications are the users running?

• Where is the IT support for the applications?

• What does the WAN look like?

User Location

The location of users is a major factor to consider when deciding where to put the Terminal Servers. Are all of the users in one central location or are there multiple pockets of users? Is there a datacenter at every location where the users are or are the users at remote offices?

Data Sources

The data that users need to access from within their Terminal Server sessions is probably the most important consideration when deciding where to put your servers. It's important to consider all types of data that a user may need to access from a session. These include back-end application data and databases as well as files and file shares, home drives, and Microsoft Windows roaming profiles. (See Figure 3.7.)

Figure 3.7: Users often need to access multiple types of data from one session

Are the users at the same physical location as their data sources? Is all application data at the same location on the network as users' home drives and Windows roaming profiles, or will users need to pull data from multiple network locations for a single session?

When considering the data that users need to access, think about how each data source will be used throughout the sessions. Will users need to access the data only during session startup or shutdown, or will they need constant access throughout the entire session? For each data source, will users only need to read the data, or will they need to write as well?

Finally, consider the impact of each data source on the users' sessions. What happens if the path to each data source is congested? Will users be merely inconvenienced, or will they not be able to do their jobs?

To help understand the importance of these questions, refer to Figure 3.8. This diagram details a situation that is becoming more and more common as organizations grow.

Figure 3.8: A user in Europe needs to access data throughout the world

In this example, a user works for a company with a worldwide presence. Apparently this company followed the advice of consultants from the nineties, because their crucial business data has been consolidated into one single database in the US. One of the main reasons that this company chose to use Terminal Server was so that their European users have fast access to the database application. This company put a Terminal Server in the US, right next to the database server, allowing the European user to access the database through a bandwidth-efficient RDP session. Sounds great! Very simple. Unfortunately, in the real world it is not always so simple.

The European user must access applications other than that one US database. Since the user is already running applications via RDP sessions to a server in the US, he might also access other applications via that same server, right?

Let's think about this before we jump to a conclusion. Should a European user really be accessing all applications via servers in the US? Sure. If the user is already crossing the WAN to connect to the database, there is no real impact to adding more applications. But will the user always be utilizing the database? What if the user just wants to use other applications? Should the company pay for the transatlantic bandwidth so that the user can create a PowerPoint presentation? What about the user's home drive? Most likely, the user will want to save files and work with others. Should he use PowerPoint running on a US server while saving files to a file server in Europe? What about PowerPoint's auto-save feature? Will this user have the patience to wait while his file is auto-saved across the ocean WAN every ten minutes?

The point here is that users need to connect to multiple data sources, and they frequently need to access data that resides in different regions of the world. While this European example is a geographic extreme, the same ideas apply anywhere. A slow WAN is a slow WAN. The previous example also applies to users in Washington, D.C. accessing databases 30 miles away in Baltimore over a 56k frame relay.

This example illustrates a situation in which a user only needs access to a database and a home drive. Other users may need to access files and data from many different groups in many different locations. Also, don't forget about Windows roaming user profiles. If a single roaming profile is to be used for all Terminal Server sessions on servers throughout the world, then that profile needs to be accessible to the user wherever they log on. (More on roaming profiles in Chapter 6.)

If that user only needed to access data from one geographic region, the design would be simple. You would put a Terminal Server next to the data and have the user connect via an RDP session. However, with multiple geographic regions, all of which that have important data for the user, the complexity of the design increases.

Applications

The number and types of applications that you want to make available via Terminal Server also affect the decision as to where the servers should be located. The application mix needed by one user may dictate that the user must connect to multiple Terminal Servers. Some users may only need to access applications on single Terminal Server while others may need to access applications across departments via many Terminal Servers.

The mix of local applications and remote Terminal Server applications is also a factor. Will any applications be loaded locally on the users' computers or will all applications be accessed via Terminal Server? If the latter and the Terminal Servers are located across the WAN from the users and the WAN link goes down, all productivity stops. Is that an acceptable risk to the organization, or should some servers be local, though all the data may not be local?

IT Support of Applications

How does your organization's IT department support applications? If all application support is conducted from one site, it makes sense for all Terminal Servers to be located at that site. Most large organizations utilize many applications supported by different people from different locations,as shown in Figure 3.9. In these cases you may have to place Terminal Servers in multiple locations, each server placed near those that support its applications.

Figure 3.9: Application support from multiple people in multiple locations

WAN Architecture

The wide area network can also affect where Terminal Servers should be located. If bandwidth is congested, Terminal Servers should be located across WAN links because they are generally more efficient than the native applications over WAN links. (Chapter 13 has hints about what to do in bandwidth-constrained environments.)