This is the third of the four part series that describes how to create custom groups to scope the Operations console, used through the rest of this series:

• Part 1: Creating Custom Groups
• Part 2: Using Custom Groups to create Views
• Part 3: Using Custom Groups with Subscriptions & Using One-Off Notifications
• Part 4: Using Custom Group to secure Views

This blog post uses custom groups, created in the first part of this series, with subscriptions and one-off notifications.

Creating Custom Groups with Subscriptions

Start by logging into a domain controller and creating a distribution list (OpsMgr_(Function)Admins) and mail-enable the distribution list. If there is an existing distribution list for the group you can use it rather than creating a new distribution list. Note that throughout this posting and series (Function) refers to Security.

Add the appropriate members to the group.

In the Operations Manager console, create a subscriber for this function in the Administration node under Notifications –> Subscribers; right-click and choose New subscriber.

Create the subscriber name as <OpsMgr_><Function><Admins>

Configure using the default to Always send notifications.

Specify the subscriber address name as <OpsMgr_><Function><Admins>

Specify the delivery address as <OpsMgr_><Function><Admins@odyssey.com>

Now create a subscription/channel/distribution group for this Function in the Operations Manager console on the Administration node under Notifications –> Subscribers. Right-click and choose New subscription.

Create a description/subscription name for this Function with <Critical ><Function>< Alerts>

On the Criteria page, specify the criteria to only notify on the following alerts:

• for an instance of the group (<OpsMgr_><Function> <Servers>, created in the first part of this series, http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!1940.entry)
• of a critical severity
• of a high priority
• with a new resolution state

Specify the subscriber name specified earlier (<OpsMgr_><Function><Admins>)

Create a new Customized copy of the existing SMTP Channel – AD, customizing it to <SMTP Channel - > <Function>

On the description for the new channel create the name as <SMTP Channel - > <Function>, and provide a description of <SMTP E-Mail - > <Function>.

The copied channel should already have the multiple SMTP servers available as shown below. Change the return address to <Function>OpsMgrAdmin@odyssey.com. This is extremely useful when server administrators maintain multiple groups of servers, as they can create Outlook rules that route the email based upon the return address of the sender.

Customize the format of the notification channel to specify the <Function> at the beginning of the E-mail subject and the E-mail message. This approach makes it easy to identify where an alert came from, which is very helpful when debugging notifications.

You should be able to see the new channel as listed below.

Using this technique for creating subscribers and subscriptions provides a method to only notify on the most actionable alerts to those personnel responsible for the systems and applications.This approach can significantly lower alert volume and enables you to target alerts to the appropriate personnel.

If an alert is found to not be critical / high priority and the server owners want to receive that alert, you can easily address this by overriding the alert to critical / high priority. To override, highlight the alert and choose Overrides -> Override the Rules -> For the object:

