MP Best Practice: Using the Seed Pattern for Easy Discovery
Discovery can be a difficult concept to implement easily. In this article, we discuss a solution that typically makes discovery much simpler by taking advantage of efficient discovery methods in Operations Manager while providing a discovery experience that is much more easily grasped by both users and MP authors.
When a management pack is imported into the system, that management pack gets pushed onto all agent-managed machines in an environment. Thus, when a discovery runs, it is running on every agent-managed machine to determine if this particular agent-managed machine has the components that determine that it is the object that is being looked for. Once it finds an instance of the object that it is looking for, the discovery will then populate any properties that are assigned to the class representing that object – these properties typically include things such as Name, ID, or version.
A lot of first-time MP authors build their discoveries such that a script is run that discovers if an object exists, and if so, will kick off any other discoveries (typically also scripts) that are targeted to that object, and populate the properties via script as well. While this pattern will work, there is the potential of an inherent problem in this situation. In this case, there will be at least one script running on every agent-managed machine in the system. Depending on the discovery interval, this script could be running quite frequently.
From a customer perspective, customers do not like having scripts running in their environment at intervals such as every 4 hours. Running scripts are highly performance-intensive actions that utilize a large amount of a computer’s resources. Furthermore, customers are highly suspicious of scripts that run on computers where they are obviously not necessary – for example, imagine being a customer an finding that the SQLDBdiscoveryscript.vbs runs on your agent-managed XP client machine every four hours! Customers tend to not trust management packs which initiate such processes.
To improve this customer experience while providing a significant performance benefit, use the seed pattern, which is described below. The seed pattern follows the fact that Operations Manager can do registry key checks very easily and efficiently, with minimal resource utilization. The idea behind the seed discovery concept is that running of scripts should be minimized, especially on wide targets, such as something like all Windows Computers.
Let us assume that you are building a management pack for ApplicationA, and one of your classes, Class1, represent the top-level physical class, which determines whether ApplicationA is installed on an agent-managed machine. If you are writing a discovery for Class1, in order to implement the seed discovery pattern, you will need to add an additional class to your management pack – let us call it Class1Seed. Inherit Class1Seed from a base class that will not provide too many side effects; something like Microsoft.Windows.LocalApplication is typically a good choice.
Now, you need to write the lightweight seed discovery for Class1Seed. For this, you need to determine a registry setting that specifies that an agent-managed machine is an instance of a computer running ApplicationA. Using the Authoring Console makes it easy to write a registry based discovery. Such a registry discovery would likely be targeted widely, at something such as all Windows Computers. Once this registry key discovery is run, it has discovered instances of Class1Seed, where each instance has a specific registry key setting that says that this computer has ApplicationA on it.
One the registry key seed discovery is done, you now have a set of instances that represents the subset of all agent-managed machines on which the classes representing ApplicationA and any of its components will need to be discovered. So the next step would be to write the actual discovery for Class1, which would create Class1 instances and populate all properties by writing the original script discovery that you had planned, except instead of targeting it at all Windows Computers, you would target it at Class1Seed. This automatically reduces the number of scripts running, improves performance impact on the overall system by not running scripts on all computers, and ensures that scripts are not unnecessarily running on computers where they are completely unnecessary.
Since Class1Seed is essentially a dummy class whose purpose is only to help with the discovery, make sure that it does not confuse the customer experience by being sure to not provide a view that shows instances of the seed class.
For a great example of the application of seed discoveries, take a look at the MP University – Track 1 content, particularly the Discovery session.