Monitoring Exchange 2013 with SCOM 2012 (Part 4)

Reporting and monitoring SLAs using the Exchange Management Pack and Operations Manager Dashboards.

(Un)Available Reports

As it was said in the first part of this article, the current version of the Exchange Server 2013 Management Pack doesn’t include reports. If you really want to have some reporting capabilities around the Exchange service, as a workaround you can use some of the built-in Operations Manager reports (such as the Availability report or the Health report). The Service Level Report Library can also be very useful, as we’ll see a little bit further ahead.

Figure 1: Reports
For example, to create an Availability report, follow these steps:

1. In the Reporting view of the Operations console, click Microsoft Generic Report Library. Right-click the Availability report, and then click Open.
2. Click Add Group. In the Group Name box type “Exchange” and click Search. Under Available Items, select “Exchange 2013 Service” and then click Add. Click OK to close the Add Group window (Figure 2).

Figure 2: Add Group

3. In the Data Aggregation drop-down box, select Hourly. Select an appropriate time interval, using the From and To dropdown boxes. Click Run to generate the report, as depicted in Figure 3. After a moment a new report with the availability status from several Exchange components will be displayed (Figure 4)

Figure 3: Availability report

Figure 4: Availability report

Advertisement

Monitoring Service Level Objectives

Looking from a higher perspective to service monitoring, companies set goals for their service availability and response times, defining the required metrics that measure if the critical resources, such as applications and systems, are available and performing at acceptable levels.
Using the industry jargon, these goals usually correspond to Service Level Objectives (SLO). System Center 2012 Operations Manager provides the capability to monitor and track service level objectives using the following features:

• Define a set of monitors that you need to track
• Running availability reports against those sets of monitors
• Using Dashboards for visualization

The Service Level Tracking feature in System Center 2012 Operations Manager offers the capability to define SLOs that you can then use to track the health of an application or group. You can define an SLO for an application, a group, or other class of objects. These SLOs focus on such targets as availability and performance.
To define an SLO for the Exchange 2013 Service, follow these steps:

1. In the Operations console, from the Authoring view, click Management Pack Objects and then, in the Authoring navigation tree, click Service Level Tracking. In the Actions pane, click Create.
2. In the Name box, type the name of the application or group. You can optionally provide a description. Click Next.

Figure 5: General

3. In the Objects to Track window (Figure 6), under Targeted class, click Select to specify the class for the service level. In the Select a Target Class window (Figure 7), select Exchange Server and click OK. The Exchange Server class will include all the Exchange servers in your organization.

Figure 6: Objects to Track

Figure 7: Select a Target Class

4. Select the management pack where this service level will be saved (Exchange Server 2013 MP customizations) and click Next.
5. On the Service Level Objectives page (Figure 8), click Add and then click Monitor state SLO to create a new monitor to track the availability of the application or group. Define the state monitor as follows:
   a) In the Name box, type Availability SLOb) In the Monitor drop-down box, select Availability.
   c) For Service level objective goal, provide the numerical measure for your objective. For example, if your goal is 99.5 percent availability, type 99.500.
   d) To refine what the monitor tracks as available, select or clear any of the following state criteria to be counted as downtime:

• Unplanned maintenance
• Unmonitored
• Monitoring unavailable
• Monitor disabled
• Planned maintenance
• Warning

e) Click OK.

Figure 8: Service Level Objective (Monitor state)

6. To add a performance monitor, click Add and select the Collection Rule SLO. Since the current version of the Exchange Server 2013 Management Pack doesn’t collect Performance information, will skip this step. Click Next (Figure 9), and then click Finish (Figure 10). Click Close to close the window when you have successfully created the SLO.

Figure 9: Service Level Tracking – Service Level Objectives

Figure 10: Service Level Tracking – Summary
The Service Level Tracking Summary Report compares the results for one or more service levels to the defined target objectives. From this report, you can examine a more detailed report, the State view, or the Service Level Agreement view.

1. In the Reporting view of the Operations console, click Microsoft Service Level Report Library. Right-click the Service Level Tracking Summary Report, and then click Open.
2. Click Add. In the Type Name box click Search. Under Available Items, select the one that as “Exchange Server” as the Target and then click Add. Click OK to close the Add Service Levels window (Figure 11).

Figure 11: Add Service Levels

3. In the Data Aggregation drop-down box, select Hourly. Select an appropriate time interval, using the From and To dropdown boxes. Click Run to generate the report, as depicted in Figure 12.

Figure 12: Service Level Tracking Summary Report

Create a Service Level Dashboard

After configuring System Center 2012 Operations Manager with the SLOs required for tracking, we can create a service level dashboard view to monitor the service level objective. The service level dashboard view allows us to quickly visualize the level of service and whether success is either above or below the target value for the currently selected SLA/instance. When you select an objective in the Service Level Objectives grid, a gauge and chart is displayed.

