Freigeben über

Management Pack Authoring in the VSAE - Tips and Tricks

  • Artikel

I started authoring management packs (MPs) in System Center Operations Manager (SCOM) when the 2007 version was released. At that time the Authoring Console was not out so I had the pleasure of learning to author in the XML directly. This was difficult at the time but I’m thankful I went through it because I still use those skills today. Another important skill that helps when authoring management packs is having a development background. At least being able to development PowerShell scripts will prove valuable because at some point scripting will be necessary in order to create an advanced custom management pack.

Tip # 1 – Don’t re-invent the wheel

The System Center 2012 Visual Studio Authoring Extensions (VSAE) can be challenging to use if you’ve never authored management packs before since it really does require some knowledge of the XML schema. This brings me to my first tip, if you aren’t sure how the XML should look then find and/or create something similar. Sometimes you can use the console, another authoring tool, a blog, or my personal favorite – searching a directory of exported management packs. In my lab I import and create lots of MPs. I will periodically use PowerShell (Get-ManagementPack | Export-ManagementPack –Path c:\temp\mps) to export all the MPs into a directory that I then use to search for examples usually using the name of the module I’m trying to use in my management pack.

Tip # 2 – Create portable solutions

My next tip involves making your VSAE solution portable. I almost always save my VSAE projects to Team Foundation Server (TFS) so if you have access to one I highly recommend it. Even if you don’t it’s still a good idea to make your VSAE projects as portable as possible. If you get a new machine, need to use the VSAE on another machine, or share your project with someone else they might get errors when trying to open or build your project. This is because certain items in your project, like the key you use to seal your MPs or the MP references you use, might not exist in the same place or at all on the machine you’ve moved your project to. You can fix this and I usually do it for all the projects I create:

  • Copy any referenced management packs (In Solution Explorer under your project\References), the key you use to seal your MP, and any other necessary files and aren’t explicitly added to your project to a directory at the same level as your management pack solution (solution name.sln file). I use Resources as my directory.
  • Close the project in Visual Studio
  • Go to the project folder and open the <Your Project Name>.mpproj file in a text editor
  • Find anything with a static path like c:\ and change it to ..\Resources\<filename>

Save the project file and reopen Visual Studio. Be sure to do the same thing if you add any additional references to the management pack. Now you should be able to copy this entire VSAE solution to another machine, open, and build it without errors.

Tip # 3 – Create a naming convention and stick to it

Some of the authoring consoles and certainly the product consoles do a poor job of naming items in a management pack. They either use GUIDs or ignore the namespace of your management pack. I tend to use Custom.Example.MyMP for the MPs I author. If I need to add a class then the ID would be Custom.Example.MyMP.MyClass. If I need to add a rule then the ID would be Custom.Example.MyMP.Rule.MyRule. This makes navigating the MP and finding items in it much easier. If I start my MP in another console and pull it into the VSAE I usually fix the IDs to adhere to my convention above.

Tip # 4 – Organize your solution

I create folders under each project for the type of items I plan to put in it. If my solution creates multiple MP files then I add new projects to the same solution. This makes your solution more modular and easier to navigate. Here is an example of one of the more recent MPs I wrote.

image

Tip # 5 – Keep your language packs in the same MP fragment as the items it refers to

I find it much easier and portable if every MP fragment (mpx) I create contains its own language packs section for the items that exist in that mpx. Here is an example of a rules fragment I created, notice that I also chose to put the Presentation section for the alert that the rule creates in the same mpx as well.

image

Tip # 6 – Always reference code files from the MP XML

If your MP contains scripts, TSQL, etc… then reference the file containing your code from the MP XML rather than pasting it directly into the MP. This makes the MP much cleaner and the code separate from the XML until it’s compiled. Here is an example of both PowerShell scripts and TSQL queries that I reference in the MP:

image

To reference the file from the MP XML you must use the IncludeFileContent along with the path to the file like I did below:

image

Tip # 7 – Snippets are your friend

Funny story, earlier this year I was sitting in a hotel lobby bar in Washington, DC and “The” Kevin Holman called me. Kevin asked me how I would author ~200 performance collection rules. My answer, as usual, was that it depends. Is this a one time thing or are you regularly going to have to create these? If this is a regular occurrence then PowerShell might be the best way to do it. However, if this is something that you just need to do once then Snippets are the way to go. He was hesitant because he hadn’t really used the VSAE yet but I talked him into giving it a shot… About a week later Kevin posts a blog on how to do it: How to use Snippets in VSAE to write LOTS of workflows, quickly!

