Do you find the Support WebCast transcripts helpful?
Let us know!

Note This document is based on the original spoken Support WebCast transcript. It has been edited for clarity.

Wally Mead: This is our second installment of sessions on MOM, and today we're going to talk about management packs, so let's go ahead and jump in and talk about our agenda for today.

The first thing we're going to talk about is how MOM, or Microsoft® Operations Manager, identifies similar agents. What that means is, how does MOM know what rules to push down to which computers? So how do we identify Microsoft SMS site servers or systems running Active Directory™ so we can push the appropriate rules down to them?

Then we'll talk about how MOM decides which rules go to which agents. There's no sense sending SMS rules down to a computer that's not running SMS, just wasting processing time and wasting memory.

Then we'll discuss implementing processing rules to agents. So how do we get the appropriate rules down to those agents?

Next, we'll talk about how MOM knows what data to collect. We'll talk about data providers and rules.

Then, on the next slide, slide 3, for the second part of our agenda we'll get into more specifics. So when you're working with processing rules, how do you go about automating responses for those processing rules? How do you have MOM automate responses to specific conditions that occur in your environment?

Then we'll focus in on the various MOM processing rule types. We'll talk about event processing rules, alert processing rules, and performance processing rules. We'll talk about how you create those and how you administer those and configure those.

And lastly, we'll talk about the rules that MOM provides by default. So we'll talk about the two management packs that Microsoft provides, which are the base management pack and the application pack.

So the first thing we'll talk about is how MOM identifies computers and knows which rules to push down. We'll discuss that first, prior to discussing processing rules specifically. So the first topic is going to be MOM computer groups (slide 2). What MOM uses computer groups for are ways to group computers for processing and management rules. So you need to have some ability of grouping similar systems together so you can push the appropriate processing rules out to those systems. You only want managed nodes to receive the rules that are appropriate for their applications, their operating system, or whatever services they have installed. In other words, all similar systems, all computers wearing the same OS, the same service pack, the same services, and the same server-based applications, have to have the same set of processing rules so that you can monitor the same information on those servers.

How MOM identifies computers is through something called computer attributes. We use computer attributes as our way of identifying computers. This is how we determine the computer's profile (in other words, its operating system that it's running, whether it's Microsoft Windows NT® 4.0, whether it's Microsoft Windows® 2000, or whether it's Windows XP), what services are running on that server (whether it's MSMQ, whether it's WIN Server, whether it's Microsoft Active Directory™ Server, or any server-based application such as SMS or SQL Server™ and so on).

(Slide 5) After we know what attributes we're using, then how we use those attributes and how we find out whether those computers match with those attributes is with a process called discovery. So there's a discovery process that MOM takes and implements and it will go ahead and query each system's registry looking through the registry to see if we can identify those specific applications or services or the operating system, and then it becomes a member of that. It's said to have that attribute resident on the computer. This discovery process occurs during a process called the managed computer scan. There's a managed computer scan process for MOM, which is where we go out and we discover systems and, basically, what we're doing is we're querying the registry to see what registry attributes they have to identify services and applications and operating systems.

The managed computer scans happen automatically every night at 2:05 A.M. That's what the default schedule is. You can go ahead and change that schedule if you wish it to be something other than 2:05 A.M. or not nightly. You can make it every x number of days and the range goes up to weekly, up to seven days. You can also force a managed computer scan anytime you want to go out there and identify new systems. For example, say you just went out and added a bunch of new domain controllers to your environment and you want to have MOM identify those domain controllers and push off the appropriate processing rules to them. You can force MOM to do a managed computer scan at any point you want.

Now, what we do with computer groups is, after we've identified systems through the attributes in the registry, then they become members of the appropriate computer groups, and then the computer groups are associated with specific processing rule groups. So that identifies which processing rules to deliver to the members of the computer group. So after we've found out that this is an SMS site server, we know that that site server needs specific rules, so we take all rules associated with SMS and push them down to that SMS site server. What we do is we discover the systems through the managed computer scan, we place them in the computer group, you associate a processing rule group with the computer group, and then we push out the rules to the members of that computer group of all the processing rule groups that are associated with that computer group, which can have multiple ones added at any single time. For computer groups, there are 47 that are built into the current versions of MOM that we have. We'll look at some of those later on.

(Slide 6) So we discussed computer attributes a little bit. Let's talk a little more deeply about that. Computer attributes are what we use to identify services and applications, such as the operating system, service pack, any services running, as well as server-based applications. What we discover are registry attributes, the registry entries. We might look for the existence of a key, so that if this key exists, then that means that it is a whatever type of a computer, or we can check the value of a key to see whether it's the correct version of the operating system or the application. For example, we have a version check for SMS to determine whether it's SMS 1.2 or SMS 2.0. So we can retrieve the value of a key. We use that to determine which operating system and what application you're running. So we'll do the scanning of those during our managed computer scan.

(Slide 7) If you don't need a computer attribute, you can actually disable it. There are a series of attributes that are built in by default. In the current version that we have, the one I'm running right now, there are 56 computer attributes that are built in. So any time you do a scan of a managed system, we're going to go out there and scan it for those 56 attributes. If you're not using some of those attributes, such as you don't have these applications installed, you don't want MOM to manage them, you can go ahead and disable those attributes if you want. Disabling them would reduce the calls to the registry that are being generated during the managed computer scan process. You can also go in there and modify the existing attributes: "I don't really want you to look at that key, I want you to look at this key," or "I want you to compare it to a different value." You can do that or you can go ahead and create your own computer attributes to help identify any type of system or application, whatever, in the registry. It's just a matter of creating an attribute that points to a specific registry location, either checking for the existence of a key or retrieving a value and putting that in your formula for the computer group membership.

Again, when you're creating computer attributes, you specify whether you're looking for the existence of a key or whether you want to retrieve a value; you specify the registry path that you're looking at and then when we do a scan we'll go ahead and do that scanning provided that computer attribute has been enabled.

(Slide 8) Now, the reason you might want to disable attributes, again, is to reduce the amount of traffic that's generated for doing these registry calls. There can be a significant amount of traffic so you do want to be careful of that and not have excess attributes that you don't really need to waste the extra network traffic and processing time. After we've done our scan looking at the attributes, then we place those computers in the appropriate computer groups. We've already talked about computer groups a little bit, but here's a little more data on them. So before you create a custom computer group, you want to make sure you have an attribute created that can be used to uniquely identify a resource that you want to be a member of this computer group, whether it's an operating system, or version, or whether it's a specific service, or whether it's a server-based application.

And then, creating new computer groups is a very simple process. You just launch off the MOM Administrator console, you go to Rules node, you expand Rules, you go to Computer Groups and you tell it to create a new computer group. When you do that, you specify what platform you want your computer group to search for, or contain members of; you can specify whether you want just primary domain controllers, or backup domain controllers, or member servers, or workstations as well. You can specify what your list of computers is as far as whether you want to take all computers, have the potential of being a member of this computer group, or only computers in specific domains, or specific computers themselves. Then you specify your formula: to be a member of this computer group you're looking at this attribute and this attribute needs to have this value to become a member of this computer group. And you can put multiple different attributes and multiple different formulas in there of operators for your computer groups.

(Slide 9) After you've created your formula, then, if you need to, you can specifically exclude or specifically include computers that might or might not be found during a scan. For example, you may just be looking at a specific domain for computers, but you know you have some SMS servers in a resource domain. So you want to have the SMS servers specifically added to the SMS servers group. So even though it might not be caught in a managed computer scan, you're saying you specifically want this computer to be a member of this group when it might not otherwise be.

Or you can exclude computers. The computer might technically become a member of this group because of its registry attributes; however, you don't really want to send down these processing rules that are associated with this computer group, to that computer. So you can specifically exclude or specifically include computers if you want to.

