I recently worked on a new book, the Windows Server 2008 Terminal Services Resource Kit from Microsoft Press with my co-author Kristin Griffin. We developed some Windows PowerShell scripts for the book that allow you to create features that don't currently exist in Terminal Services but would be useful to have. In this column, I'll show you how we created one of these scripts and what we had to do to get to the performance data that this tool requires.There are a few steps involved in creating your own tools for performance data:
- Identify the question you want to answer.
- Find the counters that can help you answer that question.
- Write the script to help you collect those counters and store the results for analysis.
This article will help you with the third item. You'll still need to review the Performance Monitor tool in the Windows Reliability and Performance Monitor to help you find the right objects and counters.
Finding performance counters
In this example, we will set the script to get the MemoryCommitted Bytes from terminal server HELEN. The System.Diagnostics namespace provides classes that allow you to interact with system processes, event logs and -- most important for this column -- performance counters.
First, list the available performance counter categories and format them so they're easy to read.
Once you know the name of the category, create a new object and assign it to a variable. Place the category name in the parentheses as we do here with the category "memory":
Assign a performance counter object to a variable and look at its counters. Use the NextValue property instead of the RawValue property, as the latter is not yet processed and will sometimes return values that you can't read.
Next, get the instance names available for the specified category. There may or may not be any instances depending on the counter you have chosen and what you're doing on that server. For example, a terminal server with no active connections will naturally have no instances of active connections.
If the counter has instances, then add the instance name (in quotations) between the parentheses of the following the command. This will yield the counters for that instance. If there are no instances, then run the command with no instance entered, like so :
Find the counter name in the listed results. Now you have all of the pieces necessary to populate the following script to make it collect performance data for a named server.
This script will save the contents of this counter to the file whose names is stored as $LogFile.
What's the logon rate?
With Windows Terminal Services, the most common questions usually involve how many people a given server can support and when it's time to add more hardware capacity to the server farm. Before adding capacity, you need to know how much stress the servers are under. One way to do this is to measure connections in two contexts: the rate of new connections added during logon times and the number of connections each terminal server sustains at a time when you'd expect people to already be logged on and working.
Both numbers are important for different reasons. You need to know the rate of logons to help determine one kind of server stress. Process creation is expensive in terms of resources, and the beginning of a session requires a lot of process creation. You need to know the number of concurrent sessions to help you see trends in server usage. Are more or fewer people using each terminal server, or is the rate of usage staying pretty steady?
Both questions -- the rate at which users are logging on in the morning and the number of people using the terminal servers -- can be answered using the script below, which creates a file with entries as shown in the example. This script reads the Active Sessions counter of the terminal server object at a given time and date and then writes that information to a comma-separated value (CSV) file that you can open in programs such as Microsoft Excel.
Every time you run the script, it appends a new line to the file in the location specified in the script. Opening the report in Microsoft Excel will show you data similar to the output here.
To get the information you want, you will need to run this script at least three times a day. Run it twice (or more often) during the time you would expect most users to log on, separated by a reasonable interval to help you see the rate of logons during that time.
Keep in mind that you may need to play with this interval to get the shape of the curve; the more often you run the script during this period, the more data points you'll get to draw the curve accurately.
Run the script an additional time during a period when you would expect most users to be logged on, such as mid-afternoon on a Tuesday. Obviously, you'll need to experiment with the timing according to the way your organization works, but the basic idea is simple: Identify a time when most people should be at work and do your best to determine the greatest number of concurrent connections you're likely to see.
I recommend creating two versions of the script: one to store logon rates and another to store concurrent connections when the server is working. This will make it easier for you to find the data you need.
Miss a column? Check out the Scripting School archive.
|ABOUT THE AUTHOR:|
A former Terminal Services MVP, Christa Anderson is a program manager on the Terminal Services team at Microsoft and author of the forthcoming Windows Terminal Services Resource Kit from Microsoft Press. She is an internationally known authority on scripting, the author of Windows Terminal Services, The Definitive Guide to MetaFrame XP, and co-author of the book Mastering Windows 2003 Server .
This was first published in January 2009