Mr. MOM goes Cloud

Send SCOM Custom Performance Counters to OMS

Markus Klein - Bern — Sun, 18 Oct 2015 06:07:14 GMT

Since the release of the Operations Management Suite there have been a lot of solutions and intelligence packs been added. One of the latest ones was a pack to upload Performance Counters to OMS by defining them in the OMS console.

This performance collection is being setup by OMS intelligence packs that are distributed to the SCOM Management Server and Agent.

Intelligence Pack ID	Intelligence Pack Display Name	Management Pack Bundle
Microsoft.IntelligencePacks.Performance	Microsoft System Center Advisor Performance collection library	Microsoft.IntelligencePacks.Performance.mpb
Microsoft.IntelligencePacks.Types	Microsoft System Center Advisor Types Library	Microsoft.IntelligencePacks.Types.mpb

This has brought up the question, if it is possible to also upload custom performance counters from SCOM into OMS. My colleague Wei Hao Lim has shown, that it is indeed possible by using two Write Actions from these Intelligence Packs. For details, look at https://blogs.msdn.com/b/wei_out_there_with_system_center/archive/2015/09/29/oms-collecting-nrt-performance-data-from-an-opsmgr-powershell-script-collection-rule-created-from-a-wizard.aspx.

For the upload to work, the Performance Object Name has to be built like this: \\FQDN\ObjectName. This means, that if you want to just add the new write actions to a standard rule, you end up with Performance Objects in SCOM that have different ObjectNames for each agent.

While this might just be a cosmetic problem, I don't really like this, having fought many battles with the SQL Performance Counters that include the SQL engine name in many cases. So my goal was to create write actions into OMS based on the ones that Wei has used, but be able to send a normal looking ObjectName into SCOM database and DWH and a OMS compliant ObjectName into OMS. To achieve this, I created two new WriteActionTypes like this:

Basically what's happening here is that I create the Performance Counters with a "normal" SCOM ObjectName and when it is time to send them to OMS, I run them through a second DataGenericMapper to change the ObjectName into the OMS compliant ObjectName format of \\FQDN\ObjectName. After that, they are fed into the same write actions, that Wei has described in his Blog Post.

As you can see, the first DataGenericMapper gets the PropertyBag output of your custom Performance Counter Script in the well-known $Data/Property[@Name='']$ format. The second one gets the same Data that is then already on the Data bus, therefore can be referred to by $Data/$. If you target a class coming off of Microsoft.Windows.Computer, the FQDN translates to

\\$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$

making the whole term look like

\\$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$\$Data/ObjectName$.

These two new WriteActionTypes can then be used in your Performance Collection Rule like this:

By doing this, you get a "SCOM-like" Performance ObjectName in SCOM while still being able to comply with the OMS ObjectName format and upload your customer performance data into OMS.

Here is the counter in SCOM:

And here the same counter in OMS:

So if you are not shy to edit Management Packs in XML, import the Management Pack and start using the new Write Actions.

The reference should look similar to this:

Now add the new Write Actions to your Rule. In the XML it should then look like this:

Now be patient, it might take a few hours for the counters to show up in OMS, but eventually they will.

Hope you are having fun with this and start using OMS more often…

You can download the Management Pack from https://gallery.technet.microsoft.com/Sample-MP-WriteActions-to-b720052e

Some general Information about Near Real Time (NRT) Performance Data in OMS:
https://blogs.technet.com/b/momteam/archive/2015/09/01/near-real-time-performance-data-collection-in-oms.aspx

UPDATE:

I added the Version 1.2.1102.0 of the OpsInsights Management Pack Microsoft.IntelligencePacks.Performance to the ZIP File. Some people have told me that this is being a blocker for installation.

Disclaimer:
All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.

Monitoring Office 365 with System Center Operations Manager 2012 R2

Markus Klein - Bern — Sun, 27 Sep 2015 02:23:10 GMT

