Wednesday, March 29, 2017

MP Authoring – Quick & Dirty – 01 – Overview


Advice to the reader
This posting is part of a series of articles. In order to get a full grasp of it, I strongly advise you to start at the beginning of it. 

Other postings in the same series:
00 – Introduction
02 – Authoring the Template MP XML Code
03 - Example Using The Template MP XML Code
04 - Testing The Example MP
05 – Q&A


Overview of how SCOM works
In order to understand what I am trying to achieve with this new series, some basic understanding of SCOM is required. I’ll do my best to give a KISS explanation. After that I’ll talk about the Quick & Dirty MP approach.

Targeting & Classes
First of all, TARGETING in SCOM is key. Without targeting SCOM workloads (Discoveries, Rules, Monitors, Tasks and so on) would run everywhere, causing a lot of mayhem.

As such Classes are made, and their related Objects are ‘picked up’ by Discoveries. Those Objects are nothing but instances of their related Class, inheriting the same attributes as their related Class. The Class and it’s attributes are defined in the so called Service Model.

Service Model
This Service Model also contains the relationship between the different Classes. For example, without a Windows Computer you can’t have a Windows Logical Disk. And per Windows Computer you can have multiple Windows Logical Disks. When the Windows Computer object is removed, so are the related Windows Logical Disks. So this relationship is also described in the Service Model.

Health Model
Over that Service Model, another layer is added, the so called Health Model, containing all the Rules, Monitors and Tasks (if any), directly related to the specific Class.

Health- & Service Model = True power!
When combined, SCOM not only has awareness of (for example) a Windows Server 2012 Logical Disk (thanks to the Service Model), but also has a deep understanding about how to decide whether the related Objects are healthy or not (thanks to the Health Model).

Because of it, SCOM workloads are executed only there where required. For instance SCOM won’t try to monitor non-present SQL databases or non-existent Exchange based workloads. Simply because the related Objects aren’t present and as such, those related SCOM (monitoring) workloads won’t be executed.

No Class = No proper monitoring
Reason why I tell you all this is because WITHOUT a proper Class, monitoring will NEVER be good, a workaround at it’s best. So Classes are a hard requirement in SCOM in order to get some proper monitoring done.

But in the SCOM Console there is no way to create Classes and their related Discoveries. Sure, you can create an Attribute but that’s an absolute no go area since you create a copy of an existing attribute (labeled extended attribute) which is a total pollution of your SCOM environment. So stay away from it. NEVER EVER USE IT! Time for a better approach…

Classes & Discoveries
Defining a Class is one thing. However, a Discovery is required as well in order to have SCOM picking up the Objects related to the same Class. And there are quite a few ways to discover new Objects. Think about WMI and scripts for instance.

However, a script based Discovery can be quite a challenge to get it right and also to KEEP it right. Meaning, along the way the Objects might be running updated software, causing the discovery scripts not working anymore, thus requiring an update as well.

Besides that challenge it’s known that WMI and script based discoveries also can have quite a footprint on the available resources on that box.

Gladly there is another type of Discovery which is light weight, which is the Registry based Discovery. None the less, when the Objects are running updated software, this Discovery might require an update as well since the registry keys – on which the Discovery depends – are modified as well.

Wouldn’t it be TOTALLY awesome to have a Discovery which is ‘Set & Forget’? Which ALWAYS runs and works on ANY Windows based box?  Now you’re about to enter the ‘dirty’ part of this series of postings…

Reverse Discovery
No matter what type of Windows box there is (or was for that matter), ALL of them share common registry keys like this one: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion.

Why not define a Class with a registry based Discovery looking only for the presence of that key? And when found, an Object of that Class is added.

Sure, since EVERY Windows based system has that registry key, ALL Windows systems running a SCOM Agent, would become an instance of that Class. And that’s not what we want.

Hence the REVERSE Discovery. The Class is defined, the Discovery is made but disabled by Default. The same MP also contains a Group which is empty by default.

How it works
When the MP is imported into SCOM, one or more new Classes will be added to SCOM. Since the Discovery is disabled by default, no instances related to those Classes will be discovered, so no monitoring – as defined in the same MP – will take place.

However, when the earlier mentioned Group is modified so that the Windows servers are added which must be monitored by that MP, and that same Group is used as an Override on the Discovery, enabling it only for that Group, those very same servers will be discovered as instances to the Classes as defined in the MP.

Soon after that the instances are discovered, they’ll enter a monitored state, based on the Monitors and Rules defined in the same MP.

Refining it
Sure, you can define registry based Discoveries on registry keys related only to the specific application you’re writing the custom MP for. In such a scenario you don’t disable the Discovery nor do you need the previously mentioned Group.

However, it will take the speed away compared to the other approach using the registry key which is present on any Windows based box. Why? Keep on reading because now you’re about to enter the quick part of it all…

Template MP XML
Suppose we stick to our approach using the common registry key for the Discovery.

