After installing the core OpsMgr components, you will have a Root Management Server, Operations and Data Warehouse databases, a Reporting Server Component, and at least one Operations console. We begin our discussion with such a baseline management group configuration, which has just been deployed across three servers and has been running for a few days. If your deployments are more complex (for example, if you are clustering the RMS or deploying redundant management servers or gateway servers), we recommend you build out and validate the core components before implementing additional components. Figure 8.1 shows our sample management group, with server names listed, to help you follow the validation steps we will be performing.

Figure 8.1. Core management group components to verify before building out.

We are going to “kick the tires” a little to make sure we have a stable foundation before moving forward with bringing this management group into a monitoring environment. Start with verifying that all instances of the console are closed; then open a new instance of the Operations console. (After you install the Reporting Component, this is necessary to make the Reporting features appear in the console.) Even better, we recommend installing the Operations console on an administrator workstation and performing all tests and production work using Operations consoles not installed on management servers.

Procedures for installing the Operations console on separate computers appear later in the “Deploying and Using the Operations Console” section of this chapter.

After connecting the console to the RMS, and possibly authenticating with the domain, we will expect to see a screen similar to Figure 8.2. This is the initial view of the Operations console, in a new management group with the Reporting Component installed. The first view of the Operations console displayed is the Administration Overview page, also seen when the root of the Administration hierarchy is selected in the Navigation pane on the left side of the console.

Figure 8.2. The Administration Overview page after initial management group installation.

The Administration Overview page shown in Figure 8.2 includes an information element that will go away once mandatory initial configuration procedures are complete; this is the Required Configuration Incomplete banner with the comment:

In order for System Center Operations Manager to manage and monitor your network, you must complete the following steps.

The two steps listed are:

These two steps are just links to the same-named tasks on the right side of the Administration Overview page in the Actions section of the page.

We will perform these mandatory configuration activities after we check out the health of the core management group components. Begin by clicking the Monitoring navigation button. The Operations console reconfigures to display its default view of the Monitoring pane. Figure 8.3 shows the Monitoring Overview page, displayed when you select the root of the Monitoring hierarchy in the Navigation pane on the left side of the console.

Figure 8.3. The Operations console’s Monitoring Overview page after initial installation.

The distinctive feature of the Monitoring Overview page is its dashboard-style chart of the quantity of computers and distributed applications in the Critical, Warning, Success, Maintenance Mode, and Unknown states. We expect to see a small number of computers at this point, because we have not added any objects to manage! The only managed computers in the new management group so far are the management server and the system running the operational database.

On the left side of the console, below the root of the Monitoring hierarchy in the Navigation pane in the upper corner, are seven view folders and the five default global views:

Global views are views located immediately under the root of the Monitoring hierarchy. You can create new, custom global views under the Monitoring hierarchy root, as well as new view folders and hierarchies of folders. Notice the Show or hide views... link at the bottom of the Navigation pane. Clicking this link pops up the Show or Hide Views control shown in Figure 8.4.

Figure 8.4. The visibility of individual view folders can be toggled on or off in the Operations console.

As you can see in Figure 8.4, you cannot toggle on or off the visibility of the global views—these views are always visible to those users who have permission to access them. The Show or Hide Views dialog box only applies to child view folders. The user role associated with the user running the console individually controls access to every view; this includes global views as well as each view in each child view folder. (We discuss user roles in detail in Chapter 11, “Securing Operations Manager 2007.”) Whereas users only see the views they have rights to, they can choose which child view folders to display in their console.

Selecting to look at just some of the view folders is useful when the organization has a large number of management packs installed and/or has created custom views; in these cases, an operator can hide the view folders that are not involved in performing their job. The three most important global views are the Active Alerts, Computers, and Distributed Applications views. You will access these views frequently when using OpsMgr. The Actions area on the top of the right side of the Monitoring Overview page includes shortcuts to these views. (The Go to Computers State view and Go to Distributed Applications State view links in the dashboard area are also shortcuts to the same views.)

We are going to check out the health of our new management group using the distributed applications monitor for the management group, created during installation of the OpsMgr 2007 product. The Monitoring Overview dashboard indicates that two distributed applications are monitored: One is in the success state and one is in the unknown state. To investigate further, we can click one of the convenience links to the Distributed Applications state view on the Monitoring Overview page, or navigate directly to the Distributed Applications state global view in the Navigation pane.

