MOM manages Windows Server 2003 networks through event consolidation and performance data gathering. It collects application, system, and security events throughout the Windows Server 2003 network and writes them to a single database repository. Processing rules define how MOM collects, handles, and responds to the information gathered. MOM processing rules handle incoming event data and allow MOM to react automatically, either to respond to a predetermined problem scenario, such as a failed hard drive, with a predefined action (trigger an alert, execute a command or script) or to consolidate multiple events into one event that correlates a group of related events. The processing rules also enable MOM to automatically determine which events are important to a network administrator, minimizing administrative overhead.

MOM processing rules can generate alerts based on critical events or performance thresholds that are met or exceeded. An alert can be generated by a single event or by a combination of events or performance thresholds. For example, a failed fan can generate a simple alert, whereas a failed database generates a more complex alert relating to the failed SQL database services and IIS Web pages that rely on the availability of the database. Alerts can also be configured to trigger responses such as email, pages, Simple Network Management Protocol (SNMP) traps, and scripts to notify administrators of potential problems.

MOM can be configured to notify various IT groups. For example, an alert triggered by a failed database can alert the help desk with email and the database administrator with email and a paged message. In brief, MOM is completely customizable in this respect and can be modified to fit most alert requirements.

MOM utilizes a Microsoft SQL Server database as the central repository for all collected data. This data includes all event log and performance data gathered from each managed computer. The database also stores all the scripts used by the management pack rules. This database must be installed as a separate component from MOM but can physically reside on the same server, if needed. Proper SQL procedures and maintenance for this database component are critical for proper MOM functionality.

The data access server (DAS) is the MOM component that is used to communicate with the MOM database. It handles all the data transactions between the database and all the other MOM services. Most requests to read information from the database use DAS (with the major exception of Reporting), as well as all requests to write data to the database.

The consolidator is responsible for controlling and updating all the managed computers in a MOM database. It delivers all client agent updates, which include updating any rules or configuration settings to the managed computers. It also delivers all data gathered by the managed computers to the DAS.

The agents are the monitoring components installed on each managed computer. They use the collected event logs and performance counter data and process them based on the management pack rules installed on the computer.

MOM utilizes the concept of configuration groups to logically separate geographical and organizational boundaries. Configuration groups allow administrators to scale the size of MOM architecture or politically organize the administration of MOM. Each configuration group consists of the following components:

As noted in the “Identifying Sample Designs of Successful MOM Implementations” section later in this chapter, MOM can be scaled to meet the needs of different sized organizations. For small organizations, all the MOM components can be installed on one server with a single configuration group, as illustrated in Figure 25.2.

Figure 25.2. Single configuration group.

In large organizations, on the other hand, the distribution of MOM components to separate servers allows the organizations to customize their MOM architecture, as illustrated in Figure 25.3. Multiple configuration groups provide load balancing and fault tolerance within the MOM infrastructure. Organizations can set up multiple consolidators, data access servers, or agent managers at strategic locations, to distribute the workload between them.

Figure 25.3. Multiple configuration groups.

As mentioned in the preceding section, two methods can be used to configure and view MOM settings. The first approach is through either an Administrator Console, shown in Figure 25.4, or Operator Console, shown in Figure 25.5. With the Administrator Console, administrators can easily navigate through a hierarchical tree structure and configure the rules, notification groups, and configuration settings. With the Operator Console, quick up/down status and overall environment health can be monitored easily.

Figure 25.4. The MOM 2005 Administrator Console.

Figure 25.5. The MOM 2005 Operator Console.

In addition to the main MMC-based console, a Web-based administration console with a Web browser such as Microsoft Internet Explorer (versions 4.01 or higher) can be used to view and configure key MOM information. Through the Web console, administrators can review the status of managed systems with the ability to take action on and update alerts. Access to the associated Knowledge Base is provided as well.

MOM has a variety of preconfigured reports and charts. The reports allow administrators a quick review of the status of systems and services on the network. They can also help administrators monitor their networks based on performance data. The reports can be run on demand or at scheduled times. MOM can also generate HTML-based reports that can be published to a Web server and viewed from any Web browser. Vendors can also create additional reports as part of their management packs.

