Kevin Holman's OpsMgr Blog : Notification

Alert Notification Subscription Variables, and linking that to the console, database, and SDK

kevinhol — Wed, 23 Sep 2009 20:54:00 GMT

Attached you will find a spreadsheet, with all the possible alert notification subscription variables that I am aware of. In this spreadsheet, I link these to the same values in the Alert table of the DB, the alert view of the DB, the Console alert view, the SDK (Get-Alert), and lastly the new R2 Connector Key pairs.

My thought was to better understand each data property type of an alert, and what you can managed, from each area. Hope this is beneficial.

Most of these are listed at my other blog post on alert description and notification variables: http://blogs.technet.com/kevinholman/archive/2007/12/12/adding-custom-information-to-alert-descriptions-and-notifications.aspx

Here is a sample shot of the spreadsheet tool:

See attached:

Creating custom dynamic computer groups based on registry keys on agents

kevinhol — Wed, 10 Jun 2009 07:09:48 GMT

I have had a few requests now for this, so I thought I would take the time to write up the process.

Lets say I have three support levels of servers:

Level 1 – servers critical to business operations (ex: customer facing web applications, SQL back-ends)

Level 2 – important servers (ex: messaging, internal apps)

Level 3 – non-essential servers (ex: non-critical or highly redundant internal apps)

Lets say we want to create overrides for certain rules… where we will page on anything in Level 1 group, email notify on Level 2 group, and simply alert for Level 3. Possibly we want to create views, and only see alerts for Level 1 servers. Perhaps we wish to scope users so they only see Level 1 and Level 2 servers in the console?

Well – the first step is to place these servers into groups.

Sure – we can do this manually, with explicit assignments to the group. But that is resource intensive over time, and we might miss one down the road. I’d prefer to dynamically create the groups of Windows Computers based on a name…. but this can be difficult sometimes – where we don't have a solid naming scheme, or other criteria to group by.

I will demonstrate another way to accomplish this… by coming up with a business process to use a registry key on your managed servers, and collect this registry attribute with SCOM. Then – use this Registry attribute for dynamic group memberships.

Ultimately – there are three simple steps to this process:

1. Create registry keys on agents.

2. Extended a class with an attribute, to discover the registry keys and values.

3. Create dynamic groups based on the attribute values from the registry.

It is just that simple.

To get started – lets talk about our custom registry key. For this example, I am going to create a new Key at HKLM\Software\ and call it “CompanyName”

Next – in that key – I will create a new DWORD Value, named “SupportLevel”

Lastly – I will assign a numeric value to “SupportLevel” on each server, either 1, 2, or 3.

In my environment…. my Hyper-V servers are critical. They host all of my VM’s, including many business critical applications. Therefore – they will get Level 1.

My Exchange 2007 servers handle all my mail traffic and notifications, so I will set their registry value to Level 2.

My Exchange 2003 servers have been retired – for MP testing only… so we will set those to Level 3.

Here is a table that shows what I am planning:

ServerName	SupportLevel
VS1	1
VS2	1
VS3	1
EX1CLN1	2
EX1CLN2	2
EXCAS	2
EX2CLN1	3
EX2CLN2	3
OWA	3

So – I get all my registry values set on all computers. This is a big job at first, but it is a one time deal, and you can even script it if you are handy.

Next… we need to discover these registry entries in SCOM, as attributes of a class. Then were can use that attribute to group objects. Since I want Windows Computer objects in my groups (Windows Computer is a good object for most overrides, scoping, notifications…etc..) we would like to have these attributes added to the Windows Computer class.

However – there is a problem. The Windows Computer object is in a sealed MP. We cannot just add information to that class as we would like. Therefore – OpsMgr allows us to “Extend” an existing class… and add our custom attributes to it. This “Extended” class is basically a copy of the existing class… it will have all the built in attributes of Windows Computer, and will also have our custom attribute properties. It’s is easier to see it than to talk about it.

First – in the Ops console – authoring pane – go to Attributes. Create a new attribute. I am going to call this one “SupportLevel”

Next – choose “Registry” for the discovery type.

Next – We need to pick the Target class. We want Windows Computer. Note – this will create a new class, named “Windows Computer_Extended” by default. We can use this name, or you can rename this whatever you want. It is your class. I will leave it at the default.

Most important! Management Pack location.

This is CRITICAL. Spend some time making sure you are creating these attributes in the correct location. If you leave this MP unsealed XML…. then any groups you create that use these attributes, will have to be placed in this same MP. Then – if you use these groups for Overrides – those overrides will be force to go in this same MP. There is a “cardinal rule” in SCOM… objects in one unsealed MP cannot reference another unsealed MP. So – we cannot have a group in one unsealed MP, and then use that group for an override in another unsealed override MP.

