Exchange 2013 Performance Health Checker Script

Microsoft has just published the Exchange 2013 Performance Health Checker script, which checks various configuration items on Exchange 2013 servers to make sure they match the recommendations published in the “Exchange 2013 Sizing and Configuration Recommendations” guidance on TechNet. It also reports on OS, system and hardware information. It can be ran remotely, against a single server or a group of servers.

 

The script takes some of the most common configuration causes of Exchange 2013 performance cases that Microsoft has encountered in support and allows administrators to rule them out quickly without having to check each server or read through the entire TechNet guidance.

 

 

The current list of items the script reports on is:

• Operation System version
• Exchange Build
• Physical/Virtual Machine
• Server Manufacturer and Model (physical hardware only)
• VM host processor/memory configuration recommendations
• Exchange server roles
• Pagefile Size
• Power Settings
• .NET Framework version
• Network card name and speed
• Network card driver date and version (Windows 2012 and Windows 2012 R2 only)
• RSS enabled (Windows 2012 and Windows 2012 R2 only)
• Physical Memory amount
• Processor Model
• Number of processors, cores, and core speed
• Hyper-threading enabled/disabled
• Processor speed being throttled
• Current list of active/passive databases and mailboxes (optional)

 

Let us look at some examples. First, we run the script without any parameters, meaning it will check the local server. We could use the –Server parameter to run it against a remote server.

By including the –MailboxReport parameter, the script presents some statistics around mailboxes and databases:

Another useful parameter is –LoadBalancingReport which looks at all CAS servers to determine how user connections are being load balanced across these servers. We can use the -CasServerList to specify which CAS servers we want to check.

Every time the script runs, it outputs the results to a log file as mentioned at the end of every output. In the next screenshot we can see the report from the cmdlet above: