We can start with examining reasons why systems go down. Figure 1.1 illustrates widely recognized reasons for outages, and the following list describes these reasons:

As Figure 1.1 demonstrates, the vast majority of failures are from software-level errors and user errors. It is surprising to note that hardware failures account for the smallest percentage of problems, which is a tribute to modern systems such as Redundant Array of Independent Disks (RAID), clustering, and other mechanisms deployed to provide server and application redundancy.

The numbers show that to reduce system downtime, you need to attack the software and user error components of the equation, which are where you will get the most “bang for the buck.”

Microsoft Windows Server and the applications that run on it, such as Microsoft Exchange and Microsoft SQL Server, expose a wealth of information with event logs, performance counters, and application-specific logs. However, this data is isolated and typically server-centric, making it difficult to determine where the problem really is. To get a handle on our operations, we need to take actions to prevent the situation shown in Figure 1.2, where applications and system components are isolated islands of information.

Figure 1.2. Multiple islands of information.

We can find isolated information in a number of locations:

Although system information is captured through event logs, performance counters, file-based logs, and experiences, it is typically lost over time. Most logs roll over, are erased to clear space, or are eventually overwritten. Even if the information is not ultimately lost or forgotten, it typically is not reviewed regularly by systems or operations personnel.

Additionally, most application information is server-centric, typically stored on the server, and specific to the server where the application resides. There is no built-in, systemwide, cross-system view of critical information or system health.

Having islands of information, where operational data is stranded on any given island, makes it difficult to get to needed information in a timely or effective manner.

In your typical unmanaged IT environment, often no one knows when noteworthy events occur. Going to each server and reviewing its event logs regularly is a massive undertaking for the typical system administrator. Although the event logs capture a tremendous amount of information, they will eventually roll over and be overwritten without being looked at; that information is lost.

You may be familiar with an old philosophical saying: If a tree falls in a forest and no one is around to hear it, does it make a sound?

Here’s the operations management equivalent: If an event is logged on a system and no one knows, does logging it make a difference?

The answer to this question is definitely “no”; if no one knows, the event may as well not be logged. This loss of information can affect the long-term health of the system—if you knew about its occurrence you could avert potential outages.

As an example, there was a situation where an Exchange server at a large manufacturing organization was receiving 1018 errors in the Application Event log for several months, but the administrators never checked the logs to catch it. Error 1018 indicates an Exchange database problem; it is a severe error requiring immediate action. The server eventually crashed and the backups were unusable—the backed up databases were corrupt. Restoring the mail system necessitated an expensive disaster recovery scenario using outside consultants, resulting in the loss of critical messaging data and the jobs of the staff held responsible.

In the end, information is only informative if you are aware of it, and it is only as good as what you do with it. To put this another way, most IT shops have many trees falling without someone hearing them...until it is too late.

Sometimes you may capture information about a system problem, but are not able to look back in time to see whether this is an isolated instance or part of a recurring pattern. An incident can be a one-time blip or can indicate an underlying issue; without a historical context, it is difficult to understand the significance of any particular incident. This is especially true with performance data.

Let’s say an IT shop brings in a technical consultant to review a system’s performance problems. To prove there is a problem, the in-house IT staff points out that users are complaining about performance and the memory and CPU are only 50% utilized. By itself, this does not tell us anything. It could be that memory and the CPU are normally 65% utilized and the problem is really a network utilization problem, which in turn reduces the load on the other resources. A historical context could provide useful information.

As a technical expert, the consultant would develop a hypothesis and test it, which will take time and cost money. Rather than trying to solve the problem, many IT shops just throw more hardware at it—only to find that this does not necessarily improve performance. With historical records, they would see that system utilization actually dropped at the same time users started complaining, and they could look elsewhere to find the network problems. Ideally, you would have historical information for troubleshooting and detecting trends.

Do you lack the in-house expertise needed to diagnose some of the messages or trends appearing on your Windows servers and server-based applications? Do you pay an arm and a leg to call in consultants, only to find that the messages are actually not all that severe? On the other hand, do you ignore messages you don’t think are significant only to later discover that they are important?

If the expertise you need is not available when you need it, you can miss diagnostic opportunities or incur higher operational costs. Missed diagnostics opportunities can translate to system outages and ultimately higher operational expenses if emergency measures are required to resolve problems.

Many IT organizations still “fly by the seat of their pants” when it comes to identifying and resolving problems. Using standard procedures and a methodology helps minimize risk and solve issues faster.

