Managed Availability needs a human-friendly interface

I might sound like I am complaining, but I really do like the Managed Availability framework introduced in Exchange 2013. It's a fantastic step forward in terms of server automation as it provides Exchange with the ability to detect and fix problems without human intervention. But it is a black box and that's not good. Managed Availability needs a more human-friendly interface, something to expose all the goodness that it does. I hope that the Exchange product group sees the same logic.

As we look forward to the arrival of Exchange 2013 Service Pack 1 (SP1), it’s worth asking what additional feature you would like to see appear in the on-premises software. At least, I think it’s a question worth asking, so here goes.

As discussed earlier this month, I very much like the Managed Availability framework. It seems to make perfect sense to enable software with sufficient intelligence to understand when something is going wrong and, even better, to be able to take an appropriate action to restore a component to full working health. Managed Availability is a great step forward in system administration. It is also an excellent example of how investment in technology required to automate and support operations in the Office 365 “service” delivers benefit to on-premises customers.

So where’s the problem? Well, it has long been a personal bugbear of mine that the Exchange engineers often do an excellent job of building new functionality only to forget the finer points of system management. For instance, at a meeting in Whistler, BC in February 2004, I asked the product group why reporting of basic system data was never incorporated into Exchange. For example, why no facility to report database sizes, the mailboxes in a database, mailbox sizes, the message volume handled by a server over a period, and so on. I thought that these were basic statistics that any self-respecting server should be capable of generating and said so.

Alas, my appeal to include some reporting capability in Exchange fell on stony ground, even after Exchange 2007 made the huge step forward by incorporating PowerShell as the cornerstone of its administrative capability. Nothing has happened in this area since and we still have no nice, easy to use method to produce reports from an Exchange server. Mailbox and administrative audit data provides a modern example of the lack of finishing in terms of reporting – how anyone thought that it was a good idea to spit out XML without providing a facility to transform the information into a human-friendly format is quite beyond me.

And so we come to Managed Availability, undoubtly useful but the black box of Exchange 2013. The technology obviously works, even if it has had some glitches, but it is obfuscated behind a confusing and complex array of probes, monitors, and responders together with tons of data written into the crimson channels used by Exchange to capture important information in the system event log. Despite the best efforts of product group members like Abram Jackson to explain Managed Availability, I don't consider the Windows Event Viewer to be a sufficiently elegant and useful GUI to decipher the output of Managed Availability and, of course, despite what might be wished in parts of Redmond, WA, not everyone uses SCOM.

Health sets make the information a little easier to consume because they boil the situation down to show whether a component (or server) is healthy and if not, where problems lie. And the Exchange documentation team, including the redoubtable Scott Schnoll in a recent blog entry, has done their level best to explain how everything hangs together. The simple fact is that Managed Availability is complex; too complex for someone who can't dedicate a few hours to poke around its innards to figure out how things hang together.

My view is that Exchange needs to include some form of user interface to reduce complexity and make the mass of data generated by Managed Availability much easier for system administrators to review and understand. For example, if Managed Availability detects that a component like Autodiscover is not working properly, I’d expect that this fact should appear on a system dashboard within the Exchange Administration Center (EAC) and that the administrator should be able to drill down to understand why Managed Availability thinks a problem exists, review the underlying data, and then decide what action could be taken (let Exchange fix the problem automatically or take some other action). Links to appropriate TechNet articles (such as this one) might also be provided.

Even a quick glance into its crimson channels shows that Managed Availability is a verbose and persistent reporter of information gathered from across Exchange. That data is available through the Event Viewer, but the Event Viewer cannot be regarded as anything other than a basic interface to raw data. The cmdlets used by Managed Availability (both the basic ones provided by Windows and the Exchange-specific ones used by EMS) are powerful tools to analyze and report problem data but the syntax is often convoluted. Not everyone is as fluent in PowerShell as an Exchange developer.

You could, I suppose, rely on a reporting framework like SCOM to interpret and report on the data generated by Exchange, but that creates a dependency on yet another product, albeit one that is often used alongside Exchange. And there are other reporting frameworks used to manage Exchange so SCOM cannot be a requirement.

So my wish for 2014 is that the Exchange product group should add a new “slab” to EAC that displays a system health dashboard using the mass of data generated by Managed Availability that allows administrators to follow the health status of a selected component from high-level status (“Healthy”, “Degraded”, “Unhealthy”) down through the results reported by individual probes that support the current health status. I know that this is a feature that only applies to the on-premises community, but given that on-premises still represents the majority, don’t they get a vote from time to time?

Perhaps the much-hyped ability of the new servicing model can enable something to be done before Exchange 2013 SP2 comes around?

Follow Tony @12Knocksinna

Discuss this Blog Entry 1

on Mar 13, 2014

I realize I am a little late to this one, but this article is spot-on, Tony! I agree completely with all you're saying here. While I haven't had any hands-on experience with 2013 yet, I sat-in on Tim McMichael's session about Managed Availability at the Expert's Conference this past year which left me glassy-eyed. It just seems like a lot to take in, especially considering so many of us Exchange admins/engineers have relied on Perf Counters and Data Collectors for years and respond to issues accordingly. Given the automated nature of MA (especially the functionality to create a bug-check and bounce the server) is something that leaves me tepid about going to Exchange 2013 at this point.
Though I think if there were a more accessible way to see what MA is doing, I'd be less apprehensive (re: scared) to consider taking the plunge.

Either way, I won't even have the time to consider upgrading to 2013 this year, though I may be able to investigate and come up with a migration plan for 2015 towards the end of the year...provided Exchange 16 isn't announced at MEC. ;)

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×