Another key feature of MOM is the capability to monitor and track server performance. MOM can be configured to monitor key performance thresholds through rules that are set to collect predefined performance data, such as memory and CPU usage over time. Rules can be configured to trigger alerts and actions when specified performance thresholds have been met or exceeded, allowing network administrators to act on potential hardware issues. Performance data can be viewed from the MOM Operator Console, as shown in Figure 25.5.

Network management is not a new concept. Simple management of various network nodes has been handled for quite some time through the use of the Simple Network Management Protocol (SNMP). Quite often, simple or even complex systems that utilize SNMP to provide for system monitoring are in place in an organization to provide for varying degrees of system management on a network.

MOM can be configured to integrate with these network systems and management infrastructures. Special connectors can be created to provide bidirectional information flows to other management products. MOM can monitor SNMP traps from SNMP-supported devices as well as generate SNMP traps to be delivered to third-party network management infrastructures. In addition, MOM can also monitor live events on Unix systems using the syslog protocol.

MOM was specifically developed to provide for the development and native utilization of multiple management pack snap-ins, known as Extended Management Packs (XMPs), within a MOM infrastructure. This provides for the flexibility to scale a MOM deployment to multiple specialized applications. For example, a specialized third-party database program can be monitored through the use of an XMP that is specifically designed to respond to criteria specific to that application, such as event IDs that indicate possible database corruption.

Software and hardware developers can subsequently create their own management packs to extend MOM’s management capabilities. XMPs extend MOM’s management capabilities beyond Microsoft-specific applications. Each management pack is designed to contain a set of rules and product knowledge required to support its respective products. Currently, XMPs have been developed for the following products, with many more in development:

MOM has several resource kits that are available that enhance the functionality for monitoring and managing a networking environment. Some of the tools include the following:

Having the proper hardware for MOM to operate on is a critical component of MOM functionality, reliability, and overall performance. Nothing is worse than overloading a brand-new server only a few short months after its implementation. The industry standard generally holds that any production servers deployed should remain relevant for three to four years following deployment. Stretching beyond this time frame may be possible, but the ugly truth is that hardware investments are typically short term and need to be replaced often to ensure relevance. Buying a less-expensive server may save money in the short term but could potentially increase costs associated with downtime, troubleshooting, and administration. That said, the following are the Microsoftrecommended minimums for any server running MOM 2005:

These recommendations apply only to the smallest MOM deployments and should be seen as minimum levels for MOM hardware. Future expansion and relevance of hardware should be taken into account when sizing servers for MOM deployment.

MOM can be installed either on Windows Server 2003 or Windows 2000 with Service Pack 2 or higher. Installing on Windows Server 2003 for new deployments of MOM is highly recommended, to take advantage of the improvements in the operating system (this is a book on Windows Server 2003, after all).

The database for MOM must be run on a Microsoft SQL Server 2000/2005 database. The database can be installed on the same server as MOM or on a separate server, a concept that will be discussed in more detail in following sections. While technically possible to run MOM on an MSDE, developer-related database, using the more robust SQL database structure for MOM information is highly recommended.

MOM itself must be installed on a member server in a Windows Server 2003 (or Windows 2000) Active Directory domain, and not on a domain controller, because it will not physically install if this is the case. It is most often recommended to keep the installation of MOM on a separate server or set of separate dedicated member servers that do not run any other separate applications.

A few other factors critical to the success of a MOM implementation are follows:

The consolidator and data access server components of MOM require the use of a dedicated service account. The same account can be used for these services, and doing so is actually recommended. However, for security reasons, it is theoretically possible to use two different service accounts from different domains. The caveat with this approach, however, is that each service account that accesses the SQL database requires a separate SQL client access license (CAL).

Like most technical implementations, MOM includes several key components that require regular backups for disaster recovery scenarios. The system state and system drive of each MOM server should be backed up to provide for quick recovery of MOM configuration information. Special add-ons to backup software specifically written for Microsoft Operations Manager can ensure the ability to back up live data from MOM systems. At this time, many of the large backup software manufacturers offer this type of specialized add-on to their products, and it would be prudent to integrate these components into a MOM design.

