Writing Terminal Service Based Scripts (Part 2)

If you would like to read the other articles in this series please go to:

QUERY TERMSERVER

 The first command that I want to talk about is the QUERY TERMSERVER command. When you enter this command, Windows will generate a list of all of the terminal servers on your network, as shown in Figure A.


Figure A: The QUERY TERMSERVER command causes Windows to produce a list of all of the terminal servers on the network

If you operate a large, enterprise class network, the list of terminal servers can be rather long. This can cause problems if you are trying to create an automated script that generates a report, because the command is designed to pause and wait for user input after each screen of information.

If your goal is to create an automated script, then I would suggest following the QUERY TERMSERVER command with the /CONTINUE switch.  Doing so causes the command to display the list of terminal servers in a continuous stream, rather than stopping after each screen full.

Another problem with using this command on a large network is that an enterprise class network can consist of hundreds of domains, each containing multiple terminal servers. If you are trying to avoid information overload, then you can limit the output to reporting only the terminal servers within a specific domain. To do so, you would use the /DOMAIN switch, followed by the name of the domain for which you want to generate a report. For example, if you wanted to list all of the terminal servers in the Contoso domain, you would use the following command:

QUERY TERMSERVER /DOMAIN:Contoso

One last thing that you can do with this command is that you can use it to create a report that lists the MAC addresses associated with each terminal server. To do so, just enter the QUERY TERMSERVER command, followed by the /ADDRESS switch. You can see what the output looks like in Figure B.


Figure B: The QUERY TERMSERVER /ADDRESS command lists the MAC addresses that are associated with each terminal server

QUERY PROCESS

The next command that I want to talk about is the QUERY PROCESS command. As I’m sure you probably know, every application is made up of one or more processes. The QUERY PROCESS command allows you to see the processes that are currently being run on the terminal server.

As you can see in Figure C, when you enter the QUERY PROCESS command, Windows lists the user who is running the process, the terminal service session through which the process is being run, the session ID number, the process ID, and the name of the executable file that launched the process (referred to as the image).


Figure C: The QUERY PROCESS command lists detailed information about the processes that are being run on the server

The first thing that you need to know about this command is that it does not list every single process by default. If you look at the figure, you will notice that none of the processes that are being run locally on the server are listed. If you would like to see a full list of all of the processes that are being run on the server, simply enter the QUERY PROCESS command followed by an asterisks, as shown in Figure D.


Figure D: The QUERY PROCESS * command lists all of the processes that are running on the server

Although the basic report that the QUERY PROCESS command produces is nice, this command is also able to produce a filtered view of the information. Before I show you how it’s done, I have to tell you that the syntax information provided when you enter the QUERY PROCESS /? Command is a bit misleading. It took me a little while to figure out how to make the filtering feature work, but here’s how it’s done.

If you want to create a filtered view based on Process ID, Username, Session Name, or Program Name, then you must simply enter the QUERY PROCESS command, followed by the piece of information that you want to filter by. For example, suppose that you wanted to create a report that showed you only the information related to process number 3360. To do so, you wouldn’t have to enter any command line switches or anything. You would simply enter the QUERY PROCESS command, followed by the process ID, in this case 3360. The resulting report looks something like the one that’s shown in Figure E.


Figure E: The QUERY PROCESS command allows you to create reports based on specific information

The exact same technique applies if you want to perform a query based on the name of the user who is running the process, the session name, or the program name. For example, if I wanted to create a report of all of the processes that are currently being run by the Administrator, I would simply enter the following command:

QUERY PROCESS Administrator

As you can see in Figure F, Windows lists all of the processes that are being run by the administrator.


Figure F: The QUERY PROCESS Administrator command causes Windows to display all of the processes that are being run by the administrator

As you probably know, every terminal service session is assigned a session ID number. If you look at Figure D, you will notice that the QUERY PROCESS command displays the session ID. However, you can not filter the output by session ID just by appending the session ID number to the end of the QUERY PROCESS command.

The reason for this is that Windows has no way of differentiating between a session ID and a process ID. Therefore, if you append a number to the end of the QUERY PROCESS command, Windows will automatically assume that the number is a process ID.

This doesn’t mean that you can’t filter by session ID though. If you want to filter the output by session ID, you will have to use the /ID command line switch, followed by a colon, and the session ID number. For example, if you wanted to see all of the processes that were related to session ID number 1, you could do so by entering the following command:

QUERY PROCESS /ID:1

You can see what this command looks like in action in Figure G.


Figure G: The /ID switch can be used to filter the report based on session ID

That’s pretty much the limit of what the QUERY PROCESS command can do. While researching this article, I tried performing more complex queries that involved filtering on multiple pieces of information simultaneously, but doing so does not seem to be supported.

Conclusion

In this article, I discussed some more commands that can be used in a terminal service environment. In Part 3, I will continue the discussion by showing you some more commands that you can use. Later on in the series, I will eventually show you how to combine some of the various commands to create some useful automated scripts.

If you would like to read the other articles in this series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top