1. In the Operations console, click My Workspace. Right-click the folder where you want to store the view, point to New, and click Dashboard View.
2. In the New Instance Wizard (Figure 13), on the Template page, select the Service Level Dashboard Layout, and then click Next.

Figure 13: New Dashboard and Widget Wizard

3. On the General Properties page (Figure 14), enter a name for the dashboard view. The Description is optional. Click Next.

Figure 14: General Properties

4. On the Specify the Scope page (Figure 15), click Add. In the Add SLA window, select the service level objective that you created, click Add, and then click OK. You can add multiple service level objectives. On the Specify the Scope page, in the Last section, set the period of time that you want to display in the dashboard view, and then click Next.

Figure 15: Scope

5. Review the settings on the Summary page (Figure 16), and then click Create. Click Close on the Completion page (Figure 17).

Figure 16: Summary

Figure 17: Completion
Since this is a test environment, it was with no surprise that the Service Level Dashboard showed a red condition, meaning the SLOs are not being met, as depicted in Figure 18.

Figure 18: Exchange SLA Dashboard

Summary

To meet compliance needs, administrators require a solution for tracking, managing, and reporting the Exchange Server 2013 messaging infrastructure. The Availability and the Service Level Tracking Summary reports can help visualizing service level goals. The Service Level Dashboard is also another available feature that displays summarized data about those service levels.

Monitoring Exchange 2013 with SCOM 2012 (Part 3)

Working with the management pack and configuring overrides in Exchange Managed Availability.

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

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

Figure 2: Override Properties

