SCOM Management Pack Authoring Training: A different approach (Part I)

It would be wrong to start off any discussion of SCOM authoring without pointing out some of the great resources that do exist on this topic:

-The MSDN Operations Manager Development Kit  (Excellent for those of the developer persuasion, but less friendly for those whom PowerShell is much more comfortable than C#)

-Steve Wilson’s classic  AuthorMP blog posts. (A bit dated, but they remain a source of some the most insightful posts on various aspects of OpsMgr)

-Jonathan Almquist’s posts both in his old, and new home

-Brian Wren has put together great video content + some awesome posts over the years

-Graham Davies and the Manageability Guys in the UK have some awesome posts: 1, 2 , 3,  4, 5, 6, 7, 8

-If you happen to be a Microsoft Premier customer there is a great workshop on SCOM Authoring with Visual Studio that came out last year

-And countless members of the community like Tao Yang &  Raphael Burri who have written high quality MPs that can serve as a primer to those who want to dig in and start authoring. (Since I started writing this post awhile back I believe Tao has hosted some MP authoring training, I haven’t gotten a chance to look at it yet, but once I do I will add a link.)

-There are of course many other worthwhile posts throughout the SCOM community both inside and outside of Microsoft, but that is what Bing, Google, and DuckDuckGo are for.

But despite all that great content out there. Management Pack authoring can be an extremely difficult skill to acquire. At least from my own perspective – starting out in MP Authoring was really hard. Even after having read the vast majority of the published info on MP authoring, and watching all the videos that are out there I can’t say that I felt particularly confident to wade into Visual Studio and start writing management packs. I understood the basic mechanics, but I lacked the ability to fill in the inevitable gaps of knowledge to be able to author custom MPs that met real enterprise level business needs.

Unfortunately, a lot of the best how-to examples and step-by-step tutorials tend to be a little generic. I suspect this is done intentionally to minimize complexity as much as possible. The hope being that a budding MP author can learn the fundamentals and then extrapolate from the excellent guide on “how to author a custom MP that no one would ever import into their real environment”, and later apply this knowledge to some real-world problem.

My brain tends to not work that way. It is easily distracted by shiny objects and Wikipedia. To learn I need concrete real-world examples, problems, deadlines.  For me the most valuable training in MP authoring came not from all the guides and links referenced above, but from a single one hour Lync call with a senior colleague at Microsoft. I had a specific question that I didn’t know how to solve and step-by-step over the course of an hour he walked me through how to build an MP that addressed that request.

I really wish there were a ton of Authoring videos like that call out there following the simple formula:

Real-world enterprise monitoring problem that is not currently addressed by a Management Pack + Screen capture video that walks through the process every step of the way.

Sadly as fun as it would be to simply complain, I think there might be some small value in me adding what little I know about MP authoring to the general ether following the format above.

I had toyed with the idea of doing or live sessions, but my home internet connection these days is DSL so the upload streaming experience is lacking, so these will be pre-recorded sessions with some light editing.

The first installment can be found here:

MP Authoring 001

I have about 10 videos planned so far and if the first few are of any use to the community I will shoot for publishing a new video every two weeks until I run out of ideas.

Management Packs: SharePoint 2013 Extended MP

I had a question recently on whether or not the SharePoint 2013 Management Pack monitors when Services are stopped?

As with most questions this is not quite as straightforward as you would expect. With SharePoint there are two kinds of services. There are your standard services that you access via services.msc which are easy to make custom monitors for:


And there are also those services that are only accessible via the SharePoint Central Administration console:


So the native monitoring available in the pack is different depending on what type of SharePoint service we are talking about. The services of the .msc persuasion are easy enough to create custom monitoring around, but does the pack monitor the specialized internal services? If we look at the 2013 pack we find the SharePoint specific services are split up into three state views. Service Front End, Services, & Shared Services:


Each is populated as follows:




So this is normally the point that I would put up my feet and bask in the glory of the product team. The SharePoint Services that can only be accessed via the Central Administrative interface are all enumerated above and they are healthy. Question answered, all is well, and there was much rejoicing throughout the land. Unfortunately, I am prone to a nasty habit of testing things. So before breaking into celebratory dance I took one of these services and stopped it waiting impatiently for the inevitable alert to roll in.


I waited for a long time. I refreshed many times. No alert came. I was sad. I also noticed that the state view for the relevant service now showed “Not Monitored” whereas before I stopped the service it showed healthy.


{Insert appropriate Expletive Here}

So what you find if you open the Health Explorer for any of these SharePoint specific services is that while there are monitors associated, it’s just that they don’t actually monitor the status of the service. So if  it is stopped you lose monitoring around that service and you will never know it unless you go to the view and note the Not Monitored.


Part of me really wants to know why this is the case. My completely uninformed guess would be that since SharePoint services can exist on multiple members of the Farm and by design you may only want them running on certain members it is hard to code a solution that isn’t going to be extremely noisy when looking at service status since you as the MP author have no idea that the service being stopped on one server is a critical situation whereas on an identical server it could be by design and non-actionable.

So how do we fix this so that you can selectively monitor service status for certain SharePoint servers and get alerts? First we have to know a little bit about how SharePoint Services work– which at the time I didn’t know much. I started by stopping services via the Central Administrative site and then trawling all relevant event logs on the SharePoint servers hoping for a nice event ID that I could use.

I will hopefully save you some time by telling you that there is no such event ID. There are some events that get generated that are related and will say hopeful things like X Service is Stopping or Starting, but you will find these won’t actually correlate with the time you stopped the service.

So this left me with PowerShell.

The basic mechanics of dealing with SharePoint via PowerShell as it pertains to Services are below. First to do anything you need Add the relevant Snap-in. Then you can use Get-SPServiceInstance to get a list of the services:

Add-PSSnapin -Name “Microsoft.SharePoint.PowerShell” -ErrorAction SilentlyContinue

Get-SPServiceInstance | ft TypeName, Identity


Then you can use the script below to check status/start/stop the service as you wish:

#To Stop a Service:

$ServiceName = “Visio Graphics Service”

Get-SPServiceInstance -server $env:COMPUTERNAME | where-object {$_.TypeName -eq $ServiceName} | Stop-SPServiceInstance -confirm:$false > $null

#To get Service Status:

Get-SPServiceInstance -server $env:COMPUTERNAME | where-object {$_.TypeName -eq $ServiceName} | Select Status

#To Start a Service:

Get-SPServiceInstance -server $env:COMPUTERNAME | where-object {$_.TypeName -eq $ServiceName} | Start-SPServiceInstance -confirm:$false > $null

From my testing I found that there are 4 different States that a SharePoint Service can be in:

When a service is initially stopped it will temporarily be listed as = Unprovisioning

Once fully stopped the Service Status will = Disabled

Service Started initially = Provisioning

Sevice Started will eventually = Online

The reason this is important is that if you create a custom script based PowerShell monitor you need to either account for each of these states in your script or alternatively you could get around this with something like any state other than Online would be considered Unhealthy. From here I had enough info to start writing a custom management pack. My original script treated ‘Provisioning’ and ‘Online’ as Healthy and ‘Unprovisioning’ and ‘Disabled’ as Unhealthy. This was then changed in a later revision so that only Online would be considered healthy since you could theoretically have a situation where a service is stuck in a provisioning state for a protracted period of time. I then explicitly gave ‘Provisioning’, ‘Unprovisioning’, and ‘Disabled’ a Status of Unhealthy, this allowed me add one additional status whereby if the script returns anything other than an expected state it will flip to a warning state indicating that either the Run As account is not properly configured or the service isn’t actually present on the server you are targeting.

The basic script is below:


I will skip over the details of how I converted this into a functional management pack, but the end result is an extended MP. By default all monitors are disabled and targeted against the SharePoint 2013 Server Class. You will need to override and enable on a case by case basis as it is likely that your SharePoint team will only care about monitoring certain services on certain members of the Farm.


Since most SharePoint environments are not fully accessible via the default action account I have added a custom Run As Profile:


Just add/associate your Run As account that has SharePoint Farm Admin privileges and you should be all set.

If you neglect to configure the Run As or you enable the monitor on a server that doesn’t have the target service you will get the following:


I tweaked the associated Alert Status for the Run As Warning to critical just so it won’t get missed.


Other than that the pack is fairly self explanatory, when a service is stopped within 15 minutes you will get an alert as below:


As with all MP’s of this nature this is a proof of concept “As-Is” pack. Script based monitoring (Particularly PowerShell based monitoring) can be some of the most intensive monitoring you can perform on a system in terms of overhead so you should test thoroughly first and insure that the extra scripts running is not negatively impacting performance.

Currently the pack does not implement cookdown. Normally you would want to limit impact by having a module that runs a single script that queries the status of all relevant services at once and then is referenced by multiple monitors. Currently there is a 1:1 relationship for each monitor, so there is a separate script for each monitor and thus a higher impact on the system. If time allows I will rewrite to properly implement cookdown but in the meantime feel free to take apart the MP and build something better/more efficient, but this should at least help get you started.

Download from: TechNet Gallery

The contents of this site are provided “AS IS” with no warranties, or rights conferred. Example code could harm your environment, and is not intended for production use. Content represents point in time snapshots of information and may no longer be accurate. (I work @ MSFT. Thoughts and opinions are my own.)