Downloads
38489.zip

An efficient IT enterprise requires a proactive approach to monitoring and managing Windows servers and applications to avoid service outages and downtime. Intelligent monitoring tools can help you keep your organization's infrastructure running at acceptable service levels. A primary requirement of monitoring tools is that they be easy to deploy and manage so that using them consumes minimal IT resources. To address these requirements, Microsoft announced Microsoft Operations Manager (MOM) 2000, an enterprise monitoring solution that provides comprehensive event management, proactive monitoring and alerting, reporting, a built-in knowledge base, and trend-analysis capabilities. After working with many customers to deploy MOM, we have some suggestions that will help smooth your MOM implementation.

Installation Prerequisites
Before starting a MOM implementation, verify that your environment meets all the prerequisites. You can't install the MOM server on a domain controller (DC); you must install it on a dedicated member server that's running Windows 2000 Advanced Server Service Pack 2 (SP2) and that has access to a DC.

MOM provides an interface that you can use to determine whether your system has all the prerequisites for the MOM server software. When you place the MOM CD-ROM in your CD-ROM drive, the MOM setup program displays a menu with several options. Select the Setup Prerequisites option to display a list of the required software. Figure 1 shows that the Setup Prerequisites program has detected that Win2K or later, Microsoft Transaction Server (MTS), Microsoft Management Console (MMC) 1.1 or later, Microsoft IIS, Microsoft Internet Explorer (IE) 4.01 or later, Microsoft Data Access Components (MDAC), and Microsoft Office Graph Component are already installed on the machine. You should install the remaining items before you proceed with MOM installation. You can install some of the components, such as the Microsoft Access 2000 or later runtime environment, the Microsoft Distributed Transaction Coordinator (MS DTC) log file size, and the browscap.ini file, without leaving the Setup Prerequisites dialog box. Other components, such as Microsoft SQL Server (or Win2K or later, if it wasn't installed), might require you to exit the dialog box, install the required software, and return to the dialog box.

Figure 2 shows the Setup Prerequisites dialog box after you've installed all the prerequisite software on the machine. At this point, clicking Setup initiates the installation program.

If you plan to install the MOM database on a separate server, you must do so before installing the MOM server because the MOM server installation program checks for the availability of the database. Installing the MOM database separately requires one custom MOM installation in which you install only the database and another custom installation in which you install everything except the database.

MOM Management Packs
MOM has a modular architecture designed to let you customize your use of the product according to your specific needs. You start with the MOM base management pack—sets of predefined computer attributes, processing rules, providers, and scripts—and tweak the settings to suit your environment. MOM's base management pack modules, which Table 1 lists, include almost everything you'll need to monitor core Windows services. During MOM installation, you select only the management pack modules that are relevant to your organization. If you find later that you need another module, you can install it then. Loading unnecessary modules simply takes up space in the MOM database and clutters the MOM management console.

In addition to the base management pack, Microsoft provides an application management pack that contains the modules that Table 2 lists. You can install application management pack modules after you install the base MOM software. Some of the application management pack modules, such as the one for Microsoft Exchange 2000 Server and Exchange Server 5.5 , require extra configuration to work properly.

MOM's modular architecture also lets third parties develop management packs that integrate with the MOM console. Some examples are NetIQ's Extended Management Packs (XMPs), the Citrix MetaFrame XP Management Pack for MOM, and Hewlett-Packard's (HP's) Compaq Management Pack (CMP) for Microsoft Operations Manager. (For a list of MOM partners, go to http://www.microsoft.com/mom/partners/default.asp.)

You can also extend MOM yourself. If you have internal applications that generate events and that write to log or other files, MOM can capture this information and use it to monitor the applications. MOM SP1 includes a new software development kit (SDK2) to help with customization.

Discovering Servers and Installing MOM Agents
After you've completed the MOM server setup, you need to deploy the MOM agents on the servers you want to manage. MOM's Agent Manager uses Managed Computer Rules (MCRs), which are based on your domain and computer names, to discover computers in your environment.

If you have a good computer naming scheme in place that specifies a server's location or function, such as NYCEXBE01 or NAEASTDC01, you can use a small set of rules to discover the machines that you need to manage. If you don't have a good naming scheme, you can use the domain and computer name with wild- cards; however, MOM might discover a lot more computers than you want to manage. In this case, you'll need to craft more rules to narrow the field to only the computers that you need to manage. To see a list of the discovered computers, right-click Agent Manager in the MOM management console, select Properties, and go to the Managed Computers tab. This tab also displays the status of agent installation on the discovered servers.

Agent Manager uses an automatic or approval-based process to install agents on the discovered machines. If you choose the automatic process, Agent Manager installs the agents on all the discovered machines during the next scanning cycle. If you select the approval-based option, the tool lists the discovered computers in the \configuration\pending installation folder so that you can individually approve them for agent installation. If Agent Manager discovers more computers than you expected, keep Agent Install set to Require Approval so that MOM will install the agents only on the computers that you want to manage. After MOM installs the agents on a computer, the agents follow the processing rules defined for the computer's group to send information from the computer to the MOM server.

Grouping Computers with Formulas
MOM uses computer group formulas to categorize computers by function (e.g., SQL Server machines). Organizing computers into functional groups lets you apply a set of function-specific processing rules to a subset of your managed-computer group. The formulas that MOM uses to group computers are based on computer attributes; MOM's base and application management packs identify most of these formulas and attributes.

To view the default groups and formulas for the MOM management packs you've installed, expand Rules in the MOM management console, click Computer Groups, and right-click a computer group such as MS SQL Server 2000. In the Properties dialog box, select the Formula tab to see the formula and the attributes that this group uses. The formula that Figure 3 shows groups together all the computers that are running SQL Server 2000 and that aren't running Windows NT Server 4.0. The formula is based on the attribute SQL Server Current Version, which is based on the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\CurrentVersion\CurrentVersion registry subkey, which is present on SQL Server machines.

Your environment might require that you divide a large computer group into several subgroups—for example, splitting a large Exchange server group into Front End, Back End, Mailbox, and Public Folder server groups. To do so, you can create new computer attributes and use them in computer group formulas. Typically, you base new computer attributes on unique registry values. If the registry values you need aren't present, you can create them on the computers that you want to manage as a separate group.

Database Management
MOM stores the data it collects about your computers in the MOM database, which is a SQL Server database. The database's default size is 500MB. You'll most likely increase the size after you know how many servers you'll be managing and how many associated rules you'll be using. The white paper "Microsoft Operations Manager: Performance and Sizing" (http://www.microsoft.com/mom/techinfo/administration/perfsize.asp) can help you calculate an approximate starting size for your database.

Microsoft recommends that instead of using an automatic file-size-growth feature, you manually increase the database size because during automatic file growth, all database operations are suspended, which can keep MOM from functioning properly. You can use SQL Server Enterprise Manager to select the MOM database, open the Properties dialog box, and increase the size. Please note that you can only increase the size, not decrease it.

Microsoft doesn't recommend changing the SQL Server database tables directly or modifying the database schema. However, you can use SQL Server Query Analyzer to gather information about events, alerts, computer groups, processing rules, and MOM configuration. MOM customers frequently ask how they can get rid of events and names of computers that they no longer manage. You can use several SQL stored procedures to perform these tasks, but we recommend that you back up the database before executing them and contact Microsoft Product Support Services (PSS) for assistance. To help maintain database size, MOM SP1 adds a feature that lets you regulate the retention period for all sampled numeric data.

Scripting
MOM SP1's SDK2 includes some excellent examples of MOM views, MOM providers (i.e., data sources for events and alerts), a Pocket PC tool—Pocket MOM—for monitoring MOM events, and a development platform to enhance MOM's capabilities. Companies typically create different views for different administrators so that they can view just the information pertinent to their function. For example, Exchange and messaging administrators would have a view showing MOM messaging statistics. One of our customers created a MOM view that shows servers as having a red, yellow, or green status so that Help desk staff could quickly see the current condition of any server in the managed environment.

Advanced users or users with some development experience (especially VBScript experience) can write new scripts and integrate them into their MOM environment. MOM SP1 provides RunMOMScript, a command-line program for testing and troubleshooting MOM scripts. More than 70 scripts written in VBScript and JScript are available in the MOM management packs. You can find these scripts under \rules\advanced\scripts in the MOM management console. The number of available scripts will depend on the number of management pack modules you've installed.

The simple script that Listing 1 shows starts a service on a given computer. The MOM script interface lets you pass parameters to the script to make it more customizable for your environment. A user can pass a computer name, service name, number of attempts, and number of seconds between retries to the Listing 1 script.

Third-Party Integration
Microsoft designed MOM for Windows-centric environments, but it can coexist with other management frameworks through Windows Management Instrumentation (WMI), SNMP, and connectors available from third parties such as NetIQ and NEON Systems. Two-way connectors to HP OpenView and IBM's Tivoli will be available soon.

NEON's iWave Integrator allows two-way communications between MOM and a Help desk system such as Remedy Help Desk. The connector automatically sends MOM alerts to the Help desk system, which generates a ticket. After Help desk staff track, resolve, and clear the problem, the Help desk system communicates back to and clears the MOM console.

From Test to Production
A typical enterprise-level MOM implementation starts with a proof-of-concept project in a lab environment that consists of a few monitored servers in a test domain. During this pilot phase, administrators explore MOM and its features and customize MOM for the lab environment. Time passes, and the information MOM provides becomes crucial for managing and monitoring the lab environment. The administrators decide that rather than end the MOM lab environment, they'll extend the same environment directly into production. Here are some points to keep in mind if you find yourself in this situation.

  • You can't easily change the name of a MOM configuration group from, for example, Test to Production. Typically, a new name requires a new installation, which won't have the same settings as the test configuration group. The easiest way to transfer your configurations of the MOM management packs you're using is to export the management packs from the lab environment and import them into the production environment. If you do so, you'll notice that the processing rule groups in the management packs are still associated with the test computer groups, so you'll need to assign the appropriate production computer groups to the processing rule groups.
  • In a test environment, using one account for both the Data Access Server (DAS) and the MOM Consolidator and Agent Manager (CAM) is acceptable. However, you should use separate accounts for DAS and CAM in a production environment to ensure that you don't grant excessive rights to the DAS accounts. The DAS account requires only local administrator rights on the server on which you've installed DAS and CAM—that is, the DCAM server; the DAS account doesn't have to be a domain account. But to ease agent deployment, you might give the CAM account domain administrator rather than local administrator rights. (Note, though, that giving the CAM account local administrator rights on each managed computer provides better security than giving the CAM account domain administrator rights.)
  • If you plan to use multiple DCAM servers in your production environment, place the MOM database on a dedicated server in your test environment, even if your test environment has only one DCAM server. Then, when you're ready to move to the production environment, you can add DCAMs to the existing configuration without any configuration changes. If you think you might extend your test environment to production, use production-level hardware for the database server from the beginning. Although moving the database to a different server is possible, Microsoft doesn't recommend it and PSS doesn't guarantee that it can solve any resulting problems.

We've described deployment options that you can use to customize MOM for your specific environment and given special attention to the challenges related to moving from a MOM test environment to a MOM production environment. The practices that we recommend for deploying MOM in a large-scale environment are based on our real-world experiences with MOM customers. MOM can help you take control of the key systems in your environment, but as with other software and services, proper deployment is a big factor in how helpful MOM can be to you.