3. 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 E2K13-MBX1.contoso.com | ?{$_.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 E2K13-MBX1.contoso.com -Identity MailboxSpace\StorageLogicalDriveSpaceMonitor\C: -ItemType Monitor -PropertyName MonitoringThreshold -PropertyValue ’50000’ -Duration 60.00:00:00

Local overrides are stored under following registry path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ActiveMonitoring\Overrides\Monitor
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

Summary

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.

Monitoring Exchange 2013 with SCOM 2012 (Part 2)

In this article we'll look at adding the Exchange servers as agent-managed computers, importing the Exchange 2010 Management Pack and installation.

Solution Topology

For the purpose of writing this article, I installed the following environment on my test lab:

Figure 1: Solution topology used in this article

Server Name	Role	Software
SC2K12-SCOM	Root Management Server	Windows Server 2012 SQL Server 2012 SP1 System Center 2012 Operations Manager SP1 + UR4
E2K13-MBX1	Domain Controller Mailbox Server CAS Server	Windows Server 2012 Exchange Server 2013 + CU2
E2K13-MBX2	Mailbox Server CAS Server	Windows Server 2012 Exchange Server 2013 + CU2

Table 1: List of servers

Exchange 2013 Management Pack Pre-requisites and Considerations

Before importing the Exchange 2013 MP into System Center Operations Manager, there are some pre-requisites that have to be met:

• You have one of the following versions of System Center Operations Manager deployed in your organization:
• System Center Operations Manager 2012 RTM or later
• System Center Operations Manager 2007 R2 or later
• You have already deployed SCOM agents to your Exchange Servers.
• The SCOM agents on your Exchange Servers are running under the local system account.
• The SCOM agents on your Exchange Servers are configured to act as a proxy and discover managed objects on other computers.
• If you are monitoring Exchange Server 2013 Database Availability Groups (DAGs), ensure that all DAG members are monitored by Operations Manager.

Before downloading and installing the Exchange Server 2013 MP, you might want to import some recommended additional management packs, such as (these are the ones I used):

• Active Directory Domain Services Management Pack for System Center
• System Center Management Pack for Windows Server Operating System
• System Center 2012 Monitoring Pack for Microsoft Windows Server 2012 Internet Information Service 8
• System Center Management Pack for Windows Server DNS

Add the Exchange servers as agent managed computers

Adding the Exchange servers to monitor as agent managed computers is the first required step.

1. Click the Administration tab and then click Configure computers and devices to manage on the Actions pane. This will start the Computer and Device Management Wizard (Figure 2). Click Next, choose Advanced Discovery (Figure 3) and select Servers Only from the Computers and Device Classes drop-down box.

Figure 2: Computer and Device Management Wizard

Figure 3: Advanced discovery

2. On the next window, browse for the computers you are adding (Figure 4) and click Next. Select Use selected Management Server Action Account (Figure 5), click Discover and wait for the discovery results (Figure 6). Figure 7 shows a brief summary that is displayed at the end of the wizard. It is mandatory that all systems running Exchange Server 2013 that are managed by Operations Manager use Local System as the Agent Action Account. Click Finish.

Figure 4: Discovery Method

Figure 5: Administrator Account

Figure 6: Select Objects to Manage

Figure 7: Summary

3. If the agent installation was successful, on each Exchange server you’ll be able to see the System Center 2012 - Operations Manager Agent listed on the Programs and Features on Windows 2012 (Figure 8). A new service is also created, the System Center Management Service, as depicted in Figure 9.

Figure 8: Programs and Features (Add/Remove Programs)

Figure 9: System Center Management Service Properties

4. To enable Agent Proxy configuration on all managed Exchange servers, in the Administration pane, under Administration, Device Management, Agent Managed, right-click on each Exchange server (Figure 10), select Properties, then the Security tab (Figure 11), and check the box Allow this agent to act as a proxy and discover managed objects on other computers. This step will also make exchange cluster instances to appear in the Agentless Managed section (ensure that all physical nodes of the cluster are monitored). Repeat the process for every managed Exchange 2013 server in the list

Figure 10: Agent Managed Properties

Figure 11: Enabling Agent Proxy

Create a new management pack for customizations

The customizations and overrides of sealed management packs, such as the Exchange 2013 MP, are usually saved in the default management pack. As a best practice you should create and use an unsealed management pack for each sealed management pack that you want to override, as shown in Figure 12.

Figure 12: Unsealed management packs
Creating a new management pack for storing overrides has the following advantages:

• It simplifies the process of exporting customizations that were created in your test and pre-production environments to your production environment.
• It allows you to delete the original management pack without first needing to delete the default management pack.
• It is easier to track and update customizations to individual management packs.

1. In the Operations Console, click the Administration button. In the Administration pane, right-click Management Packs and then click Create Management Pack. The Create a Management Pack wizard displays.
2. In the General Properties page (Figure 13), type a name for the management pack in Name, the correct version number in Version, and a short description in Description. Click Next and then Create.

Figure 13: Creating a Custom MP for customizations

Install the Exchange Server 2013 MP

With the recommended additional management packs already imported, download and install the latest Microsoft Exchange Server 2013 Management Pack (at the time of the writing of this article it was version 15.00.0620.018). You can find the latest Management Packs at the Microsoft System Center Marketplace.
Let’s look at the installation steps of the Exchange 2013 Management Pack:

1. Download the management pack file and launch the Microsoft Installer (MSI) package on the selected SCOM server. Accept the license agreement, and click Next (Figure 14).

Figure 14: License Agreement

2. Accept the default installation folder or select a new one. Click Next (Figure 15). The extraction process begins.

Figure 15: Select Extraction Folder

3. When the extraction ends, click Close (Figure 16). When the installation is complete, the management pack files are copied to the System Center Management Packs folder.

Figure 16: Extraction Complete

4. To import the Exchange 2013 MP, open the SCOM 2012 Operations Console. Click the Administration tab, right-click the Management Packs node and then click Import Management Packs (Figure 17).
5. Click Add, Add from disk and then click No on the Online Catalog Connection window. Select all the files from the Exchange MP directory, by default C:\Program Files\System Center Management Packs (Figure 18), click Open and then click the Install button (Figure 19).

Figure 17: Import Management Packs

Figure 18: Select Management Packs to import

Figure 19: Import Management Packs

6. The Import Management Packs page appears and shows the progress for each management pack. After the import process is complete and the dialog box displays an icon next to each Management Pack that indicates success of the importation (Figure 20), click the Close button. Click View and then Refresh, or press F5, to see the Microsoft Exchange Server 2013 management pack in the list of Management Packs.

Figure 20: Import Succeeded
After importing the Exchange 2013 MP, it will start immediately discovering Exchange machines. So, if you browse to the Discovered Inventory pane on the Operations Console (Figure 21), all the Exchange 2013 servers should be listed. Notice that the Database Availability Group (DAG) is also listed, although its state is Not monitored. This is a normal behavior, since the physical nodes of the DAG are already being monitored.

Figure 21: Discovered Inventory
The Exchange 2013 MP adds 3 views to the Monitoring pane (Figure 22):

• Active Alerts
• Organization Health
• Server Health

Figure 22: Organization Health
Expand Microsoft Exchange Server 2013, and then click Server Health. Right click on one of the Exchange servers listed and click Open, Health Explorer. By default, the view is scoped to unhealthy child monitors (Figure 23). Click on Filter Monitors to clear the filter (Figure 24). Expand Entity Health to view the 4 health groups for Exchange Server 2013:

• Customer Touch Points – components with direct real-time, customer interactions (e.g., OWA).
• Service Components – components without direct, real-time, customer interaction (e.g., OAB generation).
• Server Components – physical resources of a server (e.g., disk, memory).
• Key Dependencies – server’s ability to call out to dependencies (e.g., Active Directory).

Figure 23: Server Health (filtered)

Figure 24: Server Health (unfiltered)

Summary

With the Exchange 2013 Management Pack imported, SCOM is now prepared to receive the escalated alerts from Managed Availability that require human attention.
In the next part we’ll take a deeper look into Managed Availability, specifically how to interact with it and perform some configuration tasks that used to be part of the process of installing and configuring the MP.