A methodology is a body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry. It can also refer to a set of working methods. We can look at a methodology as a structured process that defines the who, what, where, when, and why of your operations, and the procedures to use when defining problems, solutions, and courses of action.

Consistently using a methodology gives you the tools to help measure or compare where you are to where you were. A methodology also includes identifying and using standards, policies, and rules of operation.

With IT’s continually increased role in running successful business operations, having a structured and standard way to define IT operations can increase your business decision-makers’ confidence that IT is a significant and ongoing business concern. In addition, that increased level of confidence may translate to higher job satisfaction for you.

Sometimes you detect problems by what did not occur, rather than by what actually happened. A good example of this is data backups. Regardless of whether the backup is successful or fails, it generates an event and some type of notification.

However, what happens when the backup doesn’t fail or succeed, but just doesn’t happen? If you are not looking closely at your event logs, you will likely not discover this fact until later. We know a case of a large educational institution doing backups that missed one server during an initial configuration. Eventually the server crashed and they attempted to restore to an earlier point, only then discovering there were no backups. Even though all their backup jobs were configured to generate success notices and notify of failures, that particular server was not generating these notifications and was missed—with severe consequences impacting management, faculty, staff, and students.

Sometimes when you do not receive a notification or event, it is a signal to take action. The bottom line is you need to be able to test whether something has failed to happen.

Even when you are notified of events, it may be difficult to tell whether you actually have a problem. Windows Server and the services and applications running under it are good about generating errors, warnings, and informational messages. The challenge is that there is so much information that it can be difficult to tell which of these thousands of messages are normal operating events, rather than errors that require remedial action.

False alarms are typically due to a lack of knowledge or inadequate filtering. Sometimes a benign message may look ominous to the untrained eye. One example would be event 11 from w32time in the System Event log, which is a warning indicating an unreachable Network Time Protocol (NTP) server. This actually is a normal occurrence and is not a problem (although several of these errors may indicate a problem that needs action).

The issues described so far generally occur in an unmanaged environment. By “unmanaged,” we mean an environment that is not using a disciplined approach for managing its operational information. By not correlating operational data across systems, being aware of potential issues, maintaining a history of past performance and problems, and so on, IT shops open themselves up to putting out fires that could be prevented by using a more systematic approach to operations management (see Figure 1.3). We will cover these issues in the next section.

Figure 1.3. Fighting fires.

A large percentage of IT departments’ budgets and resources typically focus on mundane maintenance tasks such as applying software patches or monitoring the health of a network, without leaving the staff with the time or energy to focus on more exhilarating (and more productive) strategic initiatives.

The Dynamic Systems Initiative, or DSI, is a Microsoft and industry strategy intended to enhance the Windows platform, delivering a coordinated set of solutions that simplify and automate how businesses design, deploy, and operate their distributed systems. Using DSI helps IT and developers create operationally aware platforms. By designing systems that are more manageable and automating operations, organizations can reduce costs and proactively address their priorities.

DSI is about building software that enables knowledge of an IT system to be created, modified, transferred, and operated on throughout the life cycle of that system. It is a commitment from Microsoft and its partners to help IT teams capture and use knowledge to design systems that are more manageable and to automate operations, which reduces costs and gives organizations additional time to focus proactively on what is most important. By innovating across applications, development tools, the platform, and management solutions, DSI will result in

Microsoft is positioning DSI as the connector of the entire system life cycle.

ITIL is widely accepted as an international standard of best practices for operations management, and Microsoft has used it as the basis for the MOF, its own operations framework. Warning: Discussions of ITIL and MOF can be dry; proceed at your own risk!

What Is MOF?

ITIL is generally accepted as the “best practices” for the industry. Being technology-agnostic, it is a foundation that can be adopted and adapted to meet the specific needs of various IT organizations. Microsoft chose ITIL as the foundation for its operations framework, such that the Microsoft Operations Framework (MOF) gives prescriptive guidance in operating Microsoft technologies in conformance with the descriptive guidance in ITIL. MOF is a set of publications providing both descriptive (what to do and why) and prescriptive (how to do) guidance on IT service management.

The key focus in developing MOF was providing a framework specifically geared toward managing Microsoft technologies. Microsoft created the first version of the MOF in 1999. MOF is designed to complement Microsoft’s previously existing Microsoft Solutions Framework (MSF) used for solution and application development. Together, the combined frameworks provide guidance throughout the IT life cycle, as shown in Figure 1.4.