So – we have two choices.

1. Keep an unsealed MP… and live with the fact that attribute, group, and override will all have to be placed here.

2. Create the attribute and the dynamic group in the MP, then seal it. Then – you can use this group in ANY of your override MP’s… for Exchange, SQL, etc…

I strongly recommend option #2 for this exercise… but you can make this decision for yourself.

Ok…. I will choose Option #2 (seal the MP), so I will create a new MP just for this extended class, and groups.

On the next screen – we can put in our registry information:

In this example – I am looking for a registry Value (1, 2, or 3), and my attribute type is “Int” for integer.

For the frequency, set this to a reasonable frequency to discover you machines as they come on to you network. Typically, once per day is sufficient (86400 seconds) Remember – this will run against ALL your Windows Computers… so never set this more frequent than once per hour… that creates unnecessary overhead.

Ok – lets examine our work!

Go to Monitoring, Discovered Inventory, and change target type to our new class “Windows Computer_Extended”

If you do this quickly – you may find it is empty. This is what is happening behind the scenes: All Windows Computers are now downloading our newly created MP. They are going to run the registry attribute discovery, and submit their discovery data to the management server. The Management Server will insert this discovery data in the database. Over time, you will start to see all your Windows Computers pop into this class membership. You will notice a new attribute now, in addition to all the existing Windows Computer attributes. This attribute is “SupportLevel” and will be 1, 2, 3, or empty… depending on what each agent find in the registry.

Now – I set my registry discovery to once per day…. so I will need to wait 24 hours before I can expect all my healthy agents to show up in this list. To speed things up – I am going to bounce the HealthService on these example agents. (Agents run all discoveries when a HealthService restarts, and then on their frequency schedule)

Here is an example a few minutes after bouncing the HealthService on some agents:

Next on the list – create the groups. I will create these in the same MP that the attributes exist in.

I will call my first group “CompanyName – Support Level 1 Servers Group”. I like to append the word “Group” to all groups I create as a best practice. This helps us determine this group class is actually a group when we see it in the list of classes in the UI. I sure wish all MP authors would take this to heart, since every group is actually a singleton class.

On the dynamic members screen – I will fins my “Windows Computer_Extended” class – and click Add. What we now see – is that we have a new attribute to use, “Support Level”

I will set this group to “SupportLevel Equals 1” and click OK.

Now – I can right-click my new group – and choose “View Group Members”

Yee-haw! It works! Now – I simply repeat this above step – creating groups for SupportLevel 2, and 3.

Now – that is done. This is the area, that I recommend we stop… take a breather…. then seal the MP. If you seal the MP – we will be able to use the groups for overrides in any other override MP. If you choose not to seal the MP now… any overrides you use the groups for – will be forced into this same MP. Please keep that in mind.

Since I am harping on sealing the MP…. I am going to do a quick example of just that. Jonathan Almquist has an excellent tutorial on sealing MP’s HERE and we will use his example.

**Note – when running the sn.exe commands to create our key…. we only need to do this one… not every time we want to seal an MP.

***Critical note – you need to keep a backup of this key… because it will be required for making updates to this MP in the future, re-sealing, and keeping the ability to upgrade the existing MP in production.

So, I create the folders, create the key using sn.exe, copy over the referenced MP’s from the RMS, and now I am ready to seal.

MPSeal.exe c:\mpseal\input\CompanyName.SupportLevel.MP.xml /I "c:\mpseal\mp" /Keyfile "c:\mpseal\key\PairKey.snk" /Company "CompanyName" /Outdir "c:\mpseal\output"

Works great.

Now – I can delete my unsealed MP from the management group, and import my sealed MP.

Phew. All the heavy lifting is done. Now… I have my groups… I can start setting up overrides using these groups, or scoping notifications.

On my Support Level 1 group – I will use this to set up my pager Notification subscriptions to only page based on specific classes, and this group.

On my Support Level 2 group – I will use this to override important alerts to High Priority… because I am using High Priority as a filter for email notifications, per my previous blog post here: http://blogs.technet.com/kevinholman/archive/2008/06/26/using-opsmgr-notifications-in-the-real-world-part-1.aspx

On my Support Level 3 group – I will use this group for tweaking/disabling rules and monitors for the group… turning off discoveries so they don't discover lab servers, scoping views, etc.

