SCOMNIVORE at myITforum.com

Build 316 of Lineage Explorer

I've had some time to get a new build of the Lineage Explorer out.  Build 316 is the latest.

If you aren't already familiar with this tool, check out the original post: OpsMgr Lineage Explorer.

Build 316 adds the following functionality:

1.  There's a new status bar that will show the load progress for the OpsMgr environment.  This is useful for environments with a large number of management packs.  This also doubles as an indication of which MP element type is currently populating the tree view.

2. Data Types are now processed, so you can explore their lineage as well.  Also, Class Types are selected for display first.  Build 227 selected Module Types by default.  Finally, there's a Filter by Example feature, though you can only turn it off using the View menu.  More on that later.

3. I've added a property grid for all MP element types, and gone a little further into which properties are included.  Build 227 only showed a few properties of module types only.

4. There is a Filter by Example feature that allows you to right-click on any node in the tree view and select it to be the filter (by example).  The two options are Any and Direct.  "Any" will filter the tree view, including only those MP Elements that have the element you selected anywhere in their lineage.  "Direct" includes only those MP Elements that are direct descendants of the element you select.

Here's another screen shot of what the tree view looks like after selecting "Filter by Example (Any)" on System.CommandExecuter.  Note that the View menu now shows the Filter by Example with a check mark.  This is to allow you to turn it off.  Also note that if I had selected "Filter by Example (Direct)," all of the elements in this screens shot would not have been visible because they are descendants of descendants of System.CommandExecuter, not direct descendants of System.CommandExecuter.  If this screen shot included Microsoft.Windows.ScriptWriteAction, you would have seen that it would have been included.  It would also be included if "Filter by Example (Direct)" had been selected, because it is a direct descendant of System.CommandExecuter.

There are more improvements in the works.  Most notable is the ability to view the lineage of monitor types.  This one is a little trickier, because each of the regular detections has its own lineage.  That makes it a single MP Element type with multiple lineages.

After that, it will have complete coverage of the <TypeDefinitions> section.  Then, it's on to the <Monitoring> section to allow the lineage of the components of monitoring MP Elements to be displayed.  This functionality will be similar to the monitor type handling: an MP Element with multiple lineages.

The other to-dos from the original post are still on the list.

Version 316 can be downloaded here: LineageExplorer316.zip.

Thanks for the feedback thus far.  Keep it coming!

VJD/<><

OpsMgr Scripting: WYWINNWYG

"What You Write Is Not Necessarily What You Get"

Abstract

OpsMgr 2007 has a fairly substantial library of discovery module types and monitor types that ship with it.  Even with that library, it seems that the single most important extensibility point in OpsMgr today is the ability to use custom scripts to perform discovery and monitoring tasks.  As I've developed scripts for OpsMgr, I have learned a great deal about how OpsMgr processes scripts.  This article describes some important concepts regarding how scripts are processed by OpsMgr.

Besides the Execution Environment...

There is an important distinction between the execution environment of a script and the production of the script itself.

