Businesses provide services to customers. The status of the service(s) is important at all levels of an organization. Service offerings might include email, web, or business-to-business. When a service is rendered unavailable, discovering the root cause and the impact to the business are critical steps in the service recovery process. Unplanned application, system, or device downtime may affect the business and the service delivery to the customer. With OpenView, it is possible to implement an enterprise management operations environment that will show you the status of the services that are supported by the back-end network, systems, and applications.

An overall view of the business from a service perspective enables faster resolution of any service impacting problems within the IT infrastructure. For example: You provide email services to customers (internal or external) using several mail servers that are located on different networks. The OV operator Java console can show you a graphical view of the email service. This view is possible as a result of the integration of OpenView Service Navigator at the management server. OV Service Navigator is a separate product but it is tightly integrated with OVO out-of-the-box and is available at no extra cost. The service configuration must be assigned to the operator before service views are visible within the operator's Java console. Figure 13-1 shows an example service view. The OpenView Navigator Concepts and Configuration Guide is available at the OpenView web site: http://ovweb.external.hp.com/lpe/doc_serv/.

Figure 13-1. Service graph.

The OpenView product solutions guide available at: http://openview.hp.com/solutions is an excellent place to begin if you need to get a better perspective on how the OpenView solutions for Enterprise, Service Provider, and Adaptive Management ensure rapid deployment of the correct solution for your environment. Several of the solution categories are listed here for reference.

The OpenView products installed on the management server are delivered in CD sets. Oracle for OpenView is a separate CD set. The initial installation of the OpenView management platform includes the following software products:

This section provides a high-level overview of the OpenView installation tasks. The list in Table 13-1 covers many of the tasks that you will perform during the OpenView implementation project. Depending on the scope of the implementation, you may choose to organize the tasks into one large or several small projects. Whatever you decide, it is important to document the plan and create operations procedures as part of the project deliverables.

The time it takes to install the OpenView software onto the management server will vary based upon your familiarity with the system hardware, network and operating system environments. Your experience with prior versions of the application will also prove beneficial with the installation of any new versions of the products. So, whether you are just starting or have the experience of prior installations, the first steps are listed here for reference:

HP-UX operating system examples are used throughout this part of the book. Any significant installation differences for the Solaris are indicated when appropriate.

#cat ovoinstall.defaults
# This file is parsed by ovoinstall. Values may be changed in this section
# Note: English text only.
BBCCLIENTS_PATH=/ovo_8/CD2/OV_DEPOT/HPOvOhttpsClients.depot
BBCCLIENT_PRODUCTS="OVO-CLT.OVO-UX11-CLT OVO-CLT.OVO-SOL-CLT OVO-CLT.OVO-LIN-CLT OVO-CLT
.OVO-DLIN-CLT"
RPCCLIENTS_PATH=/ovo_8/CD2/OV_DEPOT/HPOvOrpcClients.depot
RPCCLIENT_PRODUCTS="OVOPC-CLT.OVOPC-NT-CLT OVOPC-CLT.OVOPC-SOL-CLT OVOPC-CLT.OVOPC-UX11-CLT"
CDROM_DEV=/dev/dsk/c0t0d0
CDROM_INSTALL=false
CDROM_MNT_PT=/SD_CDROM
DB_CHARACTER_SET=
DEFAULT_M10I_PATH=/ovo_8/CD1/OV_DEPOT/HPOvComponents.depot
DEFAULT_SERVER_PATH=/ovo_8/CD2/OV_DEPOT/HPOvOServer.depot
FORCED=false
LANGUAGE=C
M10I_PRODUCTS="HPOvLcore.HPOVXPL HPOvLcore.HPOVSECCO HPOvLcore.HPOVBBC HPOvLcore.HPOVSECCC 
HPOvLcore.HPOVCTRL HPOvLcore.HPOVDEPL HPOvLcore.HPOVCONF HPOvLcore.HPOVSECCC HPOvSext"
M10I_PRODUCTS_INSTFLAGS="-x enforce_dependencies=false -x autoselect_dependencies=false"
MINIMAL=false
ORACLE_HOME=/opt/oracle/product/9.2.0
ORACLE_DATA_DIR=/ora_db
PACKAGES_TO_ADD=
POLICY_DATA_TYPE=
REINSTALL=false
SERVER_PRODUCTS="OVOEnglish OVOSvcNavEng"
TAR_FILES=
this listing is truncated
HP-UXHP-UX
TAR_FILE_PATH=/ovo_8/CD2/OVOServer_patches