In a default installation of OpsMgr 2007, two objects are listed in the Distributed Applications state global view. Because of our dashboard view, we expect one to be in the unknown state, and the other we hope is in a success state. The distributed application in the unknown state is clarified in the state view to be in a “Not monitored” status, and it’s identified as “A connector used by MOM components to insert discovery data, please create your own connector do not use this connector” (partially displayed in Figure 8.5). This object is “MOM shrapnel,” and we are going to ignore it. However, we do have to get used to seeing that particular distributed application in a perpetually “Not monitored” state.

Figure 8.5. Right-clicking the distributed application object presents menu choices.

The other object listed in the Distributed Applications state global view is valid and important to us—this is the Operations Manager Management Group distributed application. Figure 8.5 shows us navigating to the Distributed Applications state view, right-clicking the Operations Manager Management Group distributed application, and expanding the context-sensitive menu choices available for selection. Our cursor is over the command to invoke the Health Explorer for Operations Manager Management Group.

This distributed application object represents the health of our management group and is a convenient and centralized vehicle to oversee the end-to-end monitoring capabilities of OpsMgr.

The Health Explorer for a distributed application clearly shows that data from multiple managed objects is included in the health model for that application. Figure 8.6 shows the Health Explorer for the Operations Manager management group. The Health Explorer opens in its own window. In this figure, we expanded some paths in the health model to verify that monitors in the success state exist for multiple components of our management group.

Figure 8.6. The Health Explorer for a distributed application includes monitors from multiple managed objects.

Notice in Figure 8.6 that availability data of various services and features is included from both the OpsMgr Operations Database Component (on Thunder in our environment) and the OpsMgr Root Management Server Component (Hydra). The availability monitor for the management group appears as a rollup of the availability state from several perspectives. The Thunder computer (database server) is hosting the watching processes for agent group availability, whereas Hydra (RMS) is reporting on availability of the SDK service.

Agents connect to the RMS, but the Health Explorer shows that the computer hosting the Operations Database Component watches this process. Likewise, the SDK service connects to the operational database, but the RMS watches this process. At first glance, these monitoring perspectives seem contrary; that is, one might expect to monitor the database from the database component. In fact, the concept of externally watching a process from a separate component is a chief design feature and strength of the OpsMgr 2007 architecture.

With the health model showing success indicators for the Operations Manager Management Group, we can close the Health Explorer. Returning to the distributed application menu choices displayed in Figure 8.5, we will select the Diagram view to continue our validation of a successful installation of OpsMgr 2007. The Diagram view opens in its own window, similar to the Health Explorer. When we select a view by right-clicking an object and that view opens in its own window, we are said to be pivoting to that view.

Figure 8.7 shows the Diagram view of the Operations Manager Management Group after pivoting from the Distributed Applications global view to the Diagram view. We observe a simplified presentation of the health model, specifically calling out dependencies and relationships between the managed objects that constitute the management group.

Figure 8.7. Components and watchers in the Diagram view of the OpsMgr distributed application.

Notice in Figure 8.7 the object icons with the eyeglasses element. When you see those eyeglasses in a Diagram view, it means the object is a watcher node for one or more other objects. Follow the connection arrows in the Diagram view to discover the dependencies and relationships between objects and their watcher nodes.

Just as we validated in the Health Explorer (refer to Figure 8.6), we observe in the Diagram view in Figure 8.7 that Thunder, which hosts our Operations Database Component, is watching the availability of the agent group. Notice how the highlighted object, the Health Service Watcher Group, has an arrow pointing down to the Thunder Health Service Watcher. Similarly, notice the desk tray icon to the right of the highlighted object. This desk tray icon represents the Operations Database Watchers Group, and the arrow to the Hydra watcher icon below that indicates that Hydra is the watcher node for the health of the operational database.

For a large, complex distributed application, the Diagram view is the best way (or perhaps the only way) to visually diagnose cross-platform interdependencies. The Diagram view makes clear what objects are watching what other objects. This is invaluable to enable you to rule out that an alert of a failed distributed application is not simply a failure of a watcher node process.

Another unusual icon you might notice in Figure 8.7 is the top-level (or rollup object) triangle laid over a T-shaped intersection of pipes. This icon represents a distributed application in OpsMgr Diagram views. We can select this rollup object in our Diagram view and read useful high-level information about the distributed application in the Details pane. Figure 8.8 shows the management group details when you select the rollup object in the Diagram view.