And then, lastly, what you do is just associate the processing rule groups to the specific computer group. So you specifying, in essence, what processing rules you want sent down to members of this computer group after the computer becomes a member. So it's a fairly simple process to create a computer group.

(Slide 10) The next thing we'll talk about is processing rule groups. Processing rule groups are where you actually create your rules and group them based on some common criteria such as an application, such as Microsoft Systems Management Server, or maybe a Windows 2000 operating system. So you're taking all the rules that you want deployed down the appropriate systems and grouping them into something called processing rule groups. Rules can be manually created by yourself, the administrator, or you'll get a series of rules when you install MOM and then the appropriate management packs, whether it's the base management pack that comes with MOM, or it's the applications management pack that you can purchase optionally, or any of the extended management packs that you might get from NetIQ or any other ISVs that we have.

So again, you have these processing rule groups that we'll go into more detail about, but you associate the processing rule groups with the computer groups. Again, the reason for doing that is to make sure you're delivering the correct rules down to the correct systems. There's no reason to send down SMS rules to a computer that doesn't have SMS installed. Or there's no sense in sending down SMS Server rules down to a computer that has been identified only as an SMS client. So the association of the processing rule groups with the computer groups and having correct attributes allows you to have MOM properly identify your systems and then send the appropriate processing rules down to those computers.

(Slide 11) When you're working with processing rule groups your processing rule groups can contain child groups. That's an effective way of grouping product rules in the server- and client-based rules. For example, if you look at Microsoft's System Management Server, there'll be child processing rule groups for SMS 1.2, then SMS 2.0. Then, if you go to SMS 2.0, it'll have child groups of SMS 2.0 client and SMS 2.0 server. And then it'll break down a little bit further from there. So you can have child processing rule groups for association of appropriate rules for the appropriate type system without having a lot of top-level processing rule groups.

You can disable processing rule groups if you need to or you can disable individual rules in a processing rule group. Whatever you need for flexibility. You can turn off entire rule groups or you can turn off individual rules inside processing rule groups.

(Slide 12) Now, we have a couple of graphics so we can hopefully show you how we implement rules on the computers. The first one is implementing processing rules at a new agent. So I want to add a new computer to my environment, I want to make it a MOM agent and push down the appropriate rules. How do we do that? If you look at the graphic, the first thing that happens is the administrator creates the appropriate computer attribute, computer group, processing rule group, and whatever processing rules that he wants to be associated with that processing rule group.

Now that, again, could be the existing system that MOM has with the existing computer attributes, existing computer groups, and existing processing rule groups with rules, or you may create your own. But you have your appropriate infrastructure setup being the attributes, the groups, and the rules. Then you initiate a managed computer scan, whether you force it as administrator or you let MOM take care of that at the scheduled interval assigned. But the managed computer scan will go out and detect the computers associated with your scan. So you specify which domains you want to scan using wild cards, just by domain name and specific computers, or wild card computers in a domain, or any computers in a domain.

MOM will go out there, identify those computers, either through Active Directory or through browsing through the Computer Browser service. Then, if they are identified such that they should be MOM agents, you can either have MOM automatically push the agent out and install the agent in that box, or you can have it in the default mode which requires administrator intervention to approve that the agent should be installed on that system. So either way, the agent gets installed. After the agent has been installed, MOM will go ahead and take the processing rules from the processing rule groups that are associated with the computer groups that the new agent has been associated with and push those rules down to the agent. But basically, the scan is the important part. That's how we detect what operating system, services, and applications are running on that computer. Then, according to that scan and the attributes, we add the computer to one or more computer groups. The agent gets deployed down to that computer, and then the processing rules associated with the processing rule groups that are tied to the specific computer groups that agent is a member of, get deployed to the agent. That's how you get rules down to a new agent.

(Slide 13) The next slide talks about how you get rules to existing agents. So I'm already a MOM agent, I've already got some rules deployed, how do I get new rules down to that MOM agent? The process is, the administrator creates a new processing rule, any one of the types that we'll talk about later on. When you create a new processing rule in MOM, then there's a process. If you look at your components, there's something called a Consolidator/Agent Manager. If you look at these on my slide, I have the data access server and the Consolidator/Agent Manager separated on the two different computers. Microsoft doesn't support that. I'm showing that simply for functionality. If you're a NetIQ customer and you have Operations Manager then you know that you can have a DAS (Data Access Server) separate from a Consolidator/Agent Manager. But in the current version of MOM we're not supporting that, so it will be a single computer. I'm separating it purely for functionality purposes.

So every five minutes the consolidator checks through the DAS up to the database asking if there are any new processing rules that it needs to know about. And if there are any new processing rules, then the consolidator will go ahead and download those new processing rules down to its cache. So the consolidator will learn about those new processing rules. If you don't want to wait, you can force the consolidator to go ahead and check more quickly than whatever its five-minute interval happens to be, where it is in that five-minute process. And then, by default, every five minutes every agent performs a heartbeat function. So it generates a heartbeat message that goes from the agent up to the consolidator and at that point the consolidator will go ahead and check and see are there any changes to the processing rules for this agent. If there are, at that point the new processing rules will be provided to that agent computer and actually go ahead and push down all the processing rules at that point in time when there's been a change to any processing rule. So for this process, because we're an existing agent, there's no scan required because MOM has identified that computer. Basically, the process is, create the new rule, the consolidator has to detect that new rule (which it does every five minutes or you can force it as an admin and then the agent has to detect or request any new rules and it does that through its heartbeat). It generates the heartbeat (which says "I'm still alive"), and it says "Hey, are there any new rules for me?" If so, we provide those rules down to the agent computer.

(Slide 14) MOM providers are methods available for MOM to accumulate date. So basically, we're telling MOM what the data sources are, what data should I be looking for at the agent, what data should I be processing? So this data can be used to generate events, alerts, performance data, and then be used for reporting as well. Each processing rule uses a single and specific provider so when you create a processing rule you specify what the data provider is for the event or alert or the processing rule itself.

There are a number of providers built into MOM and you can create your own as well. A couple of things to watch for are that in the current build, in my installation, there are 162 providers installed with a base management pack. If you go ahead and install the application management pack, that will go ahead and push out or generate a lot more providers. I think it pushes it up close to 500 providers. A lot of them are Windows NT Performance counters. In fact, the vast majority of our providers are actually Windows NT PerfMon counters that we want to monitor at specific intervals.

(Slide 15) The vast majority of our providers, again, are PerfMon counters or objects, and then providers that look for events in the Windows event log, the application log, the system log, the security log, the Active Directory log, the DNS log, file replication service, and so on. There are a series of providers that will let you look for events to see that they're going into the NT event log. There are also a few specific providers that allow you to look for specific application logs such as IIS. We have a couple of providers that look for IIS logs. There are also some script-driven providers that will go out there at certain intervals and generate some data for us through scripts. There are timed event providers, for times when you want to run this event every x number of minutes or hours. There are also some WMI providers that are built-in and those are oftentimes used for DNS as well as SNMP. And then again, as I already mentioned, you can go ahead and create your own providers and generate any type of data you want to within the MOM environment, or you can go ahead and disable or modify whatever providers are already there.

(Slide 16) Now let's get into the processing rule responses. Right before we get into processing rules we'll talk about responses. Processing rule responses are automated tasks that you can have MOM generate for you for a specific event or an alert. So basically, it's having MOM automate some sort of a process when it detects a specific condition. So it performs a known response to a known condition. For example, it restarts a computer when a specific error occurs, or it stops and restarts a service when it detects some condition.

Right now a lot of you, as administrators, already have batch files or custom scripts that you run when you detect some condition when you monitor the event log. So you're monitoring the NT event log and you see some specific event id appears and you say, "Okay, that means I have to run this script." So you go out to the command-lines and you run a script or whatever you do. Processing rule responses, all they do is allow you to configure MOM to have MOM automate that processing for you. When MOM detects that condition occurring by looking at the event log, then MOM can automate the response of running the script for you or e-mailing somebody or running some sort of a command-line program, whatever's necessary. So processing rule responses allow you to automate things through MOM, some of the things that you're doing yourself manually.

