One of the great things about working with Exchange Server is the wealth of available support tools. For virtually every area of administration or management, you can find tools—some commercial, and some free; some from Microsoft, some from third party vendors—that make your life easier. In fact, there are so many tools that sometimes it's hard to keep up with them. I've been pretty much chained to the television during the Olympics, so I was slow to discover two tools that are worthy of special note, so this week I'm going to tell you about them. The first tool is the Performance Analysis of Logs (PAL) tool. It's a free tool available from Microsoft's CodePlex. The concept behind PAL is simple: It ingests Performance Monitor log files from a server running Exchange, Microsoft IIS, Microsoft BizTalk Server, or several other Microsoft applications, then provides charts, graphs, and alerts for the most significant application-related performance counters. PAL is driven by XML files that specify which counters are important for a particular application. The tool ships with an XML file for Exchange 2003 that's based on Microsoft's "Troubleshooting Microsoft Exchange Server Performance" white paper. The Exchange 2007 counter file is based on the list of counters in the Exchange documentation article "Monitoring Without System Center Operations Manager."
PAL is straightforward to use: You install it (and its prerequisites, which include Log Parser, the .NET Framework, and the Office 2003 web components), then run it and use its wizardlike interface to select the counter file you want to process and, if you're on Exchange 2007, the server role that generated it. Depending on the role you choose, you might need to answer questions about the selected server, such as the number of processors or the amount of RAM. After you've done so, PAL processes the logs and renders HTML reports that highlight the most notable performance data from the server. You can use PAL to get a quick overview of how an Exchange server is performing, then drill down to get more detail on specific counter sets that give information about a specific subsystem or component.
The second tool I wanted to mention isn't exactly a tool; it's a set of tools and associated processes for figuring out what's happening on an Exchange server given a set of transaction log files. Scott Oseychik of Microsoft put together a comprehensive set of instructions on how to analyze the contents of transaction logs on his blog entry, "'Rough and Tough' guide to identifying patterns in Transaction Logs."
Analyzing transaction logs might seem analogous to reading tea leaves or forecasting the future by examining chicken entrails. However, they're really not so mysterious; each log file contains a mix of data items readable only by Exchange and human-readable text strings. Oseychik's procedures explain how to search the log files for those readable strings and turn them into useful data by sorting, de-duplicating, and formatting the results. When you understand how to search the log files, you're well positioned to find out what's actually happening during periods of unexpected log growth.
A related note: Remember that even when nothing much seems to be happening on your server, you might still see several gigabytes of log files generated per hour. This isn't unusual, so don't be alarmed if you see constant cluster continuous replication (CCR) or standby continuous replication (SCR) traffic during ostensibly idle periods.
End of Article
Register
