Monday, August 24, 2009

SCOM: Monitor vs. Rule

When you want to monitor specific occurences there are two options in SCOM. You can use a monitor or a rule.

In this blog post i'll will explain why you should use a monitor for a specific occasion and not a rule and vice versa.


Rules Collect data from sources like EventLog, Text or Log Files and Perfmon. That data is stored
In the Operations Manager database. If you have installed a Data Warehouse database this data is replicated to this database for Reporting purposes.
Rules always target classes. You should not target rules to groups. See the Authoring Guide from Microsoft for best practices. Targeting groups results in targeting the Root Management Server, as this is the host of all groups.


Monitors are used to determine the health state of an application component. A monitor is programmed with the intelligence to determine whether a component is healthy.

Monitors exist in two flavours, Two-state and Tree-State. Thus, a monitor can either be in one of two states (green or red) or in one of three states (green, yellow, red).
The state changes when the monitor responses to the monitoring information the monitor is using.

Monitors come in three different types: Unit Monitor, Aggregate Rollup Monitor and Dependency Rollup Monitor

Unit Monitor
A unit monitor is the fundamental monitoring component. Used to monitor specific counters, events, scripts and services. This monitor can generate an alert.

Aggregate Rollup Monitor
An aggregate rollup monitor reflects the state of unit, dependency rollup, or other aggregate rollup monitors. Use an aggregate rollup monitor to group multiple
Monitors intro one monitor. This monitor then is used to set the health state and optionally generate an alert. Each object has at least 4 of this rollup monitors: Availability, Configuration, Performance and Security.

Dependency Rollup Monitor
A depency rollup monitor rolls up health states from objects linked by either a hosting or a containment relationship. Use this monitor type to make the health state of a particular object dependent on the health state of components that are either hosted or contained. For example, the SQL Server 2005 object has an dependency rollup monitor that is related to a health monitor of a SQL Server 2005 Database object. When an application database is offline is doesn't mean the health state of SQL 2005 is critical, but when the master database has problems this has a direct impact on the SQL Server 2005 object.


Monitor and rules both collect monitoring data, but the collected data is used very differently. Rules collect data that goes into the Operations Manager database and Operations Manager Data Warehouse.
Monitors evaluate data from various sources and only store the state changes and alerts in the Operations Manager database.
Monitor-collected data is never stored in the Operations Manager database and Data Warehouse and thus is not usable for Reporting.

You want to monitor disk usage on a file server and generate an alert when used disk space exceeds 85%. You also want to have the disk usage information available for reporting.
How to implement this?

  • Create a collection rule to collect disk usage information for reporting
  • Collection rules do not generate alerts, so you'll need to create a unit monitor for monitoring the disk usage health. This monitor will generate a health state change and an alert after the disk usage exceeds the threshold of 85%.

Source: SCOM Authoring Guide

Wednesday, August 19, 2009

SCOM: Upgrading to SCOM 2007 R2

Last week i was busy upgrading multiple SCOM 2007 SP1 environments to R2.

The upgrade process to R2 is actually very straigt forward. That is, if your environment is also straight forward.
A collegue of my was presented with an upgrade error when he tried to upgrade the Reporting Server and the Data Warehouse Database in the background.
Eventually it was caused because the user account the SCOM Reporting Server upgrade was started with, was configured as a user on the database without SQL roles.

This takes some time to figure out, especially when you have to work with different teams. A team for SCOM, a team for SQL and for example a team for IIS.

That's why here is a R2 upgrade info list for your convenience:
And remember, always create a backup of your database before installing a upgrade.

Sunday, August 9, 2009

SCOM: Implementing ADMP replication monitoring in complex environments

Installing a management pack in your SCOM environment is a piece of cake. So is implementing ADMP. Things change when your AD forest structure is a bit more challenging than a single domain forest. For example, monitoring 4 different forests without forest trusts.

A feature of ADMP is replication monitoring. The account which will be used for monitoring must have rights on domain controllers in the domains. From a 'lease privilege' point of view, you should only give that account rights to only the objects that are really neccesary for operational monitoring. The ADMP guide luckely describes this in detail.

Doing these steps for multiple domains is kind of a hassle. That's why i wanted to create a ADMP deployment script to help system administrators implement ADMP faster in more complex AD environments.
--- weeks later.......
I must confess that writing a one-for-all implementation script for ADMP is not easy. Eventually after multiple implementations i made my choice. I decided to cancel my journey for the ultimum. Even if i did continue to make such a script, who would use it. Who do you trust enough to automate a Default Domain Controller Policy deployment, in which you delegate some rights for the Replication Monitor account.
My advice:
- Read ADMP implementation guide
- Backup your GPO's
- Know about SDDL's and settings security on EventLog items.
Last but not least
There are some tools to help you deploy the ADMP management pack faster. I gathered all tools and hot links:
SDDL strings for EventLog security:
SID tools:
I made some VBscripts for this. I will publish them as soon as possible.