MP Authoring – Quick & Dirty – 03 – Example Using The Template MP XML Code

---

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
04 - Testing The Example MP
05 – Q&A

---

In this posting I’ll show by example how easy to use the previous made template MP XML code is, when a custom MP is required in order to monitor specific workloads.

Non existing workload to be monitored, just for the sake of it…
For this example I’ve cooked up this non existing server: SAP Logon Server. It runs one Windows service (the Spooler service) which is rebranded into the SAP Logon Service for the sake of this example. Also it logs certain events which are crucial and must be monitored as well:

• EventID 1201 of the OperationsManager eventlog, rebranded into SAP Logon Server Tokens Unloaded;
• EventID 1210 of the OperationsManager eventlog, rebranded into SAP Logon Server Bad Response Received.

The server which will become the SAP Logon Server is the DC in my test lab, DC01.

I know, it’s all none existent (accept for the DC), but like stated before it’s an example.

Items to reckon with when authoring a custom MP
There are some issues to reckon with whenever you create a custom MP:

1. You’ll need a proper name for the MP, adhering to the monitored workloads. In this case the name of the MP will become SAP Logon Server. Choose the name wisely because it’s going to have an impact on everything you’re going to do;
   
   
2. When this MP is authored, imported into SCOM and the Discovery for the SAP Logon Server Class is set so the proper server(s) will be detected, we also REQUIRE a State. In SCOM states are ONLY set by Monitors. So we REQUIRE at LEAST one Monitor. Stateless Objects are a no go in SCOM, especially for your custom made MPs;
   
   
3. As a rule of thumb: Use Monitors for services to be monitored, and Rules for triggering Alerts based on events logged in the Windows event logs. I know, with Rules there is a change of a potential alert storm, but that can be addressed easily with MP Author. And yes, I’ll tell you how.

Let’s author the MP to monitor the SAP Logon Server
There is much to tell, so let’s start. Again I’ve made multiple sections of all the steps to be taken because I want to get the message across in a decent manner.

Also I will share some additional tricks. Every trick is easy to identify since they’re all in blue text, start with the prefix <Trick> and end with the suffix <\End of Trick>.

01 – Copying the template MP XML code and modifying the names
For this you’ll need Notepad++ or the XML editor of your choice.

1. Copy the template MP XML code file (custom.application.xml). A new file will be made in the same folder, titled Custom.Application - Copy.xml. Rename this file to SAP.Logon.Server.xml, please mind the DOTS (.):
   
   
   
2. Open this file in Notepad++ and do a Search & Replace (<CTRL H>)on these 3 entries:
   Search for: Custom.Application. Replace with SAP.Logon.Server, mind the DOTS (.):
   
   
   
   
   Search for: Custom Application. Replace with SAP Logon Server, mind the SPACES ( );
   
   
   Search for: CustomApplication. Replace with SAPLogonServer, mind the LACKING spaces;
   
   
   
3. Just to be sure all Custom Application entries are rebranded to SAP Logon Server, do a count (<CTRL H>) on the entry custom. There shouldn’t be any left. If there are, start over from Step 01.
   
   
   
4. Save the modified XML and close Notepad++. As a result, the template MP XML code is now rebranded from Custom Application to SAP Logon Server. With MP Author you’ll add the Rules and Monitor as previously discussed.

02 – Adding the Monitor to the SAP Logon Server MP with MP Author
With MP Author you’ll build the required MP in order to monitor the SAP Logon Server specific workloads. Again, I won’t describe EVERY single step to be taken in MP Author, but highlight the most important ones.

1. Open MP Author and open the previously saved XML file SAP.Logon.Server.xml. It might take some time for MP Author to load and open the file, but just be patient ;
   
   
2. First you’re going to author the Monitor. Go to Monitors > New > Create New Service Monitor > select the option Manually enter service name without connecting to a computer (Advanced users only) > Next;
   
   
3. In the Select service to monitor screen, select as Target SAP Logon Server Class (now you see that Section 01 paid off ) and enter the name of the service you want to monitor. In this example Spooler:
   
   > Next
   
   <Trick>
   In order to get the right name of the Service you want to monitor with SCOM: Always use the Service Name as depicted in the service properties screen. As you can see, the Service Name for the Print Spooler service is Spooler, so you use that name in MP Author as well:
   
   <\End of Trick>
   
   
4. Enter the proper information, like this:
   - Name: SAP.Logon.Service.Monitor (please mind the DOTs (.))
   - Display Name: SAP Logon Service Monitor (please mind the SPACES)
   - Description: Monitors whether the SAP Logon Service is running
   
   > Next
   
   
5. When the service isn’t running I suppose it’s a Critical situation. So ascertain the Health State reflects that by setting it to Critical when the service isn’t running anymore:
   
   > Next
   
   
6. In this screen you’ve to change many things:
   - Select Generate alerts for this monitor
   - The Alert will be generated when the state is changed to Error
   - Select Automatically resolved the alert when the monitor returns to a healthy state
   - Leave the Alert Name to the default selection. It won’t be shown in the SCOM Console
   - Alert Display Name: SAP Logon Service isn't running!
   - Priority: High and Severity: Error
   - Description: SAP Logon Service  failure on $Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$.
   Please see the alert context for details.
   
   > Next > Finish > Save the changes. Stay in MP Author please.
   
   Now you’ve added the Monitor! Great! In the next section you’ll add the two Rules in order to monitor for the Event IDs 1201 and 1210 in the Operations Manager event log.

