Creating Discoveries – Which is the right method for you?

Creating Discoveries – Which is the right method for you?

How to understand which discovery is best for your monitoring

Purpose of article

When it comes to any form of structure for developing a monitoring strategy, whether that decision is based on a management pack build or not, everyone has different methods and different ways in which we want to achieve a certain goal.

What we want to do here is basically to not only just analyse the methods of discoveries which we have available but also help to understand which one is better suited for us.

Anyone of them will help us achieve discovering the correct class instance information, but we want to tailor it to the best fitted method.

Types of methods

If we look at this primarily at a technology based level of discovering these are the ones & also most commonly used when it comes to the initial discovery of any class objec

• PowerShell
• VB Script
• WMI
• Registry

But let’s dive a little bit more in each of them so we have a better understanding of how they perform and how we see them best suited depending on the scenario and what you are trying to achieve with your monitoring.

Discovery Method – PowerShell

Reasons to use

The most common reason why we all go with PowerShell is for one reason only – we can shape the criteria to be absolutely anything! The absolute greatest advantage of them all really.

This method really has the ability to adapt not only just to whatever we specify, but if we look at methods such as Registry, WMI, VBScript etc we can add these exact same elements into our PowerShell code. It’s also my preferred method as well whilst writing this but I’m ensuring that I remain as unbiased as possible.

But overall it can exceed over the limitations which other methods do have, and the freedom of exploration with how we structure the discovery code is endless.

Reasons not to use

Though it can do everything as stated, there are disadvantages of this method in a certain sense. See its strength can also be its drawback where you can develop the code to be anything. There’s two points to this which we will drill into by breaking this down into bulletpoints.

• Is it Too Much for a simple discovery – The benefits of other methods (Registry & WMI mainly) is that they are very specific and locked to what they have to discover. So they are more straight forward in having one purpose. Where on the other hand a PowerShell discovery method can provide too much freedom.
  
  We could end up making the discovery criteria a lot more complicated than it needs to be and we can even get into a habit of reinventing the wheel where it overlaps with what other methods can already do. So it really comes down to using the PowerShell Discovery method when you are actually required or at least need to do it. For example, say we want to find a certain registry key on all machines to define it belongs to a certain class, this can be done with just a registry key.
  
  You can use PowerShell for this too, but to re-invent the entire process to add in “Get-ItemProperty” lines in, and essentially face possible access denied issues and even dare say having to create the registry key you want to discover in the first place, it defeats the object or in this case abuses the power of this method. So I would advise to use the PowerShell method when there is no other simpler way.

• Too Much Code – Slightly the same point as made above, but more specifically on the code itself. Depending on how we write PowerShell code we could end up making it too complicated or time consuming where the discoveries run into issues for either timeouts, config churn blockages and more.
  
  When using PowerShell discovery method its always advised to keep things “simple” where you can.

Discovery Method – VBScript

Reasons to use

Very similar to the PowerShell method, however VBscript is more of a legacy & backward compatibility type of code where if we were utilising it to monitor more legacy based machines where PowerShell or any other means aren’t possible, then the VB Script method is a great one to fall back on.

Reasons not to use

Because of the fact its such a legacy and backward compatible type of code, the biggest drawback is of course going to be met by more updated machines as SDKs utilising PowerShell will have more features and more capability to where the VBScript method may not be able to reach. And if it can reach it then you are looking at more code to make up for some of the simplistic commands that PowerShell may already have on board for certain Server OS’es.

If you take a look at some of the management packs which you get with SCOM especially around the Windows Server Operating System MPs, you can see that vbscripts are used quite a lot and also within its monitoring objects. These are most likely used to accommodate the legacy OS MPs and classes which apply to lower versions of Server OS’es which can adapt to most platforms.

Using the VB Script method where necessary is also great practice, or utilising a more simplified method such as a Registry or WMI method is also great too.

Discovery Method – Registry

Reasons to use

With the exception of the PowerShell based discovery, the Registry method is indeed the most common to use. Not only just in MP authoring tools such as Visual Studios, but also in the SCOM Console in the authoring tab too when it comes to building any kind of attributes for your management pack.

The registry is great as its designed for one purpose to pick up the registry keys that you desire and is a more locked down method where you don’t have to enhance or restructure anything it simply does the job.

Reasons not to use

It’s not easy to list disadvantages to this method because of how robust it is. But if I had to perhaps pick what I would call the closest to a disadvantage it would maybe be the fact that this method has two parts to it to formulate the whole discovery.

So firstly there is the Discovery part which I will explain. So when creating a Registry method you need to first set what would be used to actually say “This computer is part of this class” which normally follows a “Key Exists” rule. You would specify a registry key to look for and this would be the primary key it would look for to determine of a SCOM managed machine would belong to this class and to the management pack.

Now that’s first part. The second part is then the Discovery Attributes part. See once we’ve set the rule of whether the certain key exists, we then need to map/locate where each class attribute will obtain its value from within the registry.

Let’s say I have a class called “Test Class” (I actually do 🙂 ) and I have properties called “Name” and “version”. I would have to specify which registry key value contains the information for each property as these properties are the attributes for my “Test Class”. When a discovery is fully successful, the Discovery part is what lists the machine into the SCOM Management Pack view in the SCOM console, but the information of its attributes will only show in the console once the registry key values have also been discovered.

It’s perhaps more to preference where some prefer to just use PowerShell to avoid having to do all of this.

Discovery Method – WMI

Reasons to use

This method again similar to the registry method has a very specific targeted use to run against WMI classes. Great for when wanting to target just WMI classes and produce a query which will obtain all of the information for your discovery attributes.

Another great point about this method is that unlike the registry method you really only have to specify one thing which is a WMI query which will detect all the attributes as well as noting that the managed machine also belongs to that class, as opposed to the two parts which the registry method has.

Reasons not to use

You tend to find that other discoveries get used to go around this method out of convenience. The WMI method is not always the most used out of all of the ones listed, perhaps due to that in most cases WMI classes aren’t always the go to source for information or at least the first source to go to. When creating bespoke monitoring its not always known for WMI classes being part of a bespoke application, but it may very well be as well as applications or technologies which may not already have an available WMI Class at hand.

Using M-Pack Creator to Create Discoveries

With everything laid out and listing its reasons to use and not to use certain discovery methods, this is where the ProtectOrg M-Pack creator comes in.

Where we list the inconveniences of some of the choices, the M-Pack creators goal is to simplify the creation of all methods and to make the process of creating management packs (especially discoveries) a less daunting task all round.

If we look at Figure 1.1 this is the Discovery Designer Page of the M-Pack creator tool which allows you to create every single method which we had listed earlier, as well as a few others which are perhaps more optional to some.

So when we spoke of the registry method for example being a two part process, our tool simplifies this by having a straight forward way of mapping the class properties to the correct registry values as seen in Figure 1.2

We have a very similar process to the WMI method as well as noted in Figure 1.3

For PowerShell & VBScript methods, there is a special intelligent feature we have but we will reveal this in the upcoming video demonstrations of this solution.

Check our YouTube channel to see the demonstrations on how to create all of these discovery methods. M-Pack Creator will be available to buy and download from our site very soon. Register your interest by using the contact form on our website to be informed of release date. Make sure you subscribe to our social channels to keep up to date.