Maybe in my next post…. I will build on this MP… and show a really simple way to add the Health Service Watcher objects to these dynamic groups… for each Windows Computer object that is in the group – so we can use these groups for Heartbeat failure notifications.

Creating granular alert notifications - rule by rule, monitor by monitor

kevinhol — Sun, 12 Oct 2008 20:56:00 GMT

Using OpsMgr Notifications in the real world - Part 2

This is a continuation of my advanced notifications posts.... from http://blogs.technet.com/kevinholman/archive/2008/06/26/using-opsmgr-notifications-in-the-real-world-part-1.aspx

There are a couple resources on the web about how to do this from C# and Powershell. The best sites I have seen are at:

http://blogs.msdn.com/jakuboleksy/archive/2007/01/18/notification-subscriptions.aspx

and

http://code4ward.net/cs2/blogs/code4ward/archive/2007/09/19/set-notificationforalert.aspx

These examples are cool - showing us we can create more granular criteria than the choices exposed in the UI.

In the second link above - the basic Powershell script is posted. However, many users have been looking for examples of how to add more specific and typical criteria. The script above will notify on any change in resolution state.... so if you use multiple resolution states, it might send an email when the alert is created, then modified, then closed. Many want a notification only when an alert comes in New.

The posted script also shows the Last Modified time in the notification in GMT.... where as a UI generated subscription would show the alert time in the correct local time zone.

The post below will show some of the changes you can make here, and some example scripts.

First things first.... let's talk about what happens when you create a normal subscription in the UI: When you run the New Subscription wizard in the UI, you are selecting from what was determined to be the most typical choices for subscribing to alerts for a notification. What this does, behind the scenes, is create some XML, and writes that information to the "Notifications Internal Library" management pack (Microsoft.SystemCenter.Notifications.Internal)

The best thing you can do to understand what is happening - is to create a SINGLE subscription in the UI, and then export this management pack, and open it in Notepad. What you will see - is that this MP holds all the configuration information for your SMTP server settings, default notification format, all the recipients and their information, product connector subscriptions, and the focus of this discussion: notification subscription details.

Find your simple subscription that you created - and look at the options. This will start with:

<Monitoring>
    <Rules>
      <Rule ID="Subscription(guid) plus other settings........>
        <Category>Notification</Category>

Look at all the default options.... this will help you understand the XML format and settings for notifications. Probably the most important to understand is <Criteria>. What you will see is all the criteria settings you just created, using the UI. Unfortunately - the UI does not expose all the possible settings for criteria....

So - you may ask - what settings are available?

Well - according to Jakub: "In terms of which columns you can query for in the criteria, it is anything that is defined on the Alert table in the db."

Whoa! That's a LOT more options. The following columns exist in the alert table:

AlertId
AlertName
AlertDescription
BaseManagedEntityId
ProblemId
IsMonitorAlert
RuleId
ResolutionState
Priority
Severity
Category
Owner
ResolvedBy
TimeRaised
TimeAdded
LastModified
LastModifiedBy
LastModifiedExceptRepeatCount
TimeResolved
TimeResolutionStateLastModified
TimeResolutionStateLastModifiedInDB
CustomField1
CustomField2
CustomField3
CustomField4
CustomField5
CustomField6
CustomField7
CustomField8
CustomField9
CustomField10
TicketId
Context
RepeatCount
AlertStringId
AlertParams
SiteName
ConnectorId
LastModifiedByNonConnector

So you can see - if you don't mind a little custom XML work.... you have a lot more choices when it comes to notifications. We can use this to create subscriptions to specific named alerts, or only alerts with a specific custom field value, a specific repeat count threshold, or for a specific computer, or resolution state. The possibilities get pretty good. If only this was all exposed in the UI!

Understanding, that once custom modified in XML - you will not be able to ever modify the same (non-standard) subscription in the UI, or you will break your XML customizations.

Ok - beyond criteria - what else is interesting, you ask?

<PollingIntervalMinutes> This defaults to 1 minute and should not be changed. This is how often the subscription will poll the SDK to look for new alerts and see if they match any notification subscriptions.

<TimeZone> Using the script as posted - it did not contain this tag. Therefore all alerts come in as GMT. Using this tag - you can set your specific time zone. Central standard time looks like this:

<TimeZone>6801000000000000C4FFFFFF00000B0000000100020000000000000000000300000002000200000000000000|Central Standard Time</TimeZone>

If you want to know your timezone code - just create any subscription in the UI - look at the Notifications Internal Library MP, and pull it out of there for use in scripting.

