Seed Based Discovery Concepts

Article
02/25/2011

Seed based discovery is a reasonably common concept that is used in many Microsoft MPs. There are a few articles out there such as this detailed one by Dan Rogers. However I was trying to explain this to someone in my team recently and realized it was not that clear exactly why and when to use it. I wanted to make sure I had a worked example to really illustrate this concept. There is also an alternative approach to consider instead of a seed but it does have issues so I wanted to walk through this topic in detail and show you why you might not want to use it. If you don’t get to the end of this article, the bottom line is that you should go with the first approach (the seed method) when using scripts for discovery.

Let’s start by looking at a standard discovery with no seed concept. Let’s say you have an application running on Windows and you want to define a class for the application and discover it. Let’s assume that this runs on any version of Windows Server. You would define your class something like the following:

Now if you want to discover this using a simple registry based discovery you might create a discovery targeted at Windows Server

This all seems reasonable so far. What will happen in this case when this MP is imported into your management group is that the MP will be sent to every computer that has an instance of the Windows Server class discovered i.e. it will go to every Windows Server you have. Then the discovery workflow will be loaded and run on each server. This discovery will stay loaded and keep running on whatever interval you set in your registry discovery even if the application is not found. This is done because the application could be installed at any point and then you want SCOM to pick it up. In this example you would end up with a single instance of the class hosted on servers that had the application installed as below:

For a registry based discovery this is not a major concern. SCOM is very efficient at running these discoveries and they are usually not schedule to run more than every few hours so it is very little overhead to the server it runs on.

However, the problem comes when you need more than a registry based discovery to discover the application fully. It may be that you need a complex script to discover the application including the properties you need and any components. In this situation you need to be careful especially if you are building MPs to ship to customers. You want to minimize the execution of scripts on servers where possible and running a full blow discovery script on a scheduled interval is likely overhead you can avoid. This is where the seed concept comes in.

The seed concept involves introducing a second class that acts as the primary discovery. This will not result in the full discovery of the application and is only there to trigger a second stage discovery that will do the real discovery. For example we may introduce a seed class as below:

Now I build my first discovery to identify that the application is present on the system with a simple registry based discovery. This is my seed discovery and is targeted at Windows Server in this example:

If this seed was discovered it indicates my application is there. However I am not ready to start monitoring yet. I need to discover the application fully and I need a complex script to do this. So I now add a second discovery that is targeted at the seed class. This will only run once I have validated the application is present.

This discovery will do whatever complex scripting it needs to do to discover one or more instances for the application. From here on things are normal. So the flow is:

All your actual monitoring should be targeted at the real class not the seed class. This monitoring will only start working after the second discovery has run and discovered the instance with any properties that are required.

The artifact of this process is an additional class and an instance of that class on every server the application is discovered on. This is not a major problem but there are a few things you can do to ensure customers are not confused by this:

Ensure the word seed is in the display name for this class
In the class description explain what it is used for and indicate no monitoring should be targeted at the class
Do not ship a view that shows state, alert etc. about this class
In your MP guide if you have one make sure you detail this class and how it is used

If the application is uninstalled, the behavior of removing instances depends on which discovery runs first after uninstall:

If the seed runs first, it will submit an empty snapshot for the seed class and this instance is deleted. However because the real instance has this seed instance as a source, SCOM will also remove it at the same time since its discovery source no longer exists. Both instances in the example above are removed effectively at the same time
If the second discovery runs first then this will submit an empty discovery for the real class and this instance will be removed. The seed instance still exists and this will only be removed on the next schedule of the seed discovery so it is a two stage process

You could definitely consider the seed based discovery for scripts but you might want to consider for WMI based discoveries as well if the WMI queries you are using are complex and may return many objects. If you absolutely cannot avoid using a script as there is no reliable way of detecting the application through the registry you should write your script that it exits at the earliest opportunity once it determines the application is not installed.

There is one alternative approach that sometimes people consider. You could have a single class that is partially discovered by multiple discoveries:

Discovery 1 is really the seed discovery and discovers existence of the application but does not populate all properties
Discovery 2 runs a script and discovers all the missing properties and any other classes it needs to for the application

This is illustrated below. In this example Application X has 4 properties. Two are discovered by the base discovery which is a registry discovery. Two are discovered by the full discovery which runs after the instance is created.

This would be built with a single class:

The first discovery targets Windows Server:

The second discovery targets the Application X class and discovers the additional properties:

In theory this works OK but there are some problems:

Monitoring may start to run before the second discovery completes. If this monitoring uses properties P3 and P4 in this example it will fail since these are not discovered yet.
If the second discovery fails for some reason which is more likely in a script that a simple registry discovery, you are in a half discovered state and again monitoring may fail as above
There is some caching behavior that can cause a transient issue:
- Application Y is discovered by the seed and P1, P2 are populated
- Second discovery runs and P3, P4 are discovered
- Now Application Y is uninstalled and the object is removed as expected
- Application Y is reinstalled
- Application Y is discovered by the seed and P1, P2 are populated again
- P3 and P4 are set to the previous value discovered in the last run. These will be correctly discovered in the next run of the full discovery but you can end up with a transient issue here

The caching problem above is due to the fact there was valid data still available for the second discovery. As soon as the instance came back this data was still there and will remain till a new discovery runs. If you want to see this happening for yourself in the sample MP follow these steps:

The Application Y full discovery adds a property to the instance of the number of sub folders on the C:\ folder.
Get it discovered by adding the appropriate registry key – check the count gets added
Now rename the registry key so App Y gets undiscovered.
Add a folder to C:\
Disable the full discovery to make sure it does not run again (leave the seed enable)
Rename the registry key back to App Y gets discovered
Observe that the old value initially for the directory count appears even though the discovery was disabled
Enable the discovery again
You should see the new value added
If you can’t see this try disabling the second discovery before you rename the registry key back so it never runs again and you will see we have kept the old data of the property values.

I have attached an MP showing both concepts. Application X shows the seed concept and Application Y shows the multiple discovery concept not using a seed:

For Application X discovery, add a registry key HKLM\Software\AuthorMPs\ApplicationX and a string value HKLM\Software\AuthorMps\ApplicationX\Version and set it to something.
For Application Y discovery, add a registry key HKLM\Software\AuthorMPs\ApplicationY and a string value HKLM\Software\AuthorMps\ApplicationY\Version and set it to something.

So bottom line, while the second method reduces the number of classes and means there are no seed instances, in practice it is much preferable to use the first method for your discovery when you are using scripts to avoid transient issues.

AuthorMPs.Demo.SeedDiscovery.xml

Seed Based Discovery Concepts

Additional resources