Figure 1.4. The IT life cycle and Microsoft frameworks.

Tip: Using MSF for OpsMgr Deployments

Microsoft uses MOF to describe IT operations and uses Operations Manager as a tool to implement that framework. However, Operations Manager 2007 is also an application and, as such, is best deployed using a disciplined approach. A suggested methodology for deployment would be using principles from the MSF, which we discuss in Chapter 4, “Planning Your Operations Manager Deployment.”

At its core, the MOF is a collection of best practices, principles, and models. It provides direction to achieve reliability, availability, supportability, and manageability of mission-critical production systems, focusing on solutions and services using Microsoft products and technologies. MOF extends ITIL by including guidance and best practices derived from the experience of Microsoft’s internal operations groups, partners, and customers worldwide. MOF aligns with and builds on the IT service management practices documented within ITIL, thus enhancing the supportability built on Microsoft’s products and technologies.

MOF uses a process model that describes Microsoft’s approach to IT operations and the service management life cycle. The model organizes the core ITIL processes of service support and service delivery, and it includes additional MOF processes in the four quadrants of the MOF process model, as illustrated in Figure 1.5.

Figure 1.5. The MOF process model.

It is important to note that the activities pictured in the quadrants illustrated in Figure 1.5 are not necessarily sequential. These activities can occur simultaneously within an IT organization. Each quadrant has a specific focus and tasks, and within each quadrant are policies, procedures, standards, and best practices that support specific operations management–focused tasks.

Operations Manager 2007 management packs can be configured to support operations management tasks in different quadrants of the MOF Process Model. Let’s look briefly at each of these quadrants and see how we can use OpsMgr to support MOF:

• Changing—. This quadrant represents instances where new service solutions, technologies, systems, applications, hardware, and processes have been introduced.

  As you add new components to your environment, you should investigate whether a Microsoft or third-party management pack is available to monitor a particular application, system, or hardware solution. (If a management pack is not available, you can define your own, building a model to describe the “vital signs” and monitoring attributes of that application.)

• Operating—. This quadrant concentrates on performing day-to-day tasks efficiently and effectively.

  OpsMgr includes operational tasks that you can initiate from the Operations console. These tasks are made available with various management packs, and you may add your own as well.

• Supporting—. This quadrant represents the resolution of incidents, problems, and inquiries, preferably in a timely manner.

  OpsMgr is all about monitoring daily operations. Management packs provide the capability, for knowledgeable users, to interpret and act on information gathered from each monitored component to resolve any difficulties.

• Optimizing—. This quadrant focuses on minimizing costs while optimizing performance, capacity, and availability in the delivery of IT services.

  OpsMgr’s reporting and monitoring capabilities can help you increase efficiency and gain greater control over your IT environment. Integrating and extending problem reporting and operations monitoring to client systems help lower your client support costs, while availability reporting allows both IT operations and management to get the information needed to quickly identify and resolve issues that affect service levels.

Service Level Agreements and Operating Level Agreements (OLAs) are tools many organizations use in defining accepted levels of operation and ability. Operations Manager includes the ability to specify SLAs using Alert Resolution States. Additional information regarding the MOF Process Model is available at http://go.microsoft.com/fwlink/?LinkId=50015.

You can think of ITIL and ITSM as providing a pathway for IT to rethink the ways in which it contributes to the business. The processes represented by ITIL and ITSM have evolved into the standard known as ISO 20000, which is the first international standard for IT Service Management.

ISO 20000 was first published in December 2005. It was developed to reflect best-practice guidance contained within ITIL. The standard also supports other IT Service Management frameworks and approaches, including MOF. ISO 20000 consists of two major areas:

These two areas—what to do and how to do it—have similarities to the approach taken by the MOF.

According to Microsoft, analysts estimate that over 70% of the typical IT budget is spent on infrastructure—managing servers, operating systems, storage, and networking. Add to that the challenge of refreshing and managing desktop and mobile devices, and there’s not much left over for anything else. Microsoft describes an Infrastructure Optimization Model that categorizes the state of one’s IT infrastructure, describing the impacts on cost, security risks, and the ability to respond to changes. Using the model shown in Figure 1.6, you can identify where your organization is, and where you want to be:

Although most organizations are somewhere between the basic and standardized levels in this model, typically one would prefer to be a strategic asset rather than fighting fires. Once you know where you are in the model, you can use best practices from ITIL and guidance from MOF to develop a plan to progress to a higher level. The IO Model describes the technologies and steps organizations can take to move forward, whereas the MOF explains the people and processes required to improve that infrastructure. Similar to ITSM, the IO Model is a combination of people, processes, and technology.