Figure 8.8. High-level management group properties in the distributed application Diagram view.

Closing the Diagram view, we return once more to the Distributed Applications global view in the Monitoring pane, shown previously in Figure 8.5. Now we want to test our PowerShell installation and integration with OpsMgr. Right-clicking again the distributed application Operations Manager Management Group, we will select Open -> Command Shell... to launch PowerShell in the OpsMgr group context. We type in the cmdlet get-State and observe the reply in Figure 8.9.

Figure 8.9. Validating the health of the management group using PowerShell.

Notice in Figure 8.9 the prompt line after the line Connecting to Operations Manager Management Server ‘HYDRA.odyssey.com’. From the prompt line, we confirm that the PowerShell (PS) context is

Monitoring:HYDRA.odyssey.comMicrosoft.SystemCenter.ManagementGroup

This context represents the rollup monitor of the distributed application—the same triangle-and-pipes object we reviewed the properties of in Figure 8.8. The response from PowerShell to the get-State cmdlet returns the health state and some descriptive details related to the shell’s context. We are looking for the response line HealthState: Success. This is the command-line equivalent to the green check mark of the Success state in the Operations console!

Another functionality we want to validate is graphing performance counters in the Operations console. After closing the PowerShell window, we right-click once again the distributed application Operations Manager Management Group and pivot to the Performance view by selecting Open -> Performance View. A new Performance window will open with an initially empty Results area and rows of counters to select for display in the Details area. The empty Results pane will have neither a units nor a time scale, and there will be a reminder that we need to select some counters to see data on the graph.

In Figure 8.10, we sorted the list of counters by the type of counter; then we scrolled down to locate the System Up Time counters. Because there are counters from two managed computers forming part of the Operations Manager distributed application, we notice two System Up Time counters—one for each computer. We tick the check boxes for those counters in the Show column and immediately see the graph populated with linear data; units appear on the left scale and time on the lower scale (see Figure 8.10).

Figure 8.10. Confirming that we can view performance data in the Operations console.

Our test of the console’s graphical performance counter display function is successful, as shown in Figure 8.10. In the instance of System Up Time performance counters, the units on the left scale are seconds. The chart correctly reflects that both computers were restarted about 5:00 p.m. the previous day, so their chart lines, although of different colors, are almost superimposed on one another. The counters increment steadily to the right as the quantity of seconds of uptime accumulates. Now that we have confirmed that rendering of performance graphs is functional, we want to unselect the check boxes in the Show column to clear the charted results pane and restore the view to its defaults. Then we can close the Performance window.

These checks verify the Operations Manager distributed application is healthy. There are just a few more items to check before we are ready to import management packs and discover objects to manage. We need to look at any unresolved alerts in the management group, and we want to validate that the Reporting Component is installed correctly and working.

To view alerts, we need to change our focus to the Active Alerts global view. The quickest way to do this is to click directly the Active Alerts view immediately under the root of the Monitoring hierarchy in the Navigation pane on the left. Or, if you prefer, you can return via the Monitoring Overview page by clicking the root of the Monitoring hierarchy. Then in the Monitoring Overview page, click the View All Active Alerts shortcut in the Actions area on the right.

Because we have not imported any application or operating system management packs, we will only observe alerts created by the base Operations Manager management pack. These alerts will relate to the health of the management group itself, and we will want to resolve any critical alerts before proceeding. Figure 8.11 shows our initial view of the active alerts in our new management group.

Figure 8.11. Active Alerts view will display problems with the management group.

It is normal for there to be just a few alerts here, which we hope were transitory and coincide with installing the management group components. It’s certainly possible for certain OpsMgr components to raise alerts during the installation of other components and then not properly auto-resolve—we call this a transitory alert because such events occurred during atypical conditions and are not expected to reoccur during normal operation of the management group.

Alerts we do not expect to reoccur can be resolved. These would include alerts with a low alert repeat count, or an alert where a reasonable interval of time has passed without that alert reoccurring. You can check the age and repeat count for an alert by right-clicking the alert and selecting Properties, which brings up a dialog box similar to the one shown in Figure 8.12.

Figure 8.12. Alert properties assist with the evaluation of the alert relevance.

This figure shows the General tab of an alert, involving a monitoring script failure, after we selected to view alert properties. In this case, we have a Warning alert, which is less serious than a Critical alert. The alert has only occurred twice, and not in the past 5 days.

