MP Authoring – Quick & Dirty – 04 – Testing The Example MP

---

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
01 – Overview
02 – Authoring the Template MP XML Code
03 - Example Using The Template MP XML Code
05 – Q&A

---

In this posting I’ll show you how to import the previous made custom MP (SAP.Logon.Server.xml) into SCOM and how to activate it by enabling the Discovery through an Override targeted against the Group (SAP Logon Server Group) contained in the same MP.

Again I’ve made several sections in order to keep it readable. There is much to tell, so let’s start!

Using the custom made MP
As stated in the previous posting, the custom MP is going to monitor a non-existing SAP Logon Server. Just as an example in order to show how easily a custom MP is created based on the template MP XML code, in conjunction with Notepad++ and MP Author.

01: Importing the MP and enabling the Discovery through an Override
Now you’re going to import the MP and enable the Discovery through an Override by using the Group present in the same MP.

Before you start:
TEST YOURSELF BEFORE YOU WRECK YOURSELF.

Meaning:
TEST the MP in a SCOM TEST environment, before putting it into production!!! I don’t accept any responsibility for broken SCOM environments!!!

1. Import the MP in your SCOM test environment. Importing the MP can also be done by MP Author or the regular way, by using the SCOM Console;
   
   
2. After the MP is imported: In the SCOM Console (log on with SCOM Admin permissions!): Go to Authoring > Groups and search for Groups with SAP in the name. Select the SAP Logon Server Group and open it;
   
   
   
3. Remove the Dynamic Member rule by using the Create/Edit Rules button.
   
   
4. Go to the tab Explicit Members and hit the Add/Remove Objects button. In the Search for: field select Windows Server Operating System (since the Discovery is targeted against that Class!) > Search > select the related Windows Servers where SAP Logon Server is installed. In this example I select DC01 > Add.
   
   In the Selected objects field the DC01 is now shown > OK > OK. The modifications to the Group will be saved now.
   
   <Advice>
   Please know that selecting the object(s) of the correct Class (Windows Server Operating System) is crucial here. Reason being that the Discovery is targeted against that very same Class. Adding object(s) of any other Class won’t work because the Discovery won’t land there. For example, adding DC01 object from the Windows Computer Class won’t make the Discovery work, nor adding the DC01 object of the Windows Server Computer Class. So please select the DC01 object of the Windows Server Operating System Class.
   <\End of Advice>
   
   
5. In the SCOM Console in the menu bar go to Tools > Objects > click on Object Discoveries. Search for SAP and select the SAP Logon Server Discovery. In the Object Discovery Details screen, hit the View Knowledge link. Now the properties of the SAP Logon Server Discovery will be shown.
   
   
6. Go to the tab Override > hit the Override button and select For a Group…:
   
   
   
7. Search for SAP and select in the Matching objects field the SAP Logon Server Group:
   
   > OK
   
   
8. Set an Override for Parameter Name Enabled by setting the Override Value to True. Since the Group is already contained in an Unsealed MP (SAP Logon Server), you can’t choose another Unsealed MP.
   
   > OK. The Override will be saved now, thus enabling the Discovery for the SAP Logon Server Class for the Group SAP Logon Server Group, containing Windows Server Operating System object DC01.
   
   In the next section you’re going to see whether all your hard work paid off!

02: Testing the MP
Now it’s finally time to see the results of your hard work!

1. Within a 5 to 10 minutes you’ll see that DC01 is discovered as an object of the SAP Logon Server Class:
   
   
   
2. It also has a State because of the Monitor you previously made, shown here in the Health Explorer of the SAP Logon Server object DC01:
   
   Let’s stop the SAP Logon Service (Spooler service actually ) on DC01 in order to see what happens.
   
   Spooler service on DC01 is stopped…
   
   
3. Yes, it works!
   
   
   And:
   
   
   An Alert is also shown:
   
   
   Let’s start the Spooler service again in order to see what happens (Monitor should go back to a healthy state and the Alert should be closed automatically):
   
   
   And yes, the Alert is closed automatically:
   
   
   
   
   And:
   
   
   And:
   
   
   
4. The Rules you made earlier work as well:
   
   
   And:
   
   
   And:
   
   
   

03 – Recap
As you can see, with the template MP XML code it’s a low effort to cook up a new MP in order to monitor custom workloads running on one or more Windows Servers.

I’ve taught may IT Pro’s this approach. Many of them are capable of authoring a custom MP based on the template MP XML code within an hour! Meaning within 60 minutes they have the monitoring up and running in SCOM!

The most crucial part here is to collect the information, like WHAT needs to be monitored and HOW? In 99% of the cases it’s pretty straight forward, thus viable for the ‘Quick & Dirty Approach’ this series is all about.

Next posting in this series
By using a Q&A I’ll share additional information about how to extend the usage of the ‘Quick & Direct Approach’, thus aiding you even more in your quest to get SCOM monitoring on par with the requirements of your organization.

See you all next time!