It is important to note that Windows Server 2003 has significant scalability advantages over its predecessors. Primarily this is because the Windows Server 2003 kernel provides better use of the 32-bit virtual address space. Because a terminal server must allocate virtual resources for all users who are logged on, whether they are active or in a disconnected state, the improved memory handling in Windows Server 2003 gives it significant advantages over Windows 2000 Server. In addition, Windows Server 2003 is more effective at using faster processors and system buses. This again gives Windows Server 2003 significant advantages over Windows 2000 Server.

Because remote serving of applications is both processor-intensive and memory-intensive, the most significant limits on the number of users a server can support are imposed by a server's processing power and available RAM. Network bandwidth and disk performance can also be factors, but typically, a server's capacity to handle requests will be exhausted well before the network bandwidth and disk drive subsystems have reached maximum utilization.

Planning should start by looking at not only the number of users you need to support but also the following factors:

These latter characteristics play a significant role in the actual usage of a server. Users can be divided into three general types:

The impact of these types of users can best be illustrated graphically. Consider the scenario in Figure 31-2. The chart shows the number of different types of users that can be supported on three different server configurations.

Figure 31-2. Terminal Services capacity example.

As you can see from the example, each server can handle a large number of data entry workers relative to other types of workers. Because CPU power and RAM are so important, the servers are given fast processors and a lot of RAM. These results are based on using Intel Xeon Processors operating at 3.2 gigahertz (GHz) and using a 2 megabyte (MB) L2 Cache with a 533 megahertz (MHz) front size bus.

While the example takes into account the types of users and the types of applications being used, it doesn't take into account the way users work. The way users work can also have a significant impact on Terminal Services. You should also consider these factors:

Believe it or not, typing speed can affect performance. Many users who type very quickly will make more updates and require more processing than a group of users who type slowly. You don't want to tell users to type more slowly, but you do want to take their typing skills into account.

Users with poor work habits can have a significant impact on performance. Consider the case of a user who exits applications rather than switching among them: The user starts Microsoft Outlook to check his mail, exits Outlook, starts Microsoft Word to type a document, exits Word, starts Outlook again to check his e-mail, exits Outlook, and so on—and does this all day long. Starting and exiting applications requires more processing and resources than simply switching among applications as you use them.

The experience settings on the client can have a significant impact on performance as well. If users have optimized their experience settings for LAN connections of 10 Mbps or higher, they will have desktop backgrounds, themes, menu and window animation, and other extras that require a lot more processing on the server. The only experience setting that actually improves performance is bitmap caching, which ensures that caching is used as much as possible to reduce the amount of data that has to be passed to the client. Client display settings also affect server performance. The default display setting is for High Color (16 bit). An additional option is available for True Color (24 bit). As 24-bit color requires a lot more processing than 16-bit color, this setting should only be used by those who need high-end color resolution, such as graphic designers.

Having covered factors that can affect performance, let's take a closer look at how to plan for capacity. Start by determining the average number of Terminal Services users. Remember that both active users and those with inactive or disconnected sessions use system resources. Then consider the types and average numbers of applications users will be running. Run those applications and use the techniques discussed in Chapter 15 and Chapter 16, to determine how much physical and virtual memory each application uses on average. This should give you a good baseline for capacity planning.

If a server will have 100 users, who each run four applications on average, and those applications collectively use 10 MB of physical memory and 24 MB of virtual memory on average, you know the system will need a minimum of 1 gigabyte (GB) of RAM for good performance. That's the baseline. You typically want to have 50 percent capacity above the baseline to ensure that the server can handle peak usage loads and can support additional users if necessary. Therefore, in this scenario you'd want to have a minimum of 1.5 GB of RAM.

Processing power is as important as RAM. A server's processors need to be able to keep up with the processing workload. As you scale up, you need to be able to add processors to handle the additional processing load of additional users. If you are monitoring server performance, pay particular attention to the Copy Read Hits % performance counter of the Cache performance object. This counter tracks the percentage of cache copy read requests that did not require a disk read to provide access to the page in cache. For best performance, you want this counter to be at 95 percent or above (optimally at 99 percent). If the counter is below 95 percent, the server is reading from the page file on disk frequently and this can affect performance. You can resolve this problem by adding RAM to the system.

Also consider network bandwidth and disk configuration in capacity planning. A network running at 100 megabits per second (Mbps) can handle hundreds of Terminal Services users. A network running at 1,000 Mbps (Gigabit Ethernet) can handle thousands of Terminal Services users. Consider existing traffic on the network before Terminal Services is deployed a limiting factor. For capacity planning, you can test the average amount of bandwidth a client uses when working with a terminal server by monitoring the Bytes Total/sec counter of the Network Interface performance object. If a client uses 1,250 bytes per second on average, this is 10,000 bits per second. In theory, a network running at 100 Mbps could handle 10,000 of these clients. Reduce this by 50 percent to shift from the theoretical to what is probably possible, and then subtract current bandwidth usage to come up with a working number.

