During the delivery
of SCOM projects, I have gone through a no. of objections/questions for
Exchange Server 2013 Monitoring View in System Center Operations Manager 2012
SP1/R2.
The questions was
related to :-
a) Why there are
only 3 views in Exchange Server 2013 Management Pack unlike Exchange Server
2010?
b) Exchange
Services Alerts are not coming into SCOM console.
c) If any Exchange
Database is mounted, then alert should be raised in SCOM.
d) If Mail queues
goes beyond 100, it should create alerts in SCOM.e) A separate view for Size of
Mailbox database.
Hereby, as per my understanding and experience, I would like to provide you with an explanation for why we have only 3 views by
default in "Exchange Server 2013 Management Pack".
The
Microsoft Exchange Server 2010 monitoring management pack is designed to be
used for monitoring Exchange 2010 events, collecting Exchange
component-specific performance counters in one central location, and for
raising alerts for operator intervention as necessary. By detecting, sending
alerts, and automatically correlating critical events, this management pack
helps indicate, correct, and prevent possible service outages or configuration
problems, allowing you to proactively manage Exchange servers and identify
issues before they become critical. The management pack monitors and provides
alerts for automatic notification of events indicating service outages,
performance degradation, and health monitoring. The Exchange Server 2010
management pack includes a new Windows service component called the correlation engine. This service determines the
best alert to raise by examining the Exchange 2010 health model through the
Operations Manager SDK service. In short, this service maintains the Exchange
health model in memory, reviews the faults for instances within the Health
Model over the last 90 seconds and raises an alert for the fault lowest in the
health model. The end result is fewer false alerts, as the correlation engine
attempts to raise an alert for the source cause of the service
Now
this complete architecture of monitoring has been changed in Exchange Server
2013 with the introduction of a new feature called “Managed
Availability”. In the Exchange 2013 Management Pack, the correlation engine is no longer used. Each monitored
Exchange server 2013 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.
“Managed
Availability” 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.
In
other words All the monitors in Exchange server 2010 MP, are simple event-based
monitors using events in the Microsoft-Exchange-Managed Availability/Monitoring
event log, logged by each Exchange server. So, each Exchange server is
responsible for monitoring itself and its health.
So the key points here :
+ In Ex 2010, we used to probe and then decide the health of Exchange using
probes, scripts, monitors, rules and correlation engine
+ In Ex 2013, this is built-in to Exchange
+ Every Exchange server monitors its own health and tries to handle any
issues that it finds on its own, this is called Managed Availability .
+ What it cannot handle is logged as an event in the managed availability -
MA event log
+ Exchange 2013 MP looks at this event log and then change state/generate
alerts.
+ So unlike the Ex 2010 MP, there is pretty much no scope of customization
in the Ex 2013 MP
+ This is because all thresholds and limits are now a part of
Exchange(2013) itself.
+ These are not properties of the MP workflows anymore.
+ There is NO way to configure the Ex 2013 Mp to behave exactly like the Ex
2010 MP
+ All changes in behavior and thresholds need to be done on the Exchange
side now.
+ These are not configurable through SCOM
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. 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.
Please
find the useful articles below:
System Center: Operations Manager Engineering Blog
MP Blog: Exchange 2013 Management Pack released
Lessons from the Datacenter: Managed Availability
Customizing Managed Availability
What's New in Exchange 2013
http://technet.microsoft.com/en-us/library/jj150540(v=exchg.150).aspx
Hope it helps!
If any improvement is required in this post, please post your comments/feedback so that we can provide much better solutions.
No comments:
Post a Comment