Writing Terminal Service Based Scripts (Part 6)

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

So far in this article series, I have shown you a lot of different commands that you can use for building terminal server based scripts. I had originally intended for this article to be a crash course in the basic syntax used in the scripts that we are going to be building. When I stopped and thought about it though, I began to realize that there was simply no way to fit everything that I wanted to talk about into an article.  Since I know a lot of you are probably anxious to start building scripts, I decided to simply go ahead and start showing you some scripts, and just teach you the syntax as we go.

As you look back on the previous articles in this series, one of the things that you will probably notice is that a lot of the commands that I talked about are geared toward creating various types of reports.  That being the case, I want to start out by showing you how to create a simple report.  We will gradually build on this technique over the next few articles.  Later in the series, I’m going to show you how to create some other scripts that have nothing to do with reporting, using the commands that you’ve already learned.

The first thing that you need to know about creating a script that generates a report is how to save the report.  For example, in one of the earlier articles I showed you how to use the Query User command.  As you may recall, entering this command into a Command Prompt window causes Windows to display information about the users who are currently connected to your server.  Although this is a nice command, its capabilities are very limited when it is used by itself.  After all, all it does is displays the users who are currently logged in.  Let’s pretend though that for some reason you needed to be able to save this information so that you could look at it again later without running another query.  The easiest way of accomplishing this would be to redirect the output to a log file.

The Windows operating system uses the greater than sign (>) as a way of indicating that a command’s output should be redirected.  Therefore, if you wanted to create a log file containing the results of the user query, you would enter the Query User command, the greater than sign, and then the path and filename of the log file that you want to create.  For example, if you wanted to create a log named SAMPLE.LOG, you could enter the following command:

QUERY USER > SAMPLE.LOG

In this example, the log file is written to the current directory, whatever that may be.  The log file itself isn’t anything fancy.  It is really nothing more than a text file.  Incidentally, the usual tool for opening a text file in Windows is Notepad.  However, you can use that Type command to view the contents of a text file from the command line.  For example, if you wanted to view the log file that we just created, you would enter the following command:

TYPE SAMPLE.LOG

You can see an example of this command shown in Figure A.


Figure A: The Type command allows you to view the contents of a text file

Occasionally you may run into a situation in which a text file is so long that it can’t be displayed without scrolling off of the screen.  When this happens, you can append the pipe symbol (|) and the word More to the end of the Type command.  This will cause Windows to pause after each screen full of information, and wait for a key press before displaying more text.  For example, if the log file that we had created were too long to fit on the screen, then we would modify the Type command to look like this:

TYPE SAMPLE.LOG | MORE

In the real world, you would probably never have a reason to create a log file containing solely the results of the Query User command.  The reason I use this particular command is just to keep things simple for now.  Hopefully though, you can see the value of being able to create a text file containing the report results.

Although the technique that I have shown you works well, there are a couple of minor problems with it.  First, you have to remember that our goal is to build a script.  Scripts tend to be run more than once.  Anytime that you redirect a command’s output to a file, Windows does a check to see if the file exists.  If the specified file does not exist, then Windows will create it for you.  If the file already exists though, then the redirected output is appended to the end of the file.  In a way this is good, but in a way it is bad.

The way that output is appended to the file if the file already exists is good because it allows you to create more comprehensive reports. Appending redirection output to an existing file allows a script to build a report in stages, rather than the output having to be separated into separate files. For example, suppose that you were to create a script containing the following commands:

Query User > sample.log
Query Process > sample.log
Query Session > sample.log

Once again, a script like this probably wouldn’t be particularly useful, but the point is that once the script was complete, the resulting log file would contain the output from each of the commands that had been run.

The way that Windows appends information to existing text files can sometimes be a bad thing though. Suppose for example that you wanted to create a script that would automatically run at a specific time each day. In a situation like that, you probably wouldn’t want the output appended to the end of the existing log file each day. Deleting the existing log file before running the script usually isn’t a good option either.

In situations like this, you are going to need to design your script so that the filename changes each time that the script is run. Ideally, the new file name should reflect the date or time when the script was run so that it will be easy to figure out when each log file was created.  Believe it or not, this is easier to do than you might think. Suppose that you wanted to output the results of the Query User command to a filename that was date specific. The commands for doing so are:

for /F “tokens=2,3,4 delims=/ ” %%i in (‘date /t’) do set datefile=%%i%%j%%k.log
Query User > %datefile%

I know that right now the command above probably looks like gibberish. I will show you what this command is actually doing in the next article in the series.

Conclusion

In this article, I have begun showing you how to create reports in a script. In the next article in the series, I will continue the discussion by building on the concepts that I have discussed in this article.

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