How Stuff Works

In reply to a comment I received, I wanted to put together a post about how things work in general, mostly with respect to the SDM as implemented in SCOM 2007.

For those of you familiar with MOM 2005, you'll know that things were very computer centric, which might make the 2007 concepts a bit foreign to you. In trying to bring SCOM closer to a service-oriented management product, the idea that the computer is central has somewhat been removed. I say somewhat, because much of the rest of the world of management has not moved entirely off the computer being of central importance, so we still have to honor that paradigm to make integration with other products easier. One example of this compromise is that on an Alert object you will see the properties NetbiosComputerName, NetbiosDomainName and PrincipalName; these are present for easier integration with ticketing systems that are still largely computer centric.

With this shift in thinking, we are able to model an enterprise to a much finer level of detail on any individual computer, as well as move above a single computer and aggregate services across machines in a single service-based representation. So what does this mean practically? For one, it means potentially a huge proliferation of discovered objects. Instead of just having a computer with a few roles discovered, we can go so far as to model each processor, each hard drive, every process, etc on every box as its own object. Now, instead of seeing a computer, you can actually see a more accurate representation of the things that are important to you in your enterprise. More importantly, however, is that this allows you to define each objects health separately from the health of the objects that depend on it and define how it's health affects the health of those things. For instance, just because one of the hard drives on a particular machine is full, doesn't necessarily mean the health of the machine is bad. Or maybe it it, and that can be modeled as well.

As was the case with MOM 2005, at its core SCOM 2007 is driven by management packs. Managements packs define the class hierarchy that enable this form of deep discovery and they define all the tools necessary to manage these objects.

Let's begin with discussing classes and the class hierarchy. We define a base class that all classes must derive from called System.Entity. Every class ever shipped in any management pack will derive at its core from this class. This class is abstract, meaning that there can never be an object discovered that is just a System.Entity and nothing else. We ship with an extensive abstract class hierarchy that we are still working on tweaking, but should allow for users to plug in their classes somewhere in the hierarchy that makes sense for them. You will be able to define your own abstract hierarchies as well as your own concrete classes. Concrete classes (i.e. non-abstract) are discoverable. Once you define a class as concrete, it's key properties (those that define the identity of an instance of that class) cannot be changed. For instance, if you want to specialize System.Computer, you can't define a new key property on it that would change it's identity, although you are free to add as many non-key properties as you like. In our system, the values of the key properties for a discovered instance are what uniquely identify that instance. In fact, the unique identifier (Guid) that is used internally to identity these instances is actually built off the key property values. Extending this computer example, if you do extend computer yourself, and someone else does as well, it is possible for a computer to be both of your classes at the same time, however, it will be identified as the same instance. You could imagine that Dell ships a management pack and some of your computers as both Dell Computers and Windows Computers, both of which would derive from the non-abstract Computer class that defines it's key properties. Thus an instance that is discovered as both would always we both in every context. The reason that the class of a discovered instance is important is that targeting of all workflows relies on this, but I'll talk more about this a bit later.

In addition to discovering individual instances, the system also allows you to define relationships between instances. The relationships also have a class hierarchy that works very similarly to the class hierarchy for individual instances. The most base class here is call System.Reference and all relationship types (classes) will derive from this. There are two abstract relationship types that are of great importance that I wanted to discuss here. First, there is System.Containment which derives directly from System.Reference. While reference defines a loose coupling of instances, Containment implies that the source object of the relationship in some way contains the target object. This is very important internally to use as containment is used to allow things to flow across a hierarchy. For instance, in the UI alert views that might look at a particular set of instances (say Computers) will also automatically include alerts for anything that is contained on that computer. So a computers alert view would show alerts for hard drives on that computer as well. This is something that is an option when making the direct SDK calls, but in the UI it is the method that is chosen. Even more important than this is the fact that security scopes flow across containment relationships. If a user is given access to a particular group, they are given access to everything contained in that group by the System.Containment relationship type (or any type that derives from it). An even more specialized version of containment that is also very important is System.Hosting. This indicates a hosting relationships exists between the source and target where the target's identity is dependant upon its host. For instance, a SQL Server is hosted by a computer, since it would not exist outside the context of that computer. Going back to what I said in the previous paragraph about using key properties of an instance to calculate the unique id of it, we actually also use the key properties of all its hosts to identify it as well. Taking the SQL Server as an example, I can have hundreds of Instance1 SQL Servers running in my enterprise. Are they all the same? Of course not, they are different based on the computer they are on. That's how we differentiate them. Even in the SDK, when you get MonitoringObjects back, the property values that are populated include not only the immediate properties of the instance, but also the key properties of the host(s).

All the examples I've mentioned thus far talk about drilling down on an individual computer, but we can also build up. I can define a service as being dependant on many components that span across physical boundaries. I can use the class hierarchy to create these new service types and extend the relationship type hierarchy to define the relationships between my service and its components.