More information about Infrastructure Optimization is available at http://www.microsoft.com/technet/infrastructure.

OpsMgr 2007 solves the isolated systems problem with end-to-end monitoring and collecting information from your different islands of information. It monitors event logs, performance monitor counters, application programming interfaces, WMI information, and network devices, locally gathering the data from each monitored object, centrally storing it, and taking action as appropriate. OpsMgr also provides a centralized console to monitor the operational status of your entire network. Figure 1.8 shows the health state of computers in a monitored organization. The view shows that there is currently a problem area on the Quicksilver computer, and if we scroll right in the Computers view in the Operations console, we would see that the affected area is within the IIS subsystem.

Figure 1.8. Viewing computer health in the Operations console.

Using this view enables us to see which systems and components are healthy and which are not. Health is based on rolling up information from each monitored object.

If you right-click a system in the Results pane shown in Figure 1.8, you can open the alert, diagram, event, performance, and state views associated with this object. You can also open the Health Explorer here from the Actions pane. The Health Explorer is displayed in Figure 1.9. You can see how OpsMgr shows the various monitored components, known as monitors, and the rollup for those monitors.

Figure 1.9. The Operations Manager Health Explorer.

At a glance, this shows that although the Web Components on Quicksilver are experiencing issues, other components on the server are available and functioning properly. Each object is shown as healthy, in an error state, or not yet monitored. Using the Health Explorer, you can quickly isolate the target area. You can even customize the view to see which applications are impacted by the affected monitor.

Operations Manager 2007 resolves the notification problem by automatically detecting and responding to changes in state, generating alerts processed using its notification workflow engine. As it collects information, responses to conditions and changes in state can be triggered at each collection point in the OpsMgr architecture. The local agent processes data and analyzes it using the business logic in OpsMgr’s rules, making a decision whether to pass the information to a central management server.

Microsoft designed the entire process to incorporate the best of all possible worlds. Agents on the monitored servers collect and initially process the information; this reduces the load placed on the management server because information is centrally acted on only as necessary.

The design also allows the local agents to continue to respond to alerts even when communication with the management server is disrupted. Preprocessing keeps the traffic flow from the agents lean and the database storage footprint light. Even so, an administrator would prefer to not be notified about all the myriad data collected by Operations Manager 2007. Accordingly, OpsMgr detects changes in state and incorporates self-tuning thresholds to be selective about the alerts it raises.

Using the Health Explorer shown in Figure 1.9, you can view the alerts related to a given monitor. You can also use the Active Alerts pane in the Operations console to look at all outstanding alerts. Figure 1.10 shows that currently four alerts are Warnings and 11 are Critical alerts.

Figure 1.10. The Active Alerts pane in the Operations console.

You can also highlight any particular alert in the Active Alerts pane to view the detail behind that alert. In Figure 1.11, you can see what a specific error is on the Pantheon server, including the cause of the error and potential actions for resolution.

Figure 1.11. Detail for an individual alert.

You can also click the Alert Rule link in the Alert Details pane in Figure 1.11 to bring up the specific rule behind that alert. Notice in Figure 1.12 that the information is broken into six areas or tabs:

In addition to generating alerts, Operations Manager can send notifications based on the severity or age of a particular alert. Using the notification workflow engine, you can define subscriptions where alerts are sent to targeted recipients in a variety of ways:

Using the Operations console, Operations Manager allows you to view the state of your organization as a whole or to drill down into detail about any particular alert.

A big problem in IT is the distributed nature of security in Microsoft applications. Many administrators have local administrative access to servers, allowing them to modify things such as system and security logs. An unscrupulous administrator can use this access to circumvent security policies, ostensibly with the purpose of getting the job done. This is a gaping hole in any organization trying to maintain tight security. You need to know if there are security changes.

Operations Manager’s new Audit Collection Services (ACS) Component can help you manage the security of your IT environment by collecting security events from managed computers for analysis. ACS helps facilitate the separation of security personnel from other IT job functions. It collects significant security events and can warn appropriate security personnel of violations of security policy. The local agent immediately forwards security log information to the Audit Collection database, moving it outside the control of the local administrator. Even if an administrator attempts to cover his tracks by clearing the Security Event log, ACS has sequestered the information. If a local administrator attempts to circumvent the process by shutting down the agent, the central console detects that and can generate an appropriate alert. You can use ACS to address regulatory compliance requirements such those legislated by the Sarbanes-Oxley Act. The product comes with reports out of the box. Figure 1.13 displays the Audit Collection Services data flow.

