Microsoft Exchange servers generate a high volume of log file information that is valuable for troubleshooting...
and performance analysis.
Many of the Exchange services and components write Exchange log files that coexist with Windows event logs, application and services logs -- or crimson channel logs -- Internet Information Services (IIS) logs and performance counters, adding detail to the overall production IT management puzzle. That is, if you can put the pieces together.
Message tracking log analysis
For all of the Exchange logs generated, the messaging platform provides very little in the way of built-in log analysis tools. The closest it comes is the Get-MessageTrackingLog cmdlet, which is intended more for specific troubleshooting scenarios, such as tracing the flow of an email message from sender to recipient, than general analysis of Exchange logs. An administrator can still get some useful trend information by applying general Windows PowerShell techniques to Get-MessageTrackingLog queries. For example, the query in listing 1 will return the top 25 senders of email on the server for the last day.
Listing 1. A mixture of PowerShell scripting and Get-MessageTrackingLog will help an administrator extrapolate trends from Exchange logs.
Windows and application event logs
Exchange writes event data to the standard Windows Application event log, and there's related information in the System and Security event logs. The Application event logging helps detect issues such as transport back pressure, database errors and Exchange service failures. The crimson channel, which is listed in Windows Server Event Viewer as Applications and Services Logs, records much more detailed information about Exchange high availability events, managed availability actions and other operational events.
Exchange Server event logs have a basic capability to search and to define actions to take in response to a particular event. An Exchange administrator must determine which events to monitor and what actions to trigger, then create a script or define an email alert that should be produced by that event.
For more detailed Exchange log analysis, such as observing trends of back pressure events, implement a monitoring tool, such as Microsoft System Center Operations Manager (SCOM) or a third-party option with intelligence built in for reading, analyzing and reporting Exchange Server application events.
Exchange has a dependency on Internet Information Services, and the IIS logs on the server capture useful data about client traffic on the server. IIS logs write to plain text files the administrator can analyze using PowerShell, third-party log monitoring tools or free tools such as Log Parser. There is no native analysis tool.
Microsoft provides Log Parser Studio, a free graphical front end to Log Parser that contains many preconfigured queries to offer insight into server activity. For example, Log Parser Studio reports on ActiveSync mobile device activity, which can reveal information about the devices that are generating the most server load, the devices that are throwing the most errors, or number of devices running a particular version of a mobile operating system.
The performance logs generated on an Exchange server are incredibly detailed, thanks to the extensive list of performance counters that Exchange Server installs on the system. There is so much information for performance monitoring purposes that it can be nearly impossible to analyze without a tool.
Microsoft engineers developed the open source Performance Analysis of Logs (PAL) Tool that can analyze performance log data against a supplied threshold file. The threshold file contains information about performance counter thresholds that are considered healthy vs. unhealthy. For example, in the case of Exchange 2013, available megabytes of memory should be more than 5%. Any less and the threshold is unhealthy.
PAL can be used to troubleshoot Exchange performance. The process involves exporting a performance monitor template, configuring performance monitoring to collect data from the server over a period of time, and then using PAL to analyze the .BLG file produced by that performance monitor.
Microsoft SCOM and third-party monitoring products can check performance data and proactively alert you to trends and threshold breaches.
Use your Exchange logs
Although Exchange Server logs provide detailed information on the server's health, performance and activity, the challenge lies in how to make use of all of the raw log data.
Manual analysis is usually reactive, performed in response to an issue that has already occurred. Long-term historical data is often unavailable, due to older logs being purged from the server, or simply due to a lack of time for the Exchange administrator to perform a deep historical analysis.
Manual Exchange log analysis is rarely efficient for detecting trends or to prevent future issues with log-based predictions. Free tools and techniques exist for each type Exchange Server log. Implement a monitoring application that will monitor multiple log sources in your environment, providing immediate reporting and alerting for trends and any issues that arise.
Exchange transaction logs gain new features
Exchange performance problems? Blame Outlook
Optimize Exchange storage usage