VERBOSE=true
TIMEOUT=5
INSTALL_DEVKIT=false

# NNM installation script options.
NNMINSTALL_SCRIPT_NAME=install
NNMDEPOT_PATH_CD1=/ovo_8/disk1
NNMDEPOT_PATH_CD2=/ovo_8/disk2

NNM_DISC_NETWORK=n
NNM_SHOW_UI=n
NNM_SNMPCOMMUNITY=s
NNM_BROWSER_PATH=s
NNM_VIEW_RELEASE_NOTES=n
NNM_INST_JAPANESE=n

# Values below here will not be read by ovoinstall when running in silent mode
ORACLE_PW_OPC_OP=opc_op
ORACLE_PW_OPC_REPORT=opc_report
ORACLE_PW_SYSTEM=manager
ORACLE_USR_DBA=oracle
ORACLE_AUTODBSTART=y
ORACLE_SID=openview
ORACLE_USE_CURR_DB=y
ORACLE_NET=ov_net
ORACLE_BASE=/opt/oracle
ORACLE_DB_REINIT=y
ORACLE_IDX_DIR=/ora_db
#

The first-time agent installation is onto the management server. This enables the server to become the first managed node. If requested by the user, during OVO server installation process, the default agents and components are assigned and distributed to the management server automatically. Subsequent distributions can be performed from the OVO administrator console or the command line (refer to the man page for the command opcragt). After the initial server components are distributed, messages from the server begin to appear in the message browser. Refer to Chapter 14 for more information about agents and components.

The processes that run on the management server and managed nodes indicate the health of the OpenView environment. If you experience any problems with the standard operation of the OpenView product, check to ensure that all the necessary processes are running. Below are three examples of checking the status of the OpenView processes. Refer to Chapter 18, “Oracle for OpenView,” and Chapter 22, “Troubleshooting Tips and Techniques,” for information about commands to check the Oracle and Operating System processes. Descriptions of the OVO processes appear later in this chapter.

Name              PID  State          Last Message(s)
 OVsPMD           1422  RUNNING        -
 ovsessionmgr     1424  RUNNING      Initialization complete.
 ovwdb            1425  RUNNING      Initialization complete.
 ovuispmd         1484  RUNNING      Successful restart. 0 ovw clients registered.
 ovtrapd          1455  RUNNING      Initialization complete.
 ovactiond        1456  RUNNING      Initialization complete.
 syslogTrap          -  NOT_RUNNING    -
 ovalarmsrv       1457  RUNNING      Initialization complete.
 pmd              1427  RUNNING      Initialization complete.
 genannosrvr      1458  RUNNING        -
 httpd               -  unknown      (Does not communicate with ovspmd.)
 ovtopmd          1453  RUNNING      Connected to native database "openview".
 netmon           1485  RUNNING      Initialization complete.
 snmpCollect      1486  RUNNING      Initialization complete.
 ovas             1492  RUNNING      Initialization complete.
 ovrequestd       1430  RUNNING      Initialization complete.
 ovdbcheck        1459  RUNNING      Connected to embedded database.
 ovctrl              -  unknown      (Does not communicate with ovspmd.)
 ovoacomm         1490  RUNNING      Open Agent Service Server Initialization Complete.
 For details about Open Agent Service use 'opcsv'.
 opc              1772  RUNNING      OVO Server Initialization Complete.
For details about OVO Manager Processes use 'opcsv'.
#