Figure 1.13. How information flows in ACS.

With security information safely and centrally stored, the security officer can generate reports and analyze the data to look for potential security problems.

OpsMgr lets you view the information it gathers quickly and effectively. It is all well and fine that information is collected, but it is for naught if the information is not easily accessible. Operations Manager presents information in ways to make it easy to view, print, or publish.

Data collected includes availability, health, and performance statistics—invaluable information for analyzing what your servers and services are doing over the long term. To help review and understand the long-term trends and conditions of your servers and applications, OpsMgr generates reports both automatically and in an ad hoc fashion, including an easy-to-use graphical report designer that’s part of the Operations Manager 2007 console. The reporting capabilities allow you to generate sophisticated reports complete with titles, numeric information, text information, graphs, and charts.

Using Views

In Figure 1.14, the Hydra computer shows some spikes in performance around midnight on 3/2/2007, which are the largest spikes captured in the graphs. This particular view actually displays several performance counters: percent processor time, processor queue length, and context switches. Using views gives you immediate access to information as it is collected, and you can adjust the view of that information quickly, perhaps to compare it with another system or examine other performance aspects, as we are in this particular view.

Figure 1.14. CPU performance analysis view.

However, the display in Figure 1.14 does not tell us if what we see is normal performance for the computer because it only shows a 24-hour period.

Tip: Self-Tuning Thresholds

OpsMgr 2007 introduces self-tuning thresholds, which serve to monitor performance counters and set upper and lower thresholds based on historical activity. The system generates an alert only when activity exceeds these normal limits.

Reporting

We can also visually put the CPU utilization spike in context by seeing what a longer-term CPU utilization looks like for that system. Views, such as the one displayed in Figure 1.14, give us a quick look at the data. We can access the long-term view of historical data using the Reporting Component. The Performance Top Objects report shown in Figure 1.15 shows performance for Hydra and several other systems, but includes a range of what Operations Manager has determined is normal activity for the week and a standard deviation.

Figure 1.15. Performance Top Objects report.

You may notice an Actions section circled in the middle of the report that allows you to open other reports of interest. For example, selecting Performance details opens a Performance Detail report for Hydra, displayed in Figure 1.16. This report gives a graphic drilldown on the minimum, maximum, and average values for the week, along with the standard deviation, which is the degree of variation for those numbers. You can expand the Actions section on this report as well to see additional reports or views. With just a few mouse clicks, we now know that the average processor utilization is about 70%. Knowing what is normal can be half the battle when troubleshooting!

Figure 1.16. Performance Detail report for the Hydra computer.

Reports are static once generated, whereas views are interactive and will update as the underlying data changes. Reports can be exported as XML, saved in CSV, TIF, Excel, or PDF format, or published as HTML (MHTML) files using the Web Archive option. The HTML option is particularly powerful because it allows you to generate reports to publish for general viewing. The only requirement is having a browser and access to the web page, which allows IT to schedule reports showing routine stats, uptime, and so on, easily and effectively. You can email reports in PDF format to specified recipients. We discuss reporting capabilities in detail in Chapter 8, “Configuring and Using Operations Manager 2007,” and report development in Chapter 23, “Developing Management Packs and Reports.”

You can generate historical reports of what has happened over any period the data is collected for use with long-term trending and capacity planning. As we just discussed in the “Using Views” section, you can also look at the information as it is collected in real time for a snapshot view of what is happening within your organization, drilling down into detailed specifics as needed.

Access to a long-term view of information can help you detect trends and patterns otherwise hidden in a snapshot view. Recall our previous example, in the “Lack of Historical Information” section of this chapter, where the IT staff called out that CPU utilization was at 50%. Using Operations Manager, we can look at the historical information and see this was actually a normal condition. Using the same process, we can detect increases in network utilization and diagnose the problem appropriately. With OpsMgr at work, the IT staff might not even need outside consulting services!

As you might suspect, the amount of data collected from all these information sources can be quite massive. To handle this flood of data, Operations Manager uses the Microsoft SQL Server 2005 database platform for centralized storage of data, collecting and storing the reporting data in a separate database from the operational information. The Operations database is used for viewing current and historical data, performance statistics, and availability data. A data warehouse separately maintains data used for reports. Storing historical data separately allows OpsMgr to respond quickly to operational situations while enabling access to historical information in the data warehouse. This capability is invaluable for a system administrator trying to understand what his servers, services, and applications are really doing.