In addition, the most critical piece of MOM, the SQL database, should be regularly backed up using an additional add-on to standard backup software that can effectively perform online backups of SQL databases. If integrating these specialized backup utilities into a MOM deployment is not possible, it becomes necessary to periodically dismount the MOM database and perform offline backups. Either way, the importance of backups in a MOM environment cannot be overstressed.

MOM agents are deployed to all managed servers through the MOM configuration process. These agents can be configured to be automatically installed for all Windows Server 2003 and Windows 2000 servers on a specific domain based on managed computer rules. These rules use the NetBIOS name of the computer and the domain to allow you to select which systems should have the client installed automatically. You can use wildcards to specify a broad range of computers. Certain situations, such as monitoring across firewalls, can require the manual installation of these components.

As previously mentioned, MOM components can be divided across multiple servers to distribute load and ensure balanced functionality. This separation allows MOM servers to come in three potential “flavors,” depending on the MOM components held by those servers. The three MOM server types are as follows:

As previously defined, a MOM configuration group is a logical grouping of monitored servers that are managed by a single MOM SQL database, one or more DCAMs, and a unique configuration group name. Each configuration group established operates completely separately from other configuration groups, although they can be configured to forward alerts between each other.

The concept of alert forwarding between configuration groups allows MOM to scale beyond artificial boundaries and also gives a great deal of flexibility when combining MOM environments. However, certain caveats must be taken into account. Because each configuration group is an island in itself, each must subsequently be manually configured with individual settings. In environments with a large number of customized rules, for example, such manual configuration would create a great deal of redundant work in the creation, administration, and troubleshooting of multiple configuration groups.

Based on the factors outlined in the preceding section, it is preferable to deploy MOM in a single configuration group. However, in some situations it is preferable not to divide a MOM environment into multiple configuration groups, or dividing it this way is unavoidable.

The most common reason for division of MOM configuration groups is division along geographic lines. In situations in which WAN links are saturated or unreliable, it may be wise to separate large “islands” of WAN connectivity into separate configuration groups.

Simply being separated across slow WAN links is not enough reason to warrant a separate configuration group, however. For example, small sites with few servers would not warrant the creation of a separate MOM configuration group, with the associated hardware, software, and administrative costs. However, if many servers exist in a distributed, generally well-connected geographical area, that may be a case for the creation of a configuration group. For example, an organization could be divided into several sites across the U.S. but decide to divide the MOM environment into separate configuration groups for east coast and west coast, to roughly approximate their WAN infrastructure.

Smaller sites that are not well connected but are not large enough to warrant their own configuration group should have their event monitoring throttled to avoid being sent across the WAN during peak usage times. The downside to this approach, however, is that the reaction time to critical event response is increased.

The less common method of dividing MOM configuration groups is by political or security lines. For example, it may become necessary to separate financial servers into a separate configuration group to maintain the security of the finance environment and allow for a separate set of administrators.

Politically, if administration is not centralized within an organization, configuration groups can be established to separate MOM management into separate spheres of control. This would keep each MOM management zone under separate security models, and alert forwarding could be set up to exchange information between different configuration groups.

As previously mentioned, a single configuration group is the most efficient MOM environment and provides for the least amount of redundant setup, administration, and troubleshooting work. Consequently, artificial MOM division along political or security lines should be avoided, if possible.

All new technologies seem to consume tremendous amounts of disk space, and MOM is no exception to this trend. Depending on several factors, such as the type of data collected, the length of time that collected data will be kept, or the amount of database grooming that is scheduled, a MOM database can grow by leaps and bounds, if left unchecked. Microsoft recommends a database volume of 5GB, although it is highly recommended to consider leaving more than enough space for the database to grow. An organization might want, for example, to keep event information for longer periods of time, which would drive up the size of the database exponentially.

(((e*s)1400)g)

It is important to monitor the size of the database to ensure that it does not increase well beyond the bounds of acceptable size. As previously mentioned, MOM requires a minimum of 40% free space on the database volume to properly index, and it is imperative that a database not grow too large to affect this performance. The following actions can be taken to reduce the size of a MOM database:

MOM can be configured to monitor itself, supplying advance notice of database problems and capacity thresholds. This type of strategy is highly recommended because MOM could easily collect event information faster than it could get rid of it.

