One of my first experiences with computers was in 1979. At the time, I was six years old, and my grandfather, who was an IBM guy, took me to his office for a day. I remember distinctly him giving me a tour of the company and showing me his company’s primary mainframe. I was fascinated with what I saw, and as you can imagine, I had a lot of questions. This was when my grandfather gave me a quick crash course in what has since become known as thin client computing.
At that time, thin client computing made perfect sense. All of the company’s employees were using (comparatively) low cost dumb terminals with a green and black, text only display. As each employee worked, the employee’s input was sent to the mainframe for processing, and the mainframe returned a few lines of text. I am guessing that there were probably never more than a hundred bytes at the most flowing between a client and the mainframe.
Today though, it’s a different story. Windows offers us thin client computing in a graphical environment. Although the technology works, and there are plenty of companies that are using it, thin client computing in a Windows environment has always seemed a little impractical to me for offices of any size at all.
There are several reasons for this. The Windows operating system and many Windows applications (such as Microsoft Office) tend to be rather bloated. This means that efficiently running multiple Windows sessions on a single server is going to require a tremendous amount of processing power and memory. Then there is the issue of sending screen refreshes to the clients. Graphics simply require a lot more bandwidth to transmit than text does.
Don’t get me wrong though. I’m not saying that Windows Terminal Services can’t work. I’m just saying that if you are planning on connecting more than one or two sessions to your terminal server then you are going to need to do a little planning and fine tuning to keep the terminal service sessions from eating up all of your network’s bandwidth and to prevent the server from bogging down.
Hardware Planning
If you are seriously considering using the Windows Terminal Services as a regular client operating environment, then choosing the appropriate hardware is absolutely crucial to your success. This is especially true for your terminal server. You really don’t have to worry too much about planning hardware for your clients. As long as the client computers can run a terminal service client and have a decent network card in them, they will be OK. As a matter of fact, one of the most successful terminal service deployments that I ever saw involved clients who were not even using PCs. The clients were using low budget computers that were running the Windows CE operating system (normally used for PDAs). However, since a Terminal Service Client component is available for Windows CE, these machines were able to run terminal sessions with no problems.
Before I get too far into discussing the hardware planning process, I want to clarify one thing up front. The recommendations that I am giving you are not the same as the recommendations that you will get from Microsoft. Microsoft is notorious for understating the hardware requirements for its products. If you don’t believe me, just look at the stated hardware requirements for products such as Windows Server 2003 or Exchange Server 2003. Sure the minimum hardware requirements are sufficient for installing the software, but the software will not run efficiently on minimal hardware. My goal in this article is to provide you with recommendations that are practical for the real world, erring on the side of caution.
Processing Power
In a terminal service environment, most of the burden falls on the server itself, so that is where you want to focus most of your attention (and budget). The first recommendation that I would make for the server is that it have multiple processors. The reason for this is that the terminal server will be basically running a virtual Windows operating system and a full set of applications for each user. The server has to be able to do this, plus run its own operating system as well. If you are going to be running more than maybe two or three terminal sessions, then a single processor server isn’t really up to the job.
Selecting an appropriate server can be a little tricky though. The reason is because adding an extra processor doesn’t double the server’s performance. A second processor will only give you about a 50% performance gain. You could go with a quad processor server, but you must keep in mind that quad processor servers are considered enterprise class machines and are much more expensive than dual processor servers ($20,000 compared to $4,000).
If you have the budget for a high end server then go for it. If you don’t have that sort of budget though, you might be better off buying multiple dual processor servers than a single quad processor server, and just balancing the workload among those machines.
System Memory
The next resource that you will want to focus on is memory. Everybody seems to have different ideas about how much memory is acceptable for a terminal server. One generally accepted guideline is that the server should have 256 MB, plus about 25 MB for each client that will attach through a terminal session. My personal feelings is that this is not nearly enough memory. My personal recommendation is that your server have at least 512 MB (preferably 1 GB), plus 64 MB for each session.
This brings up an interesting point though. Most servers can contain a maximum of 4 GB of RAM. Windows divides this memory address space into 2 GB for Windows to use and 2 GB for user mode processes (applications). This means that unless you use the /3GB switch in the BOOT.INI file (not recommended), you’ve got 2 GB with which to run user sessions. If you dedicate 64 MB of RAM to each session, then the server could comfortably accommodate 32 sessions.
In the real world, servers with 4 GB of RAM have been known to accommodate up to 75 terminal service sessions. Part of the reason for this is because some sessions will consume more memory than others. If a session is sitting idle or running a low end application such as Notepad then that session isn’t going to use anywhere near 64 MB of memory. That frees memory up for additional sessions.
Since the number of sessions that a server can accommodate will vary depending on the way that the users work, my recommendation is to plan on a server with 4 GB of RAM being able to support 32 users. If you have more users than that, then start off by buying one server. See how many users that server is actually able to accommodate in your environment and then you will know how many additional servers that you need to buy. Another option is to invest in a 64-bit server. 64-bit servers do not impose the 4 GB memory restriction.
The Hard Disk
Another important aspect to consider is your server’s hard disk resources. If you plan on hosting more than a couple of terminal sessions, then a high performance RAID array is absolutely essential.
Hard disks can only process one request at a time. The Windows operating system places all hard disk requests in a queue so that the requests can be serviced in turn. According to Microsoft, having an average of three or more items in the disk queue indicates a performance problem. Although Microsoft doesn’t exactly spell it out, you could infer that having one or two items in the disk queue at any given time is normal. So if it’s normal for Windows to have a couple of items in the disk queue, what happens to the disk queue length when the server is running ten virtual Windows environments, plus its own operating system? If you’ve got a slow hard disk, you could end up with fifteen or twenty items in the disk queue.
In a terminal service environment, there is no way to prevent the disk queue from being slammed with requests. The only thing that you can do to keep the disk queue length short is to process requests as fast as they come in. The best way to do this is to equip the server with a high performance RAID array.
Network Bandwidth
Another important resource in a terminal service environment is network bandwidth. The good news is that the Windows Terminal Services are not as demanding of bandwidth as they used to be. Version 5 of the Remote Desktop Protocol (found in Windows XP and Windows Server 2003) does a great job of conserving bandwidth. The stated bandwidth usage for Windows XP machines connecting to a Windows Server 2003 Terminal Server is roughly about 30 Kbps.
This statistic is a little misleading for a couple of reasons though. First, you must remember that in a Terminal Service environment, resource usage is exponential. The more users you have, the more bandwidth you are going to need. Even though you might not need much bandwidth for one terminal service user, supporting 20 users is probably going to require quite a bit of bandwidth.
If each session is consuming 30 Kbps of bandwidth, then 20 sessions would theoretically only consume about 600 Kbps of bandwidth, well within the limits of even a 10 Mbps Ethernet connection. Keep in mind though that 30 Kbps is the amount of bandwidth that a session uses if the user isn’t really doing much with the session. The amount of bandwidth used by a session increases substantially when a user runs a high demand application or attempts to print from an application.
Being that the Terminal Services work by sending screen images to the clients, it’s easy to think of a high demands application as being something graphically or mathematically intensive, like AutoCAD. Indeed, AutoCAD is a high demand application that would likely drain the Terminal Services of resources. However, there are some other applications that you probably wouldn’t normally think of as being high demand that can place a tremendous load on the Terminal Services.
An example of such an application is PowerPoint. Slides that contain animation, music, or high numbers of colors can place a huge demand on the Terminal Services. Internet Explorer can also become a high demand application if users access Web sites that contain video, music, animation, or that flood the screen with pop-ups. Even an Excel spreadsheet can become a high demand application, both from a processing standpoint and a screen refresh standpoint, if the user runs a complex macro. Running complex macros in Excel often causes the cursor to rapidly jump all over the screen
The point is that although a 10 Mbps connection should theoretically be sufficient for a Terminal Service deployment, there are a lot of factors that can cause a session to require excessive bandwidth. My advice is to invest in Gigabit Ethernet. Yes, a gigabit connection might be overkill, but the point is that you will never have to worry about the terminal sessions having insufficient bandwidth. Besides, the prices have fallen drastically on gigabit hardware over the last year or so.
Conclusion
In this article, I have explained that modern thin client environments place tremendous demands on the server that is hosting the terminal sessions. I then went on to discuss the topic of choosing hardware that will function efficiently in a Windows Terminal Service environment.