Before we talk about how all these instances get discovered, let's talk about why being an instance of a particular type is important. SCOM actually uses the class information about a discovered instance to determine what should run on its behalf. Management pack objects, such as rules, tasks and monitors, are all authored with a specific class as their target. What this actually means is that the management pack wants the specified workflow to run for every instance of that class that is discovered. If I have a rule that monitors the transaction log for SQL, I want that rule deployed and executed on every machine that has a SQL server discovered. What our configuration service does is determine what rules need to be deployed where, based on the discovered instance space and on where those particular instance are managed (and really, if they are managed, although that is a discussion for another post). So another important attribute about instances, is where they are being managed; essentially every discovered instance is managed by some agent in your enterprise, and it's usually the agent on the machine where the instance was discovered. When the agent receives configuration from the configuration service, it instantiates all the workflows necessary for all the instances that it manages. This is when all the discovery rules, rules and monitors will start running. Tasks, Diagnostics and Recoveries are a bit different in that they run on demand, but when they are triggered, they will actually flow to the agent that manages the instance that workflow was launched against. Class targeting is important here as well, as Tasks, Diagnostics and Recoveries can only execute against instances of the class they are targeted to. It wouldn't make sense, for instance, to launch a "Restart Service" task against a hard drive.

Discovering instance and relationships is interesting. SCOM uses a "waterfall" approach to discovery. I will use SQL to illustrate. We'll begin by assuming we have a computer discovered. We create a discovery that discovers SQL servers and we'll target it the Computer. The system will then run this discovery rule on every Computer it knows about. When it runs on a computer that in fact has SQL installed, it will publish discovery data to our server and a new instance of SQL Server will be instantiated. Next, we have a rule targeted to SQL Server that discovers individual databases on the server, Once the configuration service gets notified of the new SQL instance, it will recalculate configuration and publish new configuration to the machine with the SQL server that includes this new discovery rule. This rule will then run and publish discovery information for the databases on the server. This allows deep discovery to occur without any user intervention, except for actually starting the waterfall. The first computer needs to be discovered, either by the discovery wizard, manual agent installation or programmatically via the SDK. For the latter, we support programmatic discovery of instances using the MCF portion of the SDK. Each connector is considered a discovery source and is able to submit discovery data on its behalf. When the connector goes away, all instances that were discovered solely by that connector also go away.

The last thing I wanted to talk about were Monitors. Monitors define the state of an instance. Monitors also come in a hierarchy to help better model the state of an instance. The base of the hierarchy is called System.Health.EntityState and it represents THE state of an instance. Whenever you see state in the UI, it is the state of this particular monitor for that instance, unless stated otherwise. This particular monitor is an AggregateMonitor that rolls up state for its child monitors. The roll up semantics for aggregates are BestOf, WorstOf and Percentage. At the end of a monitor hierarchy chain must exist either a UnitMonitor or a DependencyMonitor. A UnitMonitor defines some single state aspect of a particular instance. For example, it may be monitoring the value of a particular performance counter. The importance of this particular monitor to the overall state of the instance is expressed by the monitor hierarchy it is a part of. Dependency monitors allow the state of one instance to depend on the state of another. Essentially, a dependency monitor allows you to define the relationship that is important to the state of this instance and the particular monitor of the target instance of this relationship that should be considered. One cool thing about monitors, is that their definition is inherited based on the class hierarchy. So System.Health.EntityState is actually targeted to System.Entity and thus all instance automatically inherit this monitor and can roll up state to it. What this means practically is that if you want to specialize a class into a class of your own, you don't need to redefine the entire health model, you can simply augment it by deriving your class from the class you which to extend and adding your own monitors to your class. You can even simply add monitors to the existing health model by targeting them anywhere in the class hierarchy that makes sense for you particular monitor.

As always, let me know if there are any questions, anything you would like me to elaborate on or any ideas for future posts.

Comments

• Anonymous
  October 26, 2006
  Thanks for this post Jakub, This explains a lot of information in SCOM

1. The idea of the references/relationships is kool. It will be great if you could also provide an example with 2 newly created concrete classes and show their relationships. It would be really kool, if u could show a custom-defined relationship as well in the example.
2. Sorry if this is a real dumb question. After i discover new instances, will they be persistent? I mean, when i restart the SCOM server, do i need to re-discover my instances??
3. Is it possible to discover an instance from a monitor? For example, i 've a monitor to receive alarms, and when the alarm comes, can i create a new object and assign the alarm to that object?
4. It will be also great if u could explain a bit on how do i receive SNMP traps in SCOM. In my test environment i can receive SNMP traps upto WMI already. Then i 've created a new monitor from SCOM, which uses "SNMPTrap Provider". But still i could n't receive anything in SCOM. ( Or is it bcoz i 've been using beta2 ? )   Is it possible to do "Notification Queries" in <DataSource>, If you could give me an example on that, tht will be helpful also.
5. What is the difference between "Attributes" in the atuhoring console and class definitions? How to define those attributes?
6. Sorry i may be a bit confused about this. What is the difference between "Rule" and "Monitor", and where to apply "Rule" and where to apply "Monitor"?
7. Is it possible to customise the "Overview" Screen. For example I want to display the "Distributed Applications" as "Services"

• Anonymous
  October 30, 2006
  Sorry for the delay, I was out on vacation on Friday.

1. I will work on putting together a sample that uses the SDK to insert some instances after creating some classes and relationships in a management pack.
2. Yes, it will persist as long as your discovery source (read: your connector) is in the system.
3. I am not sure what you are trying to accomplish here, but the short (and most likely correct) answer is no.
4. I don't know too much about WMI or SNMP. Perhaps someone on the newgroups can help with these questions?
5. Classes contain attributes. For instance, a Computer class would have an attribute, IPAddress.
6. Rules don't produce state changes, while monitors do. Monitors are also organized into hierarchies, while rules are not. Rules and monitors are both made of modules, but monitors are further specialized through monitor types, while rules are made up of modules directly (take a look at the sample MP I've posted earlier).
7. Not that I am aware of.

• Anonymous
  October 30, 2006
  The comment has been removed

• Anonymous
  November 01, 2006
  How is your computer managing the device but unable to discovery it? There should be various way to accomplish what you want while fully modeling the network device. If you really can't discover it until something goes wrong with it, you can have a rule listening for how you would detect this error condition, and this rule could potentially insert discovery data, if none already exists, prior to inserting the alert. Rules and monitors are executed in parallel, they are not related to each other in any way, really, and serve different purposes. At their core, they are defined similarily and modules for each are executed in the order specified in the definition. Rules can do all sorts of things, like insert events, performance data trigger alerts based on various data sources, etc. Monitors can use all the same data sources, but at the end of their workflow will only produce state change information. Sealing an MP should be done with the tool you are using. What error are you getting?

• Anonymous
  November 01, 2006
  Thanks Jakub, for keeping patience with me in explaining the Rules and Monitors :-) . Now it is more clear to me. Regarding the weird network device case... Before i explain a bit further, the reason i was asking this is , i'm also planning to use the SCOM in the telco environment. Where the network is completely different and filled with all sort of protocols. But amazingly SCOM comes with a very generic engine :-D , that could really fit in-to this type of network. Ofcourse i 've to do a lot of tweaks to fit into this. So as i 've explained in my post, i will not understand the language what the weird network device and the computer which manages it are talking. But the computer which manages it will translate for me, certain things and tht will help me to do the discovery of those network devices. But unfortuantly, mostly the computer can translate it only when the problem happens. This is kool that i could have such rules in SCOM. It will be really great if you could post some example of such <Rule> tags. I was trying to seal an MP and it was asking me for some key and some .snk file. Unfortunately I'm not sure how to generate such a .snk file.

• Anonymous
  November 02, 2006
  That is the key file that you need. I am not entirely sure how to generate these. I am sure if you do a quick search on snk, or .Net key files, you will find what you need. Regarding your other issue, can you send me and email via the site and I will get you in touch with some folks that can help?

• Anonymous
  November 02, 2006
  Alrite, managed to solve the key generation already. I got a how-to help from the msdn website that help me to do that. The command is "sn -k <outfile>". What is your email address (my email address sureshquest@hotmail.com) , so that i can send you some details on that? BTW, Just FYI, we are also working with Microsoft-Malaysia on some of the SCOM implementations. They did help me to get in touch with some of the people. But i found that ur blog helped me more to understand the SCOM :-D.

• Anonymous
  November 02, 2006
  You should just be able to hit "Email" from the right-hand side of the page. Please send me a more detailed description of what you would like to do and I can either help or point you in the right direction.

• Anonymous
  November 05, 2006
  After download the new RC1, i was trying to install it on my server. But i could not get to install the SCOM-Reporting, the setup fails with the error saying "Setup was unable to validate the SQL Reporting Services". But my reporting services are running fine, when i see from the configuration tool and also from the Reports webpage. Any suggestions here? Am i missing something?

• Anonymous
  November 06, 2006
  Please post your question to the beta newsgroups and someone from the reporting team will be able to help you out.

• Anonymous
  November 16, 2006
  The MPSeal command i had from beta2 does not work anymore :(. The RC1 does not have the MPSeal command :(. And SCOM does not allow me to reference another MP unless it is sealed. Is there a way i can get the MPSeal.exe for RC1??

• Anonymous
  November 16, 2006
  Sorry i was too quick to post the previous comment. I found the MPSeal from the supportTools folder. Just panic, when i run the older version of the MPSeal and it show me the debug prompt :-D

• Anonymous
  March 13, 2007
  How can you isolate the state changes for monitors to be contained in a mangement pack. Example, I have a group of machines that have software installed on them, I would like to group them based on software that is installed. When software is missing that object in that group changes state, not all objects that are in the other groups that are 'rooted' to the same object change state. I hope that was somewhat clear : )

• Anonymous
  March 14, 2007
  Sorry, I am not exactly sure what you are asking. Can you elaborate on the problem as exists today and how you want the behavior to be different?

• Anonymous
  June 05, 2008
  In reply to a comment I received, I wanted to put together a post about how things work in general, mostly with respect to the SDM as implemented in SCOM 2007. For those of you familiar with MOM 2005, you'll know that things were very computer centric