The execution environment is fairly straight-forward: VBScript or JScript that runs through the script processor.  In fact, if you trace back the various script modules, you will find that they all derive from a handful of native modules, all of which essentially execute cscript.exe.  All of the capabilities of that scripting engine and the facilities it can access are at your disposal (ADSI, WMI, ADO, the remainder of what's in COM, etc.)  We also use a COM object in our OpsMgr scripts that is on every system that has the OpsMgr Agent installed, namely "MOM.ScriptAPI".  This essentially provides functionality to generate well-formed XML DataItems with the appropriate format, attributes, etc.  We'll see that later.  While that's a simplification of what "MOM.ScriptAPI" does, the point is that it is not part of some custom script execution environment that runs in-process with OpsMgr.  It is just another COM object that the usual cscript.exe environment instantiates at our request.

The production of the script is quite a bit more interesting, so I'll spend the majority of this article addressing it.

Sample 1: Expansion of Embedded Selectors

First, let's define a simple script, which we'll put inside a two-state script unit monitor.  This script targets Microsoft.Windows.NTService.  I've also created two service classes from the MP templates in OpsMgr, one for Browser and one for SNMP.  This virtually guarantees that OpsMgr will discover at least one on any given system.  My test system has both.

Figure 1: The script itself.  (FYI - The $...$ selector that is not entirely in view is "$Target/Host/Property[Type="System!System.Entity"]/DisplayName$")

Figures 2a and 2b: The unhealthy and health expressions.  These are somewhat unrelated to the topic of this article, but I thought I'd add this for general purposes.  It is useful to see this and to note that any time you see wizard pages that resemble these, you are using the UI to express the configuration of the System.ExpressionFilter condition detection module.  In this case, I've defined a monitor that always returns healthy, regardless of what the script does.  You can experiment with this further, but keep in mind that you can specify just about anything for either side of each expression (i.e. row on the wizard page), including the entire gamut of $...$ selectors.  ...end aside...

Returning to the main topic, anyone that is a script developer has a particular paradigm in mind.  The script is written and runs as written.  If you've ever seen constructions that use the $...$ selectors inline (e.g. SomeVar = "$MPElement...$"), you might have assumed that there was something special about the script execution environment that somehow resolves those.  The reality is that those resolutions are done before the script is ever executed.  Therefore, we have a very tricky paradigm on our hands: the execution environment is completely standard, but the script body itself is "refined" by OpsMgr before it is embodied in an actual file and run.

Let's investigate this.  Our example script does nothing of interest except return a static property bag.  That will be somewhat useful later, but for now, the really interesting part is not what the script does, but what the script becomes.

To find the actual file that is eventually run, we need to get to the Health Service State directory and find our script.  We will actually find two versions of the script, because it is generated once for each target against which the script will run (in this case, Browser and SNMP).

Figure 3a: Finding the script location.

Figure 3b: What's finally in the first instance.

Figure 3c: What's finally in the second instance.

As you can see from the figures, everything that relates to the execution context of the script is not present in the execution environment per se, but baked into the script itself as it is readied to run.  This includes information about the target, the MPElement on whose behalf the script is being invoked, any MPElement we may need (which I grant you is usually only required for discovery scripts), and information about the target's host (which is also information from the $Target...$ selector family).

It is useful to understand this mechanism for two reasons:

1. You do not need to put everything into the arguments of the script that may seem necessary.  The script will be customized per target.  This opens up a wide array of information that can be used in the script without worrying about the command line formatting.
2. It is contrary to our normal thought process for scripting.  Understanding it provides a better picture of how your script will be invoked and it also reveals how these OpsMgr-specialty-laden scripts can be debugged.

In a practice, I always include a comment line at the beginning of my scripts that includes the first four items in our sample script: the basic identification of the Target and MPElement.  I find that to be extremely useful in tracking down script errors.

Sample 2: More Embedded Selectors: From <Configuration>, Including Overrides

Continuing our example, let's set some overrides that will make the two instances unique with respect to their configuration as well as their target.

Figure 4a: Overrides targeted to the specific service object Browser (on the test system).

Figure 4b: Overrides targeted to the specific service object SNMP (on the test system).

I also did two other things:

1. I added a few additional lines to the script

   ' Some Config Values
   '   Arguments: $Config/Arguments$
   '   Interval Seconds: $Config/IntervalSeconds$
   ' A service-specific property:
   '   $Target/Property[Type="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/ServiceProcessName$

2. I created another monitor that is almost identical to the first one.  The script itself is actually identical, but this second monitor defines the script in a UnitMonitorType and uses that custom UnitMonitorType in the UnitMonitor.  By default, script monitors created by the UI use a built-in UnitMonitorType, which means that the script body itself is defined in the UnitMonitor.  There is a subtle difference that we will discuss shortly.

Once the new configuration becomes active, we follow the same pattern to find our scripts and see what's in them.

Figure 5a: Finding the script location.  There will be four now: the original and the UnitMonitorType variant (UMT) for both instances.

Figure 5b and 5c: The contents of the two updated but UI-defined scripts.

Note that the additional property of the target came through fine, but the $Config$ selectors were unchanged.  This means that using a UI-defined script, the $Config$ selectors are not expanded.  This applies to both the "natural" configuration items and any overrides.

What's going on here?  Let's check out UMT version.

Figure 5d and 5e: The contents of the two updated, UMT-defined scripts.

Now, that's what we're looking for.  I must admit that while I have a reasonable explanation for this, I cannot give you a definitive answer.  I'll leave that for a developer that knows the exact inner workings of OpsMgr, but it appears that the $Config$ selectors are only expanded when module and monitor types are assembled for use in a workflow.  Think of it this way: when something defined in the <TypeDefinitions> section of an MP is assembled to be used in the <Monitoring> section of an MP, $Config$ selectors are expanded.  The UI-defined monitor defines the script body in the <Monitoring> section.  It uses a built-in module that itself defines the script body as whatever is in the <Configuration> of the actual monitor $MPElement$, which is defined in the <Monitoring> section.  Therefore, our UI-defined script body is never really subjected to assembly in that way.  The UMT version, with the script defined in the UMT (under <TypeDefinitions>) is assembled for use in the corresponding monitor, so we see the expansion for it.  Both are then assembled for use against the various targets that exist, which is why everything else expands in either case.

Important Notes About Expansion

There are a few additional important notes on this expansion business:

1. You must use a script argument for anything that changes between invocations of the script.  The script is created only when a new configuration becomes active.  That only happens when management packs change.  There's a myriad of things that cause a configuration change, such as group membership rules, new monitors, new subscriptions, overrides, etc., but there are an equally large number of changes to the environment that do not cause a configuration change.  Some of these include group membership updates that are the result of a dynamic rule, target property changes that are the result of discovery runs, etc.  Suffice it to say that a script can run a multitude of times under the same configuration.  This is particularly important for:
1. $Data$ selectors.  There's no way to expand a $Data$ selector when the script instance is created.  These are pulled from the contents of the <DataItem> that is passed into the module executing the script and are therefore only available as script arguments.  If you've never seen these, they're pretty useful.  For any timed script,  my favorite is $Data/@time$.  You can pass that as an argument to have the trigger time of the monitor at your disposal, in the appropriate OpsMgr <DataItem> attribute format.
2. $Target$ selectors.  We saw that these work wonderfully as embedded selectors, but you must be careful with them.  They are expanded when the script is created, which is when a new configuration becomes active.  Some $Target$ properties might change between the time the script is created from the then-active configuration and something happens that causes a new configuration to become active (and hence the script to be re-created).  If there's a $Target$ property that can afford to be a little stale, you can embed it.  If not, pass it as an argument.
3. $MPElement$ selectors are all tied to the configuration, so they're safe.  When they change, the configuration is changing, so the script will be re-created anyway.
2. I have encountered some quirks, so don't think you're losing your mind if you see strange things in your script.  I suspect that some combinations of selectors embedded in scripts are not expanded properly, but I have been thus far unable to reliably reproduce the problem.  It definitely happens, so be on the lookout.
3. The MP alias used in the selectors must be appropriate to the MP in which the monitor is being created.  If you are creating an MP yourself, that's easy to keep straight.  If not, you may not be able to predict the alias.  System.Library, for instance, is sometimes referenced as System! and sometimes as SystemLibrary<Version>!, where <Version> is whatever version of that MP was installed when the reference was made.  An easy way to determine this is to add something as an argument using the UI.  It will use the correct alias, and you can just copy it from there.

Debugging the Expanded Script

The final item that is relevant is how this can help debugging.  This goes back to the execution environment discussion I started with.  When the MOM.ScriptAPI COM object is used to submit property bags, performance data, discovery data, etc., it does so using STDOUT.  That's it.  Therefore, running your script from the location in which it was created (under Health Service State) works just fine.  It just prints the XML representation of the data item that would be picked up by OpsMgr if the script had been run inside its workflow.

Figure 6: A property bag output to STDOUT after an interactive run of the script.

Conclusion

I hope you find this information useful.  I believe it is very helpful to understand the machinations that a script undergoes well before it even hits its execution environment.  It's also useful to have so many more data from the context of the OpsMgr configuration, target, etc. available to use.  It makes scripting that much more robust, which is a major component of OpsMgr's appeal.

New Series on Workflow Tracer Module

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.

VJD/<><

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/<><