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.
End of Article
Prev. page
1
2
[3]
next page -->
