As many of you knows, the Exchange 2010 Management Pack implements an alerts correlation service, the aim of the service is to raise an alert just for the very root cause of the issue, thus limiting alerting noise. This implementation choice has many implications (I’m staying neutral here, I’m not saying they’re bad or good, just there are implications):
- you have an external service that adds load to your RMS since it keeps polling your sdk service
- management pack configuration is very different from other management packs, overrides effects are not always straightforward
- you should not dare changing any alert custom property above and including customAttribute5
Unfortunately we have our own alert automation solution that uses customAttributes, this lead to some problems on our data warehouse. You must know customAttributes are used by the Exchange MP to correlate alerts, changing these attributes breaks alert correlation and cause the alert impact staging process in your data warehouse to enter an infinite, CPU and disk taxing loop.
You can easily check if you’re in this situation by closely watching your data warehouse CPU usage and in case you suspect something bad, take a look at the Exchange2010.AlertImpactRawStagingV14 table, if it contains rows an a sustained basis then you’re likely to be in troubles.
- be sure to stop any update of the customAttributes used by the Exchange 2010 MP
- reset the exchange alerts in console (you should be able to get to the alert form the context column in the AlertImpactRawStagingV14 table)
- * totally unsupported * just delete the persisting rows from the table
This posting is provided "AS IS" with no warranties, and confers no rights.