(Slide 17) Each event or alert can either not have any response at all, which means you don't want to automate anything with MOM, you just want to have it create an event and store it in the MOM database. Or it can actually have multiple responses, so you can go ahead and say, "I want to e-mail somebody or page somebody when this specific event occurs. I also want to generate an SNMP trap so that it goes to my third-party SNMP Management console that I'm using for centralized event consolidation." You don't have to have a response or you can have multiple responses if you want.

When you start looking at events and alerts, there are a different set of responses that are available for events versus alerts. Events actually have three possible responses, and we'll talk about those in the next couple slides, whereas alerts not only have those three responses that events can have, but they have two additional types of responses, and we'll look at them coming up very shortly.

(Slide 18) Event rule responses; the first thing you can do is have it launch a script. So for those of you that have custom scripts you're running, you can tell MOM to launch off that script. You can either use your custom script that you're creating, or there are 36 scripts built into the current build (my slide says 35 by mistake), and these are the scripts that have already been added to MOM. So we built those in and they're there. You'll have more scripts that'll be added when you add in the application management pack, and I'm sure there'll be scripts that'll be built-in if you install one of the NetIQ XMPs as well.

You can also create your own scripts and you can use any of the custom Microsoft scripting languages such as VBScript or JScript® or SQL scripts. Some of the built-in scripts might be something like restart a server, as we mentioned before, or do an HTTP ping, maybe go out there and check connectivity of a server, SQL Server connectivity, and so on. And then you can go ahead and create your own custom scripts.

The next type of event rule response is execute a command or a batch file. This allows you to launch off any command-line program, which could be a script, and have MOM generate that data for you, generate that response. There are a lot of different command-line parameters that you can specify with your script if you need to, or your command-line, such as alert name, event number, computer user, severity level of an alert, a resolution state, a time, a domain—there are a series of different parameters that you can use. So basically, the difference between this option of executing a command or batch file versus launching a script is that the first option (launching a script) is a script that you add to MOM. You go in there and you code the script in the MOM database. The second option of executing a command or batch file is using scripts that you don't have in MOM; they are just script files that you compiled or they're just command-line batch files that you're running and you're just telling MOM to kick those off automatically for you. These are things you want to happen in response to an event that might occur.

(Slide 19) So the third type of event rule response is to update a state variable. A state variable is something like a location where you can pass a parameter to; MOM will store that and you can query that parameter later on. These can be stored locally on the agent for monitoring or globally on the consolidator. If you have multiple agents out there, you can have multiple agents updating a single or global state variable. This is good to maintain a count of times the condition has occurred or to set the last state of an application or service. So you can count how many times a specific condition has occurred or check what the last state of an object was that was sent to a server and store that in your state variable. Then you can actually have another script that can check the count or the state and then possibly fire off a different response, like generate an e-mail saying, "Oops, I've got 10 security violations," or, "Oh, this server seems to be going down frequently, you might want to do some manual processing on it," or whatever. That's the state variable.

(Slide 20) The next slide is going to talk about alert rule responses. Alerts can generate the same three event rule responses: launch a script, execute a command or batch file, or update a state variable. Plus, alerts have two additional responses. The first one is send an SNMP trap. This allows you to generate an SNMP trap message to be sent to your third-party SNMP Management console when a specific event occurs that generates the alert. What you need to have is the SNMP service running on either the agent or the consolidator, depending in part on where you want the response initiated from, and then you just configure the SNMP service to point to the appropriate trap destination you want. Then you can go ahead and use that option.

(Slide 21) The last alert rule response is the ability to send a notification to a notification group. What this allows you to do is have MOM generate an e-mail message, a page (which also goes through e-mail), or another command such as a net send command, to specific members of a notification group. Notification groups are just groups that are built-in (seven of them by default, but you can add more if you wish) and that allow you to specify operators for this group. You can specify that when this event occurs, which is going to generate an alert, you want to notify somebody in the help desk notification group, or you want to notify somebody in the security specialist group, or the database admins group, or any one of the other notification groups we have.

What's great about this is that you can add your own operators and you can add their work hours or their schedule. So MOM will be intelligent in that, if an event occurs that generates an alert that wants to send a notification, and it happens at midnight, it won't e-mail or page somebody that's not working at that point in time. So if you've got your schedule set up properly, MOM would go ahead and e-mail or page the person who happens to be working at that point in time. That's an excellent feature.

When you're running these responses, for some of them you can go ahead and specify whether you want the response to be run on the agent computer or the consolidator. Running on the consolidator or centralized is good for global state variables, as well as if the agent doesn't have required code such as SNMP. If the agents don't have SNMP services on them, there's no sense having to generate an SNMP trap because the agent wouldn't have SNMP. So have that alert response generated at the consolidator and just make sure the consolidator will have SNMP services running on it.

(Slide 22) With all that background on computer groups and attributes and processing rule groups and responses, we'll now kick off the last half hour of the presentation and look at the specific different types of processing rules, and we'll start with event processing rules.