Office 365 is becoming more and more commonly used these days. So naturally the requirement to monitor a bit more closely what exactly is going on in your subscription becomes a topic for a lot of small, medium and larger customers. Microsoft does offer a SCOM Management Pack for Office 365 (can be downloaded at https://www.microsoft.com/en-us/download/details.aspx?id=43708) but once you import it and look at the dashboard it provides, you might be a bit disappointed.

What the official Management Pack does give you is an overview of Incidents (Active and Resolved) and Planned Maintenance Times. There is no information on how well you are connected or what kind of performance your end users might experience. That got me thinking and experimenting around a little bit. I have created a management pack that gives you additional information on your Office 365 environment. So far only for Exchange Online, but the other components are in the works as well. The MP is not ready to share quite yet, I need to add some documentation and features to it, but I thought I test the waters a little bit by giving you all a little teaser screenshot of the current state of my O365 Exchange Online Dashboard…

Here is the Overview Dashboard

And then the detailed dashboard

So I would love to get some feedback from whoever reads this:

Is this useful?
What are the KPIs and/or synthetic transactions that are most interesting and important to you/your customers?

So much for the moment… Watch this space, there will be updates to this as I go along, hopefully with a lot of feedback from my readers.

Groups and Distributed Applications with 3-State Rollup

Markus Klein - Bern — Tue, 18 Aug 2015 04:04:06 GMT

When you work with System Center Operations Manager 2012 one of the things that you might have run into is the limitations it has on rolling up state. Sure you can choose between the Best State, Worst State and a percentage value in between, but what I often hear is: "Why can't we turn the group or Distributed Application State yellow when only one or only non-critical components are affected and red only when we lose service availability? In other words, or easier graphically, you want this:

Unfortunately, SCOM 2012 does not give you this rollup variation out of the box.

After just accepting this for the longest time, I have tried to "simulate" this behavior with normal SCOM components. I remembered that the "Health Service Heartbeat Failure" monitor has some Recovery Tasks that forcibly set a monitor's state.

So as one does trying to find out what's in a sealed MP, I exported the Microsoft.Systemcenter.2007 Management Pack from PowerShell and looked for the WriteActionModuleType. This is the one:

Internal" Batching="false">

Health!System.Health.AlertSchema

System!System.ManagedEntityKeysSchema

44cbc334-8b5f-4cb6-bee0-6bdcbc80e8d5

System!System.BaseData

As you can see, this is using a native module that we do not have any deeper insight into, it's is stored in a DLL. But we can refer to it by the ClassID I marked yellow. We could even use the module directly if it were not marked as "Internal". So the way to go for this is to implement a similar WriteActionModuleType and create a WriteActionModule using it. Looking around other blogs a bit, I found that someone had already done this:

Roman Zolotov has already created this and wrote about it in the following blog post:
https://blogs.technet.com/b/scpferublog/archive/2014/11/07/how-to-change-the-state-of-monitors-part-2.aspx

If you look at his Management Pack, he has taken exactly the same native module but created a "Public" implementation:

Public" Batching="false">

Health!System.Health.AlertSchema

44cbc334-8b5f-4cb6-bee0-6bdcbc80e8d5

System!System.BaseData

And with that he created another WriteActionModuleType that we can then use to force any Monitor into any state we want.

Health!System.Health.AlertSchema

$Target/ManagementGroup/Id$

$Config/MonitorId$

$Target/Id$

$Config/HealthState$

System!System.BaseData

Another idea taken from Roman's blog post is to use this Module type in a Recovery Action of a dependency monitor. This opened up the way to achieve what I had set out to go for. Now I could create the following…

If this is a little overwhelming, let me start by explaining the scenario.

The Scenario

During a Service Mapping engagement at your customer, you heard …

… that they have four Print Servers that make the Print Server Service
… that the only thing important is the Print Spooler service on those 4 servers
… that the CIO does not care about the individual servers but cares a lot about the print service, as they need it to print the delivery papers and invoices for their customers
… that the service will (somehow) still be available as long as one Print Server is up and running, but that they should know as soon as the first Print Spooler service goes down in order to proactively avoid a service outage
… that they want to present the appropriate state information to different audiences like End Users, Service Owners, Help Desk, etc.

Especially the last requirement connects this with the topic of this post. Depending on the audience, we need to represent the state of the Print Service in different ways:

End Users only need the Red/Green traffic light. Presenting a degraded state might lead to increased help desk calls and leaves the end user in a confused state. For them the service is purely binary, either it prints or it doesn't.
Print Service Owner / Support needs a more granular view. They need to be made aware that a part of the overall Print Service is down and that not reacting might lead to a total service outage. So they need a Red/Amber/Green traffic light. They also need a view that represents the state of the components of the Print Service in order to identify the origin of a service degradation.
Other groups may or may not fit in either of those categories. CxOs, Owners of Business Services depending on the Print Service, Department Heads, etc. all may be interested in various levels of depth on the service health. Their requirements need to be taken into consideration as well.

The Implementation

As per requirement 2, we need to make sure we monitor the Print Spooler service on the 4 Print Servers. The standard server build disables the Print Spooler service on all servers with the exception of the Print Servers. So the WMI Query

select * from Win32_Service where Name = "Spooler" and StartMode = "Auto"

will find those servers. So we can use this to seed discover instances of the newly defines "Print Service Host" Class. As we are only interested in the Print Spooler Windows Service we then discover the service with a similar discovery on just those Print Service Hosts.

select * from Win32_Service where Name = "Spooler"

This will now give us the four Print Spooler Services we are interested in.

Now from the Service Availability perspective we need to group those with the "Best Of" Rollup algorithm chosen, from a Service Degradation perspective we need to use the "Worst Of" algorithm. So let's do both, we create two identical groups from the same objects. As Group Objects do not rollup state by default, we also need to create a Dependency Monitor for either of them. In here we then choose the different Rollup algorithms.

Custom

BestOf

Error

Custom

WorstOf

Error

So far, we have two groups where one (Availability Group) stays green as long as one Print Spooler service is green and the other (Degradation Group) turns red as soon as the first Print Spooler service goes down. So the Availability Group's State would serve well for our End Users and everyone who only needs to Red/Green Service State. But we do not yet cover the needs of the Red/Amber/Green requirements that the Print Service Owners and Supporters want. For this the WriteActionModuleType introduces in the beginning comes into play. We now define a Recovery for the Dependency Monitor of the Print Service Degradation Group:

Custom
CTL!Custom.Task.Library.Set.Monitor.Action">
$MPElement[Name="ThreeStateRollup.PrintServiceDegradationDependencyMonitor"]$
Warning

The WriteActionModuleType comes from Roman's Management Pack that we have imported. Alternatively, we could of course create our own version of the WriteActionModuleType within our Print Service Management Pack.

Now we force the Print Service Degradation Group's state into "Warning" when the regular rollup changes it to "Error", i.e. whether we have one, two, three or four Print Spooler services down, our Group state is always Amber.

All we need to do now to have the 3-State Rollup is to group our two new groups together, add a Dependency monitor and use the "Worst Of" rollup algorithm. This will then lead to the following situation:

The first column is the Availability Group which by definition can only be either Red or Green. The second column is the Degradation Group which we now forced into being either Amber or Green. The "Worst Of" algorithm then turns the Print Service State to Yellow when one, two or three Print Spoolers are down and to Red when the Service Availability turns Red, i.e. the Print Service is down.

Dashboards

So this now allows us to present the State of the Service to different audiences. The Print Service box for the "Contoso Service Desk Dashboard" on the left presents the state of our new 3-State Rollup Print Service Group Object, the Print Service box in the "Contoso End User Dashboard" on the right presents the state of the Print Service Availability Group.