Wednesday, May 15, 2013

Exchange 2013 Management Pack

The Exchange team has just released the Exchange 2013 Management Pack! You can find the Management Pack here and the guide here. The guide walks through the details of deploying, configuring and using the Management Pack.
 
Prerequisites
Before you can import the management pack, verify that the following conditions are met:
  • You have one of the following versions of System Center Operations Manager deployed in your organization:
        o System Center Operations Manager 2012 RTM or later
        o System Center Operations Manager 2007 R2 or later
  • You have already deployed SCOM agents to your Exchange Servers. Show me how.
  • The SCOM agents on your Exchange Servers are running under the local system account. Show me how.
  • The SCOM agents on your Exchange Servers are configured to act as a proxy and discover managed objects on other computers. Show me how.
  • Your user account is a member of the Operations Manager Administrators role.
 
Management Pack Scope and Benefits
The Exchange team takes monitoring seriously, and they have created a pretty comprehensive Management Pack in terms of monitoring coverage, with the primary focus being reduced downtime for an Exchange environment.
 
The Management Pack contains about 75 monitors that cover Exchange component health (such as Hub Transport health), customer touch point health (such as “is OWA working”), clustered scenarios, as well as dependencies monitoring (“is Active Directory healthy”). Monitoring covers primarily availability and performance scenarios.
 
The Exchange 2013 product comes with monitoring “built in” (more on that below). This means that Exchange itself has means to detect and try to automatically recover from availability and performance issues, before an operator is notified. This means reduced alert noise, as well as reduced administrative overhead for the Exchange product itself. In concrete terms, an Exchange server may detect an issue, then try for some time to fix it automatically. Only after the automatic recovery attempts have failed is the operator notified via an alert.
 
What’s in the Management Pack?
The Management Pack is very simple. It contains a handful of classes, 3 views, and about 75 monitors described here
. There are also some dependency monitors.
 
All the monitors are simple event-based monitors using events in the Microsoft-Exchange-ManagedAvailability/Monitoring event log, logged by each Exchange server. So, each Exchange server is responsible for monitoring itself and its health.
 
In terms of scalability, this means this Management Pack will have a low impact to your Operations Manager environment. You will not require a separate Management Group for this MP for scalability purposes.
 
Where are the monitors?
If you look at the Management Pack in some tool like MP Viewer, you will discover that there are not 75 monitors in the Management Pack. This is because the Management Pack has logic to dynamically determine the set of monitors by communicating with the built-in monitoring features of Exchange (more on that below). The way to see the monitors is by installing the Management Pack in an Operations Manager environment with monitored Exchange servers and using Health Explorer (you can also see them listed in the Management Pack Guide).
 
What’s not in the Management Pack?
If you are familiar with the Exchange 2010 Management Pack, you know that it had a service called the correlation engine that ran on the Root Management Server. It basically correlated health data from all monitored Exchange components. In the Exchange 2013 Management Pack, the correlation engine is no longer used. Each monitored Exchange server is responsible for monitoring its own health, and simply reports this via the Operations Manager agent. There is a little bit of roll-up going on, from Exchange server to Organization health. There are no special components running on the Operations Manager Management Servers.
 
The Exchange 2010 Management Pack had tens of classes, leading to a pretty complex health model and many object instances being created. The Exchange 2013 Management Pack is very simple. It has only a few classes and should have a very low impact on Operations Manager in terms of instance space.
 
There are no performance counters collected by this Management Pack (as mentioned above, the monitoring does cover performance scenarios). However, all Exchange PerfMon counters are still available. It should be simple to create your own performance collection rules, if you do require them.
 
This means that by default there is way less pressure on the Management Group compared to the Exchange 2010 Management Pack, since there are no performance counters to store. But, what about reporting? There are also no reports in this Management Pack. However, you can use some of the built-in Operations Manager reports (such as the Health report) to track organization availability, or define SLAs against the Organization.
 
How does the Management Pack work?
Exchange 2013 has a built in monitoring engine called Managed Availability. It runs on every Exchange server. It contains logic for how to determine Exchange health. It detects issues, automatically performs recoveries (Exchange calls these “responders”) and ultimately notifies operators of issues, if the recoveries were not successful. The purpose of this of course, is high availability. Managed Availability is explained in more detail here
.
 
 
Notification/Alerting to Operations Manager is handled via events, so the Management Pack has a set of simple event monitors that trigger based on these events. Events are logged to the Microsoft-Exchange-ManagedAvailability/Monitoring event log.
 
  • Probes: these are sets of data collectors that measure various components. There are three distinct types of probes:
      o Synthetic transactions that measure synthetic end-to-end user operations and checks that measure actual traffic;
      o Checks that measure actual customer traffic;
      o Notifications that allow Exchange to take immediate action. A good example of this is the notification that is triggered when a certificate expires.
  • Monitors: the data collected by probes are passed on to monitors that analyze the data for specific conditions and depending on those conditions determine if the particular component is healthy or unhealthy;
  • Responders: if a monitor determines that a component is unhealthy, it will trigger a responder. If the problem is recoverable, the responder attempts to recover the component using the built-in logic. There are several responders available for each component, but the one responder that’s relevant for the Exchange 2013 Management Pack is the Escalate Responder. When the Escalate Responder is triggered, it generates an event that the Exchange 2013 Management Pack recognizes and feeds the appropriate information into that alert that provides administrators with the information necessary to address the problem.

