Windows Server Reference Guide

Introducing System Center Operations Manager

Last updated Jan 25, 2008.

The everyday management and organization of network operations can be simplified—at least conceptually—if you consider them as being comprised essentially of the following:

• User requests and the responses to those requests
• Scheduled actions and the monitoring of the success of those actions
• Signals of events, an assessment of the effects of those events, a diagnosis of their causes (if necessary), and the responses to those events

So there are really only three things to worry about, multiplied only by the number of times you need to worry about them in a day. It is this factor that distinguishes you, the network administrator, from the temp hired to answer the phone in the front lobby.

Your New Virtual Back Office

The question of whether Microsoft should package its Operations Manager product along with its operating system has kept us wondering for as long as four straight years. Previously, what was called Microsoft Operations Manager (MOM) was made available for a separate download. Now, Microsoft finds itself in the administrative tools business, which means that it produces this software not for a free download but for evaluation and sale. It's in competition with other players in this space, which means it must produce a product that is on a par with the competition.

Perhaps the most comprehensive and convincing way for you to see how System Center Operations Manager works is for you to try it yourself, right now, on one of Microsoft's safe, remote experimental servers at its TechNet Virtual Lab. Here, you can log on as a domain administrator and, for 90 minutes, see for yourself how SCOM enables the setup, scheduling, and monitoring of everyday actions and events, using a language Microsoft discovered in its labs, called English. (The figures shown here were captured from one TechNet Virtual Lab session.)

The administration concept is based on SCOM's ability to install agents throughout the network at select points, like remote sensors that report back to SCOM. This way, you can deploy the SCOM console from essentially anywhere, and be assured of an accurate report.

Like the MOM 2000 management console snap-in—which was introduced for Windows 2000 and extended, without much change, to Windows Server 2003—SCOM organizes its various levels of control granularity as hierarchical tiers, represented as Outlook-like folders along the left pane. Notice also the Outlook-like main categories down the bottom of the left pane, which Microsoft now calls nodes because that's such an unforgettable name for them.

For SCOM to manage an application or network service such as SQL Server, Exchange Server 2007, or Active Directory, it needs a set of instructions which SCOM calls management packs. Basically these are rulebooks that instruct the SCOM agents as to what to look out for. One hopes more management packs become available for non-Microsoft services, though one has been hoping such things for a long time, and unfortunately one finds oneself in one's position one time too often.

Generating Your Own Rules and Monitors

Microsoft Outlook famously introduced users to the concept of rules and alerts, and with SCOM, the company extends that concept to management tasks even further, with the generation of active rules called monitors.

In SCOM, a monitor is like a watch placed on a target component from one of the management packs. To generate a monitor, you write a rule step-by-step using a system that was literally first created for filtering incoming e-mails in Outlook.

Once you've created a monitor, you can navigate down the left pane of SCOM's Monitors node, find the monitor, click on it, and receive a full report on all instances of the type of thing the monitor is looking for throughout the network, where you've installed agents. It's as though you're a meter reader moving from house to house checking for signs of over-use.

Under SCOM—as opposed to its matronly MOM predecessors—rather than perusing down a list of events explained to you in exhaustive detail, you generate your own events that warn you, in either a default or customized way, about the specific states you're looking for.

This example shows the page for training SCOM to respond to system event 3333, which for our purposes is just a dummy event. The rule will simply fire up a sort of alert "flare" if one of the agents sees an event with that code in its header.

While an alert is typically a warning sign in case something happens (usually something wrong, but conceivably the opposite), a monitor reports a continuous condition. So using the rule system, you can train a monitor to report that a target component is "healthy" if it's registering a performance level at or above a given amount, and "unhealthy" if it's anything else. Going deeper into the system, you can set up an exception to the rule, for instance, for specific instances of the target component running on a specific computer, or by a specific user.

Books and E-books

• Meyler, Karrie; Fuller, Cameron; et al. Microsoft Operations Manager 2005 Unleashed (MOM): With a Preview of Operations Manager 2007. Sams Publishing, 2006. Preview "Operations Manager 2007 and System Center Essentials" on Safari.

Online Resources

• "Introducing Microsoft System Center Operations Manager 2007" by Dave Chappell. Microsoft Word document from the System Center home page at microsoft.com.