ECP Performance revealed and some thoughts on future Exchange management

I was both interested and impressed at Nuno Mota’s article describing how to enable a hidden performance section for the Exchange Management Console (ECP): impressed because the article is written well and interested because it reveals a detail about ECP that I had never heard of before. This either goes to prove that you really do learn something new every day or the worth of browsing through the many settings that exist in Exchange’s configuration files – in this case, %SystemDrive%Program FilesMicrosoftExchange ServerV14ClientAccessecpweb.config. [Update: Scott Schnoll of Microsoft correctly pointed out that you can enable the Performance Console for OWA too - and without having to amend a web config file]

Nuno discovered a setting called ShowPerformanceConsole that is set to “False” by default. Like all good sleuths, he wondered what would happen if the value was changed and duly set it to “True”. Lo and behold, a new “Performance Console” option appeared in the ECP menu that, in turn, reveals a very detailed set of data to help you understand what happens under ECP’s skin. For example, what cmdlets ECP instantiated to execute a command and how many resources are consumed.

Others have documented the setting before. For instance, the earliest mention that a web search throws up seems to be when Steve Goodman wrote about it as long ago as February 2010. All in all, it’s a fascinating discovery that had completely passed me by.

ECP is a pretty interesting piece of work that is becoming increasingly important in the world of Exchange. Without it, Office 365 administrators would find it pretty difficult to manage Exchange Online as otherwise they’d be forced to do everything through PowerShell. Not difficult, just harder to master and prone to error in the hands of the unwary. ECP also provides the method by which administrators who don’t have Exchange mailboxes get to manage Exchange, a feature added in Exchange 2010 SP1.

ECP’s user interface is built from “slabs”, each representing a unique piece of functionality that is revealed to users if they possess the necessary permissions (secured through RBAC) to allow the feature to be used. For example, administrators who are not members of the Discovery Management RBAC role group will never see the options to create and execute multi-mailbox discovery searches because ECP doesn’t display these user interface elements. It’s a nice way to build a customizable interface that melds itself to the needs of the user. Sometimes, as we discovered above, elements of the ECP user interface are revealed through configuration settings, but mostly it’s RBAC that’s in control.

Going forward, it’s pretty certain that the current implementation of ECP will be expanded and enhanced to support the many areas of functionality that it doesn’t already have. For example, you can’t manage a Database Availability Group (DAG) through ECP. I think what Microsoft has done in Exchange 2010 is to create a version of ECP that works well for some elements of on-premise deployments while also being suitable for Exchange Online. The bits that are not needed for Exchange Online simply didn’t make it into ECP in this release. After all, if you’re an Office 365 tenant, you could care less about DAGs because the nice people in the Microsoft cloud support team take care of DAGs for you.

Given Microsoft’s focus on management of many computers from a single console in Windows 8 Server, it’s not a big stretch to imagine a souped-up ECP fulfilling that role for a future version of Exchange. It will be interesting to see how ECP develops from this point!

Follow Tony’s ramblings via Twitter.