<IdleMinutes> This is the tag to use for Alert aging. This is used to delay a notification from being sent for "x" minutes, as long as it has not been changed in that time and meets all other criteria. This is used to keep notification noise down, if alerts are closed or acknoledged quickly, or to create "nag" notifications in additional subscription to "re-notify" after "x" amount of time has passed - and nobody acknowledged or closed the alert. NOTE: In order to use this tag - the class targeted MUST be set to "AlertNotChangedSubscriptionConfiguration".... instead of the default which is "AlertChangedSubscriptionConfiguration". The BEST way to understand this - is to create TWO IDENTICAL subscriptions to alerts, but set one to have alert aging enabled, set the other to not have it enabled. What you will see is that alert aging subscriptions have a XML tag like the following:

<AlertNotChangedSubscription Property="Any"> </AlertNotChangedSubscription>

Where standard subscriptions that do not utilize alert aging will have the following:

<AlertChangedSubscription Property="Any"> </AlertChangedSubscription>

Make sure you keep these clear. More on using these in scripts later.

Ok - that covers the most notable XML items. I would say, it is probably easiest to just configure the XML directly when you want to use these advanced properties that are not exposed in the UI. However, if you have the need/desire to create these types of subscriptions from script... we can do that, and let's see a couple examples.

Using the Powershell code posted from http://code4ward.net/cs2/blogs/code4ward/archive/2007/09/19/set-notificationforalert.aspx we want to make a couple changes right off the bat.

First thing - is we wont use the ProblemID field as in that example. This field of an alert is only consistent on Monitors. However - for any alert generated by a Monitor - the SDK property of ProblemID will be identical to MonitoringRuleID. Therefore, we can always use MonitoringRuleID property which will be unique and consistent, for a given alert, whether it came from a rule or a monitor.

To see these values - use get-alert in Powershell. For a more specific command to see just these properties on new alerts: get-alert | where {$_.ResolutionState -eq 0} | ft name,problemid,monitoringruleid.

By the way - in the database, the SDK property "ProblemID" = the DB column "ProblemID". The SDK property "MonitoringRuleID" = the DB column "RuleID".

Ok - so we will make the changes to use MonitoringRuleID and RuleID for all alerts. You can see the example in my attached script below... and there is an example posted at the link above.

Next - we will add the timezone information.... this is done by adding a new line under "$config.PollingIntervalMinutes = 1". The new line should look like (without wrapping, and this example is for CST):

$config.TimeZone = "6801000000000000C4FFFFFF00000B0000000100020000000000000000000300000002000200000000000000|Central Standard Time"

Lastly - we will modify the Alert Criteria with our custom subscription criteria. What we want to do - is subscribe to any alert with a given "MonitoringRuleID" GUID, which using this script, will query that value from the common Alert Name we see in the console. We can use any criteria here. Things to keep in mind - the first <expression></expression> tags are not necessary, as they are understood. Any other AND/OR groupings have to be done manually. Here is the code from the sample script (this should always be one line in the script - I wrapped it here to make it readable):

$config.Criteria =
"<SimpleExpression>
   <ValueExpression>
     <Property>RuleId</Property>
   </ValueExpression>
     <Operator>Equal</Operator>
   <ValueExpression>
     <Value>$MonitoringRuleId</Value>
   </ValueExpression>
</SimpleExpression>"

What the above will do - is to create a subscription that will match on the specific alert name given to the script, and then create a notification on ANY change to the alert.... such as when the alert is generated (New) AND when the alert is closed.

Let's add some new criteria using an AND statement - which will ONLY subscribe to NEW alerts:

$config.Criteria =
"<And>
<Expression>
    <SimpleExpression>
      <ValueExpression>
        <Property>RuleId</Property>
      </ValueExpression>
        <Operator>Equal</Operator>
      <ValueExpression>
         <Value>$MonitoringRuleId</Value>
      </ValueExpression>
    </SimpleExpression>
</Expression>
<Expression>
    <SimpleExpression>
      <ValueExpression>
        <Property>ResolutionState</Property>
      </ValueExpression>
        <Operator>Equal</Operator>
      <ValueExpression>
        <Value>0</Value>
      </ValueExpression>
    </SimpleExpression>
</Expression>
</And>"

That will work MUCH better.... if we only want to see a notification for new alerts. Keep adding to the criteria sections to get the subscription to match exactly what you want.

The only other things I changed in the script - was the echoed statement about what was shown to the user running the script:

write-Host "Executing script to subscribe to specific alert by name..."

