Monitoring Exchange 2013 with SCOM 2012 (Part 3)

If you would like to read the other parts in this article series please go to:

Additional Configuration to the Management Pack

Like previously said, one of the main characteristics of this MP is its simplicity. I don’t know (and I don’t risk a prediction) if Microsoft will introduce some complexity to future versions, but for now, there’s not much to configure with this management pack. Even if you have a complex and large Exchange organization, you should be fine just importing this MP into your existing environment.

There are no special components to install on Management Servers (correlation service is gone), you do not need to worry about the impact to the Management Group in terms of database size, instance space, Management Server workload etc., as the management pack was designed to scale.

However, if you should require some adjustments to the Management Pack, like fine tuning some of the monitor or probes, or disabling some unnecessary alerts, that is still possible. Let’s look how it can be done in the next chapters.

Operations Manager Overrides

Exchange Server 2013 management pack is designed to be simple to deploy and use. However, if you see alerts that are not valuable to you, you can configure overrides to turn these specific alerts off. Use these overrides only if you are experiencing specific problems.

If you want to disable some alerts, you can just create an override in Operations Manager as usual. For example, in my environment I was getting an alert regarding the available disk space on my Exchange Servers. The threshold for available disk space is 100GB, which I don’t have. I can modify the threshold in Managed availability (we’ll see how on the next chapter), or I can just disable this alert with a SCOM override.

To disable this alert in the SCOM console:

  1. Right click on the alert, and then select Overrides > Disable the Monitor > For the object: E2K13-MBX2 – MailboxSpace (Figure 1).

Figure 1: Disable Monitor with Override

  1. In the Override Properties window, clear the checkbox for the Parameter Name Enabled (Figure 2).

Figure 2: Override Properties

  1. Select a destination management pack to store the override, and click OK.

If you want to change a threshold for some monitor, this is done in the Exchange Managed Availability engine via PowerShell cmdlets. This does not involve Operations Manager at all and we’ll see how to do it in the next chapter.

Managed Availability Overrides

As we saw previously, Managed Availability performs a variety of health assessments within each server. When issues are detected, multi-step corrective actions are taken to bring the server back into a functioning state. In the event that the server is not returned to a healthy state, Managed Availability can alert operators that attention is needed.

With any environment, defaults may not always be the optimum condition, or conditions may exist that require an emergency action. Managed Availability includes the ability to enable overrides for the entire environment or on an individual server. Each override can be set for a specified duration or to apply to a specific version of the server. The *-ServerMonitoringOverride and *-GlobalMonitoringOverride cmdlets enable administrators to set, remove, or view overrides.

Managed Availability components (probes, monitors and responders) can be customized by creating an override.

There are two types of override: local override and global override. As their names imply, a local override is available only on the server where it is created, and a global override is used to deploy an override across multiple servers.

Either of the above mentioned overrides can be created for a specific duration or for a specific version of Exchange servers. The override created with Duration parameter will be effective only for the period mentioned. Maximum duration that can be specified is 60 days. For example, an override created with Duration 45.00:00:00 will be effective for 45 days since the time of creation.

The Version specific override will be effective as long as the Exchange server version matches the value specified. For example, an override created for Exchange 2013 CU1, with version “15.0.620.29” will be effective until the Exchange server version changes. The override will be ineffective if the Exchange server is upgraded to different version of Cumulative Update or Service Pack.

Hence, if you need an override in effect for longer a period, create the override using ApplyVersion parameter.

Managed Availability Local Overrides

In this example we are going to create a local override for the StorageLogicalDriveSpaceMonitor monitor, since we are getting an unhealthy condition returned by the MailboxSpace health set (Figure 3). By default this monitor has a threshold of 100GB of free disk space, we want to modify it to 50GB.

Figure 3: Event 4, ManagedAvailability

In part 1 of this series of articles we already saw how to generate health reports using the PowerShell cmdlets Get-HealthReport and Get-ServerHealth. To narrow a little bit the results, let’s try something different:

Get-HealthReport -Identity E2K13-MBX1 | where { $_.alertvalue -eq “Unhealthy” }

This produces the output similar to the following:

Figure 4: Get-HealthReport

First we need to get the list of monitors associated with this healthset that are responsible for reporting the available storage space. We can determine the collection of monitors (and associated probes and responders) in a given health set by using the Get-MonitoringItemIdentity cmdlet.

