Clustering the SCOM Microsoft Exchange Monitoring Correlation Service Part 1

It's not often I get to install SCOM into RMS clusters and this week was no exception. I'm finishing off a project that involves the installation of a SCOM 2007 R2 Highly Available environment configured as an RMS cluster on an SQL 2008 R2 cluster.

See the link below for the initial SCOM cluster installation steps:

http://kevingreeneitblog.blogspot.com/2011/02/clustering-scom-2007-r2-rms-role-on.html

The part of this project I am working on this week is based around a new Highly Available Exchange 2010 messaging environment and bringing this into the existing SCOM infrastructure.

Now, for those of you that are used to installing the Exchange 2010 Management Pack, you will be familiar with a new method that Microsoft have been pursuing in relation to management packs, and this is based around the new 'Microsoft Exchange Monitoring Correlation Service'.

The 'Microsoft Exchange Monitoring Correlation Service' is basically a noise reduction utility that sits between the Exchange 2010 and SCOM environments and filters out unnecessary alerts before you even need to start thinking about tuning!

It's based on nearly 2 years of in-house deployment from the MSIT team on their own SCOM and Exchange 2010 environment.

The Microsoft Exchange Monitoring Correlation Service installs itself as a standard Windows Service on the SCOM RMS and is viewable from within the 'services.msc' snap-in.

When I install a Management Pack into SCOM, no matter how often I have installed the same MP into other SCOM environments, I will always read the MP guide that accompanies the Management Pack as it can contain valuable information on configuration and initial tuning settings that need to be deployed to get the most out of your new MP.

When I started to read through the Exchange 2010 MP guide, I was looking specifically for instructions on clustering the Correlation Service as there's no point in having a HA environment for your RMS and SQL services and then not having the main noise reduction service for your Exchange 2010 MP not failing over to your other cluster nodes in the case of an emergency. The Exchange 2010 MP guide unfortunately has no information on clustering this service at all and after searching the web for some additional info, all I found was some references to it being added to the next version of the Exchange 2010 MP guide - whenever that gets released!! I set about clustering this service using the Failover Clustering Wizard that is built into Windows Server 2008 R2 and decided to blog about it for anyone else who finds that the Microsoft documentation falls just short of this type of information.

In part 2 of this short guide, I will demonstrate how to cluster this service and make it Highly Available within your SCOM environment.