Understand Microsoft Operations Manager's framework

Although the Microsoft Operations Manager (MOM) can be a very useful tool, it's also extremely complicated. In this Daily Drill Down, Jim Boyce shows you the components that make up MOM so that your deployment will be a huge success.

Microsoft Operations Manager (MOM) can help you collect information from systems across the enterprise to accomplish performance analysis and system management. Not only will MOM collect data from a wide variety of systems and applications, but it can also help you manage systems by providing notifications when certain events occur. MOM also executes scripts and takes specific actions in response to events. MOM can work hand-in-hand with Systems Management Server (SMS), Microsoft’s Directory Enabled Client Management (DECM) technologies, such as RIS and IntelliMirror, and other management tools to provide a complete solution. So, even though MOM isn’t a complete enterprise management solution, it can be an important piece of the management puzzle.

Because MOM does so much, you can imagine how complicated it is. In order to successfully deploy MOM, you should have a good understanding of its underlying architecture. In this Daily Drill Down, I’ll explain the way MOM works in preparation for planning a deployment.

Agents are the most basic elements of the MOM structure, and they run on every computer you monitor. An agent captures information from a variety of sources, such as event logs, Windows Management Interface (WMI), agent-generated events, and other sources.

Agents can perform a lot of processing on the raw data before passing it to MOM, which enters it into the database for further processing. Each agent can apply rules to determine the action(s) it needs to take on any particular item. The agent can also execute scripts, run batch files, and generate SNMP traps based on its rules. Agents buffer and periodically batch-submit data using compression and encryption to improve performance and security.

Agents communicate with the next component up the chain: consolidators. As their name implies, consolidators consolidate the data before passing it up the chain to the data access servers. The agents rely on guaranteed delivery mechanisms to ensure that the data reaches the consolidator(s), so if a network outage or other problem prevents immediate transmission, the data is still eventually transmitted when the communication problem is resolved.

Consolidators receive collected information from agents and process the information before passing it up the chain to the data access server(s). Consolidators take actions such as applying processing rules to the data, running scripts or batch files in response to events, and generating notifications. They can also generate their own SNMP traps and forward alerts to other configuration groups. It’s important to understand that configuration groups provide logical organization to the MOM infrastructure, enabling you to compartmentalize systems for management purposes.

Consolidators also serve as agent managers. They are tasked with discovering systems and installing agents on those systems, uninstalling agents when directed, and sending rules to the agents. The consolidator’s Managed Computer rule creates a Managed Computers list, which changes dynamically as computers are added or removed from the network and as you modify the rule using the MOM console. This list tells the consolidator which agent computers it is responsible for. You can allow a consolidator to make agent changes automatically or have it prompt you to authorize the changes. Consolidators also act as agents themselves, sending data up the chain that they gather locally. Because of this, you don’t need to install separate agents on consolidator computers.

If you are using MOM to manage a relatively small network, one consolidator will do the trick. As the network grows in size and complexity, however, you’ll likely need to add additional consolidators for a variety of reasons. First, funneling everything through one consolidator would create a point of weakness in your infrastructure. If that computer went down, you’d have to scramble to replace it. With multiple consolidators in place, you could instead revise the Managed Computer rules to enable other consolidators to take over the load while you addressed the problem.

Perhaps even more important is the fact that consolidators in a configuration group—provided they connect to the same database and use the same service account—provide redundancy within the group. A given consolidator can manage its defined set of agents but also serve other agents that can’t communicate with their designated primary consolidator. Here’s how it works.

When the Agent Manager component on the consolidator installs an agent to a computer, that consolidator becomes the primary consolidator for that agent. The agent periodically transmits a heartbeat signal to its primary consolidator. The heartbeat serves a couple of functions. First, it lets the consolidator know that the agent is alive and kicking. It also serves as a trigger for rule updates. When the consolidator receives the heartbeat signal, it sends the agent any updated rules that have not yet been applied.

If the agent doesn’t receive a response from the heartbeat, however, it connects to a redundant consolidator in the group to upload its data package. The agent continues to use the redundant consolidator but checks its primary periodically, and when the primary comes back online, the agent migrates back to it. To help you detect and manage consolidator failures, the MOM Management Pack module includes rules that can generate alerts when consolidator failover occurs.

There are also security reasons for using multiple consolidators. A consolidator must log on with an account that has administrator privileges for all computers that it manages. This can present potential security problems if you don’t have multiple consolidators and need to manage computers across domains. If you have only one consolidator across your entire domain, then a potential hacker only has to crack only that one account, thereby gaining complete access to your network. Having multiple consolidators increases the number of accounts a hacker must crack.

Also, a consolidator that monitors an Exchange server needs to log on using an Exchange Administrator account—not the domain or local administrator account—in order to collect all of the necessary information from the server. Agents on the Exchange server must log on using user accounts to accommodate MAPI requirements, while agents on non-Exchange Server computers can use the local system account. So, where Exchange Server is included in the collection infrastructure, you need to implement one or more separate consolidators for the Exchange servers.

Data access servers
Next up in the hierarchy are the data access servers (DAS), which control access to the database from consolidators and agents. All requests to add data to the central database must go through a DAS, and most queries must come through them, as well. Even the MOM Administrator and Web consoles funnel through DAS to get to the database. Data other than queries also flows from the database out through the DAS. The DAS send processing rules from the database to the consolidators, which pass them down to the agents.

As with consolidators, you can—and in most cases should—install more than one DAS for performance and redundancy. MOM provides built-in load balancing, directing database access requests to the least-loaded DAS in the configuration group. So, installing multiple DAS will reduce server load and improve performance. It also naturally provides a measure of redundancy so that if one DAS fails, another can take over without any interruption to consolidators or agents down the line. As with consolidators, the MOM Management Pack module includes rules that can generate alerts when DAS failover occurs.

The central database
At the next level is the central database. MOM runs on Windows 2000 Server or later and uses a SQL Server database to store all of the data that it collects. MOM also supports and installs the Microsoft Database Engine (MSDE), which enables you to use MOM with a SQL-compliant database, such as MySQL, of up to 2 GB without installing Microsoft SQL Server. This is a great, cost-effective solution for smaller shops, and it allows you to avoid the added hassle and expense of installing Microsoft SQL Server if you’re just evaluating MOM. If you need to scale beyond 2 GB, however, you’ll have to move up to SQL Server.

The MOM Central Server is where you install SQL Server and MOM’s core components, including the Web Console, which runs on top of IIS and provides Web-based access to the database from a Web browser to support roaming administrators. The Central Server also hosts the MOM administrator console, an MMC console that provides direct management functions.

Adding some structure
Now that you know the individual components of MOM’s architecture, let’s look at how they tie together. A configuration group comprises one database, one or more DAS, one or more consolidators, and the agents supported by those consolidators. The configuration group must have a unique name. All of the data collected from the group goes into the group’s database. Agents can cross configuration group boundaries, residing in multiple groups and sending their data to all of the groups to which they belong. The agents can send the same data to each group or tailor the data for specific groups.

There are lots of reasons for using multiple configuration groups, particularly as the managed network grows in size. Multiple configuration groups can help you organize along physical or organizational boundaries, control bandwidth usage, and accommodate administrative requirements.

In addition to configuration groups, MOM also supports computer groups, which are groups of similar computers that you manage collectively rather than individually. For example, if you have 50 workstations in a lab, you can manage them all as a group and eliminate the need to configure and manage each one separately.

You create computer groups for MOM by defining computer grouping rules. These rules specify the criteria for computers to belong to the group. The groups are created and applied only within a single configuration group—they don’t span multiple configuration groups. You can include one computer group within another in the same configuration group, making it easy to develop a structured hierarchy to suit your administrative needs.

MOM gives you several criteria for defining computer groups, allowing you to group by domain, computer name, operating system, the applications installed on the computer, or several other attributes. The groups are dynamic, so adding a new computer to the lab that has the same characteristics as the others in its group means that the computer automatically becomes a member of the group. You can also explicitly include or exclude computers.

Processing rule groups add another layer of structure to MOM’s architecture. Processing rules determine how data is collected across the enterprise and how that data is processed, and can naturally include multiple rules. Defining processing rule groups and associating them with computer groups makes it possible to easily apply sets of rules to one or more group of computers. MOM provides a hierarchical, parent/child structure for creating processing rule groups, which gives you additional flexibility for deploying rules.

For example, you might create a parent group with several child groups, with each child group associated with a particular computer group. In this scenario, the parent group would not apply to each computer group, but instead would serve primarily as a container to simplify management. An alternative is to associate a parent processing rule group with one or more computer groups, then create child processing rule groups within the parent. The result is that that all child groups would implicitly apply to the computers associated with the parent group.

MOM’s management pack
If creating computer groups, processing rule groups, defining filters and events, configuring alerts, and adding all the other structures to your MOM deployment seems like it would be a lot of work, you’re right. That’s where the management pack modules come into play. Each module provides the structure you need right out of the box, eliminating a lot of the legwork otherwise required to integrate a particular operating system, server application, or service into the mix. Each module also includes predefined attributes, scripts, Knowledge Base data, views, notification groups, and the other structures needed to get going. Check out the Daily Drill Down “Let MOM help you manage the enterprise” for a list of modules included with MOM and those that are available as add-ons.

In addition to importing management pack modules, you can also export data to create your own modules. For example, you might install a module, customize it to suit your needs, and then export it for implementation elsewhere in your enterprise. Or, maybe there isn’t a module available for a particular application, so you manually create your own. Then, you export it to use elsewhere.

Moving beyond the structure
Within the structure I’ve described are the events, alerts, filters, rules, and other objects that define how MOM collects and responds to data. The management consoles enable you to configure these, as well as view alerts, create reports, and otherwise work within MOM’s framework. There are numerous concepts to become familiar with when working with MOM, but once you have a full grasp of them, you can deploy MOM without wasting time getting confused by its complexity.

Editor's Picks