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
This is to fit in with the general Microsoft way of naming management packs – you can have more than one project in a solution and doing it this way means I can separate out my monitoring (projects) into Monitoring, Discovery and potentially presentation management packs. In practice, I almost always put my monitoring, discoveries and presentation components in the same (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:
Now; lets keep 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.