Next, I needed to install agents on the five other NT servers on my test network. I double-clicked the MMC shortcut to launch MMC with the Operations Manager MMC snap-in and explored the interface, which Figure 2 shows. After accessing the online Help, I navigated down the console tree, selected Agent Manager, right-clicked it, and opened its Properties sheet. From the Properties sheet, I added a wildcard operator to the Managed Computers tab instructing Operations Manager to immediately install agents to all the computers in my test domain. By default, Operations Manager scans for eligible computers to install the agent on daily at 2:05 a.m.
Deploying the agent software to my five servers was quick, but I ran into a minor glitch. I began receiving alert messages in the console that said I needed to reboot the servers to finish the agent installation. I restarted all the servers but received no communication between the newly installed agents and Consolidator and DAS. I found that the agent service's default configuration set it to start manually. The vendor acknowledged that the manual setting is a bug in Operations Manager 3.2 and plans to fix it soon. I reconfigured the agents to start automatically on all the servers and started the service. After the agents installed, all the components were in place. I then began to learn and configure the many elements of Operations Manager.
Operations Manager has a myriad of configurable options and offers ample leeway for administrators who want to customize it to meet their environment's needs. These options provide power and flexibility, but they increase the product's overall complexity and learning curve. I needed several hours to become familiar with the many configuration items, but after a couple of days of exploring the interface, reading manuals, and accessing the online Help, I had the product functioning on a basic level and was moving into the advanced features.
The Operations Manager MMC Snap-in
The Operations Manager MMC snap-in contains three main sections: monitor, rules, and configuration. The left pane shows the items available in the console tree. The right pane gives you a summary view of your network and the Operations Manager configuration. The monitor section of the console tree gives you several ways to view the status of agents and Consolidators on your network and the information that these components send to the database. You can view all event data, including events that triggered alerts. The rules branch gives you access to the many processing rules that are the heart of Operations Manager's functioning. Processing Rules let you determine what information to collect from which machines, how to process the information, and what action Operations Manager should take on particular events. The configuration view lets you configure settings that affect all Operations Manager components. For example, you can set database grooming options that determine information-retention periods. From the configuration view, you also control when and how Agent Manager deploys agents on your network.
Putting Operations Manager to the Test
I tested Operations Manager's ability to collect event information from the servers on my test network and respond appropriately to certain events. To begin the test, I turned on security auditing for my NT domain. Then, I opened the Operations Manager MMC snap-in, selected the Event Processing Rule Properties sheet, and created an event rule to trigger an alert and send me an email message when the program logged a share access failure audit on a particular server, as Figure 3 shows. I added this rule to an existing rule group that Operations Manager supplies as a general template for NT OSs. I set up a Messaging API (MAPI) account on the server to enable the email feature and verify the rule group's assignment to a computer group. Operations Manager also supplied several generic computer group templates that recognize particular computers according to Registry data that the installed agent supplies. For example, WINS servers, DNS servers, Win2K servers, and Exchange Server systems have default groups. Viewing the processing rules assigned to the computer groups is somewhat difficult because the window lacks sufficient space to display the full description fields.
After I created and assigned the rule, I used another client machine to attempt to access a share on the server I was monitoring. When the program logged a failure audit on the server, the agent recognized the new processing rule and passed the alert upstream to Consolidator, which sent me an email message about the failure audit. In the Operations Manager MMC snap-in interface, I saw that the event added a yellow warning triangle next to the server I had tried to access.
I tried several variations of rules and responses to check Operations Manager's functionality. Instead of sending email messages, I set rules to launch a handful of script files that Operations Manager includes. By modifying a script, I was able to configure Operations Manager to automatically restart my Exchange Server system's Internet Mail Connector (IMC) after I manually shut it down. I collected and viewed performance data on the servers in my domain. Finally, I shut down some of the servers to view Operations Manager's response to the loss of a heartbeat signal. A red down-arrow showed that Operations Manager was unable to establish communication with those servers.
I found that Operations Manager performed as advertised. This tool is very useful if you're looking for a way to cope with the task of monitoring servers and workstations in your organization. You might dedicate a large amount of resources in the initial setup and configuration of this product, but the investment should pay off in your increased capability to troubleshoot, quickly resolve problems, and analyze trends.
Register
