For a clearer picture

Month: May 2018

Part 5 – Create a Management Pack Solution and Project

Lets get started. I’d definitely recommend using a set of naming standards and I’ll go through mine as we build the management pack.

Fire up Visual Studio and choose to create a new project. The application we will monitor is called Batura – you might notice a theme to the name of my applications which dates back to my love of hill walking and moutaineering and what is, to me, one of the beautiful mountain ranges in the world.

I’ve chosen to use a SCOM 2012 R2 project but if you know that you’ll always be working on SCOM 2016 or later and don’t need the management pack to ever work on earlier versions then you can choose SCOM 2016 here. Both SCOM 2012 R2 and SCOM 2016 use the same management pack schema so the main difference here is the minimum version of the core management packs that your project will require.

You’ll notice that I have named the management pack as follows:

  • Project Name = F12.Batura.Monitoring
  • Solution Name = F12.Batura.Solution

In practice, I would ideally have a library management pack which would include classes, discoveries and relationships, a monitoring management pack for the rules, monitors, tasks, recoveries and diagnostics and a presentation management pack for the views. This can make change management easier as well as it isn’t necessary to have the same level of rigor over a change to a view as it is to a PowerShell script in a monitoring management pack.

Now we need to define our management pack properties – in Visual Studio, go to properties on the menu bar and the project properties will be the last item in the drop down.

One of the items that can frequently be overlooked is setting a management pack display name (this is different from the friendly name that you specify in this window. The display name is the name that will show in the administration blade of the SCOM console (under Management Packs) and to set the display name, click on the hyperlink at the bottom of the above window.

For the description, I like to put a link to the Management Pack documentation. If you use a document management system that injects some characters that “break” the xml then you can use CDATA tags to encapsulate the string as follows:

Using CDATA tags in Description
    
     <Description><![CDATA[http://mydocumentmanagementsystem/mydocument]]></Description>
    
  

Now; we’ll finish off setting our properties.

We’ll need to seal our management pack. If you need to create key file then the process is discussed here – the process is the same for Visual Studio 2015 and 2017 with a change of path for the relevant version.

I have also set an output path rather than using the default. I then make sure that this is included when I save my source code to Team Foundation Server (the same can be done if you are using other solutions such as Git).

You can set a default management group to deploy your management pack and then finally you can set whether you want to increment the version number with each save. If you are working as a team I would deselect this as each version number in Visual Studio is personal to you. So I always manually update the version number separately when I do my final build prior to checking in to Team Foundation Server.

With our Management Pack properties defined, we can now move on to start to create our classes.

Previous articles

Part 1 – Series Background

Part 2 – Visualisations with Squared Up

Part 3 – Application Monitoring Overview

Part 4 – Monitoring Overview

Later articles

Part 6 – Create the Management Pack components

Part 7 – Create the Squared Up Dashboard

Part 4 – Authoring the Management Pack – classes, discoveries and relationships

This is a summary of what we will walk through:

  • Create a Management Pack Solution and Project
  • Create a class for application server based on application component –> so health doesn’t roll up to windows computer. We want our infrastructure teams to support the computer and our application teams to support their applications.
  • Create a relationship that the application component is hosted by windows computer. The monitoring will be done by the agent on the computer (it is hosted by the computer) but without the dependency roll up there will be no health rollup to windows computer
  • Discover the application servers based on a registry key
  • Create Groups
    • Create a group of application servers
    • Create a computer group of application servers
    • Create a group of logical disks from the application servers
    • Create a group of websites
    • Create a group of application pools
    • Create a group of databases
    • Create a group of Health Service Watcher Objects
    • Create a group that contains all the other groups (this will provide us with the health state of the application)
  • We want our groups to have a health state based on the health state of the objects within the group. I have therefore created a dependency rollup monitor for each of the groups.
Previous articles in series

Part 1 – Background

Part 2 – Visualisations with Squared Up

Part 3 – Application Monitoring Overview

Later articles in the series

Part 5 – Create the Management Pack Solution and Project

Part 6 – Create the Management Pack components

Part 7 – Create the Squared Up Dashboard

Part 3 – Application Monitoring – setting the scene

Sometimes working with SCOM seems to be Mission Impossible so today (should you accept the challenge) we’ll look at how to create application-based monitoring for your support and service management teams.

Previous articles

Part 1 – Background

Part 2 – Visualisations with Squared Up

Later articles

Part 4 – Monitoring Overview

Part 5 – Create the Management Pack Solution and Project

Part 6 – Create the Management Pack components

Part 7 – Create the Squared Up Dashboard

Our application is called Batura and to summarise it runs on Windows and the following needs monitoring:

  • There is an application server that runs a windows service.
  • It has a couple of databases hosted on Microsoft SQL Server 2012.
  • There is an application pool and an Internet Information Services website hosted on Windows Server 2016.

We are going to create a sealed management pack using Visual Studio to create the monitoring and then use Squared Up to create an interactive \ drill down dashboard that will provide:

  • Availability Status of the application
  • Performance metrics of the components

The first consideration is how do we model the application? Let’s take a look at the application \ component classes that we require:

  • The Microsoft Management Packs already provide us with classes for SQL databases and IIS websites and application pools so we don’t necessarily have to create classes for these components.
  • There is no “out of the box” class for Batura Application Server though so we definitely need to create a class for this component

And then we will need to create the groups that we will use for scoping views, permissions and also for our Squared Up dashboard:

  • Group that contains all the application Component groups. This will show the health of our application.
  • A group of each of the application components (especially for more complex applications which might have more than one database \ website \ application pool):
    • Group of databases
    • Group of websites
    • Group of application pools
  • Computer Group – One of the gotchas with SCOM is that if the server is down then the computer object doesn’t go into an error or warning health state. If it was healthy when the server went down then all we see in SCOM is that server grey out in the console. So while it can be useful to have a computer group for scoping views and permissions, it isn’t that useful for the dashboard.
  • Health Service Watcher Group – The way around the above is to create a Health Service Watcher group for the computers that host the application components. That way, if the computer goes down then health service watcher will go to critical and we tell we have a problem.
  • Logical Disks – I also find it useful to have a group of logical disk objects that will allow an application support team to see the underlying health of the infrastructure that their application is running on. The health state of the logical disks won’t impact the health state of the application but if a logical disk is red it gives an indication to the support team that they need to start liaison with infrastructure (depending on your support model works).

The above is just an outline of one way to go about monitoring. There are other routes which we will look at in future articles. For example; you might want to create a specific class for your applications websites (and databases and application pools). This would then allow you to:

  • Use it as a target for specific website monitoring that you want for this application.
  • Have health state based on the health of a specific monitor rather than the IIS website class.

You would also likely want to monitor the URLs and databases remotely from “watcher nodes”; as I say; more on this later.

If you don’t already have Visual Studio to hand, then take a look here for how to download and create a key to seal our management pack. Let’s get started.