All we have to do now is to create a default custom MP in MP Author, defining one Class, the well known Discovery (disabled by default), the Group (later to be used for enabling the Discovery by an Override) a folder for presentation in the SCOM Console (under Monitoring) with a State and and Alert View.

Save that XML code and you’re in business! Of course, the MP is lacking Monitors and Rules, but they will be added as required per custom application/service to be monitored. So there is no point in adding them already in the template.

Let me explain it a bit more. In the next postings of this series I’ll cover the details, for now I cover the overview of it.

Custom Application = Template MP XML

  1. Since we’re going to build template MP XML, we require a template name as well. Custom Application is a good name here. MP Author is a great tool to build a MP for IT Pro’s. So this is the tool we’re going to use.
  2. Every time a name is required we type Custom Application (mind the space!) or Custom.Application (mind the dot (.)!)or in case of the Discovery CustomApplication (mind the lacking space!).
  3. We create the Class, the related Discovery (disable it when created), Folder, State and Alert View. Also a Group is created.
  4. Then we save the XML code and scrub it – using Notepad++ - since MP Author adds these annoying tags stating MP Author was used to create this MP…
  5. We save the scrubbed code and store it for later usage.
  6. Please mind that the name of the Template XML code is Custom.Application.xml. This name must be modified later on as well.

Custom application monitoring required
Suppose we have the template MP XML code stored for later usage. Now is the time to use it since we are required to monitor two servers connecting to Office 365. This is the way to go about it.

  1. We inventory the services and Event IDs defining the health and availability of a working Office 365 Connection Server;
  2. We make a copy of the Template MP XML and rename the it to Office365.Connection.Server.xml;
  3. We open this XML code in Notepad++ and do a couple of search & replace actions:
  4. Search for Custom.Application and replace it with Office365.Connection.Server;
  5. Search for Custom Application and replace it with Office 365 Connection Server;
  6. Search for CustomApplication and replace it with Office365ConnectionServer;
  7. Save the changes and close Notepadd++
  8. Start MP Author and open the XML code previously saved in Step 7;
  9. Add the required Monitors and Rules and save the MP;
  10. Import the MP in SCOM, modify the Group and use as an Override target for enabling the Discovery. Soon the correct Office 365 Connection Servers will be discovered and monitored by SCOM, with their own Folder and Views in the SCOM Console Smile.

In the future postings I’ll cover the details of it all. Please know that it won’t become a detailed guide about using MP Author. Instead I’ll highlight the most important parts of it, supporting the why of this series.

See you all next time!

Credits: The usage of the reverse Discovery isn’t invented by myself. A former colleague of mine taught me this trick, so all credits for this approach should go to him. Thank you Peter Smit!

6 comments:

Michiel Rens said...

Always interested in following blogs on this subject, looking forward to the next posts!

koolboy said...

Nice work

Gfou said...

How can you consider this kind of discovery is "set & forget" when you need to manually add servers to a group to let the discovery run on it?
It's not overly more complicated to create a real registry discovery for your app, when you are already at the point of creating a registry discovery for a custom class...

Definitely agree that no one should ever, ever use attributes and extended classes from the SCOM console, though!

Marnix Wolf said...

Hi Gfou.

Good feedback! Please let me respond to it. Sure, the Discovery has to be enabled through an Override. So that aspect isn't 'Set & Forget'.

However, the Discovery itself, is 'Set & Forget' since it will always work, thus not requiring any configuration anymore.

The purpoese of the template MP XML code is to provide a working set of XML code which is quite easy to use, thus allowing for fast and foolproof MP development.

Too many times I've seen custom MPs fail because of failing Discoveries. As such this approach tries to solve that by using the Reverse Discovery method, aimed at an always existing regkey on any Windows based box.

I agree with you that creating a regkey discovery which is application specific isn't that hard but it's error prone. Moreover when those boxes are living outside the boundaries of MP Author, requiring manual input.

Therefore this template MP XML code, with a predefined Class and regkey Discovery which always work, thus 'Set & Forget'.

Cheers,
Marnix

Gfou said...

I definitely understand your point (and have already used something similar in some very specific cases), but in my opinion it defeats the whole purpose of having discovery rules in the first place and therefore whole discovery concept in SCOM...

But anyway, that's still a very valuable serie of articles on how to create a custom class and an associated discovery, I just would have liked it even better if it emphasized more on how/why create a real discovery, since it's really not that much different than what you show :)

Marnix Wolf said...

Thanks Gfou.

At the end there is a significant difference since the template MP XML code delivers a foundation, already containing a Class, related Discovery, Group, Folder and two Views (State and Alert), thus allowing for fast and easy MP authoring.

All one has to do is limited to do is to replace the name 'Custom Application' with the proper name, using Notepad++ for instance, and add the required Monitors and Rules with MP Author.

As such IT Pro's with tons of other responsibilities not using SCOM many times, can author MPs rather fast (within an hour!) without having to worry about Classes and Discoveries.

That's the targeted audience for this series, not the people who're far more into MP Authoring (like you :)).

Cheers,
Marnix