And then I changed the formula for naming the subscription. Since these CANNOT be modified in the UI without breaking them - I changed the default naming for these script generated subscriptions:

$Subscription.DisplayName = "Script created - Do NOT MODIFY in UI - " + $NotificationRecipientName + " - " + $AlertName

This creates subscriptions in the GUI that tip any admin's off - to leave them alone:

Lastly - if we want to use Alert aging in our script - we need to change a couple of items. First - we need to add a new line for $config.IdleMinutes under the "$config.PollingIntervalMinutes = 1". Here is an example:

$config.IdleMinutes = 60

That will add an hour delay - and only notify when the alert has been unchanged, and in the console for an hour. In order to use alert aging delay - we must also change the "$config = New-Object" line from "AlertChangedSubscriptionConfiguration" to "AlertNotChangedSubscriptionConfiguration". Therefore - in order to use alert aging - you need a different script, than if you dont want alert aging.... and if you have different criteria - you will need a script for each scenario.

Below - I am attaching a zip file with a couple script examples.....

One script to subscribe to NEW alerts without alert aging, and another with alert aging.

Tips: It is probably easier just to edit the Notification MP XML for your customizations. Just remember - to ALWAYS back this file up.... and keep several copies, in case you ever modify the file in a way that is not supported.

Using OpsMgr Notifications in the real world - Part 1

kevinhol — Thu, 26 Jun 2008 22:29:33 GMT

Using notifications such as email, has proven to be somewhat difficult in OpsMgr. I get questions from each and every customer I work with on this topic.... as most people never get these to work as they want, or expect, without fully understanding the object oriented class model of OpsMgr and what that means to Notifications on alerts. Even once this is understood, there are often challenges.

First.... lets make sure we use the correct terms. Alerts are alerts.... a message that is sent to the OpsMgr database with details on something that happened. A Notification is simply a message in email, IM, SMS, etc... that is triggered by an alert.

Ok - now... on to actually using these things. :-)

First off.... notifications are configured via subscriptions. We can create a subscription and get a notification for every single alert that gets generated.... or we can filter them for specific alerts based on specific criteria.

For instance... we can subscribe to "all critical alerts" by creating a subscription that includes all classes, all groups, and just looks at "Critical" alert severity on the criteria selection.

We can subscribe to "all critical alerts coming from the exchange management pack" by creating a subscription that includes ONLY Exchange classes, All groups, and just looks at "Critical" alert severity on the criteria selection.

Further filters can be created... using groups.... such as "all critical alerts from the exchange MP for servers in Texas".

Sound good? At this point.... then - it is time to read my previous blog post on configuring notifications for specific groups and classes. It will walk you through the steps to filter based on a group of servers, or filter based on specific alerts from MP's you are interested in... and some of the issues created when you do that.

http://blogs.technet.com/kevinholman/archive/2008/02/01/configuring-notifications-to-include-specific-alerts-from-specific-groups-and-classes.aspx

Moving on.....

Now - you have set up your notification subscriptions that you like:

You have created groups that contain the Windows Computer objects and Health Service Watcher objects for each region or team.

You have created multiple subscriptions based on specific management packs... by filtering the subscription based on class, and group.

You have also specified specific criteria for these subscriptions... like only getting critical alerts in email.

Everything seems to be going well.... when someone throws a big wrench in your plan. You get major complaints with your system because:

Users are complaining that they are getting WAY too many emails.... because they are constantly getting flooded with noise from critical alerts.

Even with all the work you did.... filtering by specific class, and specific groups... you still get a LOT of email notifications. The FIRST focus should be on tuning the management packs and fixing problems. However, it is possible that some MP's are just noisy, or problematic, etc. You can adjust some of the alert severity to Warning... for alerts you don't want notifications.... but ultimately... you are getting too much in email.

Possibly - you want alerts in the console... but only want VERY SPECIFIC notifications on the "most critical" items. Your users have decided to set up a rule in Outlook and send all these noisy critical notifications to a folder.... to keep them out of their Inbox. This essentially makes sending these notifications useless.... because they will be ignored and annoy the end user. If we were sending them to a phone/pager... the phone/pager is constantly going off. What they REALLY want is a way to subscribe to only the alerts they deem REALLY critical. This may be from 10 rules, or 300 rules.

Using the GUI.... there is no easy way to do this. We cannot subscribe to a single rule, or monitor, that creates an alert. We can only subscribe to a CLASS... and therefore we will get email notifications for any critical alert that uses that class as a TARGET.