# opcsv
OVO Management Server status:
Control Manager      opcctlm     (4807) is running
Action Manager       opcactm     (4814) is running
Message Manager      opcmsgm     (4815) is running
TT & Notify Mgr      opcttnsm    (4816) is running
Forward Manager      opcforwm    (4817) is running
Service Engine       opcsvcm     (4822) is running
Cert. Srv Adapter    opccsad     (4820) is running
BBC config adapter   opcbbcdist  (4821) is running
Display Manager      opcdispm    (4818) is running
Distrib. Manager     opcdistm    (4819) is running

Open Agent Management status:
Request Sender       ovoareqsdr  (4801) is running
Request Handler      ovoareqhdlr (4804) is running
Message Receiver (BBC) opcmsgrb  (4805) is running
Message Receiver     opcmsgrd    (4806) is running

Ctrl-Core and Server Extensions status:
Control Daemon               ovcd       (4314) is running
BBC Communications Broker    ovbbccb    (1467) is running
Config and Deploy            ovconfd    (4315) is running
OV Certificate Server        ovcs       (4802) is running
#

opcmsga   OVO Message Agent         AGENT,EA(5129)   Running
opcacta   OVO Action Agent          AGENT,EA(5130)   Running
opcmsgi   OVO Message Interceptor   AGENT,EA(5131)   Running
opcle     OVO Logfile Encapsulator  AGENT,EA(5133)   Running
opcmona   OVO Monitor Agent         AGENT,EA(5135)   Running
opctrapi  OVO SNMP Trap Interceptor AGENT,EA(5137)   Running
opceca    OVO Event Correlation     AGENT,EA         Stopped
opcecaas  ECS Annotate Server       AGENT,EA         Stopped
coda      HP OpenView Performance Core      (3657)   Running
#

# ovc
ovcd    Control Daemon                      CORE (4314)     Running
ovbbccb HP OpenView BBC Communications Broker CORE (1467)   Running
ovconfd HP OpenView Config and Deploy     CORE (4315)       Running
ovcs    HP OpenView Certificate Server SERVER               Aborted
opcmsga OVO Message Agent             AGENT,EA (4321)       Running
opcacta OVO Action Agent              AGENT,EA (4322)       Running
opcmsgi OVO Message Interceptor       AGENT,EA (4323)       Running
opcle       OVO Logfile Encapsulator  AGENT,EA (4325)       Running
opcmona     OVO Monitor Agent         AGENT,EA (4327)       Running
opctrapi    OVO SNMP Trap Interceptor AGENT,EA (4329)       Running
opceca      OVO Event Correlation     AGENT,EA              Stopped
opcecaas    ECS Annotate Server       AGENT,EA              Stopped
coda        HP OpenView Performance   Core  4331)           Running

You should become familiar with the automatic startup and shutdown process for the management server and the managed nodes. During server startup, it is necessary for several services, such as the Internet services or DNS, to start prior to the OpenView processes. If for some reason the prerequisite services are not enabled, you will experience problems with OVO. Information about the specific startup and shutdown files for Oracle, NNM, and OVO is provided here for reference. In general, the order of startup for the OpenView platform is operating system communication programs, Oracle database, NNM services, OVO server, and OVO agent.

Refer to the operating system documentation for HP-UXHP-UX or Solaris for details on startup and shutdown procedures.

Initiate a new OVO session with the command opc and use the administrators' login account and password (i.e. opc_adm, OpC_adm). It is recommended to change the default password for the administrator and the default user accounts after the server is installed. During the first administrator or operator login, the password change is enforced. When you initially log into the management server you see two windows, Root and Node Bank. Figure 13-2 is an example of the administrator login session.

Figure 13-2. OVO administrator login session.

After the administrator logs into the OVO console, two windows appear by default after login authorization. However, there are many other windows available for the administrator to control and configure the OVO environment. Select the menu item “Actions” or “Window” to access the full set of administrator windows from the Node Bank. It is important to get to know all of the administrators' configuration windows. The windows are also referred to as Banks. The description and examples of using the configuration windows are covered in more detail in Sections 13.9 through 13.15 of this chapter.