Reading the alert description tells us the script failed, reporting that the specified domain does not exist or cannot be contacted. This could have been due to temporary connectivity issues, or because domain controllers or DNS servers were being restarted. It is safe in this case to close this alert; if it reoccurs, we can escalate our investigation. We close the alert by changing the alert status from New to Closed and clicking the OK button.

On the other hand, if there are many alerts, particularly if they do not appear to be transitory, these need to be resolved before going further. In particular, you should not import management packs or add additional managed objects if there are critical alerts that you cannot resolve or perhaps do not understand.

The last feature to validate for our new management group is the reporting function. This is particularly important to test when the Reporting Server and/or Data Warehouse Server components are on distributed servers. Because the Reporting Component installation uses a separate setup procedure than the one shared by most of the other core management group components, issues may come up with a distributed installation.

Because the reporting function in the OpsMgr console also depends on the IIS services of the Reporting Server component, you will want to test that the dependency is working properly. It is best to wait at least 24 hours after installing the reporting function before running a report in the Operations console.

To check out the reporting feature, we will return to the Operations Manager Distributed Application view. Click the Distributed Applications view in the Monitoring hierarchy in the Navigation pane on the left side of the Operators console.

Reports are views that you cannot pivot to in the Monitoring space by right-clicking an object. Although we are now at the same view shown in Figure 8.5 (the Distributed Applications State view), we see that Reports and Reporting are not options on the context-sensitive menu. To view the reports involving an object, select the object in the Results pane that you want the report on using a single left-click. Then in the Actions pane on the right, a collection of context-relevant reports appears to select from, as shown in Figure 8.14.

Figure 8.14. Reporting actions available in the context of the management group distributed application.

We are going to select the Health report to validate that the management group has been in a healthy state for at least the last 24 hours. The Health Report Setup and Run window appears; we show the top part of that window in Figure 8.15.

Figure 8.15. Change at least the start date of the report to get any data.

When the report window opens, the period of the report setup defaults to start and end times equal to the current date and time; so if you run the report without changing the time period, there would never be any data in it. We change the From (or start) date of the report from Today to Yesterday, creating a 24-hour interval to sample for the report. Click the Run button, and the report results appear shortly in the report window, as shown in Figure 8.16.

Figure 8.16. Availability report on the 24-hour health of the OpsMgr management group.

What we hope to see in the Availability Report shown in Figure 8.16 is 100% in the Uptime (%) column and 24:00:00 in the Uptime (h:mm:ss) column. This indicates that the health status of the management group was “success” for the 24-hour period of the report. We can drill down into each hour of the previous day by clicking the Availability Tracker link at the bottom of the Uptime column. This action generates an Availability Time report like the one shown in Figure 8.17, confirming the uptime of the management group for each of the preceding 24 hours.

Figure 8.17. The Availability Time report validates the OpsMgr distributed application’s health for each hour of the day.

If the reporting windows contain data and appear similar to those shown in Figures 8.16 and 8.17, consider your OpsMgr management group baseline installation complete and successful; you are ready to proceed with build-out activities such as importing management packs and discovering objects to manage. If your reports did not contain data or they did not render correctly in the Operations console, we recommend you troubleshoot and repair the reporting function before proceeding.

General data warehouse troubleshooting guidelines include the following:

The installation process automatically imports a number of management pack libraries. These libraries provide a foundation of object types on which other management packs depend, and they contain basic settings used by OpsMgr for the minimum functionality to manage the OpsMgr application itself, such as the management pack for Operations Manager 2007. To see the list of default libraries and management packs, navigate to the Management Pack node of the Administration workspace as displayed in Figure 8.18. (We turned off the Actions pane in this screenshot, normally on the right side of the Operations console, to allow you to read more of the Description column in the list of management packs.)

Figure 8.18. List of management pack libraries installed with OpsMgr 2007 Released to Manufacturing (RTM) version.

Just to the right of the Management Packs heading in the Details pane of Figure 8.18 you can see the quantity (40). These are the management packs automatically imported in a new management group with the reporting component installed. Notice the listing of the Default Management Pack, which does not have a Yes in the Sealed column. The Default Management Pack is where new, custom management pack objects such as monitors, alerts, and rules may be stored. In addition, overrides to customize default settings in a sealed management pack are saved to the Default Management Pack, by default.

