Whether you use Microsoft Windows 2000 Terminal Services purely as a network management tool or as a platform for hosting user terminal sessions, you need a method for managing it. Although other tools are available, the primary tool for managing Terminal Services is Terminal Services Manager. In this Daily Drill Down, I’ll introduce you to Terminal Services Manager and explain its various features. I’ll also share some techniques and tricks you can use when troubleshooting problems with Terminal Services.
Terminal Services Manager
Terminal Services Manager is a comprehensive tool for managing Windows 2000 Terminal Services. This tool is capable of controlling virtually all aspects of Terminal Services. Furthermore, the utility uses a single console to manage every terminal server in your entire organization.
Terminal Services Manager is automatically installed onto any server that you install Terminal Services onto. You can access Terminal Services Manager by selecting Programs | Administrative Tools | Terminal Services Manager from the Start menu. When Terminal Services Manager loads, you’ll see a screen similar to the one shown in Figure A.
| Figure A |
 |
| Terminal Services Manager gives you a unified view of all terminal servers across all domains. |
In Figure A, notice that Terminal Services Manager has automatically detected all three of my network’s domains (NET, Production, and Test). Beneath each domain is a listing of each server within that domain that’s configured to use Terminal Services. This unified server view makes it easy to browse the connections hosted by multiple servers in multiple domains with only a few mouse clicks.
Normally, the server detection process is completely automatic. However, if your Terminal Services Manager session doesn’t display what you expected, you can use the Find Servers In All Domains and the Connect To All Servers commands on the File menu to reinitiate the discovery process.
Working with individual terminal servers
In Figure A, I’ve selected a server named Bart. In the pane to the right, you can see all of the terminal sessions presently connected to that server. If you look in the Session column, you can see what type of session each connection is. A normal terminal session is indicated by RDP-TCP followed by a number. This number is the session number. For example, a connection represented by RDP-TCP#1 would indicate the first remote connection to the terminal server.
In the figure, there’s also a session that says Console rather than listing an RDP-TCP code. A Console session merely indicates that someone is using Terminal Services Manager to interact with that server. You’ll always see at least one console session because the console session is initiated automatically when you open Terminal Services Manager.
You may be wondering why Microsoft even bothered to list the console session. The reason is that if more than one Administrator is using Terminal Services Manager to control a server, you’ll be able to see that someone else is already working on the server. Likewise, you’ll also see multiple console sessions listed if you open multiple instances of Terminal Services Manager.
There are a couple of reasons why it’s important to know what other administrators are connected to Terminal Services. First, if an administrator is connected to a server through Terminal Services, they are likely performing some type of maintenance on that server. You don’t want to do maintenance on a server at the same time as someone else, especially if you don’t know what the other person is doing.
The other reason that it’s important to know about other connected sessions is that terminal service connections can have a huge impact on server performance. The more sessions that are connected to a server, the slower the server will run. This includes console sessions. Therefore, you’ll want to pay close attention to who else is already connected so that you don’t disrupt everyone’s productivity.
Types of sessions
Beneath the server listing in the column on the left, there are several objects. These vary with your individual sessions. In Figure A, they include the RDP-TCP Listener, the Console (Administrator), and the RDP-TCP#1 (Administrator) objects. RDP Listener represents the RDP-TCP protocol, which is used to establish terminal sessions. Even though this particular listing only represents a protocol, it does have a useful purpose. If a particular server isn’t responding to terminal requests and you don’t want to reboot it, you can reset the protocol by right-clicking RDP-TCP Listener and selecting the Reset command from the resulting shortcut menu. Keep in mind that this will also disconnect anyone who happens to be connected.
The Console (Administrator) object represents a connection to the server through Terminal Services Manager. The word Administrator in parentheses indicates who is making the connection. Likewise, RDP-TCP#1 (Administrator) indicates that the Administrator has also made a normal terminal server connection from a terminal client and is using session ID number 1. You can click on any of the connections in the list to see more information about the connection.
Interacting with individual sessions
You can interact with any of the connected sessions you see simply by right-clicking them. You’ll call up a shortcut menu containing several options that allow you to do things like disconnect users, send a message to them, or even remotely control their sessions. The shortcut menu even allows you to reset a session, check its status, or log someone off.
But you don’t have to right-click an individual session and use the shortcut to interact with sessions. Figure A shows a set of buttons just below the main console menu. Although these buttons are grayed out in the figure, the buttons become active when a session is highlighted. You can use the buttons to disconnect, remotely control, or log off a session.
Although the shortcut menu gives you quick access to several basic functions, the options it presents are by no means the extent of your options for interacting with the users. When you click on a connection or on a session within the pane on the left, the pane on the right displays two tabs, Processes and Information.
The Processes tab
The default tab is the Processes tab. It displays the connection ID, process ID, and process name for every process that the remote user is presently running through the session. This is handy information to have. Remember that all of the processes you see are actually being run by your terminal server rather than by the workstation.
Furthermore, the processes you see on this tab are in addition to the standard processes that the server must run just to be able to function. By looking at the process list, you can see what the session is presently being used for. You can also get a feel for the impact that the session might be having on available server resources.
The Information tab
The other tab available through the pane on the right is the Information tab. The Information tab displays a lot of other information, such as the client’s computer name, operating system, IP address, video resolution, color depth, encryption level, and license. You can see an example of the Information tab in Figure B.
| Figure B |
 |
