When picking up a book about a new software release, one usually finds a chapter or section of material discussing “what’s new.” This material typically covers what has changed in the latest, greatest, and most wonderful release of the product. However, so many things have changed between Microsoft Operations Manager (MOM) 2005 and System Center Operations Manager (OpsMgr) 2007, we gave serious consideration to calling this chapter “What’s Not New,” or perhaps “What Stayed the Same!”
This state of affairs occurs because the newest version of Operations Manager is truly a revamped product. In its third major release by Microsoft, the product team totally rewrote its guts. Database names are different, Registry keys are renamed, consoles continue to evolve, and most importantly, the product approaches operations management in a totally different way.
Now that you’ve had an introduction to the concepts behind operations management and the capabilities of Operations Manager 2007, we are ready to focus on the differences in various versions of Microsoft’s flagship management product. We will look at what has changed between MOM 2005 and OpsMgr 2007, including changes in approach, changes to component functionality, changes in terminology, changes to consoles, changes to the reporting feature, and differences in scalability with the new version. Although we discussed similar topics in Microsoft Operations Manager 2005 Unleashed as we looked at the differences between MOM 2000 and MOM 2005, those changes were evolutionary in nature; the changes between MOM 2005 and OpsMgr 2007 are far more revolutionary. We will also take a look at OpsMgr’s smaller brother, System Center Essentials (or just Essentials for short), discussing its capabilities and the differences between Essentials and the full version of OpsMgr 2007.
First, let’s spend a moment on a brief history of Microsoft’s presence in the server monitoring marketplace. Microsoft began including server health and monitoring functionality with Microsoft Application Center 2000, Systems Management Server 2.0, and BackOffice Server 2000. The monitoring capability enabled a system administrator to have a centralized view of information pertaining to functional health, performance, and the Event log data of the servers used within that specific application server environment.
Note: A Free Utility
If you have ever tried looking through the Windows NT Event log files for security or application issues? It can be an overwhelming task—particularly if you have thousands, or tens of thousands, of servers. Indeed, this is the reason software such as Operations Manager was developed.
Not to be confused with the extended capabilities of Operations Manager, a free utility called EventCombMT.exe is available from Microsoft. EventComb parses multiple Event logs across the network and organizes the information into a single location. EventComb started as a command-line tool and was less than an overwhelming success. Microsoft has since added a GUI. You can find EventComb at http://www.microsoft.com/downloads. Search on “Security Guide Scripts Download” in the keyword field to download secops.exe, which includes EventCombMT.exe.
Operations Manager was originally based on technology developed by Mission Critical Software for its OnePoint Operations Manager product, licensed by Microsoft in 2000 from NetIQ shortly after that company acquired Mission Critical. Microsoft’s first release of the management software addressed scalability and performance issues, along with significant improvements to management packs for Microsoft applications software. With an oft-stated goal of making the Windows Server platform more manageable, Microsoft positioned MOM 2000 as an enterprise monitoring solution, including comprehensive event management, monitoring and alerting, reporting, a built-in knowledge base, and trend analysis capabilities.
During the MOM 2000 life cycle, a single service pack was released. MOM 2000 Service Pack (SP) 1 included globalization, clustered support for the MOM database on failovers, a number of performance improvements to the event management infrastructure, enhancements to most of its management packs with particular emphasis on those for Microsoft Exchange Server and Active Directory monitoring, and several new management packs. Continuing development of the product, Microsoft began work in 2003 on the next version of MOM.
Microsoft Operations Manager 2005 was released in August 2004 with an improved user interface, additional management packs, enhanced reporting, and improved performance and scalability. Microsoft next released MOM 2005 SP 1 in July 2005 with support for Windows 2003 SP 1 and SQL Server 2000 SP 4. SP 1 was also a prerequisite for the MOM 2005 support of the SQL Server 2005 engine after that product’s release later that year. Development for the next version, initially code-named “MOM V3,” also commenced in 2005. In 2006, Microsoft officially announced the upcoming version as System Center Operations Manager 2007. Work on Operations Manager 2007 was completed in March 2007, and OpsMgr 2007 SP 1’s release is anticipated in early 2008.
Figure 2.1 illustrates Operations Manager’s life cycle.
What’s so different and new about Operations Manager 2007? To start, the name of the product itself indicates OpsMgr has had a facelift. Less noticeable, at least until you start looking into the product, is that its approach towards monitoring has completely shifted. We discuss these changes in the following sections.
One of the first differences you may notice between the versions of Operations Manager is the evolution of the product name. Versions 2000 and 2005 were known as MOM, an acronym built using the company name “Microsoft” + “Operations Manager.” Version 2007 has a System Center branding, making the complete product name “System Center Operations Manager.” (This is not to say you may not find some “MOM shrapnel” or remnants in utility names or elsewhere.) The purpose of the branding ostensibly is to align Operations Manager with the System Center umbrella of products. Although this may be the official name, we have noted some effort within Microsoft to avoid using the umbrella moniker or any associated acronyms, and simply call the software Operations Manager, thus developing a following for the product itself regardless of where it is in Microsoft’s lineup. There does continue to be a dichotomy, though. You can note this in Microsoft’s System Center Pack Catalog, located at http://go.microsoft.com/fwlink/?LinkId=71124. The search function on the page includes the ability to specify the product version; the associated dropdown box displayed in Figure 2.2 includes the ability to search on all three versions of Operations Manager, but distinguishes between the older versions and the newer System Center branded software.
More than just a name change, Operations Manager’s focus in monitoring has also evolved. OpsMgr 2007 provides best-of-breed end-to-end service management for the Microsoft Windows platform, helping you increase efficiency and achieve greater control over your Information Technology (IT) environment. Operations Manager can manage thousands of event and performance monitors across operating systems and applications to provide a single view of the health of your IT environment. This focus on viewing a service’s health is key for responding to things that may affect the normal running of business and ultimately cost an organization money. This differs from earlier versions of Operations Manager that concentrated on monitoring events and generating alerts. OpsMgr 2007 is all about monitoring health. It moves away from monitoring only individual servers and applications to holistically monitoring server and client environments.
Operations Manager 2007 builds on its predecessors by adding key features and functionality requested by customers. System administrators told Microsoft they wanted to monitor more than just individual servers; they wanted it to be easier to find computers and applications needing to be monitored, and they wanted more detailed troubleshooting and best practice knowledge. The market for management solutions also had an impact in designing Operations Manager 2007. More enterprises are implementing Service Level Management, and more companies are finding a need to monitor their ever-expanding network of Microsoft Windows–based systems.
Operations Manager 2007 is far-reaching in its changes from its predecessor, MOM 2005. Not only is there the change in focus discussed in the previous section, but scalability is enhanced, security is revamped, the structure and functionality of management packs has changed, and major alterations were made to the user interface as well as in reporting capabilities. Additionally, Microsoft has reworded some of the terminology and redesigned roles; therefore, if you were an Operations Manager 2005 administrator, you’ll find it useful to understand these changes as part of planning your transition to OpsMgr 2007.
Several terms have changed between MOM 2005 and OpsMgr 2007. This section gives you an overview of these changes, and Table 2.1 recaps these terms.
Table 2.1. Terminology Equivalents and Changes
Operations Manager 2005 Term | Operations Manager 2007 Term |
|---|---|
MOM service | Health service |
Alert severity | Health state |
Alert-generating rule | Monitor |
Performance rule | Performance collection rule |
Computer group | Computer group class, installation class |
Data Access Server | Part of SDK service functionality |
First installed Management Server | Root Management Server |
Tasks | Console and agent tasks |
The OpsMgr Health service monitors the health of the computer it is installed on; it optionally can be configured to monitor the health of other computers with agentless monitoring. The Health service is on management servers and all computers running the Operations Manager agent.
Operations Manager 2007 monitors health and looks for changes in state. The health state is the status of any monitored object. Available health states are Success (green), Warning (yellow), and Error (red).
OpsMgr 2007 uses monitors to evaluate conditions that occur in monitored objects. A monitor can assess the values of a performance counter, the existence of an event, the occurrence of data in a log file, the status of a Windows service, or the occurrence of a Simple Network Management Protocol (SNMP) trap. Based on its assessment, the monitor determines the health state (status) of a target and the alerts generated. See the “Monitoring Engine” section later in this chapter for more information on how monitors work.
Performance rules have been renamed performance collection rules, which collect performance-based numeric data. Information collected by these rules displays in a performance view for those objects. A sample view is displayed in Figure 2.3.
Computer groups in Operations Manager 2005 are used to group computers with similar characteristics. Rule groups then target groups of rules to these computers.
Operations Manager 2007 monitors individual services and applications rather than computer objects. This approach allows Operations Manager 2007 to monitor the physical server separately from the software installed on the computer. When a computer group is converted from Operations Manager 2005 to Operations Manager 2007, two object types are created. The computer group class is for the physical computer, and the installation class applies to software. Computer groups are often used for targeting overrides.
In MOM 2005, the Data Access Server (DAS) is a Component Object Model Plus (COM+) application running on the management server and managing access to the Operational database. The DAS provides a communication interface between the Operational database and other components.
The OpsMgr SDK service is many things (which we discuss in detail in Chapter 3, “Looking Inside OpsMgr”), but similar to the DAS, data flowing to and from the database is transported via the SDK service.
The Root Management Server (RMS) is a new server component and maintains the topology data for the entire management group. The console user interface comes from the RMS, which is also responsible for importing management packs. We discuss the RMS in more detail in the “Server Components” section of this chapter.
In MOM 2005, a task automated a management process. OpsMgr 2007 has several new types of tasks, such as diagnostic and recovery tasks that diagnose and repair problems, respectively. The MOM 2005 task, which could be initiated from the console or on the agent, is now known as a console task or an agent task.
OpsMgr 2007 introduces an incredible amount of new functionality and a new approach to monitoring. In this section, we discuss some of the more significant changes.
Operations Manager 2007 uses model-based management, where an IT environment is defined as a model. Models allow for more granular discovery of service components and present the ability to monitor not only the servers but also the entire end-to-end service as a unique object. Once it’s defined, you can monitor an end-to-end service just like any other device.
Knowledge is captured through models. Models put knowledge in a structure that software can act on, and they define the health of complex IT services and systems—including their structure, constraints, and policies. OpsMgr 2007 models are defined natively and represented in eXtensible Markup Language (XML). By defining the IT environment as models, Operations Manager can better understand the relationships between the distributed applications and components that make up your IT services.
Earlier versions of Operations Manager focused on monitoring individual server health, not taking into account the distributed nature of many enterprise applications and services. OpsMgr 2007 introduces service modeling, which allows distributed applications to be represented as a service. The software includes a graphical Distributed Application Designer, making the task of defining service models easier. With the Designer, you can diagram the flow of your critical distributed applications and set interdependencies for each object. Any object that OpsMgr manages can be included in a service model; you can represent and monitor applications, hardware, and networking components.
As an example, let’s consider a classic three-tiered business application with two front-end web services, a middle logic tier, and a backend database. Using the Distributed Application Designer displayed in Figure 2.4, you can quickly and easily describe monitoring requirements for this application that correspond to how it was architected. The Designer allows you to create your tiers and drag and drop each component object into the correct tier. This creates a distributed view, from which you can be alerted on every aspect of your application, minimizing resolution time for other affected systems. Now that is cool!
This end-to-end service modeling enables proactive monitoring of IT service health, enduser perspective modeling, new service-oriented views, dashboards, reports, and templates. Using the Designer will accelerate third-party management pack development for infrastructure and other types of applications.
Operations Manager 2007 introduces Agentless Exception Monitoring (AEM). AEM captures, aggregates, and reports on application crashes—commonly known as Dr. Watson errors—throughout your enterprise, giving you a view of which applications and systems are suffering the most crashes.
Using Group Policy, AEM redirects Watson clients to a designated management server and allows OpsMgr to monitor client crash and hang data as part of enterprise health. Alerts are generated based on aggregated crash trends, and reports display top crashes and trends across the organization.
Operations Manager 2005 had three consoles:
An Administrator console for making configuration changes, which used Microsoft Management Console (MMC) technology.
An Operator console for managing alerts, events, and performance.
A Reporting console for defining and publishing reports. This was actually the SQL Reporting Services (SRS) Report Manager console.
Operations Manager 2007 consolidates these three functions into one console (which is similar to the approach in MOM 2000, which combined the Administrator and Operator consoles). Whereas MOM 2005 supported a limit of 15 active Operator consoles in a single management group, there is no theoretical limit to the number of active Operations consoles with OpsMgr 2007, with 50 simultaneous consoles tested.
The OpsMgr 2007 Operations console, displayed in Figure 2.5, does not use the MMC interface, but like the MOM 2005 Operator console it has a similar look and feel to Microsoft Outlook. The console includes a toolbar, a Navigation pane and navigation buttons on the left side, the Results pane and Details pane in the center, and the Actions pane on the right side. Selecting options such as overrides, search, the Health Explorer, or Reporting launches new windows to support those operations. There are also a number of views in the Monitoring and Authoring spaces. Further information about using the Operations console can be found in Chapter 8, “Configuring and Using Operations Manager 2007.”
Both versions of Operations Manager include a Web console. Whereas the MOM 2005 Web console used port 1272 by default, the OpsMgr 2007 Web console, displayed in Figure 2.6, uses port 51908. The Web console provides similar functionality to the full console for operational monitoring.
PowerShell support, included with Exchange 2007 and Windows Server 2008, is also available using the Command Shell, which is an instance of PowerShell customized with OpsMgr extensions. Using PowerShell, an administrator can make configuration changes, view alerts, run tasks, deploy agents, and so on. The primary advantages of using PowerShell over the Operations console is that it supports scripting, thus allowing an administrator to perform most of the work that can be done in the Operations and Web consoles in a batch mode.
Role-based security allows limiting the privileges that users have for various aspects of Operations Manager, giving OpsMgr 2007 administrators granular control over what is visible and restricting user access to only those features they are authorized to use. SQL database administrators can only see SQL information; Exchange admins can just see Exchange information; and so on.
Tip: How Far Does Security Reach?
Role-based security is not limited to the Operations console; it encompasses any SDK client or application that uses the OpsMgr class libraries to connect to the SDK service. SDK clients include the Operations console, Web console, Operations Manager Command Shell, and other customized applications.
The Authoring console, planned for release with OpsMgr 2007 Service Pack 1, will provide new functionality for writing management packs without the requirement to use XML. We discuss the Authoring console in Chapter 23, “Developing Management Packs and Reports.”
The Health Explorer is a window in Operations Manager where you can view and then take action on alerts, state changes, and other significant issues. You access the Health Explorer from the Actions pane in the Operations console after selecting an object, alert, or event in the Results pane.
Health Explorer organizes information into several categories:
Availability
Configuration
Performance
Security
Within each category, all monitors and rules defined for a particular selected object will display. When the Explorer first opens, all monitors in a failed (red) state are expanded by default. If a monitor is a rollup monitor so that it contains other monitors (as in the example in Figure 2.7), those monitors are shown in a hierarchical layout displaying monitoring data for all services and applications dependent on the one that failed. This particular example shows that the MonitoringHost Private Bytes Threshold is in an error state. Hierarchically, this threshold is under the Performance category. You can see the rollup through the different monitors in the hierarchy, with the topmost monitor reflecting the state of health of the worst object.
The Command Shell in OpsMgr 2007 uses Windows PowerShell technology, providing a command-line environment administrators can use to automate administration. Using the Command Shell, you can use the get-momcommand cmdlet to get a list of Operations Manager 2007 cmdlets and the get-Help cmdlet to display help for each cmdlet.
OpsMgr 2007 supports the Web Services for Management (WS-Management) industrystandard management protocol. WS-Management identifies core Web service specifications and usage requirements to enable management using Web services. By providing a common way for systems to access and exchange management information, WS-Management addresses the cost and complexity of IT management.
MOM 2005 only supported SNMP trap monitoring. Operations Manager 2007 supports the full SNMPv2 stack (and SP 1 adds support for SNMPv1), including polling and trap monitoring. OpsMgr is now able to not only receive traps but also use SNMP to discover network devices such as routers, print servers, and computers not running Windows, even if the device or operating system is not being monitored with a management pack. You can also create your own monitors and rules using SNMP to monitor network devices or other operating systems. SNMP-based monitors and rules can collect data from SNMP events or traps, generate alerts, or change the health state of the monitored object.
MOM 2005 had limited security options: a user could be a MOM Administrator, a MOM Author, or MOM User. These were local security groups residing on each management server. Members of these groups had access to the entire Operator console, but actions were limited based on group membership. MOM Administrators and Authors also could access the Administrator console.
OpsMgr 2007 uses role-based security. Operations such as resolving alerts, executing console tasks, overriding monitors, creating user roles, viewing alerts, viewing events, and so on, have been grouped into profiles. A role is a combination of a profile (capabilities) and a scope (the breadth of data and objects one is able to access), as illustrated in Figure 2.8. Active Directory (AD) security groups typically are assigned to roles, with individual user accounts assigned to those security groups.
Role-based security eliminates the need of using multiple management groups solely to control scope between different types of users looking at data. As an example, many MOM 2005 implementations used a separate management group for security monitoring. Administrators are now able to define user roles that have access to only specific systems, views, and tasks within the console. This gives you the capability to grant access to a user who needs to manage events and performance for a select group of computers, such as mail servers or database servers. The user cannot see any other systems in the console and is unable to execute tasks other than those approved for that particular role.
This role-based security is in effect for the Operations console, Web console, command line, and any other SDK-level interfaces. Roles created during setup include the following:
Operations Manager Administrator—. This role has full privileges to Operations Manager. The role initially includes the local Administrators group (BUILTINAdministrators) or the OM Admins global group if specified during setup.
Operations Manager Advanced Operators—. Gives access to limited tweaking of the monitoring configuration and Operators privileges, described later. Members can override the configuration of rules and monitor specific targets or groups of targets within a configured scope.
Operations Manager Authors—. This role includes a set of privileges allowing authoring of the monitoring configuration. Members have the ability to create, edit, and delete monitoring configurations (tasks, rules, monitors, and views) with a configured scope.
Authors are often given Advanced Operator privileges.
Operations Manager Operators—. Includes a set of privileges to give access to alerts, views, and tasks.
Operations Manager Read-Only Operators—. Gives read-only access to alerts and views.
Operations Manager Report Operators—. This role is designed for users who need to access reports.
Operations Manager Report Security Administrators—. Includes a set of privileges designed to enable integrating SRS security with Operations Manager, giving Operations Manager Administrators the ability to control access to reports.
A user can belong to multiple roles; the resultant scope is the union of all roles the user belongs to.
Run As Profiles and Run As Accounts are used to specify users with the necessary privileges to run rules, tasks, and monitors. Keep the following points in mind:
Using a Run As Profile associates an identity with a module so that it can run as that identity. The default account for the Run As Profile is the Agent Action account. A management pack author can use a Run As Profile to associate a different identity with a module. You can override the account associated with a Run As Profile on a per-computer basis.
A Run As Account is an identity that you can associate with a Run As Profile. Using Run As Accounts alleviates the need for users to have administrator access. A Run As Account is an Operations Manager object that maps to an AD user account. Multiple Run As Accounts can be associated with a Run As Profile.
Run As Accounts are stored on the RMS and accessed by the SDK service, which we describe in the next section.
OpsMgr 2007 runs three services on the RMS:
Health service (HealthService)—. Monitors computer health. This service is renamed from the MOM service in MOM 2005. The Health service runs on management servers and agent-managed computers.
Config service (OMCFG)—. Sends updates from the RMS to other management servers and agents in that management group. It manages the relationships and topology of the OpsMgr environment.
SDK service (OMSDK)—. The SDK service can be considered the core service in OpsMgr. If the SDK service isn’t running, you cannot connect to the Operations console, because this service allows client applications to access OpsMgr data and functionality. The SDK service is responsible for importing and storing management packs in the Operations database, and it writes operational data (events, state changes, and performance counters) into the Operations database.
There is also the Operations Manager Audit Forwarding service, which sends events to a collector for storage in the Audit Collection Services (ACS) database. ACS is introduced in the “Audit Collection” section of this chapter.
OpsMgr 2007 uses Active Directory for security, discovery, and agent management. Here are some key points:
During setup, you can designate the OM Admins global group as Operations Manager Administrators, rather than using the default BUILTINAdministrators group.
The OpsMgr Discovery Wizard makes great use of OpsMgr’s integration with Active Directory, using standard Lightweight Directory Access Protocol (LDAP) queries to find devices in the directory to manage. Administrators can customize these LDAP queries.
The MOMADAdmin.exe support tool integrates agent management with Active Directory. MOMADAdmin creates an OpsMgr container, which is an AD Organizational Unit (OU) with subcontainers for each management group in your domain. The subcontainers include service connection point objects; agents query these objects to get configuration information that identifies the management groups and management servers the agents connect to and are managed by. To view these containers, you must select the option View Advanced Features in the Active Directory Users and Computers snap-in.
The MOMADAdmin tool does not extend the Active Directory schema.
An agent can be included in an operating system image. When the image is deployed, the agent queries AD to find and register with the appropriate management server.
As an example, let’s say you add the Operations Manager agent to your SQL Server 2005 image and configure the agent to get its management group information using AD. When you bring up a new SQL Server 2005 Server built with that image, it is already configured for management by the specified management group, and it will download the applicable management packs.
You can now specify database names during OpsMgr installation! The name of the Operational database, where monitoring and configuration information is stored, has changed from the previous hard-coded name of OnePoint. The default database name is OperationsManager, but you are able to specify a unique name. Specifying the database name allows you to house multiple Operational databases on a single SQL Server 2005 database server.
You also can specify a name for the Reporting database/data warehouse, which has a default name of OperationsManagerDW. The data warehouse can be on the same database server as the Operations database or on a different one (for performance reasons, we recommend they be separate), and unlike MOM 2005 Reporting, it natively supports multiple management groups.
Using unique database names enables you to do a side-by-side migration from MOM 2005 and its OnePoint database using the same hardware, although there are some considerations with the Reporting Database Server Component:
MOM 2005 Reporting and the OpsMgr 2007 data warehouse do not share code structures, so they will not be “colliding.”
Placing two “data warehouses” on the same server could be risky since they could be competing for the same resources (CPU, memory), so using a single server is not recommended with a medium or high load. Chapter 7, “Migrating to Operations Manager 2007,” provides in-depth information regarding the migration process.
You do not have to run the Operations Manager setup program to install the Operations and Reporting databases—you can just run the appropriate .msi file standalone from the command line.
The Operations database setup can run remotely (and silently) from the intended management server.
A single script can deploy the Reporting Server and Reporting data warehouse database.
When using SQL Server clustering, you do not have to install the database on every node of a cluster—just run it on the active cluster only.
Earlier versions of Operations Manager included SQL jobs that performed various types of database maintenance. This approach changes with Operations Manager 2007, which uses management pack rules to execute the database maintenance stored procedures. Grooming information, as before, is a Global Setting in the Operations console under Administration -> Settings -> Database Grooming.
One of the less visible areas of change in Operations Manager 2007 is Microsoft’s removal of evidence pointing to the product’s Mission Critical Software predecessor. We previously mentioned in the “Databases” section of this chapter that the Operational database no longer uses Mission Critical Software’s hard-coded name of OnePoint. Microsoft also revamps the Registry structure in this version, renaming the keys under HKEY_LOCAL_MACHINESOFTWAREMicrosoft from OnePoint to Microsoft Operations Manager.
Operations Manager 2007 adds several new server components. MOM 2005 had four server components (Management Server, Database Server, Data Warehouse Server, and the Reporting Server). OpsMgr 2007 adds a number of new components, including the Root Management Server and Gateway Server components.
Root Management Server—. By default, this server is the first management server installed in a management group. The RMS supports failover clustering and manages role-based security, extensibility, and analysis of the distributed health models defined in the OpsMgr infrastructure. Two Windows services run only on the RMS: the Config service and the SDK service. You can think of the RMS in some sense as analogous to a Flexible Single Master Operations (FSMO) role; it performs unique functions in the management group.
Only members of the Operations Manager Administrators user role can connect to the RMS.
Gateway Server—. MOM 2005 included the option to use mutual authentication for secure communications between the management server and agent. OpsMgr 2007 requires mutual authentication. The dilemma here is that if an agent belongs to an untrusted domain, is outside the corporate firewall, in a demilitarized zone (DMZ), or in a workgroup, it is not able to communicate with a management server if mutual authentication is required.
The gateway server uses certificates to communicate with those agents without compromising OpsMgr’s secure communication channel. You can think of this server as a proxy server; it aggregates communications from agents and forwards them to a management server inside the firewall. The gateway server belongs to the management group, but it does not have direct access to the Operations database, Data Warehouse database, or RMS. In a sense, it is a stripped-down management server. Using a gateway server allows the Operations Manager Discovery Wizard to discover target computers across one-way trusted domains, in untrusted domains, and in workgroups. (In a workgroup environment, certificates are required between agents and the gateway server.) Because all communication flows through the gateway, you only need one open port (TCP 5723) on your firewall. You will read more about the gateway server in Chapter 10, “Complex Configurations.”
Note: What, More Components?
Operations Manager 2007 also includes new components for Audit Collection Services, which is introduced in the “Audit Collection” section later in this chapter.
The RMS supports Microsoft Clustering Services (MSCS) on Windows Server 2003. The database servers, which use the Microsoft SQL Services 2005 engine, support active/passive database clustering. Further availability enhancements include:
Active/Passive: Operations, data warehouse, and ACS databases can be on the same active node of the cluster.
Active/Active: Operations database can be on one active node with the data warehouse database on the other active node.
Active/Active: Data warehouse database can be on one active node with the ACS database on the other active node.
Active/Active: Operations database can be on one active node with the ACS database on the other active node.
Active/Passive: Operations database and the Root Management Server can be on the same active node.
You can deploy management servers and gateway servers in pairs for failover purposes. OpsMgr 2007 supports fully automated agent failover for management servers; if a management server fails, the agents communicating with it will automatically fail over to another management server in that management group. Chapter 5, “Planning Complex Configurations,” includes more information regarding high availability.
A large part of MOM 2005 customization consisted of tuning performance thresholds for each installation’s unique environment. OpsMgr 2007 is more intuitive and supports self-tuning thresholds, which monitor a performance counter and set an upper and lower threshold based on historical activity within a particular business cycle. If performance exceeds these limits, the system generates an alert.
Agent deployment options now include using Active Directory, Systems Management Server/System Center Configuration Manager, or the Operations Manager Command Shell (a PowerShell instance). Agent support includes several new areas: embedded devices and Windows Vista. Like most of Operations Manager 2007, the agent code has been totally rewritten.
MOM 2005 included the capability to place monitored servers in maintenance mode, suppressing any alerts related to those servers during planned maintenance. OpsMgr 2007’s granularity allows you to apply maintenance mode to an object at any level in the hierarchy. As an example, an individual database on a SQL Server can be in maintenance mode while the rest of the server is not. This functionality gives you a much more accurate picture of the health of your environment.
Operations Manager has always supported notification using email or a pager. Improvements to notification in OpsMgr 2007 include adding instant messaging, Session Initiation Protocol (SIP), Simple Message Service (SMS) support, and support for redundant Simple Mail Transfer Protocol (SMTP) servers. Users can configure notifications individually, selecting the notification method they prefer.
Microsoft has made numerous improvements to the OpsMgr 2007 monitoring engine. The new engine uses a modular and more extensible design. The monitoring engine is the same on the management server, agent, and RMS. The new design allows for workflow isolation, with increased efficiency and more reliable monitoring. You can read more about the monitoring engine in Chapter 3.
The way OpsMgr monitors has also changed. To demonstrate the difference in monitoring between MOM 2005 and OpsMgr 2007, let’s step through the following comparison, illustrated in Figure 2.9.
Operations Manager 2005:
Operations Manager 2007:
Watches for a condition
Changes state
Rolls up state as required
Optionally generates an alert or notification
Operations Manager 2007 also refers to “monitors.” A monitor is a state machine, which monitors some aspect of an application. A monitor can be in one state at any time. Monitors have a limited number of operational states (currently three—Success, Warning, and Error). Each operational state maps to a health state. Monitors can optionally define alerting conditions.
How do monitors differ from rules?
A monitor consists of a monitor type, made up of data sources, condition detection modules, and write actions; rules are defined directly from individual modules and do not have an intermediate “type.”
Monitors can only produce state change information, whereas rules cannot produce state information at all (that is, monitors are the only thing that can affect the state of an instance).
Monitors exist in a hierarchy for every instance in the system. Rules are single workflows that act independently of one another.
Data sources for monitors include events, performance counters, Windows Management Instrumentation (WMI) information, log files, SNMP traps, WS-Management information, scripts, Object Linking and Embedding Database (OLEDB) data, LDAP data, syslog information, and so on. These data sources sound quite similar to the data sources used with management packs in Operations Manager 2005; but using monitors enables a more granular level of monitoring.
This new architecture sets a foundation for increased monitoring capabilities and extensibility.
In Operations Manager 2007, you can define synthetic transactions and deploy them to watcher nodes, which are client computers designated to run these transactions. These synthetic transactions execute and perform a sequence of steps defined in the transaction. Transactions are monitored for success or failure, performance, and duration.
Client monitoring is important because although a service may be running and available to the servers that support it, there is no guarantee that service is available to clients. Using synthetic transactions allows you to have visibility not only into service health but also into the end user’s experience.
There are multiple aspects to client monitoring, which we discuss in Chapter 16, “Client Monitoring.”
Operations Manager includes a software development kit (SDK) and a connector framework, enabling developers to build custom management packs or product connectors for OpsMgr 2007. You can extend these components to monitor non-Microsoft software and operating systems, hardware, and network devices. The connector framework enables easy integration of OpsMgr with other management technologies.
Connectors differ conceptually from management packs. Management packs are a vehicle for capturing knowledge associated with managing a particular component, which can roll up multiple components that describe an end-to-end service. Connectors are typically conduits for passing information between different management tools such as those from HP, Tivoli, and CA. You may also see connectors created for EMC Smarts and service desk solutions such as Remedy.
MOM 2005 supported a three-level hierarchy of tiered management groups, connected with the MOM-to-MOM Connector (part of the Connector Framework or MCF), which transmitted alert and discovery information between the management groups.
Operations Manager 2007 no longer uses the MOM-to-MOM Connector. Instead, you can implement connected management groups. Using connected management groups gives you a single console view, enabling you to view and edit alerts and other monitoring data from multiple management groups from the local management group. You can also initiate tasks from the local management group to run on managed objects of a connected group. There is no limit on the number of connected management groups.
New with Operations Manager 2007, ACS provides a secure and efficient way to gather Windows Security logs from systems and consolidate them for analysis and reporting.
Security events from monitored computers are stored in an Audit database. You can install the database on the same database server as the Operations database, although for security reasons Microsoft recommends they be separate. Deploying ACS involves ACS forwarders, the ACS collector, and the ACS database. The ACS agent is included in the OpsMgr agent deployment.
Microsoft gives the following numbers for ACS capacity:
150 domain controllers (DCs) to one collector
3000 Windows servers to one collector
10,000 agents monitoring workstations to a single collector
65 simultaneous consoles
Note: ACS Maintenance and SQL Server 2005 Editions
Although ACS supports both SQL Server 2005 Standard and Enterprise Edition, the version you select affects ACS behavior during its daily database maintenance window. SQL Server 2005 Standard Edition cannot perform online indexing, so it will not insert security events into the ACS database during this time. Inserts do take place with Enterprise Edition.
Refer to Chapter 15, “Monitoring Audit Control Services,” for more information about ACS.
Perhaps one way to show how much has changed between OpsMgr 2007 and Microsoft’s earlier versions is by looking at the following two figures. Figure 2.10 shows the differences in data flow between MOM 2000 and MOM 2005.
These are fairly simplistic drawings compared with Figure 2.11, which shows data flow between major OpsMgr 2007 components (for simplicity, the Web console and ACS are not included in Figure 2.11). In OpsMgr 2007, the RMS is at the center of the hub, because it is the only component that has direct communication with the user interface and the Reporting server. OpsMgr designs need to take into consideration the unique responsibilities of the RMS, which we discuss in Chapter 4, “Planning Your Operations Manager Deployment.”
Similar to MOM 2005, OpsMgr uses the Microsoft SQL Server Reporting Component, also known as Reporting Services (SRS), as its reporting engine, although OpsMgr 2007 does not use the SRS user interface. SRS 2005 includes many enhancements to the SRS included with Microsoft SQL Server 2000 and used in MOM 2005, including easier authoring and publishing.
Microsoft has integrated reporting with OpsMgr security and incorporated reporting functionality into the Operations console. As mentioned in the “Consoles” section of this chapter, you no longer use the SQL Server Report Manager web interface to view reports. The OpsMgr 2007 console includes an intuitive and easy-to-use graphical report designer—it is no longer necessary to be an SRS/Visual Studio expert to author reports!
Reporting also has several new controls to create sophisticated reports and dashboards, and Microsoft’s management packs already include many of the more common reports. Designing reports is discussed in Chapter 23.
Unlike MOM 2005 Reporting, a Data Transformation Services (DTS) job is not necessary to transfer operational data to the Data Warehouse database. The agent sends data directly to the data warehouse. This means that reporting data is now available with virtually no latency. Nor is user maintenance required on the database warehouse used to store reporting data; it automatically grooms, partitions, and optimizes itself. The data is preaggregated, summarized, and indexed; reports covering long periods of time display quickly.
Operations Manager 2007 uses object-oriented monitoring, collecting data against objects. This object-oriented approach also applies to reporting. As an example, performance reports look at a performance rule and an object when generating a report. In MOM 2005, the Processor - %Processor Time - _Total report collected data against a computer, which you found using its NetBIOS name. OpsMgr 2007 collects this information against an object—in this case Windows Operating System. The report finds data when it searches for objects that are of type Windows Operating System. You would search for objects that contain “Server 2003,” then look for those objects that are of type “Windows Operating System.” Performance reports use performance collection data, differing from some other reports such as the generic Availability report, which is based on state data and looks at entity health. The Reporting console includes knowledge showing which objects to search for to get data.
The heart of Operations Manager is its management packs, which are collections of events, alerts, and performance counters for a specific application or product feature set. Management packs (MPs) in OpsMgr 2007 use eXtensible Markup Language, supporting Microsoft’s move to model-based management and making management packs more “extensible.”
Management packs shipped from Microsoft and other vendors are now sealed, versioned, and signed with a certificate. After a management pack is imported into Operations Manager 2007, it immediately starts to monitor objects based on default configurations and thresholds. You can customize these default settings using either overrides or by creating your own monitoring objects such as monitors, rules, and tasks.
Because vendor MPs are sealed, any customizations you create are saved to a separate unsealed MP, by default, to the Default Management Pack. This ensures that when a new version of a sealed MP becomes available, the management pack is replaced without overlaying your customizations. Sealed MPs also make it easy to delete a management pack if you no longer need it, and the operation of removing a management pack is part of the Operations console.
Operations Manager 2000 and 2005 management packs used a proprietary .akm format. Using XML makes it easier to develop management packs supporting OpsMgr’s new model-based architecture.
You can convert your MOM 2005 management packs to the new format using a two-step process:
The MP2XML utility in the MOM 2005 Resource Kit converts the MOM 2005 MP from .akm file format to MOM 2005 .xml file format.
The OpsMgr 2007 MPConvert support tool converts the MOM 2005 .xml file to the OpsMgr 2007 .xml file format.
Alternatively, you can use the Migration Wizard, discussed in Chapter 7.
The following MOM 2005 MP objects cannot be converted to the 2007 format:
Operator
Report
Console scope
OpsMgr 2007 includes monitoring templates, making it quick and easy to create management packs with the Add Monitoring Authoring Wizard in the Operations console.
MOM 2005 did not immediately deploy management pack updates to agents. Changes to the agents occurred on a scheduled basis, or you could force changes immediately by specifying the Commit Configuration Changes option. Updates occur as needed in OpsMgr 2007, making the Commit Configurations Changes option unnecessary.
The Default MP is imported during the installation process. By default, any new management pack objects you create are saved to Default, although you can specify a different location (which is recommended). In addition, if you create an override to customize a setting in a sealed management pack, the override is saved to the Default MP, by default.
You may have heard the expression that “a picture is worth a thousand words.” Sometimes a comparison table can also be worth a thousand words. Perhaps we can best summarize the scope of changes using Table 2.2, which shows the differences in features between Operations Manager 2007 and its predecessor, MOM 2005.
Table 2.2. Enhancements in Operations Manager 2007
MOM 2005 | Operations Manager 2007 | |
|---|---|---|
Service-Oriented Monitoring | X | |
Synthetic Transactions | X | X (enhanced) |
Model-based architecture | X | |
Monitoring templates | X | |
WS-Management support | X | |
SNMPv1 support | X | Added with SP 1, enhanced |
SNMPv2 support | X | X (enhanced) |
Client Monitoring | X | |
Audit Collection | X | |
Native XML management packs | X | |
Reporting | X | X (enhanced) |
Self-Tuning Thresholds | X | |
Server components | X | X (enhanced) |
High Availability | X | X (enhanced) |
Monitoring Engine | X | X (enhanced) |
Notifications | X | X (enhanced) |
Connector Framework | X | X (enhanced) |
Consolidated Console | X | |
Role-based security | X | |
Active Directory integration | X | |
Windows PowerShell command console | X |
With the most recent version of Operations Manager, Microsoft has increased capacity in several areas to extend the product’s monitoring capabilities. Table 2.3 compares MOM 2000, MOM 2000 Service Pack 1 (SP 1), MOM 2005, MOM 2005 SP 1, and OpsMgr 2007’s management features. The terminology utilizes Operations Manager 2007 nomenclatures.
Table 2.3. Comparison of Operations Manager Capabilities Across Versions
MOM 2000 | MOM 2000 SP 1 | MOM 2005 | MOM 2005 SP 1 | OpsMgr 2007 | OpsMgr 2007 SP 1 | |
|---|---|---|---|---|---|---|
Managed computers in a management group | 1000 | 2000 | 3500 | 4000 | 5000 | 6000 |
Managed computers per management server | 700 | 1000 | 1200 | 2000 | 2000 | 2000 |
Management servers per management group | 4 | 10 | 10 | 10 | No defined limit | No defined limit |
Source management groups forwarding to a destination management group | 6 | 10 | 10 | 10 | n/a | n/a |
Agents per gateway server | n/a | n/a | n/a | n/a | 200 recommended | 800 recommended |
No capacity increases for OpsMgr 2007 Service Pack 1 have been announced at the time of the SP 1 Release Candidate.
In Table 2.4, we compare the basic hardware and software requirements for the different versions of Operations Manager. The hardware requirements are considerably beefed up for the newest version. (The hardware and software requirements do not change with OpsMgr 2007 SP 1.)
Table 2.4. Comparison of Minimum Requirements Across Versions
Component | MOM 2000 | MOM 2000 SP 1 | MOM 2005 | MOM 2005 SP 1 | OpsMgr 2007 |
|---|---|---|---|---|---|
Processor | Pentium-compatible 550MHz or higher. | Pentium-compatible 550MHz or higher. | Pentium-compatible 550MHz or higher. | Pentium-compatible 550MHz or higher. | Pentium-compatible 1.8GHz or higher. |
Memory | 512MB of RAM. | 512MB of RAM. | 1GB of RAM if all components are on a single server; otherwise 512MB. | 1GB of RAM if all components are on a single server; otherwise 512MB. | 1GB of RAM suggested for each component. |
Hard disk | 1GB plus 5GB for OnePoint. | 1GB plus 5GB for OnePoint. | 1GB plus 5GB for OnePoint. 200GB for MOM Reporting. | 1GB plus 5GB for OnePoint. 200GB for MOM Reporting. | 5GB plus 10GB for Operations database. 20GB for Data Warehouse database and Audit database. |
Operating System | Windows 2000 Server Family, SP 2 or later. | Windows 2000 Server Family, SP 2 or later. | Windows 2000 Server Family, SP 4 or later, or Windows Server 2003 Family. | Windows Server 2003 Family, SP 1 or later. | Windows Server 2003 Family, SP 1 or later. |
Database Server | SQL Server 2000 and Access 2000 or later for reporting. | SQL Server 2000 and Access 2000 or later for reporting. | SQL Server 2000, SP 3.0a or later, and SQL Server 2000 Reporting Services for reporting. | SQL Server 2000, SP 3.0a or later, SQL Server 2005, and SQL Server 2000 Reporting Services with SP 1 for reporting (or the SQL Server 2005 Reporting Services component) | SQL Server 2005 (with SQL_Latin1_General_CP1_CS_AS collation) for Operations and Audit Collection databases. Reporting Services Component with SP 1 for Reporting Server and Reporting Data Warehouse. |
The Prerequisite Checker is an invaluable part of the installation process, letting you know exactly what deficiencies you have before starting your installation. We describe requirements for OpsMgr 2007 in detail in Chapter 6, “Installing Operations Manager 2007.”
Tip: Eval Version of Operations Manager 2007 Available
You can download a 180-day evaluation copy of OpsMgr 2007 at http://www.microsoft.com/technet/prodtechnol/eval/scom/default.mspx.
System Center Essentials 2007 (Essentials) is a new product in the System Center family. Essentials is designed specifically for IT professionals in small and midsize businesses who face challenges similar to those of large enterprises—troubleshooting end-user problems, automating management tasks, managing multiple systems, and diagnosing and resolving problems.
Like larger environments, many small and midsize organizations use a multitude of tools to manage their IT environments; these tools tend to focus on individual areas of monitoring rather than being a comprehensive set of management tools. Tools that are easy to use often are narrow in scope and limited in functionality, whereas tools that are more functional may be overkill, are complex, and are difficult to learn—particularly for organizations with smaller IT departments. To address this need for small to medium-sized businesses, Microsoft developed Essentials 2007, which replaces MOM 2005 Workgroup Edition.
Unlike MOM 2005 Workgroup Edition, Essentials is not just a stripped-down version of Operations Manager. Microsoft spent a considerable amount of time talking to small and midsize companies with IT organizations of one or two people. Essentials, the result of this research, integrates operations management and configuration management capabilities into one central console.
In addition to a monitoring console that looks similar to the OpsMgr 2007 Operations console, Essentials can assess, configure, and distribute Microsoft and third-party software updates using the System Center Update Packager (SCUP) and WSUS 3.0; manage software and hardware inventory using over 30 attributes; and deploy software to targeted groups and computers. Although this sounds similar to that available with Configuration Manager (ConfigMgr) 2007, Essentials is limited to monitoring 30 Windows servers and 500 Windows non-server-based computers. Essentials can also monitor an unlimited number of network devices using SNMP.
Table 2.5 compares the functionality between OpsMgr 2007 and Essentials 2007.
Table 2.5. Features Available in Operations Manager 2007 and System Center Essentials 2007
Features | OpsMgr | Essentials | Comments |
|---|---|---|---|
Management packs | X | X | |
Monitor servers, clients, and services | X | X | |
Management pack authoring | X | X | Essentials has a basic interface; the OpsMgr interface is more sophisticated. |
Role-based security | X | Essentials does not include a facility for role-based administration. | |
Multiple management servers in domain | X | X | All monitored systems must be in the same Active Directory forest. |
Reporting | X | X (basic) | Essentials does not include a data warehouse or fixed grooming schedule (only a maximum of 37 days of report data can be stored); the Operations and Reporting databases are on the same server, and Report authoring is not supported. |
Fault tolerance support | X | Essentials does not support database clustering of the Operations or Reporting database or clustering the Essentials management server. | |
Connector framework | X | ||
ACS | X | ||
AD Integration | X | X | AD integration with Essentials consists of pushing Group Policy Objects (GPOs) and creating AD security groups. |
PowerShell Integration | X | ||
Web console | X |
Now let’s look at the other Microsoft product Essentials shares features with. Table 2.6 compares the functionality between System Management Server/Configuration Manager 2007 and Essentials 2007.
Table 2.6. Features Available in ConfigMgr 2007 and System Center Essentials 2007
Features | ConfigMgr | Essentials | Comments |
|---|---|---|---|
Update management | X | X | |
Software distribution | X | X | |
Hardware and software inventory | X | X | Essentials captures approximately 30 hardware and software attributes. |
Operating System deployment | X | ||
Mobile device management | X | ||
Desired configuration management | X | ||
Branch office support | X | X (basic) | Essentials does not include site servers. |
Network Access Protection (NAP) support | X | ||
Wake on Local Area Network (LAN) | X |
Microsoft has a 30-day evaluation version of System Center Essentials available as a virtual machine. You can download it from http://www.microsoft.com/downloads/details.aspx?FamilyID=27342759-e9d6-4073-918c-e9dff77d0206&DisplayLang=en (this URL is also available as a live link in Appendix E, “Reference URLs”). The image enables you to try Essentials 2007 on up to 10 servers and 50 clients.
In this chapter, we discussed the differences between MOM 2005 and OpsMgr 2007. We covered changes in terminology, functionality, capacity, and prerequisites. We also introduced System Center Essentials 2007 and compared its features with Operations Manager 2007. Essentials 2007 is the upgrade from MOM 2005 Workgroup Edition for smaller IT shops, although its functionality is very different.
The next chapter talks about how Operations Manager works; it includes an architectural overview and discussion of the workflow engine in OpsMgr 2007.