Section 10.2. Requirements for Terminal Services

10.2. Requirements for Terminal Services

Because most of the processing power that was traditionally on the desktop has moved to the server in a Terminal Services scenario, it follows that the machine hosting Terminal Services for your users should be significantly beefier than you might otherwise be used to. Perhaps the two most critical points as far as hardware requirements are CPU and RAM, followed by the network interface and links.

10.2.1. CPU Requirements

CPU requirements can be difficult to measure because individual users require different slices of processor time at different intervals. Two main factors determine CPU usage: intensity of the applications that users are running, and the number of simultaneous users. Table 10-1 gives a rough estimate for CPU requirements based on number of users and application intensity.

What Happened to Citrix?

When Microsoft introduced its revamped version of Terminal Services in Windows 2000, many predicted the demise of Citrix's venerable MetaFrame product. Citrix basically invented the idea of multiple sessions on one Windows host, and RDP is loosely based on Citrix's protocol, Independent Computing Architecture (ICA). MetaFrame has traditionally sat atop Terminal Services, using its basic functionality as a foundation and adding useful features on top. But many people have asked what with all the improvements to RDP, including bandwidth reduction, client-side caching, device mapping, sound redirection, and increased color depth, why a corporation would continue to buy Citrix's flagship product?

A feature known as Seamless Windows one-to-many connections is available with MetaFrame, but not with raw Terminal Services. For the client, this means applications you see are displayed without having to scroll or use full-screen mode. On the server, though, it's even better: all sessions on the same server that use Seamless Windows are operating out of the same physical instance of the program, saving on hardware resources.

Another hot item is application publishing, which uses a Citrix concept called Program Neighborhood to direct a user to applications via a menu of program options. The user doesn't have to know which servers run those applications with Citrix because he can just choose a program from the menu and be connected directly to it. To use native Terminal Services and RDP, the user would need to find the appropriate server and connect to it.

Additional core features of MetaFrame distinguish it from native Terminal Services. And as always, Citrix releases new features in its Service Releases. Larger organizations that use Terminal Services connections extensively might want to investigate how MetaFrame might improve their efficiency. However, most organizations, especially small businesses, will find that the initially free Terminal Services components of Windows Server 2003 (you pay only for licensing and not the initial software purchase) will suffice for their needs.

Table 10-1. Rough estimates of CPU requirements for Terminal Services

Simultaneous users	Intensity of application(s)	Recommended processor
20-25	Low	Pentium III 750 MHz+
	High	Dual Pentium III 750 MHz+ or Pentium IV Xeon any speed
35-40	Low	Pentium III or IV, 1 GHz+
	High	Dual Pentium IV Xeon 2 GHz+
50-55	Low	Dual Pentium IV Xeon 2 GHz+
	High	Not recommended

10.2.2. Amount of RAM

Here are some hard and fast facts about RAM usage with Terminal Services that you might find helpful:

• Each user takes up roughly 20 MB of the Terminal Services host machine's RAM just by logging in.

• A typical load of two to three Office applications per user will add approximately another 25 MB of RAM to the server's RAM usage.

Of course, additional applications on top of that consume more RAM, and power users typically will not run only Office applications, but rather, more powerful applications that require more hardware resources.

10.2.3. Network Interface Card

The Network Interface Card (NIC) is managed by Windows and should not require any configuration for use with Terminal Services. You should focus more on the available bandwidth and average latency on the network to which the card is connected, and not necessarily on the card itself.

Terminal Services does a surprisingly nice job of adjusting the bandwidth usage of the RDP client to the conditions of the link to which it's connected with the host. You can expect that most RDP connections will take up between 2 kbps and 7 kbps depending on the depth of color requested by the client, the amount of graphics being transmitted, whether sound is included, and other options.

10.2.4. Disk Space

The actual Terminal Services components inside Windows Server 2003 do not require any additional disk space on top of what is consumed by the normal system files. Around 15 MB is taken up for the file share that stores the client installation files for RDP. In addition, users store about half a megabyte of data for their Terminal Services profile information when they first log on to a server. (Remember that Terminal Services users' profiles are automatically roaming because their sessions follow them to whatever workstation is running the RDP client.) Other than this, not much disk space is required to support RDP.

10.2.5. Sizing for Scaling

Let's say, for instance, that you've built a server to run TS and now want to see how well it scales. Microsoft has released a group of scaling scripts and utilities that can be downloaded from:

http://www.microsoft.com/windows2000/techinfo/administration/terminal/loadscripts.asp

The single download includes scripts that should be modified to fit your environment as necessary, and an Excel spreadsheet that will guide you through fine-tuning certain Registry settings to achieve best performance on a machine dedicated solely to hosting TS applications.