You can override the priority to 2 and the severity to 2 (see http://blogs.msdn.com/mariussutara/archive/2007/12/17/alert-severity-and-priority-use-with-override.aspx for details on numbers for severity and priority).

Using One-off Subscriptions

Another option is to create a one-off subscription for the alert. To do so, right-click on the alert and choose Notification subscription to create the subscription as shown below.

Selecting Create launches a wizard to create a subscription based upon the criteria for the alert.

From this you can add the subscriber that was created for the group.

And you can specify the channel that you created for the group.

Using this approach makes it easy to add alerts to the notification as required, either by increasing the priority and severity of an alert, or creating a one-off subscription using the same subscriber and channel.

Acknowledgements and References

We owe a huge thanks to Kevin Holman for his concept (see references in the links provided below) as his ideas spurred this approach for us to use groups in this manner.

Additional links on subscriptions and how to use them include the following

• Real-world notifications: http://blogs.technet.com/kevinholman/archive/2008/06/26/using-opsmgr-notifications-in-the-real-world-part-1.aspx
• Via groups and classes: http://blogs.technet.com/kevinholman/archive/2008/02/01/configuring-notifications-to-include-specific-alerts-from-specific-groups-and-classes.aspx
• Granular alert notifications:  http://blogs.technet.com/kevinholman/archive/2008/10/12/creating-granular-alert-notifications-rule-by-rule-monitor-by-monitor.aspx
• Notifying on a keyword: http://contoso.se/blog/?p=290
• Notification scenarios:  http://contoso.se/blog/?p=263
• Alert Severity and Priority: http://blogs.msdn.com/mariussutara/archive/2007/12/17/alert-severity-and-priority-use-with-override.aspx

This is the second of the four part series that describes how to create custom groups to scope the Operations console, used through the rest of this series:

• Part 1: Creating Custom Groups
• Part 2: Using Custom Groups to create Views
• Part 3: Using Custom Groups with Subscriptions & using one-off notifications
• Part 4: Using Custom Group to secure Views

This blog post creates customized views that use the group created in the first part of this series.

The first step is to create a view folder using the naming convention of <_><Function> (such as _Security since this is for the Security team) under the top level of the monitoring pane. Store the folder in the management pack already created for this function. This approach puts the folders at the top level first in the list alphabetically, making them easier to locate.

Create an alerts sub-view under the new folder that was created (this same wizard is used to create the diagram, performance, state and dashboard views which follow):

Define the view to be limited to the group that was defined earlier, and limited to all alerts that are Not Equals 255 as a resolution state (all non-closed alerts).

Now, create a diagram sub-view under the new folder you created. Define the diagram to the target of the group that was created and to display two layers in a North South configuration.

Create a performance sub-view under the new folder. Define the view to be limited to the group defined earlier.

Create a state sub-view under the new folder, and define the view to be limited to the group defined earlier.

Next, create a three view dashboard with the state, alerts, and performance sub-views under the new folder.

The unpopulated dashboard is shown below. Click each area to add the views to the dashboard. Add the state view at the top, alerts in the middle, and performance in the bottom.

After the dashboard is populated, it should look like this:

The result of this is a customized dashboard, which displays the health, alerts and performance for the servers owned by the Security group. The next part of this series will take the concept of using this group and discuss how to integrate with subscriptions and one-off notifications.

When a server owner opens the full Operations Manager console for the first time, the number of management packs and options available within the console can seem overwhelming. There’s a way to alleviate this – you can use customized groups to carve-up the OpsMgr console so that individual groups that own servers can see only the information relevant to their portion of the entire OpsMgr environment.

This four part series discusses the process to create custom groups and leverage them to create views, subscriptions, and to secure views. The end result is an environment where the OpsMgr console is targeted to only provide a view of only those servers relevant to the particular group  This process is also followed to provide a target set of critical alerts specific to those groups that are created, and will provide notification of critical alerts to each group.

This article is the first of the four part series on using custom groups, and describes how to create custom groups to scope the Operations console.  This series will create a customized group, views, subscription and restricted access to the Operations Manager console for a company named Odyssey. The groups created here will be used through the rest of this series:

• Part 1: Creating Custom Groups
• Part 2: Using Custom Groups to create Views
• Part 3: Using Custom Groups with Subscriptions & using one-off notifications
• Part 4: Using Custom Groups to secure Views

First, let’s create a customized group for monitoring. Perform the following steps:

Define the function of the group: As an example – this could be Security, Great Plains, Custom Application #1, and so on. The function name needs to be a single word describing the function for the group, and will be used throughout the entire process.

Open the Operations Manager Console -> Administration node and create a management pack for the new group using the following naming convention: <CompanyName> <Function> <Servers>, as shown here using the example of Odyssey Security Servers. This management pack will store the entire configuration created with this four part series.

Now within the Operations Manager Console –> Authoring node, create a group with the server members and store it in the new management pack using the following naming convention: <CompanyName> <Function> <Servers> as shown in the next two screenshots, using the example of Odyssey Security Servers.

You can either explicitly defined the servers that belong in the group (shown below) or you can create a dynamic membership for the group. For our particular case, it was more efficient to explicitly define the servers for each group – as there was not a common way to define which servers a particular group was responsible for.

However, dynamic membership can be extremely powerful. There are many different options available for creating the group as shown in the next two screenshots. There are several blog write-ups available for how to create groups:

• Based upon AD site (http://cameronfuller.spaces.live.com/blog/cns!A231E4EB0417CB76!950.entry)
• By OU (http://blogs.technet.com/kevinholman/archive/2008/02/05/creating-a-group-based-on-ou-organizational-unit-in-active-directory.aspx)

This completes the process of creating a group within the OpsMgr console. You can use this group within the console to scope what information is shown by choosing the Scope button, highlighted in the next screenshot. Scoping does not decrease the number of folders and options available, but it does restrict what information is shown - meaning the user sees only the information related to systems within their particular groups. The next part of this series takes the concept of using this group to restrict the console further, creating views based upon the security group created here.