So.... what we need to develop is a STRATEGY for notifications... so we only get emails/pages on alerts that WE DEEM to be actionable. There are many ways to accomplish this... I will talk about a few that I have implemented with customers and seem to work pretty well.

1. Using Alert Priority as a notification filter strategy. (this blog post)

2. Using Powershell to create individual notification subscriptions for individual rules/monitors. This is blogged here:

http://blogs.technet.com/kevinholman/archive/2008/10/12/creating-granular-alert-notifications-rule-by-rule-monitor-by-monitor.aspx

3. Using the SDK and a product connector to modify alerts after they are generated, modifying some property on the alert such as Resolution State to a custom state, which we can then use as a criteria for a subscription.

4. Creating a custom class for a specific set of computers using the authoring console, and then subscribing only to that class.... therefore, we will only get alerts from rules/monitors that use that class as a target.

This is blogged here: http://technet.microsoft.com/en-us/magazine/cc983816.aspx

Ok.... let's get started.

#1. Using Alert Priority as a notification filter strategy.

This is my most preferred method right now for most scenarios. In MOM 2005... we had 7 alert severities to choose from....

This was great.... because we could make our notification criteria something like "Critical Error or higher" and then tune the alerts down or up.

Now, in OpsMgr - this won't work.... because with sealed MP's, and only three alert severities... it isn't as simple. There are just too many alerts in our default MP's that are tagged as critical... and perhaps we really don't want to bump them down to warning... we just want to pick which critical alerts to notify on. In comes "Priority".

There is a new attribute of an alert in SCOM, called Priority. High, Medium, or Low. Essentially, when you think about this - we now have 9 possible states for an alert "severity": Critical High, Critical Med, Critical Low, Warning High, Warning Med.... etc...etc...

In almost all of the default management packs you download... the alert priority is set to medium. We have also updated most of the MP's so that alert severity and priority are exposed as adjustable via override. This way - we can create a new notification subscription, and ONLY select "Critical" severity, and "High" priority:

What you will find.... is there you will get very few notifications by default with this criteria. This is good! The next step is to simply examine the rules and monitors that create alerts that you are interested in, and override those to change the alert priority to HIGH.

Note - when creating this override - sometimes we show the word "High" and sometimes we show the numeric number which relates to "High". In the database, this is translated numerically, just like Alert Severity is. See the table below to understand these:

Severity:

Critical 2

Warning 1

Information 0

Priority:

High 2

Medium 1

Low 0

Here is an example - I am overriding my Exchange Services Monitor alert to High priority... so I will get email notifications for it based on my subscription above:

Here is an example, for an alert for very low disk space, from a rule, where we have to use the numeric:

From that point forward, you will continue to get all the alerts in the console, but only email notifications on the alerts you want, which you set to have a HIGH priority.

So now we have a strategy! Now we can have alerts coming in the console as normal... and we will only get email notifications on specific alerts that we have deemed to be a high priority.

You could use this same design for a product connector as well... to limit what is forwarded up the chain to Tivoli, OpenView, Remedy, etc.

For part two.... see the following blog post on using powershell to subscribe to individual notifications:

Creating granular alert notifications - rule by rule, monitor by monitor

Creating a Group based on OU (Organizational Unit) in Active Directory

kevinhol — Tue, 05 Feb 2008 19:02:08 GMT

Here is a really cool feature of Opsmgr: the ability to create groups easily based on any discovered attribute of an object.

OU is something that is part of the Windows Computer object discovery. If you examine a state view – you will see in the details pane discovered information… and OU is there. Typically this means we can likely use that object (Windows Computer) and OU will be a discovered attribute of that.

This also means is we personalize a Windows Computer based state view – we can add OU:

To use a grouping, create a group, add Windows Computer object, and then a rule based on OU:

A right click – view group members reveals:

Configuring Notifications - to include specific alerts from specific groups and classes

kevinhol — Sat, 02 Feb 2008 02:29:00 GMT

So.... Say I am an Exchange Administrator in a global company.... in the good old USA.

My company has recently implemented OpsMgr 2007 to monitor our Exchange servers. I am going to configure my notification subscriptions so I can get an email anytime one of my Exchange servers has an issue.

Try #1: I start by creating a notification subscription, and I dont scope it by groups or classes (all groups, all classes). I think this sounds fine. However, instantly I find I am flooded with email notifications from every single alert coming into the console. This is NOT good!

Try #2: Therefore – I decide I really need to see only Exchange alerts. I scope the notification *classes* down to just Exchange classes. This will ensure I only receive notifications from Exchange target classes. Good? Nope.... I soon find that when an alert comes in from the base OS, or heartbeat, or hardware, we won’t get those. We need to add those classes back. If we add the heartbeat (Health Service Watcher) class – we will now get heartbeat failures for ALL machines… not just restricted to exchange servers. No good.

