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
- 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.
- 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!).
- We create the Class, the related Discovery (disable it when created), Folder, State and Alert View. Also a Group is created.
- 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…
- We save the scrubbed code and store it for later usage.
- 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.
- We inventory the services and Event IDs defining the health and availability of a working Office 365 Connection Server;
- We make a copy of the Template MP XML and rename the it to Office365.Connection.Server.xml;
- We open this XML code in Notepad++ and do a couple of search & replace actions:
- Search for Custom.Application and replace it with Office365.Connection.Server;
- Search for Custom Application and replace it with Office 365 Connection Server;
- Search for CustomApplication and replace it with Office365ConnectionServer;
- Save the changes and close Notepadd++
- Start MP Author and open the XML code previously saved in Step 7;
- Add the required Monitors and Rules and save the MP;
- 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
.
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!
.