Monitoring Exchange Server 2010 (part 2) – System Center Operations Manager 2007 R2

System Center Operations Manager 2007 R2 (SCOM) is the platform monitoring and reporting solution from Microsoft. SCOM provides end-to-end service management that includes monitoring, troubleshooting, and reporting tools. SCOM uses the concept of management packs to extend the base framework for specific applications, such as Exchange 2010. A management pack includes all of the rules, knowledge, reports, and tasks needed to monitor a product. SCOM has management packs for all of Microsoft’s server products, and even sub-components such as DNS. The Exchange 2010 management pack has a complete health model and diagnostic alerts, and service-level reports needed to smoothly operate Exchange. Although SCOM itself requires licensing, the management Microsoft management pack for Exchange 2010 is free. The latest management pack includes several new features, described in the following sections.

1. Alert Correlation

A Windows service called the Correlation Engine finds dependencies encoded in the health model to determine root cause. It uses the class hierarchy defined in the Exchange MP to understand dependencies. For example, if Active Directory goes offline, it will also report that Exchange is not fully functional. This significantly reduces the noise that was an issue in earlier versions of SCOM.

It is recommended that you install the Correlation Engine on the SCOM Root Management Server (RMS). There is a performance impact to the RMS, because much of the information must be held in memory to determine the related monitors and alerts. It is estimated that the engine requires about 5 MB per Exchange instance that is being monitored.

2. Alert Classification

Alerts are put into three categories:

  • Key Health indicator Important, service-impacting issues. Most alerts fall under this category.

  • Non-Service Impacting Issues Issues that affect specific mailboxes but do not impact the larger system.

  • Forensic Monitors diagnostics that do not represent a specific problem. These do not create alerts, but may be useful while diagnosing an issue.

3. Full Protocol Synthetic Transaction Coverage

SCOM uses the native Exchange diagnostic cmdlets to simulate user transactions or protocol tests. Table 1 shows the synthetic transactions available in the Exchange 2010 management pack. These cmdlets can also be called directly from PowerShell and do not require SCOM.

Table 1. Synthetic Transactions
ACTIONCMDLET
Unified Messaging – Remote VoiceTest-UMConnectivity -UMIPgateway
Unified Messaging – Local VoiceTest-UMConnectivity
Database ReplicationTest-ReplicationHealth
SearchTest-ExchangeSearch
Remote PowerShell – ExternalTest-PowerShellConnectivity –TestType:External
Remote PowerShell – InternalTest-PowerShellConnectivity –TestType:Internal
Mailbox Replication ServiceTest-MRSHealth
Outlook (MAPI) – InternalTest-OutlookConnectivity –RPCTestType:Server
Outlook – AutodiscoverTest-OutlookConnectivity –GetDefaultsFromAutoDiscover $True
Web ServicesTest-WebServicesConnectivity
POP3Test-PopConnectivity
Exchange Control Panel – ExternalTest-EXPConnectivity –TestType:External
Exchange Control Panel – InternalTest-EXPConnectivity –TestType:Internal
Outlook Web Application – ExternalTest-OwaConnectivity –TestType:External
Outlook Web Application – InternalTest-OwaConnectivity –TestType:Internal
IMAP4Test-ImapConnectivity
Outlook Web ServicesTest-OutlookWebServices
ActiveSyncTest-ActiveSyncConnectivity
EdgeSyncTest-EdgeSynchronization


4. Reporting

The Exchange MP now includes mail flow statistics based on the message tracking logs. Figure 1 shows a sample report for mail flow statistics.

Figure 1. Sample SCOM mail flow report

System Center Operations Manager 2007 R2_1

Service-oriented reporting is for measuring applications or features, not just the host. It is interesting to note how SCOM calculates availability information. Figure 2 shows a sample availability report.

Figure 2. Sample SCOM availability report

System Center Operations Manager 2007 R2_2

 

Table2 shows how System Center calculates availability information.

Table 2. SCOM Availability Information
MEASURMENTDESCRIPTION
Mailbox Database – Daily AvailabilityA database is available when one of its copies is mounted. The daily availability is the percent of the day that the database is available.
Outlook Web App – Daily AvailabilityBoth server- and site-level OWA states are reported. The service class is considered available when at least one OWA server is available.
Outlook – Daily AvailabilityBoth server- and site-level Outlook states are reported. The service class is considered available when at least one Outlook server is available.
Site Mailbox Database – Daily AvailabilityA site’s mailbox database availability is an average of mailbox database availabilities.
Site – Daily AvailabilityA site’s availability is its mailbox database availability minus the average of its OWA service class and Outlook service class unavailability.
Datacenter – Daily AbilityA datacenter’s availability is an average of site availabilities.
Monthly AvailabilityThe sum of the daily availabilities divided by the number of days in the month.
Raw Uptime1 – Downtime
AvailabilityRaw Uptime + Planed Maintenance Planned maintenance is considered uptime in the availability calculation.


Notes From The Field: Exchange and SCOM: Better Together

I had an interesting experience with the Exchange Management Pack in my last customer project. After planning and implementing Exchange Server in their environment, they also wanted a monitoring and reporting solution, so we decided to use System Center Operations Manager for that job.

The installation of the Exchange Management Pack (MP) was very easy, and shortly after we installed the pack it started to bring up alerts on specific items such as large queues and delivery notifications. Because of the fact that the alert also included information on how to solve the issue, it was quite easy to get rid of the alerts.

Every Exchange administrator wants a smooth-running Exchange deployment. We did our best to make sure that our deployment was well-tuned by running ExBPA and other tools. An important lesson I learned from this experience was that SCOM revealed a whole new level of detail about Exchange, and pointed out things that we needed to take care of to achieve a better operating environment. SCOM and the Exchange MP really proved their value to me in this respect.

Monitoring Exchange Server 2010 (part 1) – Performance Monitor