SolutionBase: Troubleshooting Terminal Services on Windows Server 2003

Terminal Services can add power and flexibility to providing applications to your users, but it can also create headaches. Here's what can go wrong and what to do about it.

Along with death and taxes, problems with new features such as Terminal Services are inevitable, even in the most well-planned environments. Here are some of the common problems that people face with Terminal Services implementations on Windows Server 2003.

Captain! I canna give you any more power!

Today's servers are pretty hefty and robust, and when combined with the improvements made in the Windows Server 2003 version of Terminal Services, they can handle a pretty good number of users. However, at some point, you might run into capacity issues with your implementation. Throwing as much RAM as possible at your terminal server is always a good idea, but there is a limit. Likewise, even a four-way Xeon box will eventually feel the pinch if you put too many users on it.


The server capacity problem is an easy one on the surface, but the answer depends on your circumstances. There are really three things you can do to try to address this issue.

First, the most obvious solution is to increase the capacity of the server, if possible. This is commonly known as the "throw more horsepower at it" solution. It may solve the problem, but it can be expensive and might not be necessary.

The second solution requires some analysis, but is a better longer term solution and will probably cost less in the long run. Basically, watch how your terminal server operates and make note of certain findings, such as the amount of RAM used by a user's applications. You may find that certain applications simply use too much RAM or too much horsepower to be served up using a terminal server. To see how much RAM a particular user is using for applications, open Start | Administrative Tools | Terminal Services Manager and select the connection you'd like to get information about. On the processes tab—see Figure A—you'll get a list of that connection's active processes. Make note of the process IDs (PIDs) for each process.

Figure A

Use the Processes tab to show what the user is doing.

Open Task Manager and check the box at the bottom of the Processes tab marked Show Processes From All Users. Find the PIDs from your list. You may need to add the PID column to the Task Manager view. You can do this by choosing View | Select Columns and adding the PID (Process ID) column. See Figure B for a sample, and notice that Paint Shop Pro is using five percent of the CPU and quite a lot of RAM.

Figure B

Paint Shop Pro is being run by two users and using five percent of the CPU.

(In the real world, programs such as Paint Shop Pro use a whole lot of CPU time and aren't usually suitable for Terminal Services. It was used here solely as an example and definitely is not recommended.)

How does investigating individual processes help? With some applications, you can disable certain CPU-intensive features, allowing them to act a little more friendly in a Terminal Services environment. For example, Microsoft Word has a background spell and grammar checker that consumes significant resources. Before deploying applications, or when you start to see terminal server performance degradation, audit your particularly heavy applications to see if you can make them a little easier on the power.

Finally, if you're truly maxed or don't have time to audit your applications, you can always add a different kind of horsepower in the form of additional servers. Consider moving a few of your power users to a separate box to ease up on the others.

Open, Sesame!

Do you have a user who can't log in to the terminal server? Windows might be so kind as to provide you with an error message along the lines of "The local policy of this system does not permit you to log on interactively." This is Microsoft's way of saying that you don't have permission to use the services. It basically boils down to an access problem.


These errors can be more difficult to troubleshoot. The most common problem is that the user isn't a member of the Remote Desktop Users group. However, beyond that, you may need to track down file system and/or registry keys to which an application needs access, and then either grant that access or find a way around it.

If, for some reason, you don't want to use the Remote Desktop Users group, you can also change the local computer policy or the group policy for the domain. To do this, open the Group Policy Object Editor (gpedit.msc). Alternatively, you can open Start | Administrative Tools | Local Security Policy. Browse to Local Computer Policy | Computer Configuration | Windows Settings | Security Settings | Local Policies | User Rights Assignment, and add the appropriate user or group to the Allow Log On Locally policy, as shown in Figure C.

Figure C

Change the local (or domain) security policy.

Some applications require fairly significant modification in order to work properly. Look in the C:\WINDOWS\Application Compatibility Scripts directory for installation, logon, and uninstall scripts for certain programs.

Another common problem lies in the failure to initialize an application before deploying it to your users. For some applications, you should start the program and answer any configuration questions it asks before ending the Add/Remove Programs installation shell. (See the article "Implementing Terminal Services in Windows Server 2003" for more information.)

Next, keep this in mind: Someone has probably already made it work. Look for those resources to see what they did. Sure, this is an easy answer, but guess what? It works! For example, some folks have taken significant time to compile a list of applications that work under Terminal Services and provide instructions on how to make them work. Microsoft also has a list of popular applications that are known to have problems under Terminal Services for Windows 2000. Take a look at Microsoft's list to see if your application appears, and follow the instructions to attempt to correct the situation.

Finally, bear in mind that Terminal Services can run in two security modes—relaxed and full. Full security is preferred, but not always possible. If you have an application that you need and it doesn't work under full security mode, try it under relaxed mode. Go to Start | Administrative Tools | Terminal Services Configuration. Select Server Settings and change Compatibility Mode to Relaxed. (Learning how to write scripts to solve some of these problems is probably a good idea.)

Mac and Linux

Here's a short one: You have users with Macs or Linux machines and want them to be able to use your new terminal server.


There are perfectly usable clients out there that let you make full use of Terminal Services on non-Microsoft platforms. For Linux, take a look at rdesktop, an open source client for NT/2000/2003-based terminal servers. Rdesktop requires no additional software to be installed on the terminal server.

For Mac OS X users, Microsoft provides a free Terminal Services client available for download from its Web site. This client requires Mac OS X 10.2.8 or better.

Using either of these clients, you can also connect to Windows XP-based machines that allow remote desktop connections. This could be a great option for a help desk that uses Macs but has to support PCs.

Can't find remote administration mode

If you're coming to Terminal Services in Windows Server 2003 right from a Windows 2000 installation, you might be trying to use it the way it was always used previously. Windows 2000 supported the installation of Terminal Services in remote administration mode, which provided you with a built-in method to remotely manage the server.


Microsoft has seriously revamped the multiuser capabilities of Windows in both XP and Server 2003. Both operating systems include the same functionality as Windows 2000 Terminal Services in remote administration mode without your having to install additional software components. To enable this feature, go to Start, right-click My Computer and select Properties, then select the Remote tab. Enable the Allow Users To Connect Remotely To Your Computer check box.

Speed problems

Besides hardware sizing issues, you might run into situations in which users complain about a connection to a terminal server being especially slow. This is particularly true for low-bandwidth connections. If you're sure that the hardware is not to blame, there are probably things you can do to help them out.


A prime culprit for this problem is the remote desktop background. Redrawing a background on the screen can require a tremendous amount of bandwidth. Disable the remote background, and performance will noticeably improve. Furthermore, for very slow connections, consider lowering the screen resolution so there is less to draw.

It's not all that bad

A Terminal Services server can be your friend most of the time, but definitely requires more care and feeding than a stand-alone file and print server or locally installed applications on a single PC. Fortunately, it can reduce administration, save staff time, and provide a more secure environment once you get past some of the problems that can pop up.