Each component in Exchange 2013 uses a specific set of probes, monitors and responders to monitor itself. These collections of probes and monitors are referred to as health sets. For example, there are a number of probes that collect data about various aspects of the ActiveSync service. This data is processed by a designated set of monitors that trigger the appropriate responders to correct any issues that they detect in the ActiveSync service. Collectively, these components make up the ActiveSync health set.

How should I work with this Management Pack?
First of all, this Management Pack should be simple to implement from an Operations Manager perspective. There are no special components to install on Management Servers, you do not need to worry about the impact to the Management Group in terms of database size, instance space, Management Server workload etc. You should be fine just importing this MP into your existing environment also for large Exchange deployments (as usual, we do recommend gradual deployment just in case). The Management Pack Guide includes a chapter on deployment, as usual you will need to enable Agent Proxy when you install the Operations Manager agents on Exchange 2013 servers.
 
Also, the Exchange team has been using the same monitoring logic in the Office365 environment. Normally, few changes to the Management Pack should be required.
 
If you want to disable some monitor, you can just create an override in Operations Manager as usual.
 
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. The Exchange Management Pack Guide walks through this scenario in some detail here. Since this kind of override is a modification of Exchange behavior, this kind of override is most commonly done by the Exchange administrator.
 
Also, Exchange Cumulative Updates may contain new or updated monitoring logic. These should be reviewed to determine the impact of that updated logic.
 
In terms of interoperability, this Management Pack does not upgrade the Exchange 2010 Management Pack, this is a completely new MP. It is possible to run these Management Packs side-by-side as you upgrade your Exchange environment from 2010 to 2013.
 
What’s the update mechanism for this Management Pack?The Managed Availability feature is built in to Exchange 2013. It contains the logic for how to detect issues and how to recover from them. The results of that is then reported to the event log for Operations Manager to pick up via event monitors. This means that updates in terms of Managed Availability monitors are shipped with Exchange Cumulative Updates.
As mentioned previously, the Exchange 2013 Management Pack has functionality to automatically detect these changes, so typically no Management Pack update is required.
 

Sources

2 comments:

  1. Hi Nino
    on a different subject
    (just didn't know how to reach you)
    but can you share how you created a lot of public folders and items for the msexchange.org article you just published?
    Thanks in advance
    Turbomcp@hotmail.com

    ReplyDelete
    Replies
    1. Hi,

      Sure! The script was very simple (it was actually for another project, thus the "strange" PF folder structure).
      Let me know if the following helps (obviously this is for Exchange 2010):

      New-PublicFolder -Name "America" -Path "\" -Server "AIO"
      New-PublicFolder -Name "Antartica" -Path "\" -Server "AIO"
      New-PublicFolder -Name "Africa" -Path "\" -Server "AIO"
      New-PublicFolder -Name "Europe" -Path "\" -Server "AIO"
      New-PublicFolder -Name "Asia" -Path "\" -Server "AIO"
      New-PublicFolder -Name "Australia" -Path "\" -Server "AIO"

      Sleep 5

      For ([Int] $x = 1; $x -le 50; $x++)
      {
      New-PublicFolder -Name "america.$x" -Path "\America" -Server "AIO"
      New-PublicFolder -Name "antartica.$x" -Path "\Antartica" -Server "AIO"
      New-PublicFolder -Name "africa.$x" -Path "\Africa" -Server "AIO"
      New-PublicFolder -Name "europe.$x" -Path "\Europe" -Server "AIO"
      New-PublicFolder -Name "asia.$x" -Path "\Asia" -Server "AIO"
      New-PublicFolder -Name "australia.$x" -Path "\Australia" -Server "AIO"
      }

      Sleep 5

      Get-PublicFolder -Recurse | Enable-MailPublicFolder

      Sleep 5

      Get-MailPublicFolder -ResultSize Unlimited | Select DisplayName, PrimarySmtpAddress | ForEach {
      $pf = [String] $_.PrimarySmtpAddress
      $random = Get-Random -Minimum 100 -Maximum 501
      For($j=1; $j -le $random; $j++) {
      Send-MailMessage -From "administrator@letsexchange.com" -To $pf -Subject "Email $j to $pf" -Body "Email $j to $pf" -SMTPserver "aio.letsexchange.com"
      }
      }

      Delete