Try #3: So – we need to scope the subscription using groups. We create a group with all our Exchange Server Windows Computer objects in it. We can manually add these in (Explicit) or we can use a dynamic rule based on criteria - I chose NetBIOS name, and used a naming standard of EX* (all my exchange servers start with "ex"). I used an "OR" statement since the wildcard is case sensitive.

Now I create a subscriptions - and scope it to this group - and choose ALL classes.... thinking that this way, we should get ALL notifications, including base OS, exchange, and heartbeat alerts… right?

Nope. Because of the object oriented monitoring model – we will only receive alerts from a rule/monitor with a target class that has a child relationship to the Windows Computer class. This is the only class type in the group we created. So – using the model in #3, we will get notifications from pretty much any class needed – except heartbeats. These come from the Health Service Watcher class, and have no relation to the Windows Computer class.

Try #4: I am thinking, we must add the class type to our group – and any instances of that class we are interested in. Since most object classes are a child of Windows Computer, there should not be many of these that we will have to do.

In the group – add the Health Service Watcher display name instances, in the same way we add the Windows Computer NetBIOS names:

The AND/OR verbiage is misleading…. This was opened as a bug then closed – because it is “as designed”.

Essentially – The or group at the top will include ANY of the following and groups below it…. BOTH the windows computer objects AND the Health Service Watcher objects are included: (you can right click any group and choose to show members)

I tested all kinds of Exchange alerts, and heartbeat failures – and this works. It is possible there will be other alerts we wont get in this subscription.... IF the rule or monitor that created the alert was using a target class that was unique, and not a child of "Windows Computer"

I don’t think this will be a huge hassle moving forward… because MOST alerting is done on a target which is a child of Windows computer. If we find one that is not – we just need to go back and add that class’s instances to the groups we create for notifications.

Want alert by alert notifications? Where you can subscribe to a single alert, rule by rule, monitor by monitor? Check out:

http://code4ward.net/cs2/blogs/code4ward/archive/2007/09/19/set-notificationforalert.aspx

Adding custom information to alert description (s) and notifications

kevinhol — Wed, 12 Dec 2007 19:35:00 GMT

This is just a dump of some alert description variables I pulled from several other bloggers:

Custom Properties for Alert Description and Notification:

Alert Description Variables:

For event Rules:

EventDisplayNumber (Event ID):             $Data/EventDisplayNumber$
EventDescription (Description):               $Data/EventDescription$
Publisher Name (Event Source):              $Data/PublisherName$
EventCategory:                                    $Data/EventCategory$
LoggingComputer:                                $Data/LoggingComputer$
EventLevel:                                          $Data/EventLevel$
Channel:                                              $Data/Channel$
UserName:                                           $Data/UserName$
EventNumber:                                      $Data/EventNumber$

For event Monitors:

EventDisplayNumber (Event ID):            $Data/Context/EventDisplayNumber$
EventDescription (Description):              $Data/Context/EventDescription$
Publisher Name (Event Source):             $Data/Context/PublisherName$
EventCategory:                                    $Data/Context/EventCategory$
LoggingComputer:                                $Data/Context/LoggingComputer$
EventLevel:                                         $Data/Context/EventLevel$
Channel:                                             $Data/Context/Channel$
UserName:                                          $Data/Context/UserName$
EventNumber:                                     $Data/Context/EventNumber$

For Repeating Event Monitors:

EventDisplayNumber (Event ID):              $Data/Context/Context/DataItem/EventDisplayNumber$
EventDescription (Description):                $Data/Context/Context/DataItem/EventDescription$
Publisher Name (Event Source):              $Data/Context/Context/DataItem/PublisherName$
EventCategory:                                      $Data/Context/Context/DataItem/EventCategory$
LoggingComputer:                                  $Data/Context/Context/DataItem/LoggingComputer$
EventLevel:                                            $Data/Context/Context/DataItem/EventLevel$
Channel:                                                $Data/Context/Context/DataItem/Channel$
UserName:                                             $Data/Context/Context/DataItem/UserName$
EventNumber:                                         $Data/Context/Context/DataItem/EventNumber$

Performance Threshold Monitors:

Object (Perf Object Name):                    $Data/Context/ObjectName$
Counter (Perf Counter Name):                $Data/Context/CounterName$
Instance (Perf Instance Name):              $Data/Context/InstanceName$
Value (Perf Counter Value):                   $Data/Context/Value$