| The Information tab provides useful information about the client computer. |
Information about the client computer and the processes it’s running is certainly useful, but you can get still more information. You might have noticed earlier in Figure A that I had an individual server selected, rather than one of the sessions beneath the server. You probably also noticed that, with a server selected in the pane to the left, a list of connections appears in the pane to the right.
What you may not have noticed, though, is that the pane to the right is divided into three tabs. In Figure A, the Users tab is selected, and the console displays a list of the users that are connected to Terminal Services. Notice that this list is slightly different from the session list found beneath the server in the pane on the left. The information found on the Users tab is arranged by user rather than by session. The Users tab provides you with a quick-and-easy method for telling exactly who is connected to the server.
The Sessions tab presents basically the same information as the Users tab, but the information is organized into sessions rather than users. This screen even shows sessions that wouldn’t appear on the Users tab because they aren’t related to users, such as the RDP-TCP Listener session.
The remaining tab is the Processes tab. The Processes tab contains a list of every process that the terminal server is running for each connected session. This tab displays the user name, session, connection ID, process ID, and process name. This is very similar to the process information available for individual users, except that it contains a comprehensive list of all of the processes that all connected users are running.
Keep in mind, though, that this list is only comprehensive for Terminal Services: It doesn’t display processes running outside of Terminal Services. For example, if the Alerter service is enabled on your terminal service, the process associated with the Alerter service wouldn’t appear on the list of processes because it isn’t a process being run by one of the Terminal Service clients. Likewise, processes associated with any applications running locally on the server won’t appear on the list.
Depending on your system’s configuration, there’s a chance that the process list may not even be as comprehensive as it could be. To find out if you’re really seeing all of the processes being run by your terminal service clients, select the View menu at the top of the console, and then look to see if there’s a check mark next to the Show System Processes menu option. You can toggle this option on and off by selecting the Show System Processes command from the View menu.
I personally like to see all of the system processes because I like to know exactly what’s running on my servers. Even so, there are times when you might be better off hiding the system processes. If you need to get a quick overview of what’s being run on your server, you can hide the system processes to see only the processes associated with your applications and not those associated with the operating system. For example, the processes for Microsoft Word and Excel would be visible, while things like SRSS.EXE and WINLOGIN.EXE would be hidden.
When things go wrong
As you’ve seen so far, Terminal Services Manager is powerful and easy to use. Even so, there are times when things can go wrong. For example, you might not be able to access a particular domain or server. You might also not see sessions that you know are active. Fortunately, it’s usually easy to deal with such problems.
The first thing you need to know when troubleshooting is that the information you’re seeing isn’t displayed in real time. Depending on the way that Terminal Services Manager is set up, the information may be refreshed every few seconds, every few minutes, or not at all.
To find out just how current that information really is, select the Options command from the console’s Tools menu. When you do, you’ll see the Options dialog box. As you can see in Figure C, the Options dialog box contains a section that controls the process list and another that controls the status dialog boxes.
| Figure C |
 |
| The Options dialog box contains the settings that control the console’s refresh rate. |
By default, the process list is set to refresh every five seconds, and the status dialog boxes are set to refresh every second. However, because this dialog box has an option for changing the refresh to a manual process, another administrator might have tinkered around with the settings.
Another potential problem is the unavailability of a domain or server within a specific domain. Terminal Services Manager attempts to convey which domains and which servers are presently available by graying out those that are unavailable. However, just because a domain or a server is grayed out doesn’t mean you should assume that it’s really unavailable. It’s been my experience that if you click on a domain or on a server that’s grayed out, more times than not the object will change to the normal color and will be made available to you.
If this little trick doesn’t work, there are other things you can do to establish the desired connection. First, verify that the server you want to connect to is actually working. If that server is working, verify that the DNS Server for the domain is functional and that the other terminal servers within the domain are functional. It sounds strange to check servers that you’re not even using at the moment, but the trick really does work.
While writing this article, one of my domains became unavailable through Terminal Services Manager. I assumed that I had a true domain-level problem since I had four terminal servers within that domain and couldn’t access any of them. After doing some checking, though, I discovered that one of my servers had frozen. I rebooted the problem server and suddenly the entire domain became available to me, including the servers that were functional all along.
Of course, in a production environment, rebooting is usually a last resort. There are other things you can try to reestablish a connection before rebooting. Even after a reboot, you may still find yourself having to use some of these techniques.
First, close and then reopen Terminal Services Manager. Doing so will reinitiate the server discovery process. If you still aren’t able to communicate with a domain or with a server, select the domain in question and then select the Find Servers In All Domains command on the Actions menu. Hopefully, that will make the server visible.
Another thing you can try is to select the questionable domain and then choose the Connect To All Servers command from the Actions menu. One of these tricks usually gets the job done.
Now you know how it’s done!
Managing Terminal Services can be a tricky affair if you don’t know how the management tools work. There are several utilities that can give you information about Terminal Services sessions, but the most powerful is the Terminal Services Manager. Once you get the hang of running it, you can start deploying Terminal Services on your network.