Disk subsystem performance can also have a substantial impact on overall performance, especially on a server that makes moderate to heavy use of the paging file. Because the number and frequency of standard read/write operations for files affects the design of the disk subsystem, these operations will also affect overall performance. Ideally, the disk subsystem on a terminal server will be configured with hardware RAID and multiple RAID controllers rather than software RAID. When multiple SCSI/RAID controllers are used, disks should be configured to distribute the load. When you install applications that will be used with Terminal Services, you can help spread the load by installing and configuring applications to use different disk sets on different SCSI/RAID controllers.

When you are deploying Terminal Services, your planning should include deciding where in the organizational structure your terminal servers should be located. As discussed in Chapter 30, servers running in Terminal Server mode should be clearly separated from servers running in Remote Desktop for Administration mode. This ensures that administrators and support personnel can use Remote Desktop for Administration throughout the organization and that selected users can make use of terminal servers.

The best way to achieve separation of these services is to deploy terminal servers in a separate Organizational Unit, which I will call the Terminal Services OU. You can then implement policies and restrictions for Terminal Services separately from those for the rest of the organization. To start, you should place the computer accounts for your terminal servers in the Terminal Services OU. When you do this, you can apply systemwide restrictions to terminal servers and enforce these restrictions using a computer-based policy. These restrictions then replace or are added to the restrictions a Terminal Services user usually has when logging on to the domain.

If you need to provide additional restrictions for Terminal Services users, you can do so on a per-user basis by placing the user account in the Terminal Services OU and defining userbased policy restrictions. In this way, the restrictions are enforced wherever the user logs on to the domain.

Deploying Terminal Services in a single-server environment is much easier than deploying Terminal Services in a multi-server environment. In a single-server deployment, a group of clients always connects to the same server, so that although your organization may have three terminal servers, Group A always uses Server 1, Group B always uses Server 2, and Group C always uses Server 3, as shown in Figure 31-3.

Figure 31-3. Terminal Services in a single-server environment.

A single-server configuration is the easiest to set up, as you need to perform only the following steps:

Steps 2 through 4 are discussed in detail in this chapter. Chapter 30 discussed Remote Desktop Connection client setup and support.

Deploying Terminal Services in a multi-server environment requires a lot of planning and an advanced setup. In a multi-server environment, you use load balancing to create a farm of Terminal Servers whose incoming connections are distributed across multiple servers. Clients see the load-balanced Terminal Server farm as a single server. The farm has a single virtual IP address, and client requests are directed to this virtual IP address, allowing for seamless use of multiple servers.

Multi-server Terminal Services environments can be implemented using Network Load Balancing. A variety of techniques is possible, including Microsoft Network Load Balancing as discussed in Chapter 18. Terminal Services introduces a wrinkle to the standard Network Load Balancing configuration by introducing the concept of a session. A client that connects to a Terminal Server is said to be in a virtual session. If that session is disconnected, processing continues in a disconnected state and the client can be configured to automatically try to reconnect the session. In a load-balanced farm, you always want a client to connect to the server it was originally working with. This enables users to continue where they left off without loss of data and without having to restart their applications, open documents, and so on.

For multi-server Terminal Services environments, session information can be managed using a Session Directory server (see Figure 31-4). A Session Directory server maintains a session directory database, which contains a record for each session. The record includes the user name under which the session was established, the session ID, and the server to which the session is connected in the load-balanced farm. Session Directory servers are a new feature for Windows Server 2003.

Figure 31-4. A multi-server Terminal Services deployment.

Whenever a client tries to establish a Terminal Services connection and the user is authenticated, the session database is queried to see if a session record for that user exists. In this way, a user who was disconnected from a session can reconnect to the original session on the correct server. Without session management, the user might be connected to a different server and have to start a new session.

The Session Directory server can be a separate server running the Session Directory service as shown in Figure 31-4, or it can be one of the servers in the load-balanced farm running the Session Directory service. There are several advantages to using a separate server. First of all, if you don't use a separate server, you need to use a multiple network interface configuration for Microsoft Network Load Balancing. This configuration ensures that Terminal Services can communicate with the Network Load Balancing cluster and the Session Directory server. In addition, as you scale Terminal Services, you have the option of clustering Session Directory services to provide for greater availability.

To use a session directory, all servers in the farm must be running Windows Server 2003 Enterprise Edition or Windows Server 2003 Datacenter Edition. A multi-server environment is more complex to set up than a single-server environment. To configure Terminal Services in a multi-server environment, you must follow these steps:

Steps 2 through 4, 6, and 7 are discussed in detail in this chapter. Chapter 18 discussed Network Load Balancing setup and support. Chapter 30 discussed Remote Desktop Connection client setup and support.