Operations Manager 3.2

A full server disk once blindsided me. This unexpected crisis was just one of many that I could have prevented if I had found the time to review the trend information for my servers and network. The immense task of managing increasingly complex networks has IT staff constantly putting out fires rather than relying on proactive strategies to avert problems. The larger the organization, the more pronounced this problem becomes. One of the main factors contributing to this problem is the amount of untapped diagnostic and event information available from the network's hardware and software. NetIQ's Operations Manager 3.2 offers a solution to help administrators manage and act on this pool of information.

Operations Manager is an administrative tool for collecting crucial diagnostic data, storing that information in a database, and generating automated rules-based responses to the content. Operations Manager achieves this functionality through several scalable Windows Distributed interNet Applications (DNA) architecture-based components. Figure 1 shows how the Operations Manager components relate to Windows DNA.

Operations Manager Components
At the heart of Operations Manager are three components that operate in the business-logic layer of Windows DNA: the agent, Consolidator, and Data Access Server (DAS). The agent is a service that you install on the Windows 2000 and Windows NT servers and workstations that you want to monitor. This component's main responsibility is to collect information and send it to Consolidator to process. After you install the agent, you can configure it to collect data from Win2K and NT event logs, Performance Monitor counters, and third-party application logs. This component can also generate SNMP traps and other generic events that it sends to Consolidator. Each agent sends a heartbeat signal across the network to keep Consolidator apprised of the agent's status. Finally, the agent applies processing rules for the local machine it's running on. For example, the agent might apply a rule that generates an alert when the machine exceeds a performance threshold.

Consolidator collects information that the agents supply. This component also runs as a service, and you might need to install it on more than one machine, depending on the size and configuration of your network. Consolidator acts as an agent on the machine you install it on but most often acts as an Agent Manager. As an Agent Manager, Consolidator discovers agent machines or potential agent machines (according to parameters you set) and installing or uninstalling the agent service. Consolidator's main tasks are to collect information from the agents and apply processing rules (i.e., run a script, send an email message or page to an administrator, and pass information to DAS).

DAS is the caretaker of the Microsoft SQL Server database that Operations Manager uses to store collected information, rules, and configuration data. As such, this component handles the database I/O traffic to and from Consolidator. The vendor built DAS on COM components and designed DAS to use Microsoft Transaction Server (MTS) to provide centralized database access and query logic. DAS acts as a link between the database, Consolidator, and the administrative interfaces, and as the liaison to the data layer (the SQL Server database) and the presentation layer (the administrative interface).

At the presentation layer, you can use Microsoft Management Console (MMC) to manage all aspects of the program. Through the Web console, Operations Manager also provides browser- based access that works with Microsoft IIS. You can use this interface only to monitor network information, but you can quickly and easily access HTML-based reports that you can schedule the software to publish automatically.

The components work together to channel information from your servers to a centralized reservoir in the database. At any point, administrators can exploit the collected information to troubleshoot, conduct automated problem resolution, trigger alerts, analyze trends, and perform capacity planning.

Operations Manager's components are scalable and provide deployment flexibility. Consolidator, DAS, and the SQL Server database can reside on one machine or on separate machines. Your network size and available hardware will determine the deployment. In a larger environment, you face additional choices. One database and any number of agents, Consolidators, and DASs anchor Operations Manager's fundamental administrative grouping, which the company calls a configuration group. You might want to create several configuration groups depending on your network topology, the number of remote sites that connect across slow links, and your organization's divisions (e.g., finance, engineering). To divide your enterprise along administrative boundaries, you might have one configuration group in charge of messaging (e.g., monitoring the Microsoft Exchange Server systems) and another configuration group in charge of security.

Ultimately, your deployment decision must consider three factors. First, you need to consider the amount of network traffic that Operations Manager generates. In my tests, this traffic wasn't excessive, but having slow links and many agents can cause bottlenecks.

Second, recognize how collected information affects the database's disk space. The product's technical support said agents on 25 servers with security auditing turned on can produce as much as 2GB of data per day. Although Operations Manager has utilities to prune the database, you still need to plan and size your disk arrays appropriately.

Third, Operations Manager occupies a considerable chunk of system memory. During my product testing, the Operations Manager process alone consumed 40MB of system memory. When the software ran with other processes such as SQL Server, my Dell Precision WorkStation with 400MHz dual-Pentium II Xeon processors and 128MB of RAM acted very sluggish. The product's documentation specifies the minimum Operations Manager hardware as a 200MHz Pentium processor with 128MB of RAM and 800MB of free disk space, but my experience showed that you need much more horsepower, even in a small environment. To provide a significant performance boost, technical support suggested a minimum of 512MB of RAM, and for larger environments, 1GB of RAM. The bottom line is to expect to spend some money on capable hardware to properly scale and run Operations Manager.

Deploying Operations Manager
The Operations Manager software ships on one CD-ROM along with three small printed manuals. The documentation is easy to read and well organized but is light on information about advanced topics. For advanced information, NetIQ provides online manuals on its Web site. However, the site didn't have the level of detail I expected.

The vendor claims that administrators can install Operations Manager in minutes, configure it in hours, and deploy it across a large network in a few days. I agree with the estimates on configuration and deployment, but not installation. Although the manuals sufficiently document the installation process and the process isn't difficult, setting up the requisite software took a few hours. To set up one NT server to host all the components, I needed to install MTS, IIS, MMC, SQL Server 7.0 (or SQL Server 6.5), and Microsoft Data Access Components (MDAC). To view and run reports on the local machine, I also installed Microsoft Word and Microsoft Access. A preinstallation checklist that runs when you launch omsetup.exe checks to make sure you meet the prerequisites. After I installed the required software, I was ready to install Operations Manager.

Overall, the installation went smoothly and took only a few minutes. I then created accounts for Consolidator and DAS. Consolidator required a domain account with membership to the local administrators group on each agent and Consolidator machine. To ease setup in my test environment, I added this account to the domain administrators global group. The DAS account required membership in only the local administrators group on the DAS system. Finally, I stepped through other setup items, such as defining the SQL Server database size and naming my configuration group.