As with any system, MOM includes some hard limits that should be taken into account before deployment begins. Surpassing these limits could be cause for the creation of new configuration groups and should subsequently be included in a design plan. These limits are as follows:

MOM is scalable in the sense that multiple configuration groups can be configured to forward alerts between themselves. Within the configuration groups, multiple DCAM servers can be established as well to allow for a finer degree of scalability within each configuration group. These factors enable MOM to scale to organizations of all shapes and sizes.

MOM builds upon its multiple layers of scalability. In small deployments, a single DDCAM server will suffice. As the number of monitored servers increases, the database can be separated and additional DCAM servers can be added, roughly one per every 100 agents deployed. This can be continued until a total of six DCAM servers are deployed in a configuration group, as illustrated in Figure 25.6.

Figure 25.6. Multiple DCAMs.

When the physical limits of a configuration group have been reached, or when additional factors such as security, geographic, or political considerations move an organization to choose an additional configuration group, the final level of MOM scalability is reached. Division into multiple configuration groups allows an organization to scale a MOM deployment beyond the physical limitations of the configuration group itself.

In addition to the scalability built into MOM, redundancy is built into the components of the environment. Proper knowledge of how to deploy MOM redundancy and place MOM components correctly is important to the understanding of MOM redundancy.

Having multiple DCAM servers deployed across a configuration group allows an environment to achieve a certain level of redundancy. If a single DCAM server experiences down-time, another DCAM server within the configuration group will take over the consolidator, DAS, and agent manager components for the monitored servers in the environment. For this reason, it may be wise to include multiple DCAM servers in an environment to achieve a certain level of redundancy if high uptime is a priority, as illustrated in Figure 25.7.

Figure 25.7. MOM failover.

Because there can be only a single MOM database per configuration group, the database is subsequently a single point of failure and should be protected from downtime. Utilizing Windows Server 2003 clustering or third-party fault-tolerance solutions for SQL databases helps to mitigate the risk involved with the MOM database.

Aside from actual software security, one of the most important forms of security is actual physical security. MOM servers should be physically secured behind locked doors, and login access to the console should be curtailed to help protect the critical information contained within the environment. This concept cannot be overstressed, as physical security is one of the most highly overlooked but yet one of the most critical components of a secure infrastructure.

In addition to physical security, MOM servers should be carefully locked down at the OS level to prevent unauthorized access. This includes the creation of complex passwords for service accounts and the application of the latest service packs and security updates using the automatic update features in Windows Server 2003 to help keep the environment secure and up to date. In addition, administration of MOM security can be greatly simplified via the creation of an Active Directory group that controls MOM administration. This group can be granted admin rights to MOM servers, and users can be added as members to this group. Simplifying the administration of security often strengthens security as well because administrators take fewer security shortcuts when troubleshooting problems.

Each server that contains a MOM agent and forwards events to MOM DCAMs has specific security requirements. Server-level security, discussed in more detail in Chapter 12, “Server-Level Security,” should be established and should include provisions for MOM data collection. All traffic between MOM components, such as the agents, the DCAMs, and the database, are encrypted automatically for security, so the traffic is inherently secured.

In addition, environments with high security requirements should investigate the use of encryption technologies such as IPSec to scramble the event IDs that are sent between agents and MOM servers, to protect against eavesdropping of MOM packets. More information can be found on setting up IPSec in Chapter 13, “Transport-Level Security.”

MOM servers that are deployed across a firewall have special considerations that must be taken into account. Port 1270, the default port for MOM communications, must specifically be opened on a firewall to allow MOM to communicate across it. In addition, MOM servers can be specifically configured to exist in a DMZ firewall configuration, as long as the proper access is granted to the managed servers from the DMZ.

In addition to the aforementioned security measures, security of a MOM environment can be strengthened by the addition of multiple service accounts to handle the different MOM components. For example, the DAS and consolidator can be configured to use separate service accounts, to provide for an extra layer of protection in the event that one account is compromised. The caveat to this approach, however, is that the SQL database requires an additional CAL for each service account that accesses it.

CompanyXYZ is a 500-user organization that operates out of a single location in Reno, Nevada. A single Windows Server 2003 Active Directory domain named companyxyz.com is deployed across the entire organization. All the member servers run Windows Server 2003 and handle many specific functions, such as Active Directory, DNS, DHCP, WINS, Exchange Server 2003 email, and several other third-party software solutions.