Tip: A New Type of Data Warehouse

With OpsMgr 2007, data transfer to the data warehouse is near real time; as operational information is collected from the monitored systems, it is also aggregated and written to the data warehouse, available with virtually no latency, and accessible for long-term usage.

As an example, Operations Manager can produce system and service availability reports to help keep the organization in line with its SLAs. These reports can be invaluable for managers proving the value of IT initiatives or driving home the need for IT improvements. Figure 1.17 shows a 7-day availability report. The Operations console Reporting function generated this report as a PDF file, without requiring use of any additional software. Within the console, you can schedule reports to be automatically generated. These reports can then be emailed or posted to a file share. The report output can be in the following formats: an Adobe Acrobat PDF, Excel, CSV comma delimited, TIF image, Web Archive, and XML file with report data.

Figure 1.17. Availability report.

As soon as OpsMgr is installed, it begins to use its built-in expertise. Management packs, models containing a comprehensive set of predefined rules that form an expert system, focus on the health of your systems and will alert you to significant events, suppress unimportant data, and correlate seemly unimportant information to identify potential underlying problems. Rather than simply collecting a ton of information for the administrator to sort out, OpsMgr uses its knowledge to decide what is important, what’s not, and will escalate as needed. When it determines a downgraded change in state has occurred, OpsMgr alerts appropriate personnel that you identify. Before escalating to a live person, Operations Manager can automatically respond to various situations, such as restarting stopped services. These actions are accomplished with management packs, which are collections of objects including monitors, rules, alerts, tasks, and reports.

Management packs contain the knowledge, in essence the gray matter, from Microsoft’s best people. These include the product support teams, developers, and vast resources of TechNet, Microsoft’s technical database. This expertise is enhanced with the local expertise within your organization. Knowledge is added as alerts are generated, troubleshooting is performed, and problems are resolved, thereby enhancing the system. Similar to a human expert, OpsMgr improves its skills and capabilities over time. OpsMgr looks for changes in the state of an object. After alerting the appropriate personnel, it assists in resolving the problem by providing detailed knowledge including historical performance and event information, suggestions for fixes, direct links to tasks to resolve the problem, and pointers for where to research further.

As shown earlier in the Alert Details pane in the lower part of Figure 1.11, the highlighted alert contains concrete and specific guidance on what it means, the possible causes, possible resolutions, and where to get additional information if needed. In some cases the Alert Details pane does not show the entire contents of the knowledge for a particular alert, so we duplicate the full text of the Product Knowledge tab in the following sidebar. While in the console, you could click the View additional knowledge link in the Alert Details pane in Figure 1.11 to launch the alert properties window with the product knowledge text in it.

As issues are resolved, OpsMgr learns over time and builds that experience into its knowledge repository. If the situation recurs, OpsMgr is ready to provide the knowledge of what happened before and how it was resolved.

Operations Manager 2007 includes monitors and rules in management packs that keep tabs on your services and applications. OpsMgr focuses on the health of an application. Management packs are containers that include what we call service models, these use the SMLs discussed earlier in the “Microsoft’s Dynamic Systems Initiative” section of this chapter and are formal definitions of types of objects. OpsMgr captures knowledge through models, putting knowledge in a structure the software can act on.

Management packs describe what we call classes. We don’t see classes anywhere in the Operations console, and that is by design. Classes are a concept, we can describe things about them. A class is a type of object. A database is an object, and it has common types of properties, regardless of the server it runs on. Properties give us a common way to describe a database—it has a name, an owner, and other assorted attributes.

We can describe what makes up a database, and we can describe a relationship between other objects. A Microsoft SQL database has to run on a SQL Server—so it has to have some type of relationship with the SQL Server. The SQL Server runs on a Windows computer—so it has some relationship with the Windows computer. These relationships come into play when building management packs.

As an example, let’s say we want to monitor a particular SQL database. We can define a relationship between that particular database instance and associate that database with its SQL Server engine, which is its parent object. If there is a fault condition on the database, it reports up to the parent. This changes the SQL Database Engine state in the Operations console, and the information flows up to the computer, which is the parent for the SQL Server, and its state. State is the focal monitoring point. In Operations Manager 2007, changes in state trigger alerts; when the alert is resolved, the state changes to healthy. Using the Distributed Application Designer, we can also define a relationship between the database and applications that use it.

By incorporating models and methods for monitoring in its management packs, OpsMgr uses a structured approach to determine if there are situations requiring attention.

OpsMgr continually monitors, helping ensure there are no missed events. The system also understands that certain events should take place and can generate an alert if those events do not occur. A special type of rule checks for a condition to occur within a defined time frame, such as every day between midnight and 5:00 a.m. If the specified condition does not occur within that time frame, that information is caught and an alert is generated, thus helping you to catch and take action on problems such as missed backups—one of the more useful items to check for in terms of a job not executing. Still, OpsMgr needs to be told to watch for the event; it is not quite smart enough to do what you’re thinking or to catch what it isn’t looking for.

OpsMgr uses its built-in knowledge and self-tuning capability to correlate different types of information and changes in state, ensuring that it alerts only when needed, typically reducing the number of alerts to a fraction of the underlying data. This capability reduces the flood of information typical management systems generate, allowing you to focus on what is important to keep your system up with optimal performance.

Operations Manager does all this easily and automatically. OpsMgr can automatically scan the network and install agents without any administrative intervention (although this is not turned on by default). You can even establish an Active Directory Organizational Unit (OU) managed by Operations Manager; OpsMgr uses that information to determine the management group an agent belongs to and the management server with which the agent will communicate. Updated rules and management packs are distributed automatically, helping you deploy your management infrastructure quickly and effectively. With its central console, OpsMgr allows you to implement a consistent systems monitoring and alerting policy to all your systems. Agents perform monitoring and apply the specific business logic and models for each monitored computer, automatically updating each system with the appropriate logic. Operations Manager also automatically removes business logic rules from the distributed systems, once the specified conditions no longer apply.

OpsMgr is scalable to all sizes of organizations, performing well even as it scales. The same product and basic architecture can be used to support medium, large, and enterprise-sized organizations with their varied requirements:

Operations can be monitored through a console or a web interface. The console has views into the collected information—be it state, events, diagrams, alerts, or performance. You can also view reports. You can even view the status of your IT systems in a graphical diagram view that rapidly shows you the status of all systems, as in Figure 1.18, which shows the current Active Directory status. The highest-level state is shown in the state of the group, found at the top-left side of Figure 1.18. In this particular example, the highest-level state is Healthy, immediately letting us know that directory services are functioning properly in our Odyssey.com domain. We can also drill down into more detailed status of any particular component that has a plus sign (+) next to the diagram, indicating the view can be expanded.

Figure 1.18. Active Directory Topology diagram view.

Operations Manager 2007 can be deployed from medium to enterprise-sized organizations. Its flexibility also allows you to start small, managing a specific group of servers or a department. Once you are comfortable with the management platform, you can then scale it up to the rest of your organization.

With OpsMgr handling your monitoring needs, you as an operations manager can relax (somewhat!) knowing that you will be alerted when there is a problem and have help in resolving it. It is like having your own IT genie on the job 24×7! But it won’t take your job, not if you read this book.

The data gathered by Operations Manager 2007 is collected in a self-maintaining data warehouse, enabling numerous reports to be viewable using the Operations console. OpsMgr 2007 reports are now interactive and can launch other reports, console views, and tasks. Reports can also be exported to a Report Server file share; using the Web Archive format retains links. You can configure OpsMgr to schedule and email reports, enabling users to open these reports without accessing the Operations console. Approximately 150 reports are available out of the box. Reporting in MOM 2005 used the System Center Reporting Manager product released with the first wave. With the second wave, the Reporting Manager capability is moving under the to-be-released System Center Service Manager product and is no longer a separate product.

Microsoft rebranded its SMS v4 product as System Center Configuration Manager (ConfigMgr), Microsoft’s renamed and revamped systems management solution for change and configuration management. Like OpsMgr, the product is completely rewritten. Microsoft focuses Configuration Manager on addressing simplicity, deployment, security, and configuration. Features in ConfigMgr 2007 include the following:

System Center Essentials, also called Essentials, is a System Center application for the small to medium-sized business that combines the monitoring features of OpsMgr with the inventory and software distribution functionality found in ConfigMgr. The monitoring function takes the form of a simplified OpsMgr 2007 engine that can use OpsMgr 2007 management packs, and the software distribution function is performed by the WSUS version 3.0 engine. Essentials is a wraparound shell and user interface for these functionalities in a small business network, including the essential features for monitoring, managing, and reporting as well as change and configuration management.

Using Essentials, you can centrally manage Windows-based servers and PCs, as well as network devices, by performing the following tasks:

Essentials provides a subset of the OpsMgr 2007 functionality when it comes to monitoring and managing infrastructures. The flip side of this reduced functionality is that Essentials greatly simplifies many functions compared to its OpsMgr 2007 counterparts. For example, by default the Discovery Wizard in Essentials automatically searches for both Windows computers and SNMP-based network devices in the Essentials server’s domain and local subnet—without requiring the user to enter any networking information.

Customization and connectivity options for Essentials are limited, however. An Essentials deployment includes a single management server; all managed devices must be in the same Active Directory forest. Reporting functionality is included, but it is not as robust as that included with Operations Manager 2007.

Essentials also limits the number of managed objects per deployment to 30 Windows server-based computers and 500 Windows non-server-based computers. There is no limit to the number of network devices. Chapter 2, “What’s New,” includes a full feature comparison of the differences between OpsMgr and Essentials 2007.

Using System Center Service Manager implements a single point of contact for all service requests, knowledge, and workflow. The Service Manager (previously code named “Service Desk”) incorporates processes such as incident, problem, change, and asset management. Just as OpsMgr is master of the MOF Operating quadrant, Service Manager will be an anchor for the MOF Supporting quadrant. Figure 1.19 illustrates the mapping between the quadrants of the MOF Process Model and System Center Components.

Figure 1.19. MOF quadrants and System Center applications.

The Service Manager is Microsoft’s new help desk product and fills a gap in Operations Manager: What do we do when OpsMgr detects a condition that requires human intervention and tracking for resolution? Until Service Manager, the answer was to create a ticket or incident in one’s help desk application. Now, within the System Center framework, OpsMgr can hand off incident management to Service Manager.

Design goals of Service Manager include the following:

Supported scenarios include the following Service Management Functions (SMFs) and capabilities from the MOF Operating and Supporting quadrants:

Service Manager utilizes a Winforms console, which has an appearance similar to Outlook and Operations Manager. It uses the OpsMgr agent, and the console will have the ability to run OpsMgr tasks. Service Manager brings the “designed for operations” moniker full circle by providing a means to feed production and user data back into the development process using Visual Studio.

System Center’s Data Protection Manager (DPM) 2007 is a disk-based backup product for continuous data protection supporting servers running Windows 2003 Service Pack (SP) 1 and above. (The DPM Server itself must have SP 2, and x64-bit Windows Server is recommended.) DPM provides byte-level backup as changes occur, utilizing Microsoft’s Virtual Disk Service and Shadow Copy technologies.

Microsoft describes DPM 2007 as a “best of breed” product, adding support for tape media. The Enterprise Edition offers native protection for Windows applications such as Microsoft SQL Server, Exchange, SharePoint Portal Server, and Virtual Server, plus bare metal. This means that in addition to selecting file shares, you can back up SQL Server databases and Exchange Server storage groups. Via online snapshots, disk-based recovery can maintain backup points to a 15-minute window.

System Center Capacity Planner is designed to provide tools and guidance to determine an optimal architecture for successful deployments, while also incorporating hardware and architecture “what-if” analyses for future planning. The Capacity Planner assists with planning deployments of Operations Manager and Exchange Server.

In conjunction with the second “wave” of System Center, the newest version of Capacity Planner will include a model with OpsMgr 2007 support for ACS; modeling gateway servers; backup servers for the Operations database, RMS, and data warehouse; 64-bit hardware support; database sizing recommendations and support for background loads; trusted and untrusted agents; and an enhanced predeployment wizard. Planning will be more granular to include different branch configurations and be component based.

Capacity Planner will only support OpsMgr 2007 installations running Operations Manager SP 1.

The Capacity Planner creates models with information on topology, hardware, software, and usage profiles. It also allows you to run iterative simulations on the models for performance information. Capacity Planner ties into the DSI strategy by identifying when systems deviate from a defined performance model, providing guidance to correct those variations.

System Center Virtual Machine Manager is a standalone server application, providing centralized management of your Windows Virtual machines. It currently supports Virtual Server 2005 R2, and Windows Server virtualization will be supported with the Microsoft Windows Server 2008 operating system.

Virtual Machine Manager enables increased physical server utilization, centralized management of a virtual infrastructure, and rapid provisioning of new virtual machines by system administrators and users via a self-service portal.