All posts by Jonathan Almquist

Authoring

Create a class – visual studio authoring extensions (vsae)

5 Comments

In this post, I want to demonstrate how easy it is to create a class using Visual Studio Authoring Extensions. This is in response to some blog posts out there (like this one and this one) that describe this task as “difficult” outside of a 3rd party tool. It’s actually extremely easy!

Let’s take a look at how easy it is to create a class using VSAE.

<TypeDefinitions> 
  <EntityTypes> 
    <ClassTypes> 
      <ClassType ID="ToolAndDie.Class.Computer" Abstract="false" Accessibility="Public" Base="Windows!Microsoft.Windows.ComputerRole" Hosted="true" Singleton="false" /> 
    </ClassTypes> 
  </EntityTypes> 
</TypeDefinitions>

Yep – it’s really that easy to create a class. Now all you need to do is discover it, and it’s actually just as easy to do that, especially if you’re using the registry.

My suggestion is, if you are new to authoring management packs, just take the leap into VSAE. There is no benefit in using 3rd party tools, like MP Author by Silect. I say that because, you’re not really picking up a new skillset by using these types of UI tools – however, you do pickup a new skillset that can be useful in other areas of your job by learning the language (XML).

There is a learning curve to everything – make the wise choice for your career.

Administrative Tasks, Authoring, Best Practices

Best Practices – Alert Priority

3 Comments

It’s been a while since I’ve written a best practices article. I thought about an interesting one the other day I wanted to share. Alert priority is one of those configuration elements that seems to stay tucked under the covers in the vast majority of environments that I’ve worked in, but it can be an integral piece of operations – it’s also something to consider when developing management packs.

Because of this, I think it’s a good idea to take a look at alert priority from two perspectives; development and operations.

Development Perspective

This is a well known practice for management pack development, but I’ve actually seen vendors not adhere to this practice in their management packs (including Microsoft). That is – alert priority should ALMOST ALWAYS be set to medium in a management pack. A developer should not presume the priority of an alert for a couple reasons:

1. Developers do not know what a customer considers high priority, and;

2. Customers should have the ability to freely use alert priority in processing alerts without having adverse effects.

The only case a developer should set alert priority as anything but medium, is to set is as low priority. In no case should a management pack be sealed with any alert priority being set to high.

Operations Perspective

Alert priority can be an integral part of processing alerts. Whether a command channel is implemented, another System Center product is used (Orchestrator or Service Manager), or perhaps a 3rd party product connects to your environment; Alert priority should be one of the top 3 criteria in determining whether an alert should be processed.

Fortunately, most vendor management packs do set default alert priority to medium (or low). Hopefully the days are gone when some developers set default alert priority to high.

This means that you, as a SCOM administrator, can easily add alert priority as a criteria for alert processing. This can be accomplished by setting overrides for select alert-generating unit monitors and rules. In my opinion, the best way to go about this is to use MPViewer, because you can export the management pack to an Excel spreadsheet and hand that to the group that monitors the application for review.

Once the application group has reviewed the spreadsheet and selected the alerts in which they want to be notified on, they send it back and the SCOM team can set overrides on those workflows by updating alert priority to high. If your company employs the Advanced Operators role, then there is really nothing you need to do but provide them with the spreadsheet, because then you can assign a member of the application team the privilege to update alert priority based on their requirements and when they want. The latter will dramatically reduce administrative overhead, and overall this would reduce complexity of subscriptions.

Finally, the benefit of using alert priority as a processing criteria is enormous. For example: if you just select all classes of the SQL management pack to send email notifications to the database administration team, the potential for them to ignore all email notifications is high; however, if alert priority is implemented correctly, you enhance the user experience by only sending notifications that the application team actually want to receive. This is a win-win situation.

 

If you have any best practices suggestions you’d like me to write about, let me know in the comments section or send me an email. Thanks for your readership 🙂

 

.

Authoring

New monitoring for existing vendor classes

Leave a comment

I’ve seen this question come up a few times in the forums, and thought I would write a quick post on correct targeting for monitoring instances of an existing class.

For example, let’s say you have the Exchange 2013 management pack installed and you want to collect some additional counters on Exchange Server 2013. You can easily create these counters, either by using the Operations Console or Visual Studio Authoring Extensions (or you favorite xml editor), and target the rule/monitor correctly.

You will need to add a reference to the Exchange pack either way. If you are using VSAE, it’s very easy to do this. If you are using some other xml editor, then you need to add the reference to the manifest section of you custom pack. VSAE is always going to be the easiest way to add references and target a sealed vendor public class.

If you are using an xml editor, an easy way to figure out what class to target is to open the pack with MPViewer and then taking a look at the Exchange Server class.

image 

If you click on the Raw XML tab in the details pane, you will see the class id you need to put into the target of your new rule or monitor.

image

Another easy way to find the class id of your target is to use the Operations Command Shell. For example:

get-scomclass -displayname ‘Exchange Server’ | select name, id

These are just some options for finding the correct class id. If you are creating these monitors/rules using the Operations Console, then you don’t need to worry about finding the class id – the Operations Console will automatically add the correct id and give it a UI namespace.

Please target responsibly.

 

🙂

VSAE Fragment

Health Service Watcher Group based on Domain Name

Leave a comment

Just added a fragment file to GitHub that demonstrates how to add a health service watcher group based on domain name. This can be useful for multi-tenant environments that need to implement user role scoping and notifications where the customer wants to see health service heartbeat failure alerts.

Just update the ID’s, display names, and the regular expression pattern to fit your environment.

You can view and download the fragment here.

 

🙂