Because of a recent rise in server and software malfunctions, the decision was made to deploy Microsoft Operations Manager 2005 to provide for a level of proactive management that would normally not be possible in the organization.

The total number of managed servers in CompanyXYZ’s environment was 46, and it was therefore decided to deploy a single D-DCAM server in a single MOM configuration group because this would be the most cost-effective and rational design for a MOM deployment on this scale.

The server chosen to handle all MOM activities was a robust, redundant, industry standard machine with plenty of extra disk space for the database. Windows Server 2003 was installed as the operating system, as were the SQL Server database components. Upon the successful completion of the OS and database installations, a special tool included with MOM, the Prerequisite Checker, was run to ensure that the system was ready for MOM installation. After this was confirmed, MOM 2005 was installed and configured onto the single MOM server. A single service account was created in the AD domain and utilized for the DAS and consolidator components of MOM. All applicable default management packs, such as DNS and DHCP, were installed and configured. Additional management packs, such as those for Exchange 2003, were downloaded and installed as well. The final MOM design for CompanyXYZ began to take shape, as illustrated in Figure 25.8.

Figure 25.8. CompanyXYZ design.

Upon the successful completion of the MOM server installation, specialized rules were written to handle the particular components that are unique to CompanyXYZ’s environment. Alert settings were configured so that a select group of administrators would be notified in the event of problems.

As a result of the MOM design chosen, CompanyXYZ feels confident that it will be able to easily scale its MOM deployment to a much larger number of servers, if required. The company is somewhat concerned about the single point of failure that the single MOM database occupies but is convinced that it chose the best and most cost-effective solution for its organization.

CompanyABC is a large, multinational corporation with 10,000 users spread across continents. Major locations exist in New York, London, and Tokyo, and many other smaller branch offices are distributed across the world. Each of the major locations currently hosts between 100 and 200 servers each, and the smaller branch offices host smaller numbers of servers, totaling no more than 10 in each office. The servers deployed are a mix of Windows Server 2003 and Windows 2000 servers, although occasional Windows NT, Novell NetWare, and Linux servers are distributed across the environment.

Because of its distributed nature, CompanyABC is composed of multiple Windows Server 2003 Active Directory subdomains, all within the same Active Directory forest. The forest structure for CompanyABC, illustrated in Figure 25.9, is composed of subdomains na.companyabc.com, eu.companyabc.com, and asia.companyabc.com, all subdomains within the placeholder domain companyabc.com.

Figure 25.9. The CompanyABC forest.

Because of the loss of productivity that any server downtime entails for CompanyABC, an enterprise management platform was necessary for the organization to achieve the high levels of uptime required. Microsoft Operations Manager was chosen for this task.

Because the company’s network environment was logically and geographically divided into three separate zones, it decided to use three MOM configuration groups for each geographic location and to use alert forwarding between each configuration group. Asia, Europe, and North America were designated as the configuration groups and were configured to manage not only the local hub servers, but also all the servers in the smaller offices that are closest to them on the WAN.

Each configuration group was set up with three DCAM servers to provide for redundancy and to allow for management of the 300 or so servers within the scope of each location’s configuration group.

In addition to the DCAM servers, each configuration group was outfitted with a robust, completely redundant database server with a large quantity of disk space to handle the collected data from each configuration group. Each MOM server was installed with Windows Server 2003 and the appropriate MOM components.

Security was configured to be granular, and each location was given control over its corresponding configuration group through the use of separate Active Directory Security Groups from each domain, which were granted control over the various MOM components in their particular configuration group.

Because the applications installed across the CompanyABC environment were diverse and numerous, the number of management packs added to MOM was subsequently large. The default management packs were used, in addition to the Microsoft add-on packages and several XMPs purchased from the NetIQ corporation. This allowed for the management of the disparate operating systems that were deployed across the environment.

In the event of DCAM downtime, the CompanyABC MOM environment continues to function because the other two DCAMs in the affected configuration group take up the slack. In addition, the alert forwarding configured among the three configuration groups helps to centralize the administrations across the continents.