Tip # 8 – The Management Pack Browser is a hidden but very useful feature

To get to the Management Pack Browser you can click on View\Management Pack Browser. You can also right-click on any module in your MP and choose “Go to Definition”. This helps if you need to see what parameters you can pass into a module. The MP Simulator can also be launched from the Management Pack Browser. Just right-click on any monitor, rule, or discovery and choose MP Simulator. Also, once you launch the MP Simulator if you want to see additional tracing from the module you need to right-click in the whitespace under “Start Simulation” and check “Enable Tracing for the whole workflow”.

Tip # 9 – Stick with Empty MP Fragments

With the exception of snippets I rarely use anything other than empty mpx files when authoring in the VSAE. I find the limited UI for some of the items to be more confusing than just authoring directly in the XML. If more UI work is done in the future then I might change my mind.

Tip # 10 – The VSAE isn’t always the right tool for the job

Today I almost exclusively use the System Center 2012 Visual Studio Authoring Extensions (VSAE) to author both SCOM and System Center Server Manager (SCSM) management packs. There are some exceptions to this:

  • Instance level overrides, or anything that requires a GUID in the XML. It is easier to do this in the console since it finds the right GUID for you.
  • Views and dashboards. I find this cumbersome to try and do outside of the console.
  • Forms in Service Manager. The Service Manager Authoring Tool works best for this.

In most cases, especially if I am sharing the code, I will start creating these exceptions in the consoles but might later pull what I authored into the VSAE and clean up the XML.

 

New to Management Pack Authoring?

  1. Learn PowerShell first if you don’t already know it, you will need it at some point
  2. If you’re authoring MPs for Service Manager then it might also be helpful to learn Orchestrator and/or Service Management Automation (SMA)
  3. For System Center Operations Manager, start with Silect’s free MP Authoring Tool
  4. For System Center Service Manager, start with the SCSM Authoring Tool
  5. Check out Brian Wren’s video series on MP Authoring

Comments

  • Anonymous
    August 14, 2014
    Excellent info. Thanks Russ

  • Anonymous
    August 15, 2014
    Excellent post on VSAE authoring best practices. Thanks, Matthias

  • Anonymous
    August 25, 2014
    It appears that you are unable to import a management pack that you created in scom originally, is this true? Or am I missing something silly?

  • Anonymous
    August 25, 2014
    Jeffrey, When you first create the project there is a wizard that allows you to bring in an existing management pack (In Visual Studio go to NewCreate Project from Existing Management Pack). I never use this. All it does is import in your XML and make it one giant mpx file. Instead, I organize my project into individual MPX files and copy/paste from my existing management pack. Russ

  • Anonymous
    November 05, 2014
    Thanks for tips Russ.   Can you elaborate a litle more this one: "searching a directory of exported management packs. In my lab I import and create lots of MPs. I will periodically use PowerShell (Get-ManagementPack | Export-ManagementPack –Path c:tempmps) to export all the MPs into a directory that I then use to search for examples usually using the name of the module I’m trying to use in my management pack." especially the part of  "using the name of the module"

  • Anonymous
    November 05, 2014
    Marco, once you get all the MPs in XML form you can search for key words in them. The module you want (Monitor Type, Data Source, Probe, Condition Detection, Write Action, etc...) can be found in the XML and you can learn how it works once you find it. For instance, I might have a performance collection rule that uses the System.Performance.OptimizedDataProvider data source but I don't really understand how that data source works. I can search the XML and find where that is defined (System.Performance.Library.xml). Once found I can see the parameters this data source takes (including optional params), the overrides defined, and the modules that it uses to get the performance data and filter it for optimization.

  • Anonymous
    November 05, 2014
    The comment has been removed

  • Anonymous
    November 05, 2014
    The comment has been removed

  • Anonymous
    November 06, 2014
    Thanks for sharing Russ. Personally I still prefer to use this library http://systemcentercore.com They have indexed all ops and sm management packs by version, with a nice interface, easy to search through and get to the xml. Cheers, Marco

  • Anonymous
    November 07, 2014
    That's a fine alternative if you're only searching common libraries. I often forget how I did something in an MP I wrote years ago so I like to have everything, including the common stuff, local.