Source files for currently installed management packs are located on each management server at %ProgramFiles%System Center Operations Manager 2007Health Service StateManagement Packs. Do not import from this folder when performing future management pack import operations because these management packs are already part of your OpsMgr environment.

You must import other management packs into the OpsMgr management group to monitor specific applications. These management packs fall into several categories:

It is a best practice to import only the management packs required to meet your monitoring and management goals. Specifically, it is a poor practice to import “every management pack you can find.” Each imported management pack incrementally increases the overhead load of the management group. Too many unused or unnecessary management packs can clutter the Operations console to the point that you miss indications of issues with the applications you do need to monitor.

In the next section, we will import some of the additional operating system and application management packs provided by Microsoft on the installation media. You might ask, “Why not import all of them?” Although you certainly may do that, we recommend you carefully review the list of management packs in Table 8.1 and import only those you will use in your environment.

You can use the Operations console or PowerShell to import management packs. Using the console provides visual feedback on the progress and status of the import operation, whereas using PowerShell offers opportunities for automating and error-proofing the import process. We will import some management packs using the console and then import some with PowerShell to demonstrate both methods. Perform the following steps:

After the selected management packs have been imported, our new management group is ready to begin monitoring the SQL 2000 and SQL 2005 database server applications, the Windows 2003 operating system, and the IIS and Terminal Services features of Windows 2003. Before these management packs were imported, the only monitored application was Operations Manager 2007 itself! The discovery rules contained in the management packs immediately go to work, detecting which monitored computers the new management packs apply to, and deploying appropriate monitors and rules to those computers.

Next, we will import some management packs using the PowerShell command shell. We will add monitoring support for Microsoft Information Worker applications and the Windows Client operating systems to our new management group by importing the applicable management packs. We could import the management packs with PowerShell one at a time using the install-ManagementPack cmdlet. Perform the following steps:

Management pack dependencies are something to watch out for when using PowerShell to import management packs. Whereas the Operations console validates dependencies and will not proceed with management pack import if there is a problem, PowerShell batch operations fail unexpectedly when dependent management packs are not previously installed. It is a good idea to use the Operations console’s Import Management Pack feature to investigate management packs for their dependencies before creating a PowerShell script for bulk import. Then ensure your PowerShell script lists the management pack import cmdlets in a sequence that considers any dependencies.

Now we will perform two quick checks to verify that the imported management packs are installed correctly and working. We will exit the Operations console and start it up again after the import operations, to make sure our console loads the new management pack elements.

You will recall that after completing our initial installation of OpsMgr 2007 with the reporting component, 40 management packs were installed in our management group. We observed the count of the number of installed management packs in the results pane header shown in Figure 8.18. We know we added 11 management packs using the Operations console and 12 with our PowerShell script (for 23 total additional management packs imported). Now, when we return to the list of installed management packs in the Administration space, we confirm with pleasure that there are 63 (40 + 23) management packs installed in our management group.

You can note in Figure 8.3, earlier in this chapter, that prior to any management packs being imported, seven child folders of views were present below the global views in the Navigation pane. After importing these 23 management packs, we expect some new views to be available in the Monitoring space. As a final check, we will navigate to the Monitoring space and open a view added by one of the newly imported management packs.

Figure 8.24 shows the Monitoring space after the additional management packs have successfully been imported. In the Navigation pane, we observe 11 view folders, four of which are new: Microsoft SQL Server, Microsoft Windows Internet Information Services, Microsoft Windows Server, and Microsoft Windows Terminal Services. The imported management packs added these folders of views, as well as new views in the Microsoft Windows Client folder.

Figure 8.24. Verifying the functionality of the newly imported Windows 2003 Server management pack.

To verify we are getting the correct functionality of the Operations console after importing the new management packs, we can open one of the new view folders shown in Figure 8.24. The Windows Server State view in the Microsoft Windows Server view folder correctly shows that the operating systems of the two OpsMgr core component servers are in a Healthy state.

The console’s Connect to Server applet remembers the identity of the RMS first connected to, and it will not prompt you again for the name of a management group. By default, the console connects to the RMS it last connected to. To change the focus of the Operations console to another management group, select the Tools -> Connect... item from the console’s main menu bar. This invokes the Connect to Server applet, where you can enter the information for another OpsMgr management group. Connecting to another management group adds an entry to the Registered Servers list remembered by the Connect to Server applet, and it changes the default connection to the last management group selected.

