Exchange 2013 Managed Availability vs Custom PowerShell Monitoring Scripts

It’s always a nice moment when you get a mention in the Windows IT Pro column of the Godfather of Exchange MVPs, Tony Redmond.

In that article Tony is discussing the merits of the new health reporting PowerShell cmdlets in Exchange Server 2013 (Get-HealthReport and Get-ServerHealth).

The context…

When I (Tony) wrote about the influence that the Exchange 2013 Managed Availability framework exerts over Database Availability Groups, I received a note from a member of the Exchange product group to ask why I had recommended using a PowerShell script (Get-DAGHealth.ps1) rather than making any attempt to leverage the Get-HealthReport cmdlet (thoughtfully provided to measure and report on the good health of Exchange 2013 servers). Furthermore, why not use SCOM as Managed Availability and SCOM work well together in terms of providing administrators with a view onto what might be going wrong within a DAG.

Fair points, and Tony’s answers are worth reading as he also goes on to explore those new cmdlets a little further.

Here is a little more on the topic from my perspective.

Get-DAGHealth.ps1 is a PowerShell script I wrote to fill a need – monitoring Exchange 2010 DAGs that were doing “stuff” that administrators would like to know about such as content indexes failing, databases failing over, database copies failing and causing copy/replay queues to grow.

Naturally those administrators did not have monitoring tools (such as SCOM) that had built in Exchange 2010 intelligence, or had other monitoring tools that required custom scripting to be able to monitor applications like Exchange.

Being a firm believer that PowerShell exists to solve these problems for us I went ahead and wrote the script, just as I had written other “monitoring” scripts before it (such as Get-DailyBackupAlerts.ps1).

The other main motivation was to develop some good solid code to roll into Test-ExchangeServerHealth.ps1 (which I have since done, and frankly that script has improvements that have yet to be ported back to Get-DAGHealth.ps1).

The very first version of Test-ExchangeServerHealth.ps1 was born in the time of Exchange 2007 (and the first versions could even do some health checks for Exchange 2003). It was updated and re-written many times over the years, adding Exchange 2010 and then Exchange 2013 compatibility. Obviously it pre-dates Managed Availability by some time.

When Managed Availability hit the scene in Exchange 2013 I was immediately interested. A server health monitoring system baked into the product, built to solve the problems that occur at the scale of Office 365, and with new PowerShell cmdlets to play with is great if you ask me.

And Managed Availability also has responders built in to take corrective actions for various problem scenarios, something that I received many requests for in my PowerShell scripts but never felt comfortable implementing.

And with the quirks in a couple of the  Test-* cmdlets that shipped with Exchange 2013 it seems pretty clear to me that Managed Availability is the future and the old Test-* cmdlets will be deprecated.

I mean look at all the detail it provides for databases alone. Powerfull stuff.

But it is still early days. Managed Availability is a complex beast. I imagine it works great with SCOM and inside of Office 365. But for the average Exchange administrator who is looking for a health report my opinion at the moment is that MA gives us lots of data but not the type of report that can be quickly and easily read by administrators or managers of varying technical experience.

The Exchange product team has posted several blog posts to teach us more about Managed Availability, but there is still a lot of documentation to be completed.

So, while I’m personally very eager to learn more about Managed Availability, for the time being I still see the value in custom scripts such as Get-DAGHealth.ps1, and I’m always glad to see them recommended by people like Tony.

That said, we all need to move with the times. If Microsoft is investing their efforts in Managed Availability, and we can expect the Test-* cmdlets to become less relevant and useful over time, then Managed Availability is also where we need to focus as administrators.

So, in 2014 you can be sure that I will be consuming as much information about Managed Availability as I can, and will be eagerly attending all of the MA sessions at MEC (and hopefully talking more with the “member of the Exchange product group” that reached out to Tony).

Perhaps there will even be a new PowerShell script that leverages Managed Availability instead of the Test-* cmdlets. Time will tell.