• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint Online
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Videos
    • Interview Videos
    • How To Guide Videos
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Exchange Server / Exchange 2013 Managed Availability vs Custom PowerShell Monitoring Scripts

Exchange 2013 Managed Availability vs Custom PowerShell Monitoring Scripts

January 5, 2014 by Paul Cunningham 4 Comments

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).

get-daghealth-output

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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
[PS] C:Scripts>Get-ServerHealth -Identity E15MB1 | where Name -like "Database*" | Select Name
 
Name
----
DatabaseAvailabilityMonitor
DatabasePercentRPCRequestsMonitor
DatabaseRPCLatencyWarningMonitor
DatabaseRPCLatencyErrorMonitor
DatabaseHealthStoreNotificationMonitor
DatabaseHealthLogGenerationRateMonitor
DatabaseHealthLogCopyQueueMonitor
DatabaseHealthLogReplayQueueMonitor
DatabaseHealthCircLoggingMonitor
DatabaseHealthDbCopySuspendedMonitor
DatabaseHealthDbCopyFailedAndSuspendedMonitor
DatabaseHealthStoreNotificationMonitor
DatabaseAvailabilityMonitor
DatabasePercentRPCRequestsMonitor
DatabaseRPCLatencyWarningMonitor
DatabaseRPCLatencyErrorMonitor
DatabaseHealthLogGenerationRateMonitor
DatabaseHealthLogCopyQueueMonitor
DatabaseHealthLogReplayQueueMonitor
DatabaseHealthCircLoggingMonitor
DatabaseHealthDbCopySuspendedMonitor
DatabaseHealthDbCopyFailedAndSuspendedMonitor
DatabaseSizeMonitor
DatabaseSizeMonitor
DatabaseRepeatedMountsMonitor
DatabaseRepeatedMountsMonitor
DatabaseSizeEscalationProcessingMonitor
DatabaseAvailabilityEscalationProcessingMonitor


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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
RunspaceId              : 75591758-b589-45c1-99a7-8326b5927a04
Server                  : E15MB1
CurrentHealthSetState   : NotApplicable
Name                    : StorageLogicalDriveSpaceMonitor
TargetResource          : E:
HealthSetName           : MailboxSpace
HealthGroupName         : ServerResources
AlertValue              : Degraded
FirstAlertObservedTime  : 7/11/2013 10:58:44 PM
Description             :
IsHaImpacting           : False
RecurranceInterval      : 0
DefinitionCreatedTime   : 7/11/2013 10:48:56 PM
HealthSetDescription    :
ServerComponentName     : None
LastTransitionTime      : 7/11/2013 10:58:44 PM
LastExecutionTime       : 7/11/2013 10:58:44 PM
LastExecutionResult     : Succeeded
ResultId                : 65379030
WorkItemId              : 714
IsStale                 : False
Error                   :
Exception               :
IsNotified              : False
LastFailedProbeId       : -2002822569
LastFailedProbeResultId : -1635197854
Identity                : MailboxSpaceStorageLogicalDriveSpaceMonitorE:
IsValid                 : True
ObjectState             : New


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.

ma-documentation

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.

Exchange Server Exchange 2013, Managed Availability, PowerShell

Comments

  1. Roman Bezroukov says

    May 16, 2018 at 8:03 pm

    The script Test-ExchangeServerHealth.ps1 works correctly on Exchange servers with IPv4 addresses or both IPv4/IPv6 because GetHostByName function returns only IPv4 addresses.
    I have IPv6-only Exchange 2013 servers (on Windows Server 2012 R2) in our environment, so I had to modify the script:
    replace
    $ip = @([System.Net.Dns]::GetHostByName($server).AddressList | Select-Object IPAddressToString -ExpandProperty IPAddressToString)
    with
    $ip = @((Resolve-DnsName -Name $server -Type AAAA).IPAddress)

    Reply
  2. Jamaican says

    February 9, 2015 at 7:59 pm

    It would be great to have a script that will highlight healthreport for managed availability

    Reply
  3. Mohammed Abdul Muqtadir says

    October 18, 2014 at 11:41 pm

    Hi Paul,

    Get-Healthreport failing on exchange 2013 management shell. I am using SCOM 2012 SP1.
    Could you suggest the reason ?

    Regards,
    Abdul

    Reply
    • Paul Cunningham says

      October 19, 2014 at 12:01 am

      It will fail if the health manager service isn’t running. Other than that you’ll need to provide a lot more detail about your problem.

      Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • Changes in Microsoft 365 Apps Channels and Why You Should Care
  • A New Tool to Manage Exchange-related Attributes Without Exchange Server
  • Microsoft Launches Group Ownership Governance Policy
  • Making the Case for Identity Governance in Azure Active Directory
  • Prepare an Office 365 migration plan assessment using PowerShell

Copyright © 2022 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland