SCOMNIVORE at myITforum.com

Distributed Applications Custom MP

If you have begun to work with distributed applications, you have begun to work with one of the most impressive areas of Operations Manager. This is the facility that allows you to truly take the health model approach to the next level. Essentially, it is a graphical tool that allows you to model your infrastructure along service boundaries, as opposed to the physical boundaries to which we have always been accustomed.

Behind the scenes, Operations Manager creates many entities in the management pack to which you save your distributed application. These are classes, instances of those classes, relationships, monitors, etc.

I plan to blog about several facets of understanding and implementing distributed applications in the future, but one foundational element is an MP I have written that includes a new distributed application template that I think you will find useful.

It is a completely blank distributed application that will appear in the Template list when you create a new distributed application. It is very similar to the "Blank (Advanced)" template that ships with OpsMgr, but it is truly blank. It will appear as "Empty Distributed Application" in the template list.

There are two differences between my "Empty Distributed Application" template and the "Blank (Advanced)" template that ships with OpsMgr:

1. The "Blank (Advanced)" template includes a dependency monitor named "Blank Distributed Application Health Roll-up". This is a curious monitor for three reasons:
   1. It is a dependency monitor whose parent is Entity Health -> Availability but it makes a dependency link to the Entity Health aggregate monitor for everything in the DA. That's somewhat redundant.  Actually, I think it would be best described as "recursively redundant," since that gives you Entity Health -> Availability -> (this monitor) -> Entity Health -> Availability -> ...
   2. The logical function of this monitor is already performed by the "All Contained Objects" dependency monitor already under Availability (hence the redundant part of my comment).
   3. This monitor is disabled.
2. Along these same lines, my template adds a dependency monitor named "All Contained Objects" under Configuration, Performance, and Security, to match the one that is under Availability by default. These are enabled by default but can be easily overridden if desired. You may want certain DAs created from this template to be availability-only, etc., but I think the presence of the monitors will help.

The current version of the sealed MP is 24.1.1.1010.  The MP is available for download here:

com.focus24.Distributed.Applications1010.zip

VJD/<><

OpsMgr Lineage Explorer

Summary
As I've been researching management pack elements over the course of the past 18 months, one task that I find myself doing over and over again is researching the lineage of management pack elements.  With the inheritance and composite module features of the OpsMgr design, this can take you down quite a road.  I have long wanted to write a tool that makes this easier.  This is it.

What This Tool Does
This tool allows you to explore the lineage of OpsMgr MP elements.

Why This Tool Is Useful
OpsMgr is very object-oriented in its design.  As such, it includes inheritance for class types and relationship types.  Also, the workflow engine in OpsMgr is the driving force behind all discoveries, monitors, and rules.  All discoveries, monitors, and rules are based on modules that perform various functions.  All module types derive, eventually, from either managed code or native code.  One major difficulty in researching a new management pack you've loaded (or from which you intend to learn) is that module types can also be "composite" modules, which contain any number of other modules that are linked together to form a new module type.  Often, you will find a discovery that uses a data source module that is a composite of three or four modules.  Those three or four modules can themselves be composites of several modules.  Some management packs have modules that must be un-wrapped to four or five levels before you really understand the base modules that make up the actual work the workflow is doing.

This tool loads your OpsMgr environment from the database and then allows you to inspect the class types, relationship types, and module types installed.  It allows you to expand them to see their lineage (either their parentage for class types and relationship types or in the case of module types, their composition tree down to the underlying native or managed modules).

Future Directions
I am currently working to extend this viewer to include:

• MonitorType Lineage
• Discovery DataSource Lineage
• Discovery Target Lineage (useful for disabling the "root" discoveries for a management pack)
• Rule Lineage

I also plan to add more features around presenting the data:

• DisplayStrings.  Everything is an ID right now, which is the most important item for using what you see in your own MP.
• A view into the <Configuration/> block for modules.  This is easy to do at face value, but to make it intelligent, the schema really needs to be parsed so one can easily see how a composite module is using a member module.  This would also involve expanding the SchemaTypes involved.  Many times, this is a simple $Config$ reference, which just passes the problem up the chain; however, the implementation of many modules do not require the configuration of certain member modules to be specified.  Instead, they configure the member module directly.  This is often the case with the Expression Filter.  The bottom line is that a view into the <Configuration/> block will be introduced shortly, but it may or may not be introduced with some intelligence around parsing the schema.  At some point, however, that would be the desired end state for this part of the tool.
• I have a function that I have not completely implemented that will allow a module to be right-clicked and selected as the filter for the entire display.  This would be very useful, for example, in determining which modules eventually use a script, publish performance data, or generate alerts.  Most management packs are intuitive, but I've seen a few write actions in rules that bury the GenerateAlert module a few levels deep, which makes it difficult to flag them as alert-generating.
• Exception handling will improve as I get feedback and break the tool more myself.  I'm following the basic premise that I recently discussed with a friend and peer developer: I'm not catching exceptions unless I plan to do something useful with them.  This is a fairly innocuous tool at the moment, so I'm assuming that you'd like to see the stack trace as much as I do.  I'll spare everyone from the Spartan "Could not connect to database." message box for the time being.

Getting the Tool
The current build (227) is available for download here:

LineageExplorer227.zip

VJD/<><

"Plain Old" Host and Network Device Ping Monitor

One of the first monitoring situations you will undoubtedly encounter with OpsMgr 2007 is the "Failed to Ping Computer" alert.  This alert is generated after an Agent Watcher loses contact with a health service on a agent-managed computer.  It is an automatic check that is well-conceived, but isn't quite what you might expect by its name.  When you think of a "failed to ping" alert, you normally think of a ping monitor, running consistently against an IP, that fails to ping.

Similarly, the out-of-box monitoring for a network device is to pull a MIB-2 OID from the box as a connectivity check.  This is also not the common conception of network device availability or an equivalent to a network ping.

In both cases, it would be nice to have a "plain old ping."  For this reason, I've developed a management pack to provide this.  This management pack includes:

• A ping performance data source module designed for collecting response time (performance), with overrideable parameters for the number of packets to send and the size of each packet.
• A ping unit monitor type designed for determining whether the target is responding (availability), with overrideable parameters for the number of attempts that will be made to ping the device and the delay desired between attempts.
• A rule that targets the SNMP Network Device class with the aforementioned ping performance data source module, with write actions to the operational database and data warehouse.  This allows network device response time to be graphed, reported, etc.
• Two unit monitors that use the aforementioned ping unit monitor type.  One is targeted to the SNMP Network Device class and one is targeted to the Health Service Watcher class.  The proxy agent to which any given network device is assigned will run the monitor and therefore do the actual ping for that network device.  The agent watcher for any given health service should do the actual ping for that health service, but this seems to always be the RMS in my test environment.  Let me know what you experience.

When you override the parameters for either the performance rule or the availability monitors, be sure to take the overall time your options will take into consideration and increase the script timeout if required.  If you have retries and delays set such that the evaluation of the monitor could take more than 2 minutes, you must increase the script timeout above 120 seconds, for obvious reasons.  If the script always times out, you will never receive an alert.  Likewise with the performance monitor, where a timeout will prevent any performance data from being collected.

The current version of the sealed MP is 24.1.3.1016.  Our public key token is b77a5c561934e089.  It is available here:

com.focus24.PingMonitor1016.zip

VJD/<><

Welcome to my blog at myITforum.com!

My name is Vin DiPippo.  I am the principal technologist at FOCUS24, a professional services organization and Microsoft partner located in Rhode Island, USA.  We specialize in solutions that utilize Microsoft technologies.  Key specializations within Microsoft's product line are System Center Configuration Manager 2007 and Operations Manager 2007.

This blog will contain a mix of content that will be mirrored from my other blogs but will also contain content specific to myITforum.com.  I will do my best to avoid confusion, but unfortunately, there are several different audiences for which I will be writing:

• A technical audience for general topics, such as SQL Server, Windows Server Infrastructure, networking, security, etc.  This will be in a branded weblog available through our web site.  I'll promise great content, but content that will also be selected and presented to showcase the company's capabilities.
• A business audience for general topics, such as IT management, ITIL, patterns and process, etc.  This will be the second "personality" of the branded web log.  Ditto on the marketing slant.
• Communities content.  I'm concentrating on System Center first, because I have quite a bit of content I intend to share.  I currently have my first community blog, SCOMNIVORE, on WordPress (www.scomnivore.com, which points to scomnivore.wordpress.com currently).  Rod Trent has been very helpful in getting me set up on myITforum.com (i.e. here), which is looking so far like the best place to pitch the community content tent.  This will be commercial-free, of course.

For the System Center content, I will be starting with OpsMgr content.  I actually have quite a bit more SMS/ConfigMgr content because my company has been the principal responsible party for several SMS/ConfigMgr installations since SMS 2003 first hit the scene.  Many are large and most have taken us down roads that involve pushing the envelope with reporting, scripting, etc.

For OpsMgr, I believe the content is more valuable due to timing, which is why it gets first priority.  As the product matures, I believe that many of the features we are all providing through scripts, tricks and utilities will be absorbed into the product.  I am also confident that the documentation team will eventually have technical manuals to supplement the how-to guides now in publication or under development.  In the meantime, MPs, XML, Managed Code, scripts, and the results of hours of research into what OpsMgr 2007 looks and feels like under the covers are sorely needed.

As far as the name goes, I stumbled on the name "SCOMNIVORE" and like it.  I know the correct parlance is "OpsMgr," but since that's not even close to a word, nothing creative came to mind.  I suppose I could have come up with some acrostic, but the point of that is to only present some malformed generalization related to the letters that is never truly relevant.  Therefore, I chose to do something with SCOM.  SCOMNIVORE it is, then.

My sincere hope is that you find the information and resources on the blog useful.  Please comment vigorously regarding the contents of this blog, both present and future.

Enjoy...

VJD/<><