Since we asked our end users to configured Activesync against a different URL, we set up a dedicated VIP on the load balancer, and isolated the bottom two CAS servers. Doing this was easy... we changed the public DNS entry to facilitate the isolation. (I wish MSFT Best Practices would encourage an isolated URL for Activesync deployments)

The high CPU in black is coming from ActiveSync.

The green spike is from RPC Client Access service.

I ran MSFT's DebugDiag on the servers and don't know if that is the right tool to use, or what to do with some of the more advanced results. Any tips are appreciated.

Journaling. Our archiving processes was using 8000 MAPI connections to a server, and caused high CPU

Outlook users on NAT. Many people using outlook anywhere were behind a NAT. Our load balancer load balanced them by IP rather than cookie (as 2010 sp1+ supports it)

Activesync Calendar issue. iPhones were hammering our server with calendar updates that were rejected due to an Apple programming bug. We stopped the ActiveSync app pool and updated autodiscover to point all Activesync users to a dedicated CAS Array

So in the end the solution was to create a dedicated CAS array for Jornaling, Activesync, and Outlook Anywhere traffic. We co-located Journaling + BES onto the same array. This was a poor mans QOS and fault isolation for each service.

The tool we used to identify the high CPU culprit was "Exmon", however just know that running Exmon will cause trace files to appear in \program files(x86)\Exmon. If these files aren't deleted they may fill the drive.