The administrators' primary windows include Root, Node Bank, Node Group Bank, Message Group Bank, User Bank, Profile Bank, Node Hierarchy Bank, Message Source Templates, and Message Browser. Each window contains default icons, or you can add an icon to represent a part of the configured components for your environment. When you select an item from the menu, a pull-down menu opens. The pull-down menu contains other actions or configurable components.

Select or highlight an icon with the left mouse button and click once. You will know the icon is selected if a shadow box appears around the symbol. While the symbol is highlighted, activate a pop-up menu and hold down the right-mouse button. The pop-up menu lists items that can be executed against only the highlighted symbol and the object it represents.

Select multiple nodes, hold down the control key, and select multiple icons with the left mouse button. Another method to select multiple nodes is to create a square window around the nodes. Hold down the left mouse button in the upper left corner of the window you want to make around the nodes. Drag the mouse to the right and down, and you will see a box surround the nodes. When the box includes the nodes you want to select release the left mouse button. The nodes that were inside the selection box are highlighted. This is a fast method to select many nodes for tasks that require drag and drop. Figure 13-3 and 13-4 are examples of the Root Banks

Figure 13-3. The Root Bank contains the symbols and icons that represent all of the configuration components.

Figure 13-4. The node for the management server is in the Node Bank by default after OVO software installation.

Node icons in the Banks and Groups represent managed nodes in the OVO domain. The Actions and Window pull-down menus at the top of the Node Bank lead to the configurable components or the Message Browser. The messages from the managed nodes will appear in the Message Browser window. Figure 13-5 is a view of the primary message browser window. The messages in the browser are identified with attributes that are listed at the top of the browser window (for example, Severity, Duplicate Count, Flags SUIAONE, Date, Time, Node Name, Application, Message Group, Object, and Message Text). The messages remain in the browser until they are manually acknowledged or automatically acknowledged using message correlation.

Figure 13-5. The Message Browser contains the list of messages from the managed nodes and the management server.

Table 13-4 lists the configuration components available from the Actions and Window pull-down menus. These menus are repeated on each of the administrators' windows (except the root window). This has the advantage of providing quick access to configuration components. These menu items are used often to add, change and remove configuration components. In the case of the Action menu item, it is context-specific depending upon the current active window.

Looking at an OpenView domain is overwhelming at first glance if there are many nodes shown as individual icons inside the Node Bank. There are many components within the Administrator's GUI that help you organize the look and feel of the OVO console. You can organize the nodes by using the built-in tools, such as node groups, node hierarchies, and node layout groups. The next sections explore some ideas on how to organize the nodes within the administrator and operator consoles.

Nodes

Deciding which nodes to manage is one of the OpenView administrators' primary tasks. Different types of nodes managed by OVO are brought into the configuration, including

• Controlled—. Agent installed and allows remote logins, actions and monitoring.

• Monitored—. Agent installed but does not allow remote logins or remote actions.

• Message allowed—. No agent, node sends SNMP traps (for example, router or printer).

• Disabled—. Node is not monitored for status, sends no messages.

• External nodes—. Only send events via SNMP that will be processed and transformed into OVO messages. These are referred to as nodes for external events inside the GUI.

After you determine which nodes and or node type to manage, add the node to the Node Bank. Unlike NNM, OVO does not manage any node automatically. You must add the desired node to the Node Bank first. Adding a node can be done by either using the menu in the OVO Node Bank, or even more convenient, by drag/dropping from the NNM ipmap.

If the node is fully managed, a Node Configuration window appears and waits for you to verify the default settings or make changes. After you click OK, the information about the node is stored in the database. The node is not yet installed with the agent software; you will perform this task after the node configuration is complete. (Refer to Chapter 14 for agent installation techniques.) If the node is only sending events to OVO in the GUI, use the Add Node for External Events window. Although the GUI method is described here, there are commands to accomplish the same tasks. The Add Node configuration window is shown in Figure 13-5a for reference.

Figure 13-5a. Add Node configuration window contains the fields used to describe information about the managed node.

