EDIT 9/23/2009: We have updated the download link to the Exmon tool which now also works on Exchange 2007 as well as Exchange 2010.

I am pleased to announce that this month's Exchange Web release contains a tool that the Exchange performance, development, and operations teams at Microsoft have used for quite some time called Exchange User Monitor (Exmon) and can be downloaded here.  Exmon for the first time allows an Exchange administrator the ability to see in amazing detail the performance of an Exchange server.  Shown on a user by user basis, Exmon allows you to see how much CPU, latency, network traffic, and disk each user on an Exchange server consumes.  It can be run in almost realtime (minute by minute analysis) or over longer (multiple-hour) capture periods.  Exmon also 'bubbles' up data sent back to the Exchange server from Outlook 2003 and higher about the user's actual experience, showing the actual RPC (network+server) latency and even the name of the process talking to the Exchange server (so you can see ActiveSync usage and other 3rd party MAPI applications).  The data Exmon exposes is the 'raw' data that many of the Exchange Performance counters use in calculating the running averages.

Internally, this tool was used to help understand the performance of Outlook 2003 and other MAPI applications during the development of Exchange Server 2003.  We use it to understand the broad impact of performance across a server, but also to troubleshoot specific performance problems with individual users.  The impact to the server being 'traced' is minimal, allowing it to be run on very large servers.

I'd love for you to download the tool, give it a whirl, and tell us what you think.  We'd love to see what use you can come up with for this data, problems you're able to solve, and conclusions you're able to make.

On a personal note, I recommend looking at a number of traces to 'aquaint' yourself with what's normal.  Exmon data can be highly dynamic in range.  It's best to use longer traces rather than smaller ones, because MAPI traffic can be very bursty, unless you're trying to look at a very microscopic level.

- Chris Mitchell