The event processing rules define what MOM does with data generated by the designated provider. This data can be used to generate an event for MOM or actually filter data to prevent it from going to MOM (and we'll talk about that a little bit later on) or collecting performance data, say you want to monitor this specific Performance Monitor counter. The event processing rules are contained in processing rule groups, so in the MOM Admin console you would expand out Microsoft Operations Manager, you would expand Rules, you would expand Processing Rule Groups, and then you would go to a specific processing rule group such as SMS. And that's where you would start finding event processing rules.

MOM includes almost 10,000 processing rules in the management packs. The base management pack contains about 6,000 rules and, obviously, the rest are in the application management pack. One thing you need to be cautious of is that when you're installing MOM, you may not want to install the entire base management pack when you first implement MOM because of the fact that there are 6,000 event processing rules there and you may have computers that are going to be hitting the vast majority of computer groups (in other words, getting the vast majority of those rules). Do you really want to push all of those rules down to agents when you're first installing MOM? Generally, we recommend you install MOM and then install only the bare minimum processing rule groups that you need to have installed. In other words, from the base management pack, pick and choose that "Yes, I want the Windows 2000 operating system and Windows 2000 Active Directory, but I don't want to install the other processing rule groups or the management packs." That way you can start slowly with MOM, see what kind of data MOM is going to generate for you, get your first management pack tuned the way you want it — turn off processing rules that you don't want, turn off the alert rules or whatever it is you don't want, turn those off so you're not getting extraneous data — get MOM operating the way you want for that processing rule group or management pack and then install another management pack. So go out there and install the Active Directory pack or go out there and install the IIS pack or whatever the case is. So you install the management packs one at a time, tune them the way you want so they provide the appropriate information for you, and then go ahead and install another management pack. Otherwise, if you don't, you may get flooded with event information coming down through MOM by deploying all 6,000 rules at one time.

(Slide 23) As I mentioned, there are 10,000 rules in the management packs, 6,000 in the base; that means there are about 4,000 in the application management pack. When you purchase the application management pack, again, you only want to install the appropriate application management packs that you really need, that is, SQL Server, or Exchange, or SNA, or whatever the case is, and we'll talk about those at the very end of the presentation.

(Slide 24) There are different types of event processing rules (we'll talk about those in the next slides), and again, you can have your responses generated. You can have MOM automate the launching of a script, a command or a batch file, or update a state variable. There are a lot of different responses you have, either the built-in ones or ones you create. So to get to event processing rules, expand out Rules, expand out Processing Rule Groups, and go to the appropriate group. Either go to one of the existing groups or create your own processing rule group if necessary. Then add the rules to the appropriate processing rule group, either one of the built-in ones or a group that you might create yourself.

Now, on the next slide, slide 25, we'll talk about the five different types of event processing rules: event rules, filter rules, missing event rules, consolidation rules, collection rules. In each of the upcoming slides I'll go ahead and cover those for you in a little more detail, but those are the five different types of event processing rules you can go ahead and generate.

(Slide 26) For the first one, we'll talk about these event rules. Event rules allow you to have MOM generate an event from some data source and store that event in the MOM database. So you want to know when this event occurs from whatever your data source is. You can use almost any of the available provider types. Basically, what you're looking at is collecting data from event logs to the standard Windows event logs. You can't use Performance counters for event rules though; those are for performance rules. You can specify what criteria to create the event from. So if in the event log you see a source of SMS with an event id of 542, with a severity type of error, then you want to generate an event. There are also advanced options you can specify whether it's the agent, the computer, the domain, description, event type, user, etc. There are a lot of different advanced options you can configure.

(Slide 27) You can also schedule when you want MOM to process the data. You may tell MOM, "I don't care about things that are happening from 8:00 A.M. to 5:00 P.M. because I'm there right then. I can go ahead and look at the event log and see things. I want MOM to track things in the 5:00 P.M. to 8:00 A.M. range when I'm not there." So you can schedule when you want MOM to process data or whether you want to always process data, which is what the default is.

You can tell MOM to generate an alert, so you can have MOM generate an alert based off the event that has been raised. If you wish, you can have it automate a response. So to your event, you can have it initiate any one of the three event responses— a script, a command, or a state variable. Now, if you have the event also generate an alert, then you can use the other two response types of SNMP trap or notification, but you'd have to have the event generate an alert to do that.

And lastly, you can add in your own company knowledge. In our processing rules we have built-in knowledge. Knowledge from NetIQ and knowledge from Microsoft stating that when you see this event, the reason is because of this, or here's how you solve this, or whatever the case is. So there are some links, maybe, to specific Knowledge Base articles on the Microsoft Support Web site. But you can also add in your own company knowledge. So you can add in information that you want tracked along with this specific type of event. So maybe it's your own procedures that you want to respond to this event, or maybe you have procedures to diagnose the problem, or maybe a specific person to contact. For example, you need to contact John because he's seen this before and he knows what to do. So you can add in your own company knowledge along with the knowledge that's already provided inside the management pack.

(Slide 28) The next type of rule is the filter rule. A filter rule has the possibility of preventing data from getting to the MOM database. So you're saying, "Okay, an agent is sitting in the event, but we don't care about that event. Just throw it away. Don't send it up to the MOM database." There are three different types of filter rules. There's a pre-filter rule, which does not store event data in MOM or process any additional rules. Basically, we ignore the data after we get the pre-filter rule. There's a database filter rule, which says don't store the event data in MOM, but continue processing rules because maybe this data will be applicable for some other rule that might fire off a similar response. And there's the conditional filter, which does store the data in MOM from the event, provided that the event data matches another rule, that is, if some other rule says, "Hey, go ahead and store this data inside the database."

(Slide 29) Most of the configuration for a filter rule is the same as an event rule. Everything you need to know for things like configuring your schedule and your provider and so on, are all the same for filter rules. Database and conditional filters can generate responses, but pre-filters can't because, basically, in a pre-filter you're just saying, "Hey, I don't care about this data so just go ahead and hide it from MOM. It's in my application log in the event system, but I don't want MOM to know about it."

(Slide 30) The next type of event is a missing event rule. This allows you to have MOM create an event if a specific event or process does not occur when expected. For example, you're doing a nightly backup of your server and you know that backup should complete sometime in the timeframe of midnight to 3:00 A.M. So you could create a missing event rule that says, "If you don't see this specific event occurring in your application log in the midnight to 3:00 A.M. timeframe, generate this event for MOM so that I will know that something didn't finish correctly." In this case, it would be the backup. So you schedule it when you're expecting that event to have occurred. In this case, my schedule would say midnight to 3:00 A.M. So basically, you're scheduling when the event is considered to have been missed because it hasn't appeared in this period of time.

(Slide 31) The remaining configuration is very similar to the event rules. You specify what provider you want to monitor, you specify what your criteria is; for example, if you're looking at the event application log, you'll look for this event source, this event id, etc. You can create an alert if necessary. If you create an alert, you can suppress duplicate alerts, which means that if the same alert is generated multiple times because it matches the same criteria, then only generate one alert. You can generate an alert through the event rule response, and then, if you told the missing event rule to generate an alert, then you have the alert rules responses as well and you can have an existing or company-specified knowledge base.

(Slide 32) The next type of event rule is the consolidation rule. A consolidation rule allows you to accumulate multiple events into a single event that's stored in the MOM database. So this is good if you have some condition that tends to generate a lot of events. Let's say a network adapter card fails and it generates a lot of events in your event log, or maybe a hard drive is having problems and it might generate hundreds of thousands of events over a period of time in the event log. So what you could do is, even though those hundreds of thousands of events appear in the NT event log, you could tell MOM, "Okay, these all match these criteria (which you specified), so treat it them as one event for MOM." So only one event would go up there saying, "Hey, I've got this error condition occurring." That allows you to save space in the MOM database. The attributes are basically the same; you specify your time period, say, "I need to have these events occur within a timeframe of 60 minutes, and if I get multiple events with the same attributes within that period of time, then consolidate them into a single event inside MOM." Otherwise, every single time the event occurred it would generate a new event inside MOM taking up database space.

(Slide 33) The remaining configuration for consolidation rules is similar to the event rule we discussed in a little more detail: the providers, the criteria, the schedule, and the knowledge base. For consolidation rules, you don't have responses or alert generation, but you could have another event processing rule that would look for the consolidation rule data and have it generate an alert or generate some sort of response if you wanted it to. But consolidation rules on their own don't have responses generated for them.

(Slide 34) And the last type of event processing rule is a collection rule. A collection rule just states what data MOM should be looking at and storing it in the database when it normally wouldn't be. So you've got some event data that's being generated and you want to store that in MOM, but MOM is not collecting it by default, either because that data is not written to the event log (which is primarily where MOM looks for event data) or it might be written to the event log, but the default collection rule has been disabled. So you have the rule in there that says collect everything from the application log, but you disabled that rule because you didn't want all application log entries. So if you disabled that, then you might want to create a collection rule specifically to say, "Well, if you happen to see this event id in the application log from this source, send that to MOM."

Or you can also use a collection rule to have MOM collect data from a specific application log. For example, we automatically collect data from IS logs if they've been enabled. You might also create a rule that says collect data from SMS log files because a lot of you are SMS people and you are very familiar with the log files SMS creates, and it creates a lot of logging. Or you could create a collection rule that states not only monitor events from the event log, but also look at the SMS log files.

(Slide 35) When you're creating your collection rules, you specify what event parameters to store in MOM. There are a series of event parameters that are generated. One parameter specifies just the drive and path a log file was found in, another specifies the name of the file, another one specifies the provider that was used and parameter number four actually specifies the entry in the log file that changed. So that would be the one that gives you the real meat of why this event got created. But again, the remaining configuration is similar to the event rules where you can specify your provider; now, you may need to create your own provider to go look for something in the SMS log files. That doesn't mean you're creating a provider by doing coding in some sort of scripting language, you just tell MOM, "I want you to look at this data source" and that's what creates a provider. You can specify your criteria, you can specify the schedule (when to process data), as well as the knowledge base. That's very, very applicable for collecting data that MOM wouldn't normally collect for you.

(Slide 36) Okay we're done with the event processing rules. Now we want to talk about precedence for a second. What is the order in which MOM processes the event processing rules? The first processing rule we'll look at is pre-filter at agent. We process pre-filter rules first because pre-filter rules say, "You may not want to process this data any further." You may want to hide this data from the MOM database, so we look at that first. Then we go to collection rules. If you're not filtering that data, you specifically want to capture this data, so then we go to collection rules.

After collection rules, we have consolidation rules, then event, then missing, and then other filter rules. So you've collected this data and now you want to consolidate it down into a single event. Then you go to the normal event processing rules and then, lastly, the missing processing rules, that is, an event didn't occur within a specific timeframe. Then, at the very bottom you have the other filter rules, being the database and conditional filter rules. So we have the pre-filter rules at the top and then we have the database and conditional filter rules down at the bottom.

(Slide 37) Okay, so that's it for event processing rules. I've got about 15 minutes to get through alert processing rules and performance processing rules. Alert processing rules are useful for common responses to newly created events. Where this really comes in handy is if you've got a lot of event processing rules that are generating alerts for you, but they aren't automatically generating any responses to those alerts. So for the built-in management packs or rules that you create on your own, you may have those events generate alerts, but you neglected to put responses on those alerts because maybe you didn't know who you wanted to notify, you didn't know what the command-line or the script was, or whatever the case was. You didn't have any responses to them. So an alert processing rule allows you to generate a response to alerts that are already being generated by some other event rule. That just saves you from having to go back and modify maybe 15 or 20 different event rules to add a response; you can now generate that response through a single alert processing rule.

(Slide 38) The alert processing rules, again, are contained in processing rule groups: you go to Rules, you go to Processing Rule Groups, you go to your specific rule groups, and then you go to Alert Processing Rules. There are about 100 alert processing rules that are included inside MOM and they are about evenly split between the base management pack and the application pack. They both have 49, I believe it is. The ones that we have built in, generally, what they're doing is generating a notification when an alert is generated for a specific severity level. So you might see alert processing rules that state generate any alert or notification when you see an event of severity level error for SQL Server or SMS. That's generally what they're doing—automating an alert response of a notification for specific severity levels.

(Slide 39) Alert rules. For the alert rules themselves, the alert criteria are used to determine which alerts to process. So you're looking for a specific alert source, a specific severity level, and you're looking for alerts from a specific processing rule group (for example, you want to look at just SQL Server, just SMS, or whatever it is), and then you have your advanced options. Your advanced options are for alert description or name, a computer, a domain, an owner, a resolution state, time that the alert was generated, and any of the custom feelers you can have when you're generating your own alert data.

(Slide 40) So that's what you're looking at, as far as your criteria. You are specifying when you have an alert and it is based on whether this alert is at this level from this source with this severity level, from this application, and possibly other criteria in your advanced options. Then you can schedule when you want that rule to be processed and you can have a generated response. This is generally why you have alert processing rules, to have an automated response when the alert rule, being the event rule that created the alert, didn't necessarily create the response. So you can have any of the five responses: launch a script, SNMP trap, send a notification to a notification group, run a command or batch file, or update a state variable. And then, again, you can update your company knowledge base along with that.

Those are alert processing rules. If your event processing rules generate responses, then you may not need to worry as much about alert processing rules, but they're there for alerts that were generated that didn't have any responses on them—that is primarily why you would look at alert processing rules.

(Slide 41) Okay, performance processing rules. Performance processing define what performance data MOM processes. Pretty simple. By default, we don't monitor all performance data. You know there are hundreds or thousands of Performance Monitor counters, objects and counters, that are available through the performance system, through PerfMon or performance in Windows 2000. Obviously, we don't want to tell MOM to monitor every single one of those, so we have specific providers. There are about 130 of those by default, and if you use the application pack, it brings it up to 450 or so providers that are looking at specific PerfMon data sources. These are contained in processing rule groups; again, to get to them expand MOM, Microsoft Operations Manager, expand Rules, expand Processing Rule Groups, go to the specific processing rule group, and then go to Performance Processing Rules. Then you can either view the existing performance processing rules that are included with the management packs or create your own. Generally, these are going to be Windows NT Performance counters, but you can also include WMI numerical data if you wish.

(Slide 42) MOM includes about 500 performance processing rules in the packs. There are about 200 in the base pack and about 250 or so in the application pack in the current build. This data will then be sampled according to the sampling schedule that you specified with the provider and the built-in ones have a built-in timer, such as every minute, or every 5 minutes, or 15 minutes, or half hour, or whatever it is, and you can change that timer if you want. The data can be graphed inside of a graph in the MMC console so you can graph the data there or the data can just be ported into a report. There are an awful lot of reports that are generated through the MOM reporter utility that actually use performance data. So a lot of data there is generated for the reporting. None of these performance data objects are graphed by default, but you can go into the MMC console and you can tell it to graph any one of these. So you can see a graph through your MMC console if you wish or through the Web console if you're using Web console.

So on the next slide, slide 43, we'll go ahead and talk about the two different types of performance processing rules. The first one is a measuring or a sample rule. Measuring rules define, basically, what performance data you want MOM to collect and process. So, for example, you want to look at this PerfMon counter or this WMI numerical instance and you want to collect this data and send it to MOM. So you can use any of these built-in providers, again, about 130+ in the base pack and almost 500 total with the application pack as well. The vast majority of those, I think all of them in fact, are Windows NT Performance counters. You can also create WMI numerical instances if you wish. There are a lot of SQL Server counters, for example, in the application pack. That's what really jumps you up, all the SQL Server counters that are generated. So sample rules or measuring rules basically state, take this PerfMon counter and monitor it every x number of minutes and take that data and give it to MOM.

(Slide 44) So you schedule the data to be processed, just like we talked about with the event rules. You can generate a response, so you can do any of the event processing rule type responses: start a script, execute a batch file or command, update a state variable, and it can also contain company knowledge if you want to have company knowledge involved. The sampling rate for sampling data is done with the provider. So, with the provider, you specify you want to check the log ons-per-second counter, you want to check that every five minutes, or whatever your case is. You would specify your sampling when you generate the provider itself.

(Slide 45) The other type of performance processing rule is called the threshold rule, where a measuring or sample rule collects the samples of data and feeds them to MOM. The threshold rule tells MOM to watch for specific values for your performance data, and if a value is reached, exceeded, or changes by a certain value, then you want to go ahead and generate some sort of response. For example, if the CPU hits 80 percent utilization, then you want to generate an alert that might e-mail somebody in the performance notification group or maybe the hardware support group or the help desk or whatever it is.

You can use any of the included providers or create your own custom provider, if you wish. Again, you can schedule when the data is to be processed and you can specify what criteria to match. You can look at data from a specific instance, a domain, a specific computer, or any of the advanced options that we discussed before.

Now, the rule value of your threshold rule is on this next slide, slide 46, where you specify what your threshold value is. So you're specifying, when you sample this data, when you look at the data, and you see that the sample's value is either greater than some value or less than some value, then go ahead and generate some sort of response, like an alert response. For example, my CPU is 80 percent utilized, so generate an alert; or my hard disk free space has fallen below 10 MB, then go ahead and generate an alert. You can use less than as well. Or you can say, look at the average over n number of samples, and if my average of n number of samples is greater than or less than this value, then go ahead and trigger the threshold, trigger this alert. Or you can say, over n number of samples, if my value has changed by this amount, then trigger the threshold. So if you've gone from 50 percent utilization up to 60 percent utilization in two samples; that might not be good. So if your change in value over n number of samples has gone up or down a specific number, then go ahead and trigger the threshold. So what you probably want to have it do is generate an alert to say "general alert" because your CPU is being over utilized or your hard disk is being filled up, there's not much free space left, and so on. Then generate whatever type of alert response you want, any of the five alert responses will be applicable because you're generating an alert. You can also go ahead and add in your own custom data with that. So that talks about the different types of processing rules there are: event processing rules, alert processing rules, and performance processing rules.

(Slide 47) In the last couple of minutes let's go ahead and talk about what rules MOM provides by default, and that's through our management packs. So let's talk about the MOM base management pack first. The MOM base management pack is what you get when you buy MOM as a product. That's going to have processing rules and groups and attributes and computer groups and so on for these applications and services. Windows 2000; there are a large number of processing rules for the Windows 2000 operating system where you're looking at just the specific data inside of it, looking for things for just every computer, or just domain controllers, or just servers, or Dr. Watson events, or license logging service, or file replication service, and so on. You get Active Directory management pack, so there's a set of rules in there for monitoring Active Directory, looking for your DC locators, your SYSVOL, your time syncs, and making sure your servers are available, and so on, and then space available on your Active Directory. IIS is looking for configuration and use of your IIS service, looking at both 4.0 and 5.0; looking at performance rules and reporting rules for IIS for generating reports and performance data. Terminal Services; we have rules in there for Windows Terminal Services for Windows 2000.

Then there's more. On the next slide, slide 48, we'll talk about the second part of that. We have rules for MSDTC. We have rules for a lot of the networking services such as WINS, DHCP, DNS, RRAS, MTS, and MSMQ. So these guys are oftentimes looking for availability or utilization or performance of that service, making sure the resource is still available to the users when they need that resource.

SMS is actually included in the base management pack, so you have rules in there for monitoring SMS 1.2 servers and clients, as well as SMS 2.0 servers and clients. If I remember correctly, there are around over 1,000 rules for SMS that are in the SMS management pack.

And then there is MOM itself. There are management rules in the management pack to have MOM monitor itself, looking at MOM conditions, such as whether you have a memory leak condition or too many handles or whatever the case is. It also looks at significant events and so on. So many rules for monitoring MOM itself are included with the MOM Server product.

Now, one thing to caution you on here (I mentioned it in the MOM overview session we had in March) is that we also do have some rules for Windows NT 4.0; however, the Windows NT 4.0 rules, or the management pack that Microsoft provides with MOM, is a limited functionality pack in that all we allow you to do is monitor events from the system log of the NT 4.0 server or computer. If you want full functionality, if you've got a lot of Windows NT 4.0 servers in your environment (again, MOM requires Windows 2000), then you'll want to go to NetIQ, and NetIQ has an XMP, an agent, that gives you full functionality of your Windows NT 4.0 environment. So that's something to be aware of.

(Slide 49) Then the other management pack that we currently have available, or we will have available soon after the product ships, is the application management pack. This gives you rules and knowledge for some of your value-added services: Exchange 5.0 and Exchange 2000; SQL Server, SQL 7.0, SQL 6.5 (I think), and SQL 2000 as well; Proxy Server; Site Server; and SNA Server. So these are all inside the application management pack. These do not come with MOM. When you buy MOM, you get the base management pack, but if you need to have MOM monitor these value-added services here on this list, then you need to purchase the application management pack.

Now, the application management pack will not be available initially when MOM ships. When MOM goes RTM, the application management pack won't be available yet. This will go beta in the July timeframe most likely. So you'll be able to get a beta and work with it then. Then when it goes to RTM code, you can purchase the full product and the appropriate licensing and implement it at your sites.

One thing we're also planning on doing as far updating management pack data is making it available on our Web site. So when we have updates on the application pack or the base pack, then you will be able to go up to our Web site at http://www.microsoft.com/mom/, the official MOM Web site, and download management packs, updated processing rules, management packs, etc. You'll just need to purchase the appropriate licensing and then add the license data into the MOM console. Then you can install the management pack and it will go ahead and be implemented properly for you.

Okay, I'm out of time, so let's go ahead and go through our summary on slide 50 and then kick it over to Heidi for Q&A. So just as a quick summary for you, MOM deploys processing rules based on membership in associated computer groups. What we do is a discovery process to identify computer attributes on your computers. If we identify the appropriate attributes on your computer, we make you a member of the appropriate computer group, unless you're excluded from that computer group, then we go ahead and associate processing rule groups to computer groups. If your computer becomes an agent and you're a member of XYZ computer group, you're going to get the processing rules that are associated with the XYZ computer group automatically.

MOM uses providers to specify the source of data for processing. The most common providers are Windows NT Performance counters and then the providers that look for your event log data, the application log, the system log, the security log, file replication, DNS, Active Directory, and so on.

(Slide 51) Processing rules dictate which data MOM processes. So you have a provider that tells MOM, "Here's the data I want," and then the processing rules tell MOM what to do with that data. The management packs are prepackaged sets of processing rules, and initially, we'll have two management packs, the base management pack that will come with MOM when you purchase the MOM Server license, and then at some point later on we'll have an application management pack that will give you the available rules and processing rule knowledge for the applications we looked at: Exchange, SQL, SNA, site server, and Proxy Server.

All right, at that I'll kick it over to Heidi and she can introduce the Q&A portion.

Heidi Moeller: Thanks so much, Wally. It is time to move on to the Q&A portion of this support WebCast. Before we do so, I do have a couple of notes for you. Joining Wally is Kevin Conner from NetIQ and he's here just to help field all those questions that relate to any of the NetIQ products. Now, for more information on upcoming or past WebCasts, you can visit http://support.microsoft.com/webcasts/. There you will see the information about the upcoming sessions, and if you scroll down to the bottom and select the Past WebCasts link, it will take you to a list of all the past WebCasts we have done.

A quick reminder for you that the Q&A portion of this Support WebCast is intended to encourage further discussion of the Support WebCast topic; however one-on-one product support issues are beyond what we're able to address here. Now, since MOM hasn't been released yet, my guess is there won't be any support questions anyway, but I did want to include that. So with all that said, let's go ahead and get started on the Q&A.

The first question is, Is the beta still open for MOM, and if it is, can I join? Also, is there any information for joining that beta?

Wally: The answer to the beta program question is no. The beta program has been closed for a while now and the reason for that is that we're very, very close to shipping. We're in the final beta stages and we are expecting a shipment release to manufacturing very soon. I can't give you anything tighter than very soon, but we're at the very final stages. Because we're so close to being done with the product as far as having it out the door, the beta program has not been available for a while now. So there's no ability that I am aware of for getting anything from that MOM product group as far as the beta. Maybe if you contact your field office, they may have a copy of the beta version that was available, and if they get you that much you can play around with it, but as far an officially supported beta type function, that process has been closed for a while. And we are getting very, very close to RTM. I can't give you a date because I don't know a date, but it will happen very, very soon.

Heidi: Excellent, next question. Did you say a computer can belong to multiple groups?

Wally: Yes, a computer can absolutely be a member of multiple computer groups. I've got my MOM Server with me right now. If I go look at all computer groups on my environment, I've got two computers in my site. I've got my MOM Server and my SMS site server, and my MOM Server happens to be a member of about 15 computer groups at one time, and my SMS server happens to be a member of about a dozen or so computer groups at a single time. Again, the computer groups are associating specific attributes with your computer. For example, the computer groups that I'm a member of right now are Windows 2000, that's the Windows 2000 any server. I also have Dr. Watson running, so it's a member of Windows 2000 Dr. Watson. It's got the license logging server installed, so it's a member of the Windows 2000 license logging server, it's a Windows 2000 Server. I have Windows 2000 domain controllers. My SMS server is a Microsoft SMS 2.0 Server. There are some hardware groups, there are MSDTC groups, there's an IIS group, there's a WMI group, there's a service pack version group, and there's some specific for MOM type servers. So yes, absolutely, your computers can be members of multiple computer groups simultaneously and what that means to you is that you get the rules that are associated with all of those computer groups that you're a member of.

Heidi: Okay, just a quick note. We're very interested in your feedback regarding this session, the WebCast program overall, and any topic suggestions you may have for us. So if you could take just a few moments to send us some feedback we would appreciate it. You can use the alias feedback@microsoft.com. If you do use that alias, be sure to include "Support WebCast" in the subject line.

The next question is, Does MOM support the use of Perl script?

Wally: Right now, what we're supporting are scripts within MOM itself, the scripts that you have included in the MOM database are VBScript, JScript, and what we call custom, but custom really are SQL scripts. So that's what we have. Now, if you want to create your own Perl script or something else, you can have that already compiled or send your appropriate run time version along with your command-line and you can have MOM launch that off of the command-line in response to an event. However, the scripting languages that we're supporting are the Microsoft languages of JScript, and VBScript, and the SQL scripts.

Heidi: Excellent. SMS is part of the base management pack, but SQL Server isn't. Will any SQL-related monitoring be available with the SMS pack?

Wally: In the SMS rules, there are some rules that will look and state that SMS Server can't find SQL Server. So things like the SMS Executive or the Data Loader or somebody having problems inserting events into SQL Server, you would see some of those types of events, but as far as other monitoring, no. That would come from the actual SQL application pack that, again, will be going into beta hopefully in July and then RTM some time after that.

Heidi: Can we choose what mail agent we want for use with MOM?

Wally: There are two mail agents. There's Exchange, which includes Microsoft Outlook®, and there's also SMTP. So when you're configuring your e-mail server, the two choices are Microsoft Exchange or SMTP, and Exchange can include Outlook as your agent. There is one issue, but I don't remember what it is, with Office XP that just came up. Outlook 2002 just came out and there is some issue with it and there's a KB article on it already. But it is something that is very easily worked around. So those are the two that we support, Exchange and SMTP.

Heidi: When will the manager pack for App Center 2000 be available?

Wally: What we're doing with additional manager packs in the future, is the MOM product group is working with the application groups themselves, that is, the App Center group and the SQL group and so on. We're working with those groups and we're kind of doing a joint effort. We're trying to drive them to have them generate their own management packs because, obviously, they know the application, they know what things to look for, they know what the appropriate performance data should be, they know what is a good condition, a bad condition, and so on. So we are working with the different application groups within Microsoft to get them to create those. Very similar to what you saw with SMS in that, with SMS initially, it was the SMS group that generated all the PDFs, all the package definition files. And now it's not the SMS group that generates those, it's the actual product groups, so the Office group creates one for Office XP. The Windows 2000 PDF or SMS files are generated by the Windows group. So you'll find the same thing happening with MOM and management packs.

However, just like with SMS and the PDFs, it was a slow process getting them going on that, so we are working with different groups in the company to work on those. We are working with the App Center group to get Application Center processing rules generated. I have no ETA on that at all, but I know there has been discussion with them on getting that going.

Heidi: Okay, next in line. What typical administration tasks are needed to support the MOM Server database?

Wally: The first and biggest thing that you want to do for administering MOM and keeping things going in a good manner in your database, is the one thing I mentioned during my presentation; that is, when you install MOM, you don't want to just blast out all the management packs that come with the base management or the app pack when you get it. You want to selectively install individual management packs so that you control the amount of data that MOM is generating at any one point in time. So if you just go up and blast in all 6,000 or 10,000 rules, your MOM database is going to get flooded with the amount of data that you get returned, especially when you have large numbers of agents that you're working with. So what you want to do is install, for the base management pack, just Windows 2000 rules, for example, and tune those so that you get the appropriate data out of your Windows 2000 rules. Then you go back and implement Active Directory, or then you implement IIS or DHCP or DNS or whatever it is you want to do. Install the individual management packs from the big management pack, tune that the way you want it to be, disable rules, disable child processing rule groups, add new rules that you think are important, and get the information you want flowing there, then add the next one. So that's the first thing you do, make sure that you're being selective in how you install your management packs.

Then, the second thing that you're going to have to do is be very aggressive in your database grooming values. Because MOM is going to store a lot of data in your database from all these different agents that you can have installed, some of you will have hundreds if not thousands of agents that you're running that you're going to have management packs on. That's going to be a lot of data going to MOM so you're going to have to go in and be aggressive with your database grooming values.

The database grooming values are, basically, how MOM automatically filters data or removes data from the database, or ages data out of the database. It is very similar to the database maintenance tasks that SMS has included with it: delete aged Discovery data, delete aged inventory history, delete aged status messages, and so on. There are similar tasks for MOM to clean out its database. Up on the MOM Web site, http://www.microsoft.com/mom/ (I don't know that it's there today, but it will be there by the time MOM RTMs) there's going to be a scalability white paper, and in that scalability white paper the guy who wrote it went to great pains to go through and figure out scalability data, what type of hardware you need to support this number of agents in this type of networking environment. He also went through and figured out how you should probably set your database grooming values so that you do clean out the database in a quick period of time so the database doesn't grow to multiple gigabytes in size, which it may do.

Now, the default database is like 500 MB, and by default we set it to not grow, in other words, to keep it a fixed size. In fact, I think that Microsoft support is not supporting automatically growing the MOM database, so you need to monitor that. In fact, there are rules in there to monitor the MOM database and tell you how much free space you have in your MOM database. Then you just monitor that and do your database grooming so you clean things out.

So those will be the two best things for you. Actually, I'll add a third one: control your installation of your management packs so you get the data out of them that you want. Go in there and tune those, disable rules you don't want, maybe put in filter rules to filter out data that is collected by default that you don't really care about, and then do your database grooming.

A fourth one is just don't put the MOM agent out on every single computer you have. MOM is designed for monitoring server computers, not workstation computers. That doesn't mean it can't monitor workstations, but it's not designed for that. It's designed for monitoring your critical servers and the applications running on those servers. So don't install on a bunch of workstations, and that, again, will help control the amount of data going into the MOM environment.

Heidi: Okay, not sure if you're going to have an answer on the next question. I think it's going to be relative to when the product is released, but Do you have any idea if the product will be included on MSDN, and if so, when that would be?

Wally: That, I don't know. My guess is because we put most of our products on MSDN, that it will be there, but of course they need to have the product RTM first and then there's always a lag time between when it RTMs and when it can get to TechNet or MSDN or Select shipments and so on. So I'm sure it will make it on there, that would be my guess, just because of the amount of other things we put on MSDN, but I can't tell you when.

Heidi: I'm guessing that the MSDN group probably has a feedback alias that's referenced on the CD, and they would be a good group to contact and ask that question to.

The next question is, Can SQL 7.0 be used with MOM or do you have to use SQL 2000?

Wally: The Microsoft Operations Manager product does require Windows 2000 or later, and it does require SQL 2000 and later, as far as installation of MOM. That doesn't mean that you can't monitor a SQL Server 7.0 computer with the base management pack as far as monitoring the computer itself, and then with the application pack monitoring the SQL server application; however, to install MOM, we do require Windows 2000 and SQL Server 2000. If you're not in a Windows 2000 environment, you're not in a SQL Server 2000 environment, and you don't have the capabilities of installing or going to those versions of software, then you might want to look at NetIQ's Operations Manager which, again, as I mentioned in the March WebCast, that's where we got this product from. We licensed it from NetIQ and their product does support Windows NT 4.0 and it does support SQL Server 7.0 as well. So if you're in that type of environment and you can't set up a single Windows 2000 and a single SQL Server 2000 computer, then you can go ahead and look at the NetIQ product and their Operations Manager product. Otherwise, just install a single box and we can go ahead and get MOM installed and you can still monitor the SQL Server 7.0 computer as long as MOM is installed on Windows 2000 and SQL 2000. That's still correct, Kevin?

Kevin Connor: That's entirely accurate.

Heidi: Okay, next in line. What options are there for integrating customer user data with events and responses?

Wally: I guess I don't really understand what you're looking at. What other type of data? What you probably could do, if I'm understanding what you want, is you could probably create some sort of a provider to have MOM look at data that you've already generated on your computer from some other source, whether it's an application log or something else. You can create some sort of a provider, maybe through WMI, as a good, easy way of doing so, to have MOM look at that data, collect that data for you, and then do some sort of processing of that data with some sort of a processing rule. If that's what you're looking at, then sure, you can go ahead and create a provider to do that type of data. For example, I created a provider to have MOM look at SMS log files and specifically generate an event only if the SMS log file had an entry in there that said error. So if the description, which happens to be parameter number four of the generic single line log file provider, says error, then go ahead and generate an event. So you can do that, you can have it look at some other data source. Most likely, if it's not like an ASCII text file type entry, it would be something through WMI, and you could certainly have WMI as a data source for providing data and then have MOM process that data for you with some sort of a processing rule.

Heidi: Thanks, Wally. How would one manage custom apps using MOM? Is there a reference doc on how to do this?

Wally: Well, there's a lot of documentation that comes with MOM and that documentation will tell you how to go out there and create your own processing rules and processing rule groups. As far as the management, obviously, you have to know what is specific to your application as far as how to identify it in the registry and then create the attribute and computer group and processing rule group and rules for that for monitoring what you deem necessary for monitoring that application, whether you have your own specific PerfMon counters that you've generated and integrated in the system or whether you have your own application log or you're just having your application write things to the event log or some other method using some other provider to pull data out.

But it's very, very easy to go out and create management packs via just going into the Admin console and creating a processing rule group and then creating the appropriate rules. One nice thing with MOM is that after you create a custom management pack or just create your own processing rule group, you can take those rules that you created, that processing rule group, and you can export that, save it out to a file, and then import that into another MOM installation. So it's exactly what you would do when you want to get the application pack or when you go to NetIQ and you get one of their extended management packs for monitoring NT 4.0, ODBC, Oracle, or something else. You would import that management pack, that set of rules, into your MOM database. And it's a very easy thing to do, just, obviously, you have to purchase either our application pack or one of NetIQ's Extended Management Packs (XMP), and you'd have to get the licensing for it.

On your own code, you just go ahead and create your own processing rule group with the appropriate providers that you need and the attributes for your computer group and then create your rules. Then you can save that out in case you ever needed to reinstall, or if you have another portion of your company that has MOM installed locally and they want the same rules, you can export those out into a file and then they could import it into their own location. But the documentation that comes with MOM will specifically tell you how to create your processing rules.

Also, there will be a Microsoft Official Curriculum (MOC) course on MOM coming out. The last I heard from them, they were looking at a beta hopefully sometime in the middle of summer, like the July-August timeframe. So my guess is that by the end of the year you will have a mock course that you could take on MOM and that would, obviously, show you how to create processing rule groups as well as processing rules.

Heidi: What kind of SNMP support does MOM have? Can one do alerts, gets, and sets?

Wally: What we advertise is that we can generate SNMP traps, that is, the ability of taking an event and converting it into an SNMP trap message and sending it out to a trap destination; however, we also do have a provider in there that allows you to do SNMP extended trap enhancer and, of course, I can't find it now, but there is a provider that allows you to also receive SNMP data. In fact, if you happen to go to Tech·Ed next week, there's a presentation at Tech·Ed on MOM and it's on integration and connectivity. In that presentation, the guy shows how to consume SNMP data using WMI. If you have the WMI SDK, it actually has an SNMP browser and an SNMP provider. You could use that SNMP provider to pull out your data, your gets or whatever and pull that data into that provider through MOM and then have MOM utilize that data for you. That could be you pulling out reading data to determine whether or not you want to create an event in MOM or that could possibly be a response doing that as well. So those are a couple of different capabilities that you have. Kevin, do you have any more data you might want to throw on that?

Kevin: Actually no, I think that you've covered it quite adequately. With the SNMP, one of the difficulties that we see is that sometimes the MIB information can be a little bit confusing. So you do have to customize that a little bit, but using the WMI interface as well has been something that helps. We've seen some people use third-party applications that I believe you're already partnering with from a Microsoft perspective to kind of clean up the mid information and forward that as an SNMP trap into MOM. You're right also that MOM can send out SNMP information to those external systems.

Wally : Yes, and I know that this guy who did that presentation (he's specifically in the WMI group) was specifically talking about the WMI SDK and how it already had a MIB already compiled for the SNMP provider for WMI, so you definitely want to get the WMI SDK and then use the SNMP provider that's there. That should help you get on your way of doing your SNMP integration with MOM.

Heidi: Okay, excellent. So the next question is, Will MOM be grown to support network management of L2 and L3 network equipment with integrated Visio® 2002 AutoDiscovery?

Wally: As far as will MOM become a network management tool, we don't have designs that I'm aware of for taking MOM and making it be an enterprise-wide network management application so that you're doing all the things that right now are being done by your SNMP products, and there are your HP OpenView and a lot of other products that are out there like Enterprise Framework systems. I'm not aware of any plans to do that at all. So I'm not aware of anything for network management that you're looking at there.

As far as integration with Visio and the AutoDiscovery, as you know, MOM is coming out very shortly and Visio 2002 with this AutoDiscovery has just come out, so it'll take some time to get things integrated totally, but I can see that as being something that might happen in the future. We're always looking at ways to enhance our product and when we do come out with the next release of MOM, we'll have some different capabilities and we're actually looking at some different ways of doing discovery. I can't tell you whether it's going to be the AutoDiscovery that Visio 2002 has, but I know we are looking at how to make discovery more efficient than the current process is. Kevin, do you guys have anything that will go out there and do any L2 or L3 network equipment monitoring? I'm not aware of anything.

Kevin: My response would be pretty comparable to yours. One thing that NetIQ is providing is connectors into the network management systems, such as Tivoli, Unicenter, and in particular, HP OpenView is quite popular. Netcool connector also exists. Getting intermediate devices would really be the way to bring it into kind of a centralized pane of glass, to use the kind of higher-level enterprise management system and then have MOM events alert forward and then automate responses back into the MOM system through the, in this case, higher-level enterprise management system. In terms of doing intermediate devices, it's kind of a common request, but it really hasn't been the core competency for NetIQ to go after the intermediate hardware, and at this point we don't have existing plans to do that.

Wally: Yes, and if want to learn more about the connectors that Kevin was talking about, you can go up to their Web site at http://www.netiq.com/. They actually have a catalog you can look at called NetIQ Extended Management Packs, which are the management packs they are planning on generating for MOM. On the fourth page of that they reference those connectors that Kevin was talking about and also server hardware and some of the other management packs. So that's a good source if you want to look at some of the things that NetIQ is doing to help integrate with MOM and to provide further capabilities than what Microsoft is providing by default. They've got some good information up there for you.

Heidi: Excellent. Next question, Does the Web console provide all the same functionality you would find on the MOM console?

Wally: No, as we mentioned at the WebCast in March I believe it was, the Web console gives you, if you're familiar with the MMC console, three different, what we call, snap-ins, for that. There's a monitor snap-in, a rule snap-in, and a configuration snap-in. The Web console basically allows you to do monitor snap-in, which is viewing existing events, alerts, performance data, looking at reports and so on. It does allow you to respond to alerts such as saying, "Okay, I went ahead and handled that. I'm going to set your resolutions state to resolved." But it does not give you the ability of creating rules, or rule groups, or making any kind of configuration changes to the global settings of your site or initiate management computer scans and so on. So the Web console is an administration-only console as far as basically viewing reports, whereas the MMC console gives you those capabilities plus the ability to configure management rules and processing rule groups and configure global settings.

Heidi: Okay, with that question answered we've cleared the queue of all of the questions that were submitted during today's broadcast. I want to thank all of you for joining us today. A reminder that you can get to information on all upcoming Support WebCasts and archive information from http://support.microsoft.com/webcasts/. We typically have at least one Systems Management WebCast live every month as well as lots of on-demand content. Wally joins us just about every month to do these presentations. We hope you have an opportunity to join us in the near future. Thanks so much for joining us today. Have a great day and goodbye.