As a MOM Administrator you may often find your head sunk in the Operator Console. If you wear multiple hats, then you're most likely viewing the problems in your environment. Even if the role is strictly administering MOM, the Operator Console validates the work placed into the rule creations or modifications. The Operator Console is also used to view alerts, events, short-term performance data, and data arranged in two new views: State view and Diagram view.
The Operator Console can be used to connect to any Management Server. Once connected, the first noticeable difference from MOM 2000 is the new look. The MOM 2005 Operator Console has been drastically revised for ease of use. In fact, the look and feel of the Operator Console is much like Outlook 2003.
Not only is the console aesthetically pleasing, the new layout and views go a long way in making the console easy to navigate and functional. In addition, a Task pane has been included, which can be customized to provide various tasks or applications that can be launched by the operator, which are context-sensitive to what the operator may be viewing at the time.
Many of the management packs, Microsoft-released or third-party, include views that organize Alerts, Events, State, Performance, or Diagram. The views included represent data that is generally relevant to the technology in hand but by no means is meant to display all the data in the most useful ways. You may often find that additional views need to be created or existing ones need to be edited. The MOM Administrator and/or Author can create views that can be shared by all users. The MOM Operator Console can be customized by the users to display the data relevant to them.
Views serve the purpose of filtering data to useful content — such as those options just mentioned. Often, the alerts may be more relevant than the events, for instance. An example is viewing broken connection objects in Active Directory through a Diagram view rather than Alert or State views. Fifteen alerts on broken connection objects are generally better understood in a picture than trying to correlate the alerts to determine where the problems exist.
The Operator Console displays the views into top-level nodes that hold all the views of the same type together. This helps the operator flip back and forth quickly between useful areas of information. The following sections detail the information you can expect to find in the different views.
Not surprisingly, the Alert view is where alerts are displayed. Anything dealing with alerts, including viewing details, changing resolution state, changing ownership, viewing associated events, and viewing the knowledge base and the history can all be accomplished in this view.
Alert details (see Figure 6-3) are composed of the following:
Properties: Displays all data about the alert. Includes description, name of rule, rule location, time of event, source, and agent.
Custom Properties: Assignment to Alert owner can be added here. Additional Alert views can be created to limit views to alerts that have been assigned to a particular individual. A Ticket ID corresponding to a Helpdesk ticketing system can be used to track the alert with an incident.
Events: Displays any events that correspond to the alert.
Product Knowledge: Displays any knowledge base information from the management pack author/vendor. The Product Knowledge generally has information that can help resolve the alert. Product Knowledge is context-sensitive to the rule that generated the event.
Company Knowledge: Displays (and allows editing of) company-specific knowledge for a rule.
History: Displays history of changes to the alert such as creation, state change, assignment, and responses (notifications, remediation scripts).
Alerts can be sorted by any column to shift focus. For example, to see any recent alerts, the alerts could be sorted by the Time Last Modified field. To see alerts based on criticality, sorting by Severity would display the most critical problems at the top of the list.
State view offers a new roll-up view indicating health with red, yellow, and green indicators. At a glance, an administrator can quickly view the status of all the computers and their relative components. Because State view uses the same indicators as found in Alert view, potential component problems are easy to understand.
Each row in State view represents a different agent. The columns that make up each row are indicators displaying the high-level component status. For example, if there is a Disk issue, an administrator could select Disk and expect to see further detail in the State Details pane. The pane in this example would display the instances of the Disk and relative status for Free Space and Latency, as shown in Figure 6-4.
Further detail (to the Alert level) is also available. Consider the Disk example: If there were an unhealthy indicator on Free Space on Instance C:, double-clicking the indicator would bring up the Alerts pane focused on the alert displaying the problem condition.
Many of the available management packs (MP) come with defined State views, filtered to display the information relevant to that MP. However, if a State view doesn't exist for a particular technology, it can be created. State views can also be modified to display the component state on just the things that interest you.
Microsoft Operations Manager collects far more events than those that are visible in the Alert view. Not all events generate alerts because it may not be necessary to know when specific events occur. This is often the case when events are used to collect data for reporting. The event data is valuable for long-term trending but may not be useful to know immediately.
For example, a particular, non-critical application runs as a service. Every now and then, the service will shut down from an application problem. To remedy this, a MOM rule is created to pick up the application event when the condition occurs and MOM responds by starting the service. Since the problem is corrected immediately, an Alert is not required. However, the event data is collected so that a report listing all the times the event occurred can be reported.
If you're looking for a task status, you must refer to the Event view. Because tasks executed on the agent always report their status to the Generic Provider type (named Internally-generated Event), they display only in the Event view. Event rules could be created to generate an Alert on any task execution to display the status. Keep in mind however that it would be extremely difficult to filter out the noise.
Based on the Grooming settings in the Administrator Console, MOM is capable of displaying graph data up to this value. If the operator is interested in seeing recent server performance, using the MOM Performance Views can save time. Views can be created to group the data together for immediate viewing or so you can refer to it whenever necessary.
The same thing could be replicated in Perfmon. However, the information would have to be collected upfront to see any history. Like MOM, Perfmon can be used to store data over a period of time. The console can also be customized to display relevant data. The difficulty is in setting up performance monitoring for a whole set of servers or trying to share the customized Perfmon console. Because MOM centralizes the data collection, the views, and makes it easy to share them, it makes sense to view performance data this way.
Two types of Performance views can be utilized to display information in the most helpful way. The Performance view groups computers in a Computer Group together. This serves as a launch point to drill down deeper into the performance information of that particular computer. This view does not provide any performance data without drilling down.
The Performance Data view displays more specific, more detailed, and more relevant data pertaining to a group of performance information (e.g., objects, instances, and counters) as well as the most recent data point. Both kinds of views can be used to display graphs (see Figure 6-5).
Keep in mind that no view of this type, either Performance or Performance Data, can be used to display a graph initially.
Most Performance Data views are set up to display only the default amount of data. The default amount, unfortunately, is two hours. While this may be sufficient for a quick glance, it doesn't really provide any bit of trending. To change this behavior, locate the Performance Data view that requires a longer time-frame and follow these steps:
We illustrate how to do this by modifying the "Free Megabytes" view (located under All/Performance Views/Microsoft Windows Server Base OS/Performance/Logical Disk). The Performance Data views in this management pack are, by default, set to 24 hours instead 2 hours.
Right-click the Performance Data View and choose Properties to get the Performance Data View Properties dialog box, as shown in Figure 6-6.
Click the "measured in specified time period" check box (if it's not already selected).
In the View description area, choose the underlined statement next to "and measured."
In the Graph Date and Time Filter dialog box, shown in Figure 6-7, change the ranges appropriately.
Click OK to accept the changes and exit the Graph Data and Time Filter dialog box.
Note that the time period has changed to reflect 7 days. Click OK to accept the changes to the Performance Data View Properties, as shown in Figure 6-8.
In our example, we set the value of "measured in specified time period" to 7 days.
Three types of views exist for Computers and Groups and basically arrange information relevant to the container type. The Computer Groups view displays all the Computer Groups in a Management Group and displays the Rule Groups associated to it. This view can serve as a launch point for the Computers view. Double-clicking any of the Computer Groups will display the computers that are a member of that Computer Group.
The first tab of the Computers view displays all the attributes that were discovered for the selected computer. The second tab displays all the Rule Groups that the selected computer should be running. The third tab shows all the Computer Groups that the selected computer is a member of. The fourth tab, Roles, displays all the roles that were discovered by Service Discovery Rules.
The third view, Computer Attributes view, is used to display attribute information from various computers. As shown in Figure 6-9, specifying this type of view for all attributes that match the wildcard "*Windows Current*" would result in displaying this value from any computer that had the attribute.
Diagrams are new to MOM 2005. These are imported with management packs. They're useful in displaying a high-level overview of a given environment in a topographical format and show the state of the components that make up that environment.
Hovering over a computer in the Diagram view displays further information found in discovery as well as status or other relevant data. Double-clicking a computer displays an Alert view filtered to that particular computer. If a Diagram view exists for a given management pack, these deserve some attention. Often, it may be easier to correlate information together to display a high-level picture. A well-designed Diagram makes this possible. For example, if you view 10 different alerts regarding a replication error in Active Directory, it would be a little difficult to determine where problems exist without knowing the environment very well. However, if you were to view it in a topology, as shown in Figure 6-10, you might see that one domain controller had multiple broken connection objects, and it would be very clear that the domain controller in question had a potential problem.
Diagrams have limited flexibility in their viewing styles such as routing style, node placement, rendering quality, background images, and the number of levels to display. The most useful component of a diagram (aside from the graphical view of problems) is the ability to export to Visio!
There's a good reason diagrams weren't discussed in the Administrator Console. Diagrams can't be created in the Administrator Console; instead they are created through the Operator Console but are limited to the Diagram types imported with management packs. MOM 2005 offers very limited views that can be created from these objects.
The Public View node encapsulates all the different view types, organized by folder layout. Unlike the other view nodes, Public view does not filter based on any view type. Instead it displays them all. Any views created under Public view are available for all users to access. Viewing through any other node displays the new Public view in the correct area. For example, if a Public view for alerts is created in the root of the Public View node, it will be displayed there. Switching to the Alert View node will display this new Alert view; however, as expected, switching to the Event view, will not display the new Alert view.
Any Public view can be copied and pasted to the My Views node. These views are specific to the user running the Operator Console and are not shared. Any view type can be copied/pasted or created in this space.
There are two ways to limit noise in Microsoft Operations Manager: Views and Group. By now, you should be very familiar with how views can help limit the amount of information you're viewing through the choosing the particular View node that makes sense. These can be further defined by manipulating the properties of the Views. The third component of this is to use the Group type to switch to the group that defines the computers that you wish to view information from. Selecting a group type is illustrated in Figure 6-11.
For example, the MOM Administrators decide that they'd like to view all the alerts from MOM that are specific to scripts that have run long. In order to do this, the MOM Administrator starts off by choosing the Alert node. From there, the admin drills down to Microsoft Operators Manager/Operations Manager 2005/Script and Response Events and chooses the "Script Errors Alerts-Long running or hanging scripts."
The view displays all the alerts matching the criteria in the given view. The administrator decides that there are far too many alerts to dig through. After deciding that it's the SMS agents throwing back errors, the administrator sets one more limit to the view. To do this, the admin drops down the Group list and chooses Microsoft SMS 2003 Advanced Clients. Now the MOM Administrator can see all the alerts that match the criteria for "Script Errors Alerts-Long running or hanging scripts" from only the computers that are in the Microsoft SMS 2003 Advanced Clients Computer Group.
This type of scoping can be used in every view type. If you recall from the Administrator Console section, the console scopes limit what you can view in the Operator Console. Any of the Sub-Groups added to the console scope can be used to limit the view. If users have console scopes, their views are always limited to the console scope no matter which view they use. However, they can further define their view by using the Group drop-down and choosing any Sub-Groups defined in their console scope.
By using the Custom Properties tab of any alert, the MOM Operator Console can be used to track alerts that are assigned to MOM operators. Using the Alert Owner field, the alert can be assigned by using the drop-down list or typing in the assignee. Additionally, views can be created based on the Alert Owner field.
If the particular alert is always assigned to the same operator, the rule itself can be defined to pre-popu-late the Alert owner field with the specified individual as shown in Figure 6-12.
When the alert is finally resolved, the operator can input the details by using the Resolve Alerts dialog box. This can be enabled or disabled by right-clicking anywhere in the Alerts pane. In the Set Alert Resolution State drill down, choose Prompt for Alert History comments.
Earlier in the Administrator Console section, the tasks were described as actions that can be executed against the agent or directly from the Operator Console. In the Operator Console, the Tasks pane can be displayed by choosing View in the menu and Tasks pane (or Ctrl-T).
The Tasks pane, shown in Figure 6-13, is context-sensitive. This means that depending on what computer is in focus, only certain tasks are available (defined in the Administrator Console). If the task is not available for a particular computer, the task name is grayed out. Clicking any of available tasks will start the Launch Task Wizard unless there are no parameters defined in the task. Otherwise, the task will launch immediately.