Get-MonitoringItemIdentity -Identity MailboxSpace -Server E2K13-MBX1 | ft name,itemtype –AutoSize

Figure 5: Get-MonitoringItemIdentity

Now that we have the list of monitors, let’s find out which one is reporting an unhealthy state, by running the following cmdlet:

Get-ServerHealth | ?{$_.HealthSetName -eq “MailboxSpace”}

Figure 6: Get-ServerHealth

To figure out why the monitor is failing, let’s list the configuration details of StorageLogicalDriveSpaceMonitor monitor.

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/MonitorDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like “StorageLogicalDriveSpaceMonitor”}

Figure 7: StorageLogicalDriveSpaceMonitor details

You can also use Event Viewer to get the details of monitor definition. The configuration details of most of the Monitors are stored in the MonitorDefinition channel:

  1. Open Event Viewer, and then expand Applications and Services Logs > Microsoft > Exchange > ActiveMonitoring > MonitorDefinition.
  2. Click on Find, and then enter StorageLogicalDriveSpaceMonitor.
  3. The General tab does not show much detail, so click on the Details tab, it has the configuration details specific to this monitor. Alternatively, you can copy the event details and text and paste it into Notepad to see the details.

Figure 8: MonitorDefinition

From the last 2 steps we discovered that there is a field called MonitoringThreshold with a value of “1”. I’d say that’s a good candidate to tweak in order to modify the health result returned by the monitor.

Use the following command to create a local override, and change the MonitoringThreshold value to 50GB:

Add-ServerMonitoringOverride -Server -Identity MailboxSpace\StorageLogicalDriveSpaceMonitor\C: -ItemType Monitor -PropertyName MonitoringThreshold -PropertyValue ’50000’ -Duration 60.00:00:00

Local overrides are stored under following registry path:


The Microsoft Exchange Health Management service reads this registry path every 10 minutes and loads configuration changes. Alternatively, you can restart the service to make the change effective immediately.

Figure 9: Windows Registry

Finally, to remove the local override that was created for the StorageLogicalDriveSpaceMonitor probe, run the following cmdlet:

Remove-ServerMonitoringOverride -Server E2K13-MBX1 -Identity MailboxSpace\StorageLogicalDriveSpaceMonitor\C: -ItemType Monitor -PropertyName MonitoringThreshold

Managed Availability Global Overrides

Configuring global overrides is not much different than configuring local overrides. The main difference is that a global override is used to deploy an override across multiple servers.

For this example we’ll use a recent problem that affected some Exchange systems throughout the world. As you are probably aware, the release of Exchange 2013 RTM CU2 and CU2 v2 caused some BSOD on DAG member servers when Exchange is deployed in multi-domain Active Directory forests.

The workaround for this problem, while the new version of the CU2 was not released, was to disable the responder “ActiveDirectoryConnectivityConfigDCRestart” to prevent forced reboots of Exchange server. Since the problem only occurred on a specific version of Exchange, we’ll want to specify that the override only applies to build number 15.0.712.24.

We can use the following command to get version information for Exchange 2013 RTM CU2 servers:

Get-ExchangeServer | ft name,admindisplayversion

Figure 10: Get-ExchangeServer version

Use following command to create a new global override:

Add-GlobalMonitoringOverride -Identity Exchange\ActiveDirectoryConnectivityConfigDCServerReboot -ItemType Responder -PropertyName Enabled -PropertyValue 0 -ApplyVersion “15.0.712.24”

Use following command to make sure the responder is disabled:

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/responderdefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like “ActiveDirectoryConnectivityConfigDCServerReboot”} | ft name,enabled

If the responder is disabled, Enabled should have a value of “0”, as depicted in the following picture:

Figure 11: Get-WinEvent

Global overrides are stored in the following container in Active Directory:

CN=Overrides, CN=Monitoring Settings, CN=<Exchange Organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=Contoso, DC=com

Figure 12: ADSIEdit


The Exchange 2013 Management Pack is much simpler and straightforward to configure than its predecessors. Nevertheless, if some tweaking is necessary regarding the monitors and alerts, overrides can be configured in Operations Manager and also in Exchange Managed Availability.

In the next part of this series we’ll cover reporting.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top