There are several methods to add nodes to the Node Bank. (Refer to the OVO Administrator's Reference, Volume I for more detailed information.) Examples of the process to add nodes to the Node Bank are shown here for reference. Each example assumes that a selection is made from the menu.

Example 1: Actions→Node→Add

This method is ideal for installing one node at a time. You need to provide the hostname of the node you want to add. OVO then attempts to determine additional attributes (IP address, system type, and so on) by querying the node's SNMP agent. If an SNMP agent is not running on the managed node, you will need to set the machine type manually in the configuration window.

Example 2: Edit→Copy

Locate the node in the root map, by selecting Edit→Find→Object by Selection Name (or some other attribute; see the list in the Selection Window). Once you have identified the node, select the node, and from the menu select Edit. In the OVO Node Bank, select the menu item Edit→Copy. The new node appears in the Node Bank. A drag/drop from the ipmap would also work to add the node to the Node Bank.

Example 3: Open the Node Group Bank, double-click with the left-mouse button on a node group icon, and then select from the menu, Actions→Node→Add

Add a new node to the node group and it will automatically appear in the Node Bank (Holding Area). Here you could also use the Menu option Edit→Copy, Edit→Paste. Node Groups are covered in more detail in Section 13.9.2.

Example 4: Actions→Node→Add for External Events

Use this method for managing devices that typically do not have the OVO agent installed but are capable of sending their events to a node that does have an OVO agent (a proxy node) or directly to the server. When the event arrives on the managed node, it is transformed into an OVO massage and sent to the server. A use case is to manage SNMP devices like routers, bridges, network printers this way. The external events icon changes status as the messages from the external nodes are processed on the server. When the window “Add Node for External Events” opens, provide a label name for the icon in the GUI. The dialog box for external events is shown in Figure 13-6.

Figure 13-6. Add Node for External Events dialog box.

Select the Network Type, IP-Addr, IP-Name, or Others. This determines what type of entry you will use in the Node Pattern field. For example, if you use IP addresses in the Node Pattern Field, select IP-Addr. Provide a Node Pattern, which is actually a node name pattern (such as *.hp.com). The Node Pattern field can contain wild cards for the IP address range if there are many nodes on one a network that will send events to the server (i.e. 192.14.*.*). Other options for the address range can include and exclude specific IP numbers (i.e. 192.14.123. <5 –le [<#>] –lt 72>. Finally, select the Type of Node, Message Allowed (in order to enable the events from the external node(s) to appear in the browser). The external node icon is located in the node bank with the other node types as shown in Figure 13-7. Configure the external device to send SNMP events to the OVO server.

Figure 13-7. Nodes for external events in the Node Bank.

Example 5: Upload the node configuration from the command line. (Refer to Chapter 17, “Server Administration,” for details on this method)

Example 6: Command line method, see the man page for opcnode.

Node Groups

All the nodes you plan to manage with OVO must appear in at least one Node Group. This is important because the Node Groups (shown in Figure 13-8) are assigned as part administrators' responsibilities and part operators' responsibilities. For example, if you add a node to the node group and the node group is assigned to the administrator or operator, they will begin to see messages from the new node after the next login session. Simplified administration is another advantage of organizing the nodes into a Node Group. For example, you may have a Win2K server (node) running IIS and an Oracle database. This node might appear as a member of multiple Node Groups (such as W2k, Oracle or Database). Also, assignment of Template Groups to node groups as the domain grows helps simplify distribution and configuration changes. Select Window→Node Group Bank→Add.

Figure 13-8. Node Group Bank.

Node Layout Groups

Use this concept to pre-arrange the nodes within a window hierarchy for your operators. By default, OVO presents all managed nodes in a single, “flat” window (Managed Nodes Window) in the Operator GUIs. When there are so many icons in a window, it is difficult to distinguish which node manages what environment. For example, in the node bank, you might have several hundred nodes in the domain and the icons appear very small. Creating Node Layout Groups lets you create a hierarchy of windows where, for example, you organize your managed nodes by location or geography, by the role these systems fulfill, or by other custom criteria. You could use the features of the window to pan and zoom or create a quick navigator window, but you could also organize the nodes inside the current window.

Create a Node Layout Group from a window that contains individual node icons or other Node Layout Groups. From the menu, select Actions→Node→Add Node Layout Group. Add the name, label and description in the dialog box (Figure 13-9). The icon for the Node Layout Group is now in the window. In this example, we use the Node Bank window.

Figure 13-9. Node Layout Group dialog box.

Create a Node Layout Group for each physical location, department, or type of application (see Figure 13-10). Drag and drop the nodes onto the Layout Group Icon. This allows you to see only the Layout Group icons in the window when you login and open the Node Bank. Drill down into a Layout Group and double-click the left mouse button. Node Layout Groups may contain other Layout Groups.

Figure 13-10. Node Bank Layout Group.

Node Hierarchies

A node hierarchy is used to configure what organized view in the Motif GUI the operators see when they open the Node Bank. To customize a node hierarchy, use the Node Hierarchy Bank. For example, if the nodes are located in different regions, states, or departments, you can build a node hierarchy to represent the logical organization of the nodes for the operator's console.

For example, from the Node Bank, select Window→Node Hierarchy Bank. Within the Node Hierarchy Bank, select Actions→Node Hierarchy→Add. After you enter the name, label, and description, the new symbol for this Hierarchy appears in the Hierarchy Bank (see Figure 13-11).

Figure 13-11. Add Node Hierarchy dialog box.

Double-click on the new symbol to view a Holding Area Symbol. All the nodes are available for use within the Node Hierarchy. A Node Hierarchy is assigned to the operator and provides an organized view of the operators managed node responsibilities, for example, Shipping East Coast (see Figure 13-12). A procedure to assign the Node Hierarchy to an Operator is outlined here.

1. Highlight the Node Hierarchy icon.

2. Open the User Bank.

3. Select the operator account to modify.

4. Select the Node Hierarchy button in the Operator Configuration window. (You cannot type in the Node Hierarchy Dialog Box.) Select the Get Map Selection button; this transfers the name of the highlighted Node Hierarchy into the Operators Configuration the next time the Operator logs into the OVO via a Motif GUI. The node bank will be organized into the Layout Groups you defined in the Node Hierarchy. The operator is assigned only one Node Hierarchy at a time.

Figure 13-12. Node Hierarchy Bank.

A Node Hierarchy defines “how” a user will see their assigned nodes. The assigned Node Groups in the user's responsibility matrix define “which” nodes the user sees.

Message groups are an important part of the configuration. An OVO message contains all of the important attributes that help determine who will need to see this event in their message browser. One of the attributes is the message group. For example, a message might contain the message group attribute called Database. The message group attribute of an OVO message will be defined by the OVO administrator as part of the agent's template configuration. See Chapter 14 for more information about templates. If an operator's configuration includes the message group Database, the message will appear in the operator's message browser. All messages must be organized into logical categories called message groups. The default message groups are Backup, Certificate, Database, HA, Hardware, Job, Misc., Netware, Network, OpC, OS, Output, Performance, Security, SSP, and SNMP.

The message group “Misc” plays a special role by catching all undefined messages. If an arriving OVO message contains a message group attribute which is not part of the Message Group Bank, it will be assigned to all OVO users who have the message group “Misc” assigned. However, the original message group value (as part of the OVO message) will be displayed in the message browser.

An example of how to create a new message group is shown here for reference. Select from the menu Actions→Message Group→Add. Enter the name, label, and description for the message group (see Figure 13-13). Click OK. The icon for the new message group appears in the window (see Figure 13-14).

Figure 13-13. New message group added to Message Group Bank.

Figure 13-14. Message Group Bank.

You can change the look of the icon by highlighting it with the left mouse button. Open the pop-up menu with right mouse button. Select Change Symbol Type. This opens the window for the symbol types you may choose from, as shown in Figure 13-15. (Refer to the Administrator's Reference, Volume I for more information.)

Figure 13-15. Changed Message Group “Shipping” symbol type.

The operator responsibilities and tools are assigned to the operator and to the operator account. Each operator's configuration is located in the User Bank. There are three methods to create a new user and assign responsibilities using the GUI. The first method is to assign a profile. A profile is preconfigured with the node groups, message groups and applications (covered in Section 13.12). The components are typically customized for each operator depending on their responsibilities. The profile is typically named and assigned based upon the operator's role. A profile may contain other profiles.

The same profile is reusable for operators who have similar responsibilities. Pre-configured profiles save time when adding new operators—you just create the new account and apply an existing profile.

The second method is to create the user account and define responsibilities and application tools for each individual account. The third method is to use a combination of both of the other methods. The configuration that is assigned to the operator determines what nodes the operator sees in their OVO console. For example, if an operator is responsible for all the mail servers but not the database servers in the management domain, they will only see messages related to events coming from the mail servers. The next section provides a closer look at configuring a new OVO operator using a profile.

The profile is a method to configure an environment that includes all the attributes that an operator needs to perform their tasks. The profile includes the applications that appear on the desktop, the message group, and node groups. If there are responsibilities necessary in addition to those in a profile, they should be selected for the individual requirement of the specific operator account.

The introduction of Smart Plug-Ins (SPIs) includes appropriate operator profiles for managing the environment to which the SPI configuration is assigned. An example of how to assign a profile to an operator is shown in steps 1-8. Fig 13-16 shows the OS-SPI profile.

Figure 13-16. OS-SPI and Administrator profiles.

In the operator's GUI, OVO operations console is a primary tool for resolving problems that have been identified and presented in the message browser. After the decision to further investigate a problem is made, the operator should not have to leave the console to do so. Tools are built into the operator's console to help isolate and resolve problems. In the operator's GUI, the tools are provided in the Application Desktop, as shown in Figure 13-19.

Figure 13-19. Application Bank.

The OVO Administrator has "all" applications available for direct use or for assignment to operators in the Application Bank. This resource area contains symbols that represent categories of tools that are readily available for use. The tools are represented by symbols arranged in a hierarchy starting with a top-level represented by oval shaped symbols, called application groups. If you double-click on the icon, you'll find that the second level contains specific tools for that application group category. The top level of the Application Bank contains square-shaped symbols that are executable. Drag and drop the node onto the application to initialize the program. The Application Bank's oval-shaped symbols represent Application Groups, a collection of applications. Double-click with the mouse on the application group icon to move to the second level of the hierarchy.

The symbols at the second level could represent additional Application Groups within this category if the symbol is oval. There are also square icons, which are ready for use and only require a drag/drop operation, as previously described.

The applications icons are embedded with program instructions that execute programs on the specific node or on the management server. For example, to check the status of a node, drag and drop a managed node symbol from the Node Bank onto the square symbol in the Application Bank called ITO Status. This task executes the command opcragt –status on the OVO server and returns the results to the operator console in a separate window.

Customized application techniques are covered in more detail in the User Guide.

Figure 13-20. Application Group.

The primary tasks performed by the operator include following troubleshooting procedures to resolve the problems reported in the message browser. The operators accomplish the problem-solving tasks with OVO tools found inside the operator's console. The problem-solving tasks are outlined here for reference. There are two operator user interfaces, Motif and Java. The two desktops provide the same basic functionality; this is covered in more detail later in this section. However, some of the key differences between the two should help you make decisions on which is right for your operations environment. Table 13-6 is a comparison of some key differences between the Motif and Java user interfaces.

The operator's Motif desktop at login, as shown in Figure 13-21, contains five primary windows, Root, Managed Nodes, Message Groups, Application Desktop and Message Browser.

Figure 13-21. OpenView Operator Motif console.

The Java Console contains a list (on the left pane) of the operators managed nodes, message groups, applications, and services (if configured). (Refer to the OpenView Operator Java Users Guide for more information). Figure 13-22 is an example of the Operator Java User Interface.

Figure 13-22. OpenView operator Java user interface.

The administrator is responsible for defining the customized environment for each operator. The operator configuration is controlled through the Motif graphical user interface by logging on as the OVO Administrator. At this time, there are no administrator functions (such as customization, configuration distribution, and so on) available through the Java console. You can also log on as opc_adm in the JAVA GUI, but you will have operational capabilities only. The administrator can define operator responsibilities based on specific skills or roles via a profile. The profile contains all the tools, applications, node groups, and message groups required by the operator. When the operator account is configured with a name, password, preferences, node hierarchy, the profile is added. Use this method to quickly configure many operators based on the roles they have within the enterprise. Every operator will not see all messages; only those that originate from the nodes which are members of the assigned Node Groups and have a Message Group assigned to the user. By limiting the scope of the messages the operator sees, we maintain focus on the important events that cause messages in the browser. This enables the operations, development, support, and other experts with the knowledge of the applications, servers, and network and services experience to own the problem until it is resolved.

The operator relies upon the tools assigned in their profile to get the job done. In some instances, operators require tools that are not included in the profile. After the application is defined in the administrators' application bank window, assign the application to the operator. Assign the operator's application desktop.

For example, if you want to assign the OV Services to one operator and not a profile, open the application bank in the operators' configuration. Open the application bank window and drag and drop the OV Service application group into the operator's application window. The next time the operator logs into the system he will see new menu items and network tools in the root window. She will also see the Internet icon in the root window.

There are many configuration tasks for the management server. After the initial installation, customize the server environment. A few of the most popular initial configuration tasks are described in this section.

Example Server Duplicate Message Suppression

Select Actions→Server→Configure. Select duplicate message suppression from the window shown in Figure 13-23.

Figure 13-23. Server duplicate message suppression.

This configures the server to display and increment a counter for duplicate messages in the message browser. If there is information that should accompany a message in the form of a note, it is referred to as an annotation. You can either discard the duplicate messages or add them as annotations to the original message.

Many tasks that you will complete using the graphical user interface are also accomplished from the command line. This is important because you might prefer to automate some tasks and perhaps write your own scripts to perform them. For example, you may want to distribute the templates or components for several nodes and with the command opcragt, which is easily done. Chapter 14 contains a practical use example for command line distribution.

Documented problem-solving techniques and procedures for the operators are provided with Motif and Java graphical user environments. The tasks usually fall within the following categories:

In addition to problem-solving tasks, other resources and documentation are available online to help the operator become proficient with OVO as quickly as possible. Download the Java GUI configuration components at http://<management_server>:3443/ITO_OP/. Refer to Figure 13-24.

Figure 13-24. The OpenView Java GUI includes a link to a web-based view for online help and other information.

As another example, an operator working from the Java console can select the Help menu→Contents. The following web page, shown in Figure 13-25, contains links to information about “What's New,” Operator Help, OpenView Navigator Help, and the OV Java GUI Operations Guide.

http://<management_server>: 3443/ITO_OP/help/en/ovo/html/index.htm

Figure 13-25. OV Operations and Service Navigator Documentation is available online via a user-friendly web-based view.

One of the most challenging parts of learning about the OpenView platform is remembering what file is located in which directory. The tables in this section are quick references for the binaries, configuration, log, component, and queue files that are located on the server and managed nodes (for HTTPS-based agents and DCE-RPC-based agents). The server stores the platform specific agent configuration files. Reference the Administrators Reference, Volume 2, for the agent platform-specific file locations.

The following documentation is available in PDF format (unless otherwise noted) after installation on the management server. The files are located in the directory /opt/OV/www/htdocs/ito_doc/C/manuals.

The management server is installed with a primary web page, http://<management _server>:3443/ITO/. This page contains links to many other resources as shown in Figure 13-26.

Figure 13-26. OVO Tools and Resources web page.

This section provides a list of the major steps that are accomplished by executing the ovoinstall program.

Chapter 13 covered a lot of ground and should be a helpful reference for new and experienced OVO administrators. The chapter included key concepts and best practices for a new enterprise management implementation with OpenView, and touched upon some of the details of the configuration tasks. Finally, the chapter ends with lots of resources and references, which although available from other sources are consolidated here for quick reference. The next chapter continues with more details about the components and how to deploy the OVO configuration.