Service Monitors:

Service Name                         $Data/Context/Property[@Name='Name']$
Service Dependencies             $Data/Context/Property[@Name='Dependencies']$
Service Binary Path                $Data/Context/Property[@Name='BinaryPathName']$
Service Display Name             $Data/Context/Property[@Name='DisplayName']$
Service Description                 $Data/Context/Property[@Name='Description']$

Logfile Monitors:

Logfile Directory :                  $Data/Context/LogFileDirectory$
Logfile name:                        $Data/Context/LogFileName$
String:                                  $Data/Context/Params/Param[1]$

Logfile rules:

Logfile Directory:                   $Data/EventData/DataItem/LogFileDirectory$
Logfile name:                        $Data/EventData/DataItem/LogFileName$
String:                                  $Data/EventData/DataItem/Params/Param[1]$

Notifications:

$Data/Context/DataItem/AlertId$                                       The AlertID GUID
$Data/Context/DataItem/AlertName$                                   The Alert Name
$Data/Context/DataItem/Category$                                    The Alert category
$Data/Context/DataItem/CreatedByMonitor$                       True/False
$Data/Context/DataItem/Custom1$                                     CustomField1
$Data/Context/DataItem/Custom2$                                    CustomField2
$Data/Context/DataItem/Custom3$                                    CustomField3
$Data/Context/DataItem/Custom4$                                    CustomField4
$Data/Context/DataItem/Custom5$                                    CustomField5
$Data/Context/DataItem/Custom6$                                     CustomField6
$Data/Context/DataItem/Custom7$                                     CustomField7
$Data/Context/DataItem/Custom8$                                     CustomField8
$Data/Context/DataItem/Custom9$                                     CustomField9
$Data/Context/DataItem/Custom10$                                  CustomField10
$Data/Context/DataItem/DataItemCreateTime$                      UTC Date/Time of Dataitem created
$Data/Context/DataItem/DataItemCreateTimeLocal$               LocalTime Date/Time of Dataitem created
$Data/Context/DataItem/LastModified$                                 UTC Date/Time DataItem was modified
$Data/Context/DataItem/LastModifiedLocal$                          Local Date/Time DataItem was modified
$Data/Context/DataItem/ManagedEntity$                               ManagedEntity GUID
$Data/Context/DataItem/ManagedEntityDisplayName$             ManagedEntity Display name
$Data/Context/DataItem/ManagedEntityFullName$                   ManagedEntity Full name
$Data/Context/DataItem/ManagedEntityPath$                          Managed Entity Path
$Data/Context/DataItem/Priority$                                          The Alert Priority Number (High=1,Medium=2,Low=3)
$Data/Context/DataItem/Owner$                                           The Alert Owner
$Data/Context/DataItem/RepeatCount$                                  The Alert Repeat Count
$Data/Context/DataItem/ResolutionState$                               Resolution state ID (0=New, 255= Closed)
$Data/Context/DataItem/ResolutionStateLastModified$                 UTC Date/Time ResolutionState was last modified
$Data/Context/DataItem/ResolutionStateLastModifiedLocal$          Local Date/Time ResolutionState was last modified
$Data/Context/DataItem/ResolutionStateName$                       The Resolution State Name (New, Closed)
$Data/Context/DataItem/ResolvedBy$                                     Person resolving the alert
$Data/Context/DataItem/Severity$                                          The Alert Severity ID
$Data/Context/DataItem/TicketId$                                           The TicketID
$Data/Context/DataItem/TimeAdded$                                       UTC Time Added
$Data/Context/DataItem/TimeAddedLocal$                               Local Time Added
$Data/Context/DataItem/TimeRaised$                                      UTC Time Raised
$Data/Context/DataItem/TimeRaisedLocal$                              Local Time Raised
$Data/Context/DataItem/TimeResolved$                                  UTC Date/Time the Alert was resolved
$Data/Context/DataItem/WorkflowId$                                      The Workflow ID (GUID)
$Data/Recipients/To/Address/Address$                                    The name of the recipient

The Web Console URL:
$Target/Property[Type="Notification!Microsoft.SystemCenter.AlertNotificationSubscriptionServer"/WebConsoleUrl$

The principalname of the management server:
Target/Property[Type="Notification!Microsoft.SystemCenter.AlertNotificationSubscriptionServer"/PrincipalName$

Severity:
	Critical	2
	Warning	1
	Information	0
Priority:
	High	2
	Medium	1
	Low	0