The Enter Credentials dialog box does not remember domain user logon information, and it only displays the local computer and the domains it is a member of as choices in the Domain drop-down selection list. The console will prompt for user credentials authorized to access the Operations console in the domain where the OpsMgr RMS is located. When accessing OpsMgr management groups in domains that do not trust the domain where the Operations console is located, you must manually supply appropriate user credentials and domain names on each use of the console.

There is no theoretical upper limit on the number of Operations consoles installed in a single management group. Install the console wherever it makes work more convenient and efficient for the operations staff. However, each console that is open creates several network connections and causes the RMS to open a connection to the operational database on behalf of the console. This means that consoles are not inconsequential in terms of their impact on the network and the OpsMgr management group.

Microsoft suggests that you not plan for more than 30 simultaneous Operations console sessions in one management group. We recommend you close any console sessions when not in active use.

Operations Manager 2007 includes a simple but invaluable feature to embed any relevant web content right in the Operations console. We will demonstrate this by creating a global view using the Web Page view type. We right-click the Monitoring space and select New -> Web Page View. In the simple setup dialog box, we enter the information shown in Figure 8.34 to link to the online System Center Pack Catalog at Microsoft’s website.

Figure 8.34. Creating a Web Page view that links to the System Center Pack Catalog.

After we create the Web Page view with the settings shown in Figure 8.34, we find a new custom global view named “System Center Pack Catalog” in the Operations console. Clicking this view opens the website at Microsoft in the Results pane, as shown in Figure 8.35. You can image the many possibilities for integrating the OpsMgr console with your intranet, partner extranets, vendor support sites, and other network management applications.

Figure 8.35. Web page view pulls relevant web-based content right into the Operations console.

The Web Page view is added to your OpsMgr monitoring toolkit along with the other views we have seen, such as the Alert, Event, State, Performance, and Diagram views. You can combine any of these view types to create custom, functional dashboards that intermingle the content of any view in the management group. In a fashion similar to how OpsMgr’s distributed applications allow you to combine monitoring of disparate objects into a single entity, dashboard views enable you to merge visual instrumentation elements from anywhere in your OpsMgr monitoring space into one view.

Management packs add many dashboard views to the console; as an example, all the performance and health monitoring views in the Windows Server management pack are dashboard views. Next, we will create a dashboard view that combines several other types of views. Perform the following steps:

In the embedded Web Page view, we have extended our OpsMgr console view to include a live view into a dashboard from another management application, the web-based HP Systems Insight Manager. After you have added the desired embedded views to your dashboard, you can later swap out an embedded view by right-clicking its header and selecting Remove View.

Access to the maintenance mode status (the wrench icon) appears throughout the OpsMgr monitoring space. This makes it easy to quickly view or update the maintenance mode state for an object. Maintenance mode enables you to avoid alerts or errors that might occur when a monitored object, such as a computer or distributed application, goes offline for maintenance. In a small environment with just a single administrator, this feature might not get used that often. However, in a large environment, maintenance mode is a key mechanism to permit team collaboration.

Figure 8.38 shows the Diagram view of a distributed application created to monitor an enterprise backup solution. The diagram illustrates a backup media server, passing through a pair of network switches, connecting to a pair of tape libraries. The Tape Libraries entity is a distributed application component we created that includes the two physical tape libraries as contained objects. We placed the parent entity in maintenance mode and selected to propagate those settings to contained objects, because the repair work we will be doing affects both tape libraries equally. Notice the wrench icon present, the empty unmonitored circle (rather than a check mark) next to the Tape Library component, and the contained tape library objects.

Figure 8.38. Viewing the maintenance mode settings of a distributed application.

We noted in the Duration field of the maintenance mode settings that we expect the work to be complete at 5:00 p.m. At that time, all three objects (the Tape Libraries entity and the contained tape library objects) will come back out of maintenance mode, and monitoring will resume on all components. OpsMgr 2007 polls maintenance mode settings only once every 5 minutes, so there can be a delay in an object’s scheduled removal from maintenance mode.

By default, the Operations console can only put 50 objects into maintenance at any one time. To adjust the amount of objects that can be selected and put into maintenance, modify the following Registry value: HKCUSOFTWAREMicrosoftMicrosoft Operations Manager3.0ConsoleConsoleUserSettingsMaxItemsForMaintenanceMode.

The Health Explorer is a very important feature in OpsMgr 2007. It is so useful in assessing the true operational state of an object that we nominate it as the “top tool” on the OpsMgr workbench! Earlier in this book, in Chapter 3, we explained how the Health Explorer is bound to the Service Modeling Language (SML) used by OpsMgr management pack developers that architect health models. When you have an object’s Health Explorer open, you are really looking into the brain of that monitor, with lots of accessory tools available to help you explore further.

When you see an object in the Operations console that is not healthy, the quickest way to answer the question “What’s wrong?” (and even possibly to fix what’s wrong) is to right-click the object and select Open -> Health Explorer. In our management group, the computer Gryphon is in a critical state, so we open that object’s Health Explorer in Figure 8.39.

Figure 8.39. The Health Explorer for an object can offer recovery tasks to fix the problem.

As we walk down the health model of Gryphon in the Health Explorer shown in Figure 8.39, we see the problem is in the computer’s performance, specifically that the threshold for a handle count was exceeded. This indicates a possible problem with memory on the computer.

The Health Explorer exposes and provides access to many other features of OpsMgr. For example, the upper portion of the Explorer has controls to reset the health state, view the detailed properties of a monitor, and apply an override for any selected monitor. Using the Overrides control, you can also view any other managed objects in your OpsMgr management group that have overrides for that monitor.

On the State Change Events tab on the right side of the Health Explorer, you can always see a chronological history of state change events for that object, as well as the context for the event that caused the state to be changed. Additionally, if the management pack author has included them, you may find suggested recovery tasks available to run in the Additional Recovery Options area. In our example in Figure 8.39, see the recovery task Restart Health Service, which you can select to run. We can infer, from the presence of this recovery task, that the management pack author’s experience indicates this recovery task may fix the memory-related handle count threshold error.

Management pack templates and the Add Monitoring Wizard are used to create and target custom object types, enabling you to extend the management capabilities of OpsMgr 2007. To create a new management pack from a template, you can right-click the Management Pack Template node and select Add monitoring wizard. Alternatively, you click the Add monitoring wizard shortcut in the lower portion of the Navigation pane.

OpsMgr 2007 provides templates for similar object types to help make it easier to create custom objects with the Add Monitoring Wizard. Management pack templates are conceptually comparable to Microsoft Word templates, which make it easier to create similar Word document types. Operations Manager provides the following default templates:

A distributed application service monitors the health of a distributed application that you define. It creates the monitors, rules, views, and reports necessary to monitor your distributed application and the individual components it contains. When creating a distributed application in OpsMgr 2007, you first create the service that defines the distributed application monitoring object at a high level. Next, use the Distributed Application Designer to define the individual components that are part of the distributed application you want to monitor. We cover using the Distributed Application Designer in detail in Chapter 19, “Managing a Distributed Environment.”

To create a new distributed application service and invoke the Distributed Application Designer, right-click the Distributed Applications node and select Create a new distributed application. You can also click the New distributed application shortcut in the lower portion of the Navigation pane. Templates are available for the following categories of distributed applications:

Operations Manager 2007 groups can delegate authority, scope access to specific areas of the Operations console, and override the default settings of management packs. To create a new group, right-click the Groups node and select Create a New Group, or click the New group shortcut in the lower portion of the Navigation pane. This invokes the Create New Group Wizard, which walks you through these five steps:

Use the Management Packs Objects node, in the Authoring pane of the Operations console, to create objects that define how monitoring will be performed in your management group. You can view existing attributes, monitors, object discoveries, rules, tasks, and views by clicking the appropriate leaf object under the Management Pack Objects node. You can also create new attributes, monitors, rules, and tasks from each corresponding leaf object. Here is a description of each leaf object and its purpose:

The following five leaf objects in the Device Management node allow you to perform post-installation configuration of specific Management Servers, agent-managed computers, agentless managed computers, and network devices:

Nine management group settings are exposed at this node, organized under the Agent, General, and Server headings. These are global settings because they control the behavior of the entire management group.

Figure 8.41. The Overview and Alert Details screens from the Mobile console.

Chapter 11 discusses the creation and management of user roles and Run As Accounts and Profiles in detail. Here is a summary of the functions located at the Security node of the Administration pane:

At the Management Pack node of the Administration space, you can view a list of all the management packs that exist in your management group—both sealed and unsealed management packs that you imported, and unsealed management packs that you created. You can create new unsealed management packs as well as import sealed and unsealed management packs from vendors and other OpsMgr community professionals. There is also an export management pack function; use this to create an unsealed management pack copy in a file system location of your selection. Exported management packs can be stored for backup purposes, imported into other management groups, and exchanged with other OpsMgr community professionals.

When you create a new management pack, a corresponding view folder is created in the Monitoring space. By viewing the properties of a management pack here, you can see the same management pack dependencies information exposed by the Import Management Pack Wizard when importing new management packs.

OpsMgr 2007 can send a notification to operators when an alert occurs, in case the operator is not watching the Operations console at that moment. Three steps are required to enable external notification to an operator. As we noted previously in this section, when describing the Settings -> General -> Notification feature, you must create notification channels before proceeding to create recipients and subscriptions. That is the first step to enable notifications. Perform the remaining two steps here at the Notifications node of the Administration pane:

A connected management group provides the capability for the Operations console user interface in one management group to query data from another management group. You can add the connection information for a connected management group here. That information is the management group name, the FQDN of the RMS, and the credentials to use to connect to the other RMS. The default credentials are those of the SDK service account of the local management group.

OpsMgr 2007 supports the ability to synchronize alert data with other applications, such as other management systems, using product connectors. Product connectors subscribe to alerts and forward them to other products. OpsMgr comes with one product connector installed, the MOM Internal Connector. OpsMgr components use the MOM Internal Connector to insert discovery data. You should ignore this entry in your product connector list. If you install other product connecters developed by third parties, they will appear in the product connector list. The properties page of a product connector has a subscriptions area where you would configure the connected product to receive forwarded alerts as desired.

The most common way to use OpsMgr Reporting is the targeted report method. With this method, you access the report from the Monitoring space, select the object you want report data for, and click one of the reports displayed in the Actions area on the right side of the Monitoring space.

This launches the report view, with the object of interest prepopulating the object list in the report parameters. Figure 8.42 shows a report on the memory performance of the Hydra computer for the last week. It also shows a performance report, which is generated by selecting to view the parameters of the report (View -> Parameters from the report view).

Figure 8.42. A targeted report after running, with the parameter pane displayed.

In Figure 8.42, the performance report graph in the lower portion is the report itself, and the parameters header in the upper portion includes the criteria used to generate the report. (For this figure, we scaled the graph to 80% of its actual size to fit it in the screenshot along with the parameters header.) We call this a targeted report because we invoked the reporting view in the context of the Windows Server 2003 Monitoring view with a particular computer selected. It just took a few mouse clicks to generate the report, and we did not need to know details about the report’s construction, such as the fact that memory performance history is part of the Window Computer object class.

Figure 8.43. The Percent Processor Time report for multiple systems, initiated from the Actions pane.

We can create the identical report, with a few more mouse clicks, by navigating to the Reporting space, selecting the Windows Server 2003 Operating System report library, opening the Memory Performance History report, and adding the computer object(s) to report on in the report parameters. Figure 8.44 shows the report details after selecting that report in the Reporting space.

Figure 8.44. The Reporting space exposes available reports in the generic report library.

If you design and save a new custom report, you can locate it at the Authored Reports node of the Reporting space. Notice also in Figure 8.44 that one of the report libraries is the Generic Report Library.

Generic reports are really like templates, used to derive the targeted and context-focused reports. For example, generic reports exist for data based on alerts, availability, events, configuration changes, and performance. By opening a generic report of the type of data you want to report on, you are then free to select any criteria from across the management group to construct a custom report.

After running a targeted report or a generic report you have customized, you can export the results from the report view using the File -> Export command. Available export formats are XML, comma-delimited (CSV), graphic TIFF, Acrobat (PDF), Web archive (MHT), and Excel workbook. Another option available after you have run a report is to save that report as a “favorite report,” which puts a shortcut to that report in the Favorite Reports node of the Reporting space for quick access in the future.

You can create scheduled reports by selecting File -> Schedule from the Report window after running a report. A three-step wizard allows you to specify a delivery method, schedule, and parameter(s) for your report to automatically run and save to a file share of your selection. You can select the same file formats for scheduled reports as when exporting a targeted or generic report. A list of scheduled reports in your management group appears at the Scheduled Reports node in the Reporting space.