Exchange 2013 EAC showing some frayed edges

Last July I wrote about the Exchange Administration Center (EAC) and how it was being introduced in Exchange 2013 to replace the creaking and slow Exchange Management Console (EMC) as featured in Exchange 2010 and Exchange 2007. Now that we’ve had some time to assess the finished object, as shipped in the RTM version of Exchange 2013, some remarks on how EAC turned out seem appropriate.

To begin, some positive points. First, I very much appreciate the general speed of EAC when compared to EMC. Things just seem to happen more snappily.

Second, it’s great to have a console that runs on so many browsers. I move between Chrome and IE and EAC appears to run smoothly on both. I have no doubt that it also works well on Safari and Firefox. Of course, we’re not just discussing PCs or workstations any more either – EAC opens up the ability to run on Windows RT Surface, iPads, and other devices, which is also a very good thing.

Third, the introduction of EAC has made administration much simpler all round in Exchange 2013. It’s now a matter of EAC or EMS when you want to work with server objects or maybe OWA options (really some EAC code reused) when users want to change mailbox options. The sometimes confusing set of EMC and the Exchange Control Panel (ECP) with some administration features being implemented in EMC and not in ECP and vice versa is no longer present. In addition, user options are much better integrated into OWA than is the case with Exchange 2010.

But inevitably as with all new software, some problems also exist. I’ve already publicly noted my concern that EAC has dropped the three PowerShell learning tools that are so useful to anyone who wants to understand the cmdlets and syntax of EMS, and that I didn’t like the fact that context-sensitive menus are no more in EAC but do exist in OWA. Aside from those issues, here’s my current hate list for EAC:

No preview capability is provided for dynamic distribution groups. On the surface, you might say “so what”, but this is a useful feature that’s in Exchange 2007 and Exchange 2010 that allows you to determine whether the query you base a group upon will actually end up addressing anyone when someone uses the group to send mail. And what’s worse is that a preview feature that looks very much like the one you’d use for dynamic distribution groups is available for email address policies. If Microsoft can create and implement a preview function for email address policies, wouldn’t a little cut and paste magic work for dynamic groups? After all, both email address policies and dynamic distribution groups used OPATH queries to determine the set of objects that they operate against.

A preview option like this would be really nice for dynamic distribution groups

The engineer who determined how group membership is shown is clearly under the impression that either groups are very small or administrators enjoy frantic scrolling through large data sets. There’s no way to resize the list control either so this qualifies in the category of brain-dead and dumb. Generally speaking, I dislike the way that space is used (or rather, abused) in Microsoft’s new graphic design guidelines, but who am I to comment?

Four items in a list of distribution group members? Simply not enough!

If you assign Full Access control over a user’s mailbox, you’ll see that EAC prepopulates Exchange Trusted Subsystem and Exchange Servers in the set of objects that have full access. Unsurprisingly, this is because these groups enjoy full access to every mailbox, which they use to manipulate mailboxes as required by Exchange. The problem is that you’re allowed to mess with these entries and remove either or both from the list. Now, if you mess with Exchange permissions, my experience is that bad things happen.  I’ve removed both groups just to see what happens and nothing dramatic has occurred so far, but I have a nagging suspicion that something will soon – and if it doesn’t, then why are these highly privileged groups shown in the list?

Exchange Trusted Subsystem and Exchange Servers need to access mailboxes, but does EAC need to show them?

It’s true that EMC shows you the same information (EMC actually also shows you NT Authority\SELF too), but I complained about the problem for Exchange 2010 and I have complained about it for Exchange 2013 too (see the the formal bug report on Microsoft Connect).

Change often brings both good and bad with the ratio between the two dependent on the views and experience of the observer. Some people will absolutely love EAC and some will hate the new console. Others will be like me and grumble about the bits that are considered broken or problematic while accepting that Microsoft has cast the dice and won’t bring back EMC (thankfully). All we can do is note the problems and file bug reports to make Microsoft aware that more work is needed to make EAC the finished version. Make sure that you bug anything that you find that you think Microsoft should fix in an update for Exchange 2013. If you don’t, then you cannot complain if EAC remains in the same state for the next few years.

Follow Tony @12Knocksinna