Mirror at myITforum.com

June 20, 2008

Thanks to Rod Trent at myITforum.com, I’ll be mirroring this content on myITforum.com.

Check it out here: http://myitforum.com/cs2/blogs/vdipippo/default.aspx




New Series on Workflow Tracer Module

June 20, 2008

I’ve written a new series on the Workflow Tracer module that I developed to help trace the contents of DataItems moving through workflows.

The series starts here.  I’m keeping this one on WordPress only at this point because it has several links that thread together the four parts, plus diagrams.

Remember that this is a 4-part series with two distinct takeaways:

  1. It starts with a reasonably thorough treatment of workflows, modules, and data items.
  2. The fourth part presents a managed code module that I think anyone interested in a deep dive into workflows will like.


Distributed Applications Custom MP

June 20, 2008

If you have begin 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  Our public key token is b77a5c561934e089, though I don’t think you’ll need it for this MP; it’s probably not one you’ll re-use (no modules, etc.).

The MP is available for download here:



OpsMgr Lineage Explorer

June 20, 2008

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:



“Plain Old” Host and Network Device Ping Monitor

June 15, 2008

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  Our public key token is b77a5c561934e089.  It is available here:




Welcome to SCOMNIVORE…

June 4, 2008

Welcome to SCOMNIVORE, a blog about Microsoft’s System Center Operations Manager 2007.  My name is Vin DiPippo.  Through this blog, I will be sharing the body of work we have done with OpsMgr at my company, FOCUS24.

FOCUS24 is a professional services organization and a Microsoft partner.  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.

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.