In the previous part “SCOM Platform in 5 minutes. Part 1: Health Model“, we learned that for each monitoring entity, SCOM creates a hierarchical Health Model to represent a structure of the top level entity and its components (to a certain level of details).

Because all nodes in Health Model may represent different type of components, they need different attributes to describe them. Looking at the example Health Model in the first part (Fig. 1), we may suppose that the appliance itself may need the following attributes: IP address, serial number, location, description, model and make, etc. A disk object would need an Id attribute, size, slot, manufacturer, attributes, etc.

These sets of attributes are called classes. So, a SCOM class is defined by its name and a list of attributes, which are called “properties”. In this terms it’s really close to a class definition in object oriented languages (but SCOM classes don’t have methods, only properties).

When we were defining classes for a storage appliance and a disk, they had nothing in common (i.e. no common or similar properties). This is simply because they are completely different beasts in the real world. But what if we need to create classes for similar, but yet different objects? For example we have different storage appliances from the same vendor, so they have some common properties, but then they got some specialization: they can be block, file, and object storages. Going ahead, that can be said, that most of monitoring will be common for these appliances, except specific aspects for their specializations. Luckily, likewise object oriented languages, SCOM has inheritance mechanism. When one class inherits from its parent class, it inherits all properties of the parent class, which also inherits all properties of its parent, etc. At the end, a class contains properties defined in the class itself and all recursively inherited properties:

The above SCOM class hierarchy example shows real classes from Windows Monitoring set of management packs. The most root object in SCOM (like ‘object’ in C#, for example). The “System.Entity” SCOM class is always defined and has one property called “DisplayName” of string data type (other data types are double, int, enum, etc.) After few children a “Microsoft.Windows.LogicalDisk” class is defined, which brings another property: VolumeName (also of string data type). And so on. Because all properties are inherited, the resultant properties for the “Microsoft.Windows.Server.2008.LogicalDisk” and “Microsoft.Windows.Server.10.0.LogicalDisk” classes will be the following:

NB! Health Model hierarchy is completely different from class inheritance hierarchy. They have nothing in common.

Summarizing, the SCOM class hierarchy principles are the following:

• SCOM defines classes. The root class is System.Entity.
• Each class has a name and a set properties. Properties are optional.
• Classes may inherit. Child class inherits all parent class properties and may add its own properties.
• Properties has data types.

Summarizing the example, we saw the following:

• The base System.Entity class defines “DisplayName” property.
• The Microsoft.Windows.LogicalDisk defines “VolumeName” property. 
• The Microsoft.Windows.Server.LogicalDisk defines specific properties like Size, Quota, File System Type, etc.
• The Microsoft.Windows.Server.{WindowsVersion}.LogicalDisk classes not defining any additional properties, but allow to distinct types.

In the next article, I’m going to describe another concept named in the first part: hosting relationship. This also has a connection to another concept mentioned (but never explained) in this article: key properties. Stay tuned!