Exchange 2013's browser-based management console drops EMS learning tools

As you might have realized from Exchange 2013 Preview, Exchange 2013 dispenses with the MMC-based administrative console that’s been part of the product since Exchange 2000. I don’t shed many tears about this development because Exchange 2010’s Management Console (EMC) had become slow and unwieldy. Some might even apply the “fat, dumb, and happy” label to EMC, but I wouldn’t go quite that far even though the console went through some choppy waters after Microsoft shipped IE9 and EMC didn’t function quite as well as expected.

The IE9 bug developed into a long-running fiasco that took Microsoft a surprising length of time to fix, but that’s not the reason why they decided to chop EMC from Exchange 2013. The more pressing requirement was to create a unified browser-based management platform that was common across on-premises and cloud deployments. The Exchange Control Panel (ECP) proved the essential concepts for both Exchange 2010 and Exchange Online but its functionality was limited. For example, you couldn’t even create a new mailbox with ECP. Server management was also a notable omission. This was understandable because customers don’t need to manage servers when they subscribe to Office 365 and Microsoft's immediate development  priority was to create a UI to manage Exchange Online.

Exchange 2013 includes a new browser-based management console called Exchange Administration Center (EAC). It’s a much-enhanced console that builds on the principles established by ECP such as RBAC-controlled UI display and support for multiple browsers. In fact, EAC is a pretty impressive replacement for both EMC and ECP.

But EAC falls down in one important way. It totally lacks any of the valuable learning tools for PowerShell that are in EMC. As you’ll recall, all of the Exchange management tools are built on top of a common business logic layer implemented through a large set of PowerShell cmdlets. The Exchange Management Shell (EMS) allows direct manipulation of the Exchange cmdlets but because the cmdlets set is so large and capable, it takes anyone some time and effort to become fluent so that Get-Mailbox, Get-MailboxDatabase, Set-DatabaseAvailabilityGroup and all of the other cmdlets become well-known and invaluable tools for a busy Exchange administrator.

EMC includes three tools that help administrators become acquainted with EMS cmdlets and syntax. The EMC wizards show the EMS code that they execute to perform a function such as creating a new distribution group; all of the commands executed by EMC can be captured in a log; and you can view the commands that EMC will execute to update objects when viewing their properties. Collectively these are fantastic ways to learn about EMS. In fact, you can cut and paste code from EMC into Notepad or another editor to create the basis of scripts that can be used to manage Exchange.

I understand that the Microsoft developers had tons of work to do to create EAC and ensure that it was functionality equivalent to the combination of EMC and ECP when Exchange 2013 shipped. At least, to make sure that all of the options available in EMC/ECP that still make sense in Exchange 2013 are available through EAC. It’s also fair to assume that some developers might believe that the PowerShell learning tools are in the “nice-to-have” category and, as such, it’s OK to put them off until a future service pack comes around. Even so, I think that Microsoft will disappoint both experienced and novice administrators when they discover that EAC offers zero insight into the code that it executes to do its work. It’s a sad omission.

On the other hand, Exchange 2013 does fix a bug that PowerShell scripters might have run into during the transition from local PowerShell (as used in Exchange 2007) to remote PowerShell (as used in Exchange 2010 and 2013). Scripts that worked in Exchange 2007 sometimes didn’t work with Exchange 2010 because of a difference in pipeline processing. Workarounds existed, but the bug frustrated administrators when carefully crafted code didn’t work as expected.

For example, the following code* doesn’t work in Exchange 2010:

Get-Content Users.txt | Get-Mailbox |% {$_.EmailAddresses.add("smtp:$($_.SamAccountname)@contoso.com"); Set-Mailbox -Identity:$_.Identity -EmailAddresses:$_.EmailAddresses}

This is a rather nice example of the power (no pun intended) of a single (complex) line of code that reads a list of user names from a text file, fetches the current set of proxy email addresses, and adds a new “contoso.com” SMTP email address to each mailbox.

In any case, because of improvements made to the way that EMS processes pipelines containing multiple Exchange cmdlets, the code works just fine in Exchange 2013. Despite the gloom of losing a valuable insight into EMS through the management console, Exchange 2013 gives something back in another area. Things aren’t quite so bad after all.

Follow Tony @12Knocksinna

*Tom Maddock wrote the original one-liner