Historically, gathering performance data when troubleshooting Microsoft Exchange Server wasn't much fun. You had to figure out what performance counters you wanted to use, then set up Performance Monitor to gather data for several days before you could do any troubleshooting. Thanks to a new diagnostic feature in Exchange Server 2013, that's no longer the case. The Exchange Diagnostic Service is always gathering and storing performance data about the Exchange 2013 server so that you can troubleshoot problems as soon as they're discovered. After I explain how to configure the Exchange Diagnostic Service, I'll show you how to easily access the stored data when you're troubleshooting.
Configuring Exchange Diagnostic Service
With a default installation of Exchange 2013 cumulative update 6 (CU6), the Exchange Diagnostic Service constantly records information from about 3,000 performance counters, storing that information in log files for seven days. By default, the daily performance log generated by the Exchange Diagnostic Service takes up 5GB of space on the drive where you install Exchange. Not so long ago, giving away 5GB of drive space for files that might never be used would be reason for administrators to get up in arms. However, as Tony Redmond notes in his blog post "Exchange 2013 diagnostic and performance log files," disks are so large these days that this typically isn't of concern. In addition, if you deploy your Exchange servers as recommended in the Exchange Team Blog post "The Preferred Architecture," your C drive is likely going to have terabytes of unused space.
Whether or not space is an issue, you can control how much data is stored in the daily performance logs by editing the Microsoft.Exchange.Diagnostics.Service.exe.config file. If you installed Exchange in the default location, this file is located at C:\Program Files\Microsoft\Exchange Server\V15\Bin. In the
Notice the MaxSize and MaxAge parameters. Exchange will delete data as soon as it reaches the first of those two values. So, for example, if you set MaxSize to 1GB but leave the MaxAge at seven days, you'll end up retaining only one or two days of performance data because the size limit will have been reached.
I recommend increasing the MaxSize and MaxAge values as high as you can if you have the space. If your Exchange 2013 server has a 4TB drive, why not keep 30GB of daily performance data for 30 days? You'll thank me later when you need to troubleshoot a performance problem that doesn't occur on a regular basis.
Note that the Microsoft.Exchange.Diagnostics.Service.exe.config file will likely be overwritten by future cumulative updates. So, if you change the MaxSize and MaxAge values, be prepared to change the values again after installing the next cumulative update.
Retrieving the Performance Data
Now that you know how to control the amount of drive space taken up by the daily performance logs, let's look at how you can easily retrieve the data in those logs. If you open one of the generated .blg files in Performance Monitor, you'll find it looks something like that in Figure 1.
As you can see, it's a jumbled mess. Fortunately, there are some helpful Windows PowerShell cmdlets that let you select a single performance counter and put that counter's data in a separate .blg file. With the Get-Counter, Import-Counter, and Export-Counter cmdlets, you can turn this jumbled mess into information you can use for troubleshooting problems.
First, run the following command to get summary information about the daily performance logs:
Import-Counter ` -Path $env:exchangeinstallpath\Logging\Diagnostics\DailyPerformanceLogs\*.blg ` –Summary
The information returned will look similar to that in Figure 2. As you can see, this server has two days of data in the daily performance logs.
To retrieve the data from a single counter and put it into a separate .blg file, you can use the following PowerShell command, which uses both the Import-Counter and Export-Counter cmdlets:
$Data = Import-Counter ` -Path $env:exchangeinstallpath\Logging\Diagnostics\DailyPerformanceLogs\*.blg ` -Counter \\EX01\MSExchange ADAccess Domain Controllers(*)\LDAP Read Time ` $Data | Export-Counter -Path \\EX01\C$\temp\WorkingSet.blg
Before you run this command, though, you need to replace \\EX01\MSExchange ADAccess Domain Controllers(*)\LDAP Read Time with the name of the desired performance counter and its path. You must use the following format to provide this information:
\\ComputerName\CounterSet(Instance)\CounterName
The ComputerName value is required, even if the counter is on the local computer. You can find the names and paths of the counters available on a server in Performance Monitor.
After you run the command, you'll have a single workingset.blg file that contains all the data from all daily performance logs for the performance counter you chose.
To take this process one step further, I wrote a script named Get-EDSData.ps1. It gathers performance data from the counters you specify and tells you how many times your counters went over the threshold you set. You can download this script from the TechNet script gallery.
Before you use Get-EDSData.ps1, you need to create a .csv input file that specifies the counters you want to see and the threshold you want to set for those counters. Figure 3 shows a sample input file, but you can specify any counters that are recorded in the daily performance logs and you can set any thresholds you like.
After you created the input file, simply run the Get-EDSData.ps1 script on the Exchange server you want to test, with a command like this:
.\Get-EDSData.ps1 -File .\test.csv
The script will pull the data for each performance counter you listed and test the data against the threshold you set. This information is written to the results.txt file. As Figure 3 shows, it tells you how many times your counters went over the threshold.
The script will also output a .blg file for each counter, which you can open with Performance Monitor.
Troubleshoot Now Instead of Later
With Managed Availability Diagnostic, the performance data you need for troubleshooting Exchange 2013 servers is already at hand. Using Get-EDSData.ps1 makes retrieving and analyzing that data much easier.