Section 03: Adding the Rules to the SAP Logon Server MP with MP Author
Time to add the two Rules!

1. In MP Author: Go to Rules > New > Create New Windows Event/Alert Rule > select the option Manually enter event log name without connecting to a computer (Advanced users only) > Next;
   
   
2. In the Specify event rule data screen, enter the proper information, like this:
   - Event Log: Operations Manager
   - Event ID: 1201
   - Event Source: HealthService
   - Deselect the option to Collect Data
   
   > Next
   
   <Trick>
   Sometimes it can be a challenge to find the right names of the event log and event source. With this trick however, you’ll be 100% sure that SCOM is using the correct information. As such the Rules will work right away without requiring deep troubleshooting.
   
   Open the event you want SCOM to monitor and go to the Detail tab. There are two entries you require:
   - Provider Name, which adheres to the Event Source,
   - Channel, which adheres to the Event Log name in MP Author.
   
   <\End of Trick>
   
   
3. In the next screen the proper Class (MP Author refers to it as Target), SAP.Logon.Server.Class, should be selected by default. When not, correct it:
   
   > Next
   
   
4. MP Author is a great tool but has some disadvantages like creating impossible names. This is on purpose since the names with the dots have to be unique. Otherwise the MP will be flawed. None the less, it’s Best Practice to makes those names smarter and still keep them unique. In this case I’ve modified the entries to this:
   - Name: SAP.Logon.Server.EventID.1201.Rule (please mind the DOTs (.))
   - Display Name: SAP Logon Server Tokens Unloaded (please mind the SPACES)
   - Description: Alerts when the SAP Logon Server has unloaded tokens
   
   > Next
   
   
5. In the Specify alert for event rule screen you can tweak many things. Choices will be based on the requirement of your organization. As such, the settings I choose here are only an example, nothing more.
   - Alert Name: Used in the MP only, not shown in the Console. When it’s reasonable, leave it;
   - Alert Display Name: Used in the Console, so make it smart. In this case: SAP Logon Server has unloaded tokens.
   - Priority: High, Severity: Error;
   - Description: You can leave the default which will dump the event description in the Alert. In this case however I’ve chosen a default text without any parameters. The buttons on the right of the screen (Data, Target, Host and Group) can be used to add parameters to the description, making the Alert much more worthwhile to read. It’s up to you, simply experiment!
   
   <Trick>
   When using Rules, there is always a change of an Alert Storm, meaning way too many Alerts come in for a single situation. Which is really bad. However, Alert suppression enables you to prevent that from happening. So when authoring Rules, based on events, always check how many events are created in a single time slot, like 10 minutes, an hour, half a day and a whole day.
   
   Based on that information you can add Alert suppression to the Rule you’re authoring, thus preventing potential Alert Storms. However, Alert suppression can also be unwanted when people want a single Alert every time the event takes place.
   
   None the less, hundreds of Alerts about the same issue within a day is way too much. So better to apply Alert Suppression and using the Repeat Count column in the Alert View in the SCOM Console. When using Alert Suppression, the Alert itself is stopped when it’s already triggered. Instead the Repeat Count counter is raised by a single instance.
   
   That way you’ve the best of both worlds: Not an Alert Storm and yet a perfect way to show how many times the situation triggering the Alert, took place. Just remember, the Repeat Count counter starts at zero (0) meaning the Alert took place 1 time .
   
   Simply hit the Alert Suppression button and ‘play’ with the various options available. The available options for alert suppression do explain themselves.
   <\End of Trick>
   
   In this posting I don’t use Alert Suppression, so I skip it. > Next
   
   
6. Interesting! By default any monitoring workload in SCOM runs 24/7. Sure you can change that but that’s quite a challenge. With MP Author however, it’s very easy to accomplish! Awesome! For this posting however, I don’t use any schedule so the Rule runs 24/7.
   
   Again, it’s up to the requirements of your organization what to choose. When not using the default (24/7), make sure to DOCUMENT it and COMMUNICATE it with the organization. Otherwise your next job could be flipping burgers…
   
   > Next > Finish > Save the MP.
   
   
7. Now you’re going to author the Rule to monitor for Event ID 1210 in the Operations Manager event log, using Steps 01 to 06 of Section 03.
   
   Use this information when authoring the Rule:
   - Log Name: Operations Manager
   - Event ID: 1210
   - Event Source: HealthService
   
   - Name: SAP.Logon.Server.EventID.1210.Rule
   - Display Name: SAP Logon Server Bad Response Received
   - Description: Alerts when the SAP Logon Server has received bad responses
   
   - Alert Display Name: SAP Logon Server has received bad responses
   - Description: The SAP Logon Server has received bad responses! Check the Admin Console for more details.
   
   
8. At the end of the Wizard you’ll be shown this summary screen of your settings and input:
   

Save the MP and close MP Author. Now the MP has the two Rules and the Monitor. Nice! Time to test it!

You can download the authored SAP Logon Server MP from here. Download it, open it in MP Author and check it out. Please know however that the Wizards in MP Author are a one-way street. Meaning when creating anything (like a Rule, Monitor, Class (Target), Discovery and so on) there is a Wizard. But once created, that Wizard isn’t available anymore.

None the less, you can compare the code with your own code. Enjoy!

The next posting in this series
In the next posting of this series I’ll describe how to use the MP you just made by importing it, enabling the Discovery through an Override aimed at the Group contained in the same MP. See you all next time!