ovowin_75_tsg

8/3/2019 ovowin_75_tsg

1/91

HP Internal Only

Version 4.0

Edition Date: 05/ 06/ 2005

HP OpenView

Windows Solution

TechnicalSales

Guide


2/91

Copyright 2005 Hewlett-Packard

Development Company, L.P. Page 2

Contents

Contents ...................................................................................................................................... 2

Product introduction ...................................................................................................................... 4

Purpose of this guide .................................................................................................................. 4

Product description..................................................................................................................... 5

Feature Set Overview ............................................................................................................... 13

W hats new before OVO for W indows 7.5?............................................................................... 40

Whats new with OVO for Windows 7.5?.................................................................................. 41

Target market .......................................................................................................................... 50

Deal assessment......... ....... ........ ........ ........ ........ ........ ........ ........ ........ ....... ........ ........ ........ ........ 51

Enabling technologies and their buzzwords........ ........ ....... ........ ........ ........ ........ ........ ........ ........ . 52

Competitive landscape ............................................................................................................. 55

Versions and supported platforms....... ........ ........ ........ ........ ........ ........ ........ ....... ........ ........ ........ 60

Requirements........................................................................................................................... 62

Product integrations....... ........ ........ ........ ........ ........ ........ ........ ........ ....... ........ ........ ........ ........ .... 64

Additional or related products................................................................................................... 71

Integration with other non-HP Products and SPIs.... .... .... .... .... .... .... .... ....... .... .... .... .... .... .... .... .... .... 75

Architecture................................................................................................................................ 76

Building the quotation ................................................................................................................. 76

Building Your Own Application Management Solution ........ ........ ........ ........ ........ ........ ........ ........ . 76

Scalability............................................................................................................................... 79

Performance considerations fit ........ ........ ........ ........ ........ ........ ........ ........ ....... ........ ........ ........ .... 80

Order and configuration guide.................................................................................................. 84

Information required from the customer........ ........ ........ ........ ........ ........ ....... ........ ........ ........ ........ 84

Ideal technical fit...................................................................................................................... 84

Demonstration ............................................................................................................................ 84

Quick Installation guide Reusable Engagement Packages........ ........ ........ ....... ........ ........ ........ .... 85

Manuals.................................................................................................................................. 85

Online-help ............................................................................................................................. 85

Marketing Material .................................................................................................................. 85


3/91



White papers and other technical documentation ....... ........ ........ ........ ........ ........ ........ ........ ........ . 85

HP-internal............................................................................................................................... 87

Contacts.................................................................................................................................. 87

Evaluation.................................................................................................................................. 87

Where to get the software......................................................................................................... 88

What to do (and what not to do!) .............................................................................................. 88

Typical project plan.................................................................................................................. 88

Who do you need to get it done?.............................................................................................. 88

Troubleshooting.......................................................................................................................... 88

Troubleshooting Tools........ ........ ........ ........ ........ ........ ........ ........ ....... ........ ........ ........ ........ ........ 88

Online troubleshooting tools and features ........ ........ ........ ........ ........ ....... ........ ........ ........ ........ .... 89

Product configuration tips and techniques........ ........ ........ ........ ........ ....... ........ ........ ........ ........ .... 89

Dos and Donts....................................................................................................................... 89

Training..................................................................................................................................... 89


4/91



Product introduction

Purpose of this guide

This Technical Sales Guide (TSG) is being created as a way to brief those professionals focused on presales

technical support about the capabilities, configuration, and performance considerations of HP OpenView

Operations for W indows and the available SMART-Plug-Ins (SPIs). System management concepts and

functionality are discussed.

Throughout the document we use OVO for Windows as abbreviation for the Operations for W indows solution.

OVO for Unix will be used as abbreviation for Operations for HP-UX/ Solaris.

This guide assumes that the reader has a basic understanding of network and systems management concepts

and processes.

All examples and figures contained in this document are for illustration purposes only. Refer to HP

OpenView documentation sets on the products listed above for more detailed information.

Using the Technical Sales Guide, computer professional will be able to:

Provide accurate technical information regarding solution capabilities.

Configure basic solution architecture.

Map customer requirements to technical capabilities.

Understand the product structure to prepare a quotation for the prospective customer.

Demonstrate the product solution.

Set up an evaluation of the product solution.


5/91



Product description

Managing a multi-vendor environment requires an approach that simplifies the potentially complex problems of

communication and coordination, and treats the network as a collection of cooperative, communicating

entities. OVO for W indows is based on the Manager-Agent concept. The agents role is to collect managementdata and send exceptions to the central manager. The manager provides a central repository to centrally store

these messages for access from operator consoles as well as a central location for the management

configuration. The link between the manager and the managed nodes is implemented by means of agents,

which are running on the managed nodes. The manager is split into a management server and a management

console. The product is implemented using Microsoft technologies such as Microsoft Management Console

(MMC), Windows Management Instrumentation (WMI), and the Component Object Model (COM).

OVO for W indows manages the availability and performance of the distributed systems, network elements,

and applications through policies. By configuring and deploying policies, you define which management

information should be monitored; for example the Threshold Monitoring policy defines what performance data

should be collected.

The performance monitoring is built on the capabilities of the embedded performance component (code name

CODA). This component is a dynamic data collection and logging component that, based on the instructions

from a threshold monitoring policy, collects metrics from all measurement sources: program, external, SNMP

MIB, W MI, and perflib. By default, a set of so-called Golden Metrics will always be collected. Using this

historical data enables examination of resource utilization and performance trends, the information needed to

understand how well the IT resources are performing.


6/91



Figure 1: The Big Picture

The management server provides all possible management functions that can be performed on several hundred

managed nodes. It centrally deploys policies onto all platforms and agents onto Windows 2000 and NT

systems. The management server stores messagesand policy configuration and other data to manage services

throughout the enterprise (for example, services and relationships to other services).

An intelligent agent on each managed node is responsible for the communication with the management serverand for the execution of corresponding actions on the managed nodes. The agent receives requests from the

management server to either run or stop a policy, and communicates back on an exception-basis any relevant

data or messages collected by the policy. The management server and the agents communicate using remote

procedure calls (RPC), HTTP and DCOM (package deployment only). The agent stores all its performance data

locally, based on instructions configured via a policy deployed to the managed nodes. This data can be

viewed graphically for assisting in trend analysis, regular performance reporting, and can be used in

conjunction with generating events that can be forwarded to the message browser. The agent can also work

autonomously, which means that whenever the agent cant communicate with the management server (either

the server or the network link is down) it will locally store the messages and run automatic commands. W hen

the connection to the Management Server is re-established the locally buffered messages are forwarded to the

Management Server.

Management consoles provide a graphical user interface visualizing and editing information stored

by the Management Server. From the management console you can initiate service and node discovery

and configuration, policy editing & deployment as well as access runtime data such as messages, service

maps, and performance graphs. The management console is a Microsoft Management Console (MMC)

snap-in giving the user a W indows native look and feel. The management console can be installed on


7/91



separate computers and enables multiple operators that can manage the environment from different

computers. As user roles are applied to the Windows user, each user may have a limited view and

limited capabili ties thus splitting the operator responsibi lity across the operational staff. Multiple

Management Consoles can connect concurrently to the Management Server.

Process Steps

OVO for W indows provides functionality for performing daily operational tasks and for managing and

resolving problems to guarantee the availability of the managed environment. Daily operational tasks typically

include monitoring the managed environment and responding to problems, requiring the following basic steps:

Identification -observing the environment

Notification - becoming aware of the problem

Analysis -understanding the problem and its cause and its impact on the enterprise

Solution -determining how to solve the problem

Resolution -starting an automatic or operator-initiated command to resolve the problem

Tracking - closing and documenting the problem

For automating these fundamental steps and linking events, recover commands and instructions OVO for

Windows provides the four process steps: collecting, processing, presenting, and acting.

Figure 2: Procedural flow on how to integrate management information into OVO for W indows

Collecting gathers the status information from the managed environment. OVO for W indows Intelligent Agents

provide real-time monitoring of events that occur within the managed environment and collects performance

Managed Objects

1. Collection

2. Processing

4. Action3. Presentation

Automatic

Actions


8/91



information from services and nodes. Events can originate from various managed objects like networks, web

stores, systems, databases, monitored applications, or IP devices.

OVO for W indows supports the following event sources, which are essential in commercial IT environments:

Perflib

WMI Store

Windows Event Logfiles

System Logfiles

External Messages (opcmsg command and API)

SNMP Events

Custom metrics made available by scripts or external programs

Another important source of information is the performance data, like Perflib metrics, W MI etc., that OVO for

Windows can be configured to collect. Collecting performance data continuously on managed nodes can give

valuable information for use in trend analysis and forecasting, as well as allowing you to analyze performance

bottlenecks and improve service levels for users.

Performance data is usually available in abundance; the goal is to reduce this data to important information.

OVO for W indows assists you in determining what key performance data are relevant, it provides the

capabilities to monitor several key metrics and thresholds on these key metrics.

An example of a typical event, in this case a customer variable, is a monitored system parameter, which

exceeds its defined threshold. N ot all messages sources generate events in the same fashion. OVO for

Windows provides a standardized message format for all event sources. In general, the event sources

normalize outside-world data received in their particular format into a common format for further processing

and presentation to operators.

On the agent level, OVO for W indows uses filters and thresholds to assure that only relevant information is

forwarded to the central system, reducing network traffic and providing the scalability required to manage

large distributed environments. OVO for W indows follows the principle of management by exception, that is, it

generates messages only when there is trouble. Automatic commands can be configured to start when a

defined event occurs and bring the status of the managed object back to normal without any manualintervention. The configuration of automatic commands is easily made, from a central point, without any

programming.

The OVO for W indows agent is directed by a set of management policies or short policies. The policies hold

configuration data for the OVO for W indows agent and are stored centrally on the OVO for W indows

management server. Policies maybe created, modified and deployed to the agent systems. Policies direct the

agent software what sources are monitored and what events a generated. Each policy in itself may have


9/91



different rules to instruct the agent in detail how to react to a certain state of the managed node. An example

policy would be a W indows 2000 Application Log Policy monitoring MS Exchange 2000 Server entries in the

Windows application event log. An example rule within this policy would be to generally forward all critical

MS Exchange log entries to the management server. If a MS Exchange event meets the condition of a rule, a

set of customizable actions can be configured. An action is usually a message that is forwarded to the

management server and optional an automatic or operator-initiated command.

Processing selects important or critical status information and makes it available on the central system in a

consolidated fashion.

All relevant information passing from OVO for W indows intelligent agents to the central management server is

consolidated and converted into a standard OVO for W indows message format. Although the information is

extracted from different sources, OVO for Windows assures consistent presentation of information. Regardless

of the information's source, operators respond using a consistent, intuitive process.

Unusual conditions (events) will result in a notification of the operator through the Management Console, OVO

for Windows's MMC graphical user interface.

Additional message management functionality includes message classification and filtering, and assuring the

presentation of important information. Positive and negative filtering is provided. Positive filters forward events

that match a specified pattern for presentation to the operator or start an automatic command. Negative filters

suppress events matching specified patterns.

OVO for W indows provides the capability to locally log forwarded or suppressed events that matched a rule

as well as events that didnt match any rules. OVO for W indows classifies events not matching any filter as

"unmatched". Unmatched messages often occur with new or undefined sources. Unmatched messages can be

analyzed to configure appropriate positive or negative filters for smooth event handling if they are likely to

appear again. Although not required, a good setup of OVO for Windows message sources includes policies

and rules for all events. This ensures that on any incoming event the appropriate action will be performed,

regardless of the event source.

Proactive warning to prevent problems in advance is possible with OVO for W indows by configuring OVO for

Windows to watch for specific events and collect and analyze performance data, which indicate that a

problem is very likely to occur within a short time. An example would be to send a notification message if disc

space has increased with more than 10% in the last hour. Early warning of potential problems enable

operators to perform pro-active problem management by fixing potential problems before end-user services are

affected.

OVO for Windows also allows messages to be combined into logically related groups. A message group

combines messages from multiple, related sources, and allows sorting them into certain categories.

Presentation provides different views of the problems that occurred in the managed environment. The

messages, nodes and services are colored depending on their severity.


10/91



The operators working environment is the Management Console, which gives a view of the service

environment from a business, organizational, or system perspective, depending on how it is defined by the

user. The operator manages the service components by using the various views in the OVO for W indows

console tree and details pane in MMC. The console tree offers a hierarchical, visual representation of the

nodes, services and tools. The detail pane hosts the list view, message browser view, and map view. The

message browser is the view of all the active messages received at the console. The map view presents a two-dimensional, graphical view of the entire service or node hierarchy, including any subsystems or sub services.

The service map allows the operator to drill down to the root cause of a problem and to obtain information on

how the services within the managed environment are connected and what other services and entities might

also be affected.

Figure 3: Example Service Map View

The map views root cause and impacted services options are excellent tools for a quick identification of the

problem and its impact, which helps the operator to make the right prioritization decision among the

problems, as it is possible to easily see which problem impacts the service environment the most.


11/91



Another example shows the OVO for W indows performance grapher:

Figure 4: Example OVO for W indows Performance Grapher

The grapher is launched either within the context of a service or node, or underneath new grapher items in the

MMC console. The grapher connects to the embedded performance component on the agent via a http

connection. The system has a pre-defined set of graphs included out of the box (e.g. CPU, disk, network

usage), more graphs are part of the SPI installations. New graphs can be created. The new grapher in OVO

for W indows 7.0 replaces the PerfView grapher technology used in former versions of the platform. Graphs

can be used in operator initiated actions.

OVO for W indows uses colors to indicate the severity of the messages as well as the status of services, node

groups and nodes. HP OpenView's color coding scheme is based on the OSI telecom standard.

Figure 5: HP OpenView's event color coding


12/91



The operators use the message browser as a starting point to review and respond to each message. Here they

find all related message information including the availability and status of all pre-configured automatic

commands. The operator can also add personal annotations to messages to document what steps were taken

and to use this information at a later stage to streamline the problem resolving process.

Furthermore, the OVO for W indows service view provides an overall view of the IT environment and allows

users to analyze the impact on the overall business services by providing end-to-end service oriented business

views.

Acting performs planned activities and automatic and operator-initiated commands, stores information and logs

the actions (audit).

When operators use OVO for W indows to manage the nodes in the network, there will be many repetitive

tasks, which they have to carry out. A set of standard tools comes with OVO for W indows for the most

common tasks; it is also possible for the administrator to define custom tools.

OVO for W indows provides the concept of Tools: Operators can perform actions on one or multiple remote

nodes without the need to physically log on. The OVO Administrator can define the user context and password

in which the tool is launched, without making this information available to the operator.

It is possible to create a broad range of tools for the daily operating tasks such as checking the available disk

space on a node before running or installing a program, or starting management applications, verify if all

processes (services) are running. The tools may be of five different types; executable commands, Java Script,

VB Script, W indows Scripting Host Script or W eb URL.

These tools can also be associated with a service or a node to provide context when the tool is launched and

to let the operator know what tools are available when operating on a particular service or node.

The OVO for W indows administrator can associate commands with messages to resolve problems. A

command can be the execution of a VB script (Windows platform only), a Unix shell script, a program or anapplication There are two types of commands; each message can be associated with one command of each

type:

Automatic commands are commands started without operator intervention upon creation of an OVO for

Windows message. If local automatic commands are configured, these commands are immediately triggered

by the OVO for W indows intelligent agent, which is hosted on the managed node. This is possible even if the

central OVO for W indows management server is not running, or if the network is down. The agent will in this


13/91



case log the message and performance data on the managed node, and continue to run automatic commands

as specified by the policy. W hen the connection to the management server is re-established, the locally

buffered messages are forwarded to the management server. An example of an automatic command could be

the deletion of all temporary files on a hard disk if the space exceeds a pre-defined threshold.

Operator-initiated commands are commands predefined by the administrator, and started by the operator inresponse to a message that indicates a problem. An example of an operator-initiated command might be to

restart a shutdown application on the operators request, or to start an analysis application, like the

Performance Grapher for performance analysis, on a system reporting a performance bottleneck.

Feature Set Overview

OVO for Window s Management Console

The OVO for Windows console is composed of a set of views constructing a management environment for the

operator. A view is a virtual representation of some aspect of your IT environment. Views allow operatorspinpointing important information. Views can be as broad as viewing the entire enterprise IT infrastructure, or

as specific as seeing only the nodes that are causing a particular service to fail. Here are examples of the types

of views OVO for Windows provides:

End-to-end (top down view) of a service or segments of the service chain.

View of impacted services (if one of the dependent sub services failed).

Ability to view the root cause of a problem, i.e. the sub services that impact higher-level services.

View all messages or filtered views of messages for a managed node, a group of nodes, or a service.

View of tools (the entire tool tree, sub-tree or the tools associated with a service or node)

Administrative views on managed nodes, e.g. installed agent functionality and policies.

The following illustrations show the basic elements of the OVO for W indows management console.

Figure 6: OVO for W indows Management Console


14/91



You can manage a service as a whole, or you can manage the services components by using various views in

the OVO for W indows console tree and details pane in MMC. The Services folder in the console tree is a

hierarchical, visual representation of a service, such as printing, e-mail or Internet connection, and itssupporting software components. The managed nodes folder is a visual representation of the managed nodes.

The details pane on the right side hosts the list view, message browser view, and map view. You can also start

the Performance Grapher to graph system, network, or application data.

The OVO for W indows service console allows you to:

Focus on services that impact your business the most using the map view.

Display information in your preferred format such as the map view or list view.

Sort messages in the order you want, according to various criteria, in the message browser.

Display all managed nodes the management server has "discovered," and all nodes that are being

managed in OVO for W indows.

View which policies are installed on a managed node.

Display the tools associated with a service or node.


15/91



Message Brow ser View

The message browser is a view of all the active messages received at the console for all nodes and services. It

is possible to open a message browser at each level of the node and service tree, to see the messages only for

the selected node or service. Additional the message browser allows the operator to filter on a set of attributes,

e.g. the message severity or a pattern in the message text etc.

Figure 7: OVO for W indows Message Browser

Using the message browser, you can:

Evaluate all current messages according to color-coded status

Read message text

Review instructions and review and add annotations to a message

Determine impacted services

Start operator-initiated commands

Review status of operator-initiated commands

You can simplify the message display by showing only messages from systems or services of special

interest to you. The browser headline displays the message attributes in a condensed format you can

interpret quickly.

Service M ap

The service map is an integral part of OVO for W indows and helps IT operators to easily focus on the business

services. The overall view of the IT environment that it provides allows operators to analyze an event in terms ofimpact on the overall business services. Operators can see at glance the operational status of the service

environment. The service view also provides a way to describe the dependencies between service, hosts (incl.

the associated hardware) and processes running.

Below is an example of a service map. The Map View shows the entire service hierarchy, the type of

relationships the service has with other components/ services, and nodes supporting that service. You can also


16/91



view just a specific sub service or node. The services are colored to reflect their status, just as with messages.

For each service you can open a message browser containing the messages related to the service.

The service map view features a Hyperbolic Tree that enables navigating in larger service maps by

automatically centering and enlarging a highlighted service icon. While navigating through the service tree, the

Hyperbolic Tree unfolds depended or related sub services.

Figure 8: OVO for W indows Management Console: Service Map View

To manage the services more efficiently, the Service Console comes with the following features:

A root cause view, which displays all the services that have led to the current status of the service. This

helps the operator to quickly identify the core problem within the service hierarchy and the related

messages in the message browser.

An impacted services view, which identifies at a glance the higher-level services that are affected by a

problem in a certain sub service.

Service specific tools can be defined for each service in the hierarchy by the OVO for W indows

administrator. The tools can be run on a service from the launch tool menu.


17/91



Service configuration, which is made easy through the service configuration editor.

Within the service hierarchy each service has a Service ID. OVO for W indows messages have a reference to

this Service ID to feed real-time data into the service map. The state of a parent service is defined through status

calculation and status propagation from its child services and/ or through messages for the service itself.

Service hierarchies can be based on any kind of relationship such as on applications, geography,

organizations and infrastructure. Operators can have different entry points in this service hierarchy so that each

operator can focus on the services in his particular area of expertise and responsibility.

When a message with a specific service ID is received, the status of the entire service will be evaluated

according to the status calculation rules that have been established for the particular service, which is affected.

Service Conf igur ation

The service editor allows you defining how services in the Service Hierarchy are dependent on each other, and

allows you defining rules that evaluate the severity based on the state of the contributing services. Although youcan use the service editor to create an entire service hierarchy, SMART Plug-Ins -or short SPIs - (from HP or

other vendors) provide the capability of inserting a basic hierarchy, which you can then fine-tune and connect

to higher levels within your service hierarchy. SPIs such as the SMART Plug-In for W indows, contain policies

and an auto-discovery feature that automatically discovers managed nodes and processes running on the

node, assign and deploy automatically matching policies, and create a basic service hierarchy. The discovered

services hierarchy then can be modified by using the service editor to match the requirements for your

environment. You can also build on the SPI service hierarchy, using it as a building block in a larger hierarchy

that you create.

NOTE: The auto-discovery, auto-assignment of policies and the automatic creation of the service hierarchy are

features provided by SMART Plug-Ins.

If you plan to create your own service hierarchy from scratch, or do a major extension of the existing map, it is

helpful to draft your service hierarchy before you start using the service editor. When planning your service

hierarchy, keep the following questions in mind:

Which IT services do you provide? Which ones do you want to monitor?

Who are the customers of your services? Which organizations, departments, or lines of

business are important to you?

How can you logically group the services you provide? Which services are used by other

services?

How do problems in one service affect another? Which status propagation rule should you

apply?

How do you evaluate the severity of a problem? W hich status calculation rule should you

apply?

Which service actions are appropriate?


18/91



Determination of status severity depends on the rules set up in the service configuration editor. For example, if a

service is comprised of five other services, each of which receives a "warning" message, what should the final

status be? Warning? Critical?

There are different approaches you can use to determine the severity of a service:

Status Calcula tion defines how to compute the severity status of a service from the status

severity levels its sub services propagate. Basically, the services own status is calculated from

the status of all the contributing sub services, and messages affecting the service itself.

Status Prop ag ation defines whether a sub service is more or less important compared to

other sub services. It describes how the status of a child service is interpreted by the parent

service.

Severity calculation must often account for many variables, it is recommended to look at existing rules provided

by SPIs for examples of status calculation and propagation.

How events and messages map to serv ices

In previous chapters, we explained that events trigger messages, and that messages provide status information

on a managed node in the OVO for W indows console. Since services are high-level abstractions that must be

defined within the IT environment, it is necessary to establish a link between individual services, service

hierarchies, and incoming messages. The management server maps a message to a service by its service id. To

ensure correct mapping of messages to service(s), you must use a unique service id for each service and use it

consistently in the service editor and in the configuration of the policies outgoing messages.

Ex am ple of M anag ing a Business Service

THE SCENARIO: You want one operator to monitor your accounting service, which includes general ledger,

accounts payable, and accounts receivable software programs as well as databases across several managed

nodes, as shown below: Here, we assume that you will use default values (for example, propagation rules,

messages) for the services and policies you establish.

1.Draw a simple diagram of the different elements you want to monitor for the accounting service, and

determine the dependencies. An example diagram is shown. The dotted lines indicate dependencies, which

you establish later.

Figure 9: Service View dependencies examples


19/91



2.Make the nodes where the accounting applications elements (databases, programs) are located managed

nodes, launch the NT Service Discovery if the node is a Windows node to build the System Infrastructure

services, and the Windows OS policies will be deployed automatically.

3.Add the component services, which are the building blocks of your accounting service model. For example,

you would add the General Ledger component, and indicate that it is hosted on managed node A.

Create dependencies between services. For example the databases are more than likely a component of

another service (e.g. Oracle or SQL Server), and thus the accounting services would be dependent upon thesedatabase services. You may also want to build dependencies upon different System Infrastructure services to

identify different types of problems.

Create additional policies to monitor and associate messages with the services. (See online help for

information on message attributes).

The Operator tasks:

1. If one of the monitored services changes state to something other than normal, perform a root

cause analysis to determine which service caused the abnormal state2. If the service is in the operators control, retrieve the active messages and select the message that

caused the problem

3. Own the message

4. You may want to do an impact analysis to determine the effect this component has on other

services in the enterprise (this is helpful in prioritizing multiple problems)


20/91



5. Review the message and instruction texts to get additional information about the problem

6. Perform an operator-initiated action if one has been established by the administrator. This may

resolve the problem or give additional information to help resolve the problem

7. Annotate the message to indicate how the problem was solved

8. Acknowledge the message so it moves to the Acknowledged Messages browser

3.5 Collecting Mana gement Inform ation

On each managed node, OVO for Windows establishes various message collection services (OVO for

Windows intelligent agent) to gather exactly the management information the operators need to get their job

done. These services extract and initially classify the information by assigning values to the message attributes

severity, service name, application name, message group, object name and managed node name, and others.

Messages can be captured from various sources described below, regardless of whether the event is related to

network, system or applications specific incidents. If the original information text is cryptic (that is in binary

format) or a number (for instance an SNMP object identifier), it is possible to map the original information to a

readable message. Parts of the original text (for instance the error number) can be used in the message, which

is forwarded to the operator.

Windows Security, Application and System events are written to the Windows Event Log and can be captured

by the OVO for W indows Windows Event Log policy. Some Windows Event Log messages have pre-defined

attributes provided by the application sending the message. These attributes are automatically mapped to the

OVO for W indows message.

System/ Application Logfiles contain events written by applications to communicate their status and error

information. The Logfile Entry policy analyzes logfiles, extracting the information and assigning the configuredattribute values to all messages extracted from this source. Original logfile entries can be modified with a

powerful pattern matching language (similar to regular expressions) to build new more meaningful message

text. Preprocessing tasks performed by the OVO for W indows intelligent agent locally on the managed node

can be defined for the logfile, for example, to convert binary logfiles to an ASCII representation.

The OVO for Windows Message Application Programming Interface (API) and Command Line Interface (CLI)

allow applications to directly feed status and/ or event information into OVO for Windows on the managed

node via the OVO for W indows Message Interface. Typically, the API or CLI will be used within new

applications or user defined scripts to deliver the information most efficiently to the management server.

Monitoring Services

Sophisticated monitoring is key to providing exception-based and pro-active problem resolution. The OVO for

Windows agent provides distributed monitoring capabilities. With the Measurement Threshold policy

functionality it is possible to define threshold conditions, which the monitored values periodically are checked

against. If the thresholding condition is met, a message is generated to inform the responsible OVO for

Windows operator. It is possible to define several threshold values for the same source, for example to


21/91



configure the policy to send a warning message when disk space of 90% and a critical message when it is

95% full.

Monitoring values can be gathered from any program or user defined script, Perflib, the embedded

performance agent, as well as retrieved from SNMP Management Information Bases.

Custom monitoring applications can make use of the monitoring API and CLI to feed their values directly into

OVO for W indows. They can either be triggered by OVO for W indows to deliver their values or the

information is asynchronously sent from the monitor.

Minimum or maximum threshold values as well as Visual Basic Scripting expressions can be used on the NT

managed node to combine multiple metrics in a condition or to calculate values from multiple metrics and

threshold the results.

The use of VBScripting allows the user to do advanced calculations of a threshold or multiple thresholds, for

example calculating a threshold value for multiple monitor sources, such as a threshold for the total free disc

space for all discs (C, D, and E) on a computer. Another example is to create a critical alarm if the usedprocessor time is greater than 90% and the processor queue length is greater than 3.

Messages generated by OVO for W indowss monitoring service consist of the message attributes and the

definable message text, which can include actual monitoring values. The messages are treated identically to

those of other sources, so that logging options and message bound actions can be applied.

Figure 10: Example for objects monitored by default

M onitored Object Threshold Reset Va lue Monitor ing

Value

CPU utilization 90% 85% 5 min.

ProcessorQueueLength 3 2 5 min.

3.6 Using Policies to M anag e Systems

The concept of OVO for W indows management policies allows you to centrally define the rules on how to

monitor objects throughout your IT environment. For example, the W indows Event Log policies allow you to

intercept Windows Event Log messages matching defined conditions based on the rules created or modified by

the OVO for W indows administrator. Policies then can be distributed to one or multiple managed nodes. OVO

for W indows provides versioning on policies and inventory reports for managed environments. A sample


22/91



inventory report would include the managed nodes and currently active policies along with their version

number. If a specific condition is met on a managed node, a message is generated and sent to the OVO for

Windows management server and displayed on one or more OVO for W indows console systems. This

concept allows you to:

Consolidate event messages from all computers to a central location Handle events on a priority basis (e.g. by severity)

Add annotations to a message to document steps taken

Execute operator-initiated commands

A policy is a set of rules and actions that help automate network and system administration. Using OVO for

Windows, the administrator can deploy policies to various destinations to provide consistent, automated

administration across the network.

Every policy belongs to one policy type. Each policy type has its own editor on the OVO for W indows

administrators console.

OVO for W indows is an open platform: The design of OVO for W indows allows to introduce new policy

types along with the associated policy editor and new agent or subagent functionality.

Overv iew on Policy Typ es

Logfile Entry: Evaluates (binary or text) logfi les on the node (UX and - less common on - NT), andgenerates messages that match a rule in this policy.

Open Message Interface: Intercepts messages that are externally generated by the opcmsgcommand or API call (UX and NT). It compares a message against rules defined in an Open Message

Interface Policy. Rules process the information provided in the command line or API call further, e.g.

automatic or operator-initiated commands are associated and instructions attached.

Windows Event Log: Monitors the NT Security, Application, System and other Event Log messagesand generates messages for matching entries.

SNMP Interceptor: Intercepts SNMP traps on managed node (for UX and NT) and generatesmessages for matching the rules.

WMI Source: Provides monitoring of W MI instances (e.g. application data) with a sophisticated setof rules and features (Windows only).

Scheduled Command: Runs a specified command (UX and NT) according to a specific schedule,intercepts the results and sends a message if the command was successful or not. Recently, scheduled

command policies also support execution of VB Scripts (Windows only) and Perl scripts. A number of


23/91



COM objects are available to trigger actions such as sending a message to the console or collecting a

metric in the embedded performance agent.

Serv ice Process Monitor : Added for ease-of-use, user friendly selection of services and processes to

be monitored. Implemented in the threshold monitoring policy, it uses VBScript for service monitoring

and Perl for process monitoring. New with OVO for W indows 7.5

Threshold Monitoring Policies:

Measurement Threshold: Polls different measurement sources (for example real time performance

monitoring = perflib), determines whether the values exceed configurable parameters, and sends

notification messages to the message browser. The Measurement Threshold policy has access to

various types of sources, e.g. Perflib (Windows only) or MIB variables (local or remote node). Other

sources are program/ scripts submitting opcmon values (commandline or API) and the type external that

- similar to the Open Message Interface -evaluates values submitted by an external application.

On the Windows platform the Measurement Threshold Policy can utilize scripting (via Visual Basic) for

sophisticated multi-source thresholding.

Performance Collection Policies:

Performance Collection Policies: These are implemented via Measurement Threshold policies and are

combined with thresholding. You can collect metrics based on all sources for measurement threshold

monitors. If you simply want to collect metrics, just leave the threshold tab empty.

Flex ible Ma nagem ent Policies: These are policies supporting Manager of Manager (MoM)

configurations, also named flexible management configurations. Note, only one policy of this

type is active, so the last policy deployed wins.

NodeInfo Policies: These allow central configuration and maintenance of the nodeinfo file. You canspecify attributes such as port ranges, health checking and tracing with this configuration file.

Discovery Policies: These are policies used to trigger automatic discovery of services at a given

polling interval. After the initial discovery is completed, only the deltas will be forwarded to the

management server and made available to the console users. With former versions, discovery

and synchronization was offered via the means of tools.


24/91



Figure 11: Deployment Packages

Policy Deployment

Deployment Packages contain software and intelligent agent components to be deployed on the managed

nodes. OVO for Windows has a single main agent components on the Windows platform:

OpenView Operations Agent: This includes the formerly known Enterprise Message/ Action Agent and the

embedded performance component

OpenView Operations Agent is the core component on the managed node. The three key parts are the

Message Agent, which is handling the message forwarding to the management server, the Action Agent,

which is launching automatic and operator-initiated commands, as well as tools (initiated from consoles), and

the Embedded Performance Component. The key function of the performance component is polling of metrics

in a defined time interval and storing the collected data locally on the managed node. The collected data can

then be accessed via the performance grapher or collected centrally with Reporting tools like the reporter.

Packages containManageme


25/91



In addition it consists of several subagent process managing various message sources, e.g. for Threshold

monitoring, Logfile, SNMP and W MI.

SPI packages are usually optional packages which hold additional functionality that has to be deployed to a

managed node where the SPI is installed.

NOTE: A SPI extends the base functionality of OVO for W indows. The term SPI (SMART Plug-In) is typically

used if the component is an optional add-on to the core OVO for W indows product and has to be purchased

separately (e.g. SMART Plug-In for Microsoft Exchange Server). Note, there are 3 exceptions of SPIs that

provide basic monitoring and are free of charge and part of the foundation:

SPI for web server (formerly known as passive monitoring component (PMC) for internet services

SPI for Microsoft Windows

SPI for HP-UX, Solaris, Linux, AIX and Tru64

Instrumentation packages are additional software components adding a set of executables, libraries and

configuration files to extend the capabilities of the agent. The tools located in a previously named Windows

Module Tools package are now modelled as an instrumentation package. Deployment of instrumentation

gives you the choice to pick individual components. In case you assign policies to policy categories, and you

deploy one of those policies. the corresponding instrumentation package will implicitly be deployed.

To deploy policies the administrator has two options:

Automatic deployment: Functionality provided by SPIs/ Modules that support auto-discovery and auto-

deployment (Windows only). Auto-deployment might not be desired in large IT environments

(scalability/ bandwidth considerations)

Manual deployment: The administrator manually selects and deploys the policies to managed nodes.

On deploying policies to a managed node, the appropriate agent package - if not already present on the

managed node - will automatically be deployed along with the policy. Each policy has a dependency to one

or more agent packages.

A new feature is synchronizing the nodes policy inventory with the policy inventory that exists on the

management server. This is useful, e.g. if the node has a pre-installed agent. Then, the synchronization feature

will detect the existence of this agent, will update the servers policy inventory. Synchronization is implicitly

called if you want to deploy a policy, or if you explicitly want to synchronize.

Policy Versioning

OVO for Windows ships a set of pre-configured (out-of-the-box) policies which cover the most common

management tasks. These policies can be modified or used as templates for custom policies to meet your

specific needs. You can also create a new, blank policy from a chosen policy type. The policy editors provide


26/91



support and online help to support you in creating your own custom policy. Every time a policy is modified, the

minor version number is automatically increased.

OVO for W indows has two policy management areas:

The first policy management area is similar to a file/ directory structure: Policies and policy folders can becreated, policies can be grouped in any form. Examples are by node or group of nodes, by platform type, by

logical function in the IT environment, or by application hosted on the managed node. This area is the typical

workplace for the administrator.

In the second area the policies are grouped by type, i.e. each folder holds all available policies of a given

type. These folders do not allow substructures. The Policies Grouped by Type area is usually used for a

reference list of all available policies, administrators may copy a policy from this area to the above mentioned

work area to perform customizations. This area also provides access to previous version of a given policy.

To obtain an overview over managed nodes and the installed and active policies, as well as an overview over

the configured services and the used propagation rules, OVO for W indows offers a reporting in HTML format.The reporting tools are available via: Tools->Reporting-> Inventory & Service Reporting.

Configuration store and transfer: OVO for W indows uses a RDBMS to store and retrieve policies, including all

versions of policies. To move or transfer configuration data between OVO for W indows management server a

download and upload tool is available.

Policy Groups

With several hundred policies deployed to a large number of managed nodes, keeping track of the installed

policy is a challenging task.

Use OVO for W indows features for keeping track of your developed and deployed policies. The versioning

feature and the ability to create your own hierarchy of policy groups assist you in keeping a good overview.

A policy group is a logical group, similar to a file system directory. A policy copied into a folder will remain

the same until it is deleted or replaced by a policy of a higher version.

The following shows some ideas of how to group policies:

By platform type (Windows 2000, N T, HP-UX, Solaris)

Groups for policy development and production

By location, site

By application, e.g. MS Exchange server, MS SQL server

By nodes or node groups

Policy groups also offer the following advantages:

Only policies that are members of policy groups can be exported / downloaded


27/91



Policy groups can be assigned to node groups. As new nodes are added to node groups, all

policies of the assigned policy groups will be deployed. The implicit deployment can be

disabled.

Policy Catego ries

Policy categories is a means of grouping policies and adding a some semantics to them:

If policies of a certain policy category will be deployed, and an instrumentation directory

with the same name exists, policy management will implicitly deploy corresponding contents

of the instrumentation directory

Policy categories can be used with user roles. A role can be configured to allow permissions on policies only

for a certain set of policy categories

3.7 Message Processing

Agents monitor managed nodes for specific events depending on the policies installed on the managed node.The Event/ Message policy types can generate a message or an action in response to an event. For example,

monitoring and responding to SNMP events requires an SNMP Interceptor policy to be deployed to that

managed node. For each event source the OVO for W indows administrator sets up one or more policies with

positive and negative filters to accept important or suppress irrelevant events.

When an event occurs, the agent checks if the event matches any of the rules defined for the policy. The rule

configuration defines specific event attributes including the text pattern the event should match against, and can

be fine-tuned for each managed node and information source. When an event matches all defined attributes, it

is qualified for further processing for example forward a specific message to the management server, or start

local automatic commands immediately.

The processing of rules in a policy is top down; the event is sequentially processed against the rules. The first

rule matching generates the message, and the processing is stopped after the first match.

The order of rules is important: The top down processing order requires the more special rules to be processed

before more generic rule.

Example: A disk space policies contains 3 rules, the rules are as follows:

Critical if disk is used over 95%

Major if disk is used over 90%

Warning if disk is used over 70%

To implement this correctly, the order has to be 1st rule critical, 2nd rule major, 3rd rule Warning. Note that if

the Warning rule would be the first rule, the result would be a Warning condition on any disk space usage

over 70% even if it were 99%. In this case the more critical rules would never be reached since the Warning

rule will already match.


28/91



Suppress Rules: OVO for Windows also offers the concept of suppressing rules. At the first glance a

suppressing rules seem equal a rule that just doesn't match, i.e. just leave a matching rule out. Why do we

need suppressing rules?

Following example of an advanced disk space policy will provide an example for a suppress rule:

Disk "C:" critical if over 80% used, no events if below 80%

All disks critical if over 95% used

All disks major if over 90% used

All disks Warning if over 70% used

Assuming now that "C:" disk is used 75%, this would not match the first rule -since it is below 80%, but would

be matched by the generic "all disks warning over 70%". However this is not desired, since the all events for

"C:" below 80% should be suppressed.

To accomplish this insert a suppressing rule

Disk "C:" critical if over 80% used, no events if below 80%

Suppress all other Disk "C:" conditions

All disks critical if over 95% used

All disks major if over 90% used

All disks Warning if over 70% used

Another usage for the suppress rules is within policies that have a large number of rules, e.g. the SNMP policy.

The suppress rule here can be used to improve the performance: If the SNMP policy is processing only a

specific pattern in the OID, all events that don't have this pattern can be suppressed before all the otherconditions are being processed and thus saving processing time.

Unmatched events: Several policy types offer the option to create an event if it does not meet any of the defined

matches or suppress conditions. There are 3 options what to do with an unmatched event: Forward it as a

regular event to the active message browser, forward it directly to the acknowledged message browser, or

ignore the message. The option to forward is usually use in the development stage of a policy. The

administrator here can see what events are generated by a message source and to create a matching rule for

events of interest. It is usually best practice to provide a rule for all-important events and turn on the "ignore

unmatched" switch. For some policy types that receive the events from an external source, e.g. the Open

Message Interface Policy, is might still be useful to have unmatched events forwarded to the active message

browser.

Local logging of events is provided. You can define which events, if any, should be logged on the managed

node from which they originated, for example by choosing to log events that match a rule and trigger a

message or are ignored or to log events that do not match any rules in the policy.


29/91



Message buffering on the managed nodes will be activated by OVO for W indows if the management server is

not reachable. Buffering continues until the connection can be re-established. Local automatic commands are

still run even if the connection to the management server is down.

Message specific instruction texts can be linked in OVO for W indows to each message. Specific Instruction text

may be attached to each rule within a policy, or generally to the policy. They may contain addition instructionsor help for the operator of what has happened and how to best resolve the problem.

Message specific annotations can be added to each message. An operator usually adds an annotation to a

message to inform other operators or the administrator about which actions he has taken on the message. All

annotations are stored in the central repository. Automatic and operator-initiated commands can also be

configured to add an annotation to the message if completion was successful and the results. In addition the

annotation shows which operator executed the command, along with start/ stop time. In case of a command

failure an annotation will always be written.

The Measurement Threshold Policy features 3 levels of messages, each with individual text and associated

commands. The Start message is generated if the threshold is violated for the first time, the Continue message isgenerated if the threshold is still violated in the 2nd and all subsequent polling intervals. An End message can

be configured if the threshold was at least once violated and is now back to normal. To each of these

messages a Message Key can be associated and can be referenced by other message to automatically

acknowledge these messages. E.g. an End message can automatically acknowledge all Start and Continue

message from the same message source, the messages can be correlated.

Some message sources might generate a lot of duplicated messages (e.g. SNMP traps). These messages may

fill the Message Browser and don't contain additional of information, and may therefore not desired. Several

policy types provide a way to suppress duplicate messages. The suppression of duplicates of duplicate

messages uses either a time interval, for instance suppressing all events occurring more frequently than each 30

seconds for no longer than 5 minutes, or a counter, for instance accept each 5 th event. It is also possible to

combine the two methods.

Forwarding messages to external services such as trouble ticket systems is possible by configuring a WMI

policy and setting up an automatic command using VB scripting to feed the message information into the

trouble ticket interface. For further details, see a corresponding white paper.

3.8 Performance Monitoring on W indow s

The performance and availability management is based on the same concept of using policies to define which

data to monitor and collect. The performance data is stored on the managed node and provides a near real-time status as well as an historical view on the service infrastructure.

The performance monitoring is built on the capabilities of the embedded performance component. This is a

data collection and logging component. Deploying Threshold Monitoring policies to Windows managed nodes

start the collection of comprehensive resource and performance data (Perflib, WMI, etc.) from applications,

networks, and operating systems.


30/91



You can manage the performance data by enabling further metrics to be collected. You do this with the

help of threshold monitoring policies. If you dont want to collect any metrics you may stop the

embedded performance agent via the opcagt command, that allows to stop individual subagents:

opcagt stop id .

The collection metrics can be accessed via the advanced thresholding monitor or graphed with thePerformance Grapher that can be started from the OVO for W indows console

Using the historical performance data, the Performance Grapher enables examination and diagnosis of

resource utilization and performance trends. With this understanding bottlenecks in the IT infrastructure can be

discovered and eliminated.

OVO for W indows delivers a standard measurement collection, collecting the golden metrics. This collection is

available cross platform and will offer a good out-of-the-box solution for most users. For advanced users

threshold monitoring policies can be used to enable further collections.

Alarming is configured with the Measurement Thresholding policy:

The basic Measurement Threshold is a set of rules for typically one source (e.g. a single metric). This single

source may have additional attributes attached that can be used with the filter, however the source submits only

a single value.

An example for a single source would be mentioned "Free Disk Space" policy, it submits a single value (free

space in bytes) and may attach attributes such as the disk identifier (e.g. "C" or "D") if multiple instances are

available on the managed node.

The advanced features of the Measurement Thresholding policy make it possible to create advanced threshold

conditions for multiple sources, i.e. calculate/ correlate a threshold condition from multiple sources within thesame policy. The single fixed threshold condition from the basic threshold can be extended to multiple sources

within the same context (policy) and to define the threshold conditions programmatically including multiple

sources (VBScript or Perl script based).

These advanced thresholding capabilities provide a very flexible and powerful set of tools to address even

complex monitoring tasks.

How to use ARM w ith OVO for W indow s?

Management of ARM instrumented applications is only possible with the HP OpenView Performance Agent

(formerly: Measureware agent). Note, you also need the HP OpenView Performance Manager in order to view

the graphs based on data collected with the HP OV Performance Agent.

Figure 12: OVO Performance Collection overview


31/91



Description of how OVO for W indows collects and processes performance data

1 The OVO for Windows central management server (accessed via a local or

remote console) is the starting point, all policies are centrally stored and

administered here.

2 OVO for Windows monitoring policies are created and modified using the

threshold monitoring policy editor.

3 The OVO for W indows administrator assigns policies to managed node and

deploys OVO for W indows components, both policies and packages.

4 As soon as the common agent, the OpenView Operations Agent is deployed,

the embedded performance component will start collecting the golden metrics.

As new threshold monitoring policies are deployed that enable collections, the

performance component will increase the number metrics collected.

5 The metrics are sampled and stored at regular intervals to create a historical

view over time. The historical data can be used to examine resource


32/91



utilization, performance trends, and capacity planning. (See step 10.)

6 When specified thresholds are exceeded, the Measurement Threshold policy

instructs the agent to create a message and send it to the management

server.

7 The management server forwards the message to all management consoles.8 The message is received, and operators view it in the active message

browser on the management consoles.

9 The message contains information and optional operator-initiated commands

to evaluate performance issues. These operator-initiated commands include

launching of the performance grapher.

10 Operators can use the performance grapher to graph and analyze the

performance data, (the historical data that was collected during the time the

threshold violation occurred.)

Perform ance Monitor ing on UNIX Systems

Performance management of HP-UX and other UNIX systems is possible from OVO for W indows if the

performance sub agent (=Coda) is explicitly deployed. This performance data from UNIX systems can also be

accessed using the performance grapher. Alarming is based on the definitions in corresponding threshold

monitoring policies.

In addition the HP OpenView Performance Agent (formerly: Measureware) is offered. This gathers performance

statistics directly from the UNIX kernel into circular, configurable log files. The correlation of data from the

different logfiles is done automatically by the HP OpenView performance agent processes running on the Unixsystem. This performance data can not be accessed using the built-in performance grapher you need to use

the HP OpenView Performance Manager to access data from this agent. The OVO for W indows OpenView

Performance Manager is available shortly after release of OVO for W indows 7.0. Alarming on UX systems

based on the HP OpenView Performance Agent can be done through the alarmdef file.

3.9 The Performance Grapher

OVO for W indows provides a graphical tool to analyze resource utilization information collected by OVO for

Windows managed nodes. The Performance Grapher can, for example, be used to analyze and document

long-term IT resource utilization data from one central location.

Figure 13: OVO Performance Grapher


33/91



The Performance Grapher provides real time and history data, for example, on:

Health on transactions

CPU performance

Memory usage

Network performance

3.10 User Roles

Let me start by having a look at tasks of typical administrators:

Plan the product implementation

Install and configure the product

Maintain the product configuration

Develop and deploy policies and agents as necessary

Create tools

Create and modify service hierarchy

Tasks of typical operators include the following:

Monitor the status of a service or system using default or custom views


34/91



Troubleshoot the problem or isolate it using the appropriate combination of filters to research

the problem or the appropriate view to drill down to it

Resolve the problem by using tools (an application or program that is not associated with the

event) or a pre-configured command (script, application)

Draw performance graphs regularly to verify system performance trends, etc.

Detect services that have problems or are unavailable, determine services that cause the

problem and to find the related messages

Review messages to monitor the health of the managed systems

Select from a variety of tools, information sources, and problem-solving techniques to resolve

problems

Maintain history for all problems you resolve

OVO for Windows fully supports user roles that can be defined very granular. A given Windows user is

assigned multiple roles. You can set-up roles for operators, administrators, and a mix of both. Multiple

concurrent administrator users are supported.

You can use different users and roles in order to split responsibility in your environment. The responsibility split

may be overlapping or fully disjunct, depending on the needs of your staffing.

User roles do not necessarily correspond to separate people in all circumstances, but instead refer to the kind of

tasks to be performed. In some environments, one person may perform all functions, while in others, the

operator as well as the administrator role may be divided among several people.

First, you define the role. A role encompasses viewing rights to services, nodes and tools and capabilities. The

following are the properties you can use when setting up a role:

Limited view to services

Limited view to node groups and nodes

Limited view to tools

For messages, you define per message group, whether or not the messages can be viewed, acknowledged,owned, severity changed, and performed other actions on them

For policy management, you define per policy group, whether the policies contained therein may be viewed,

edited, deleted, and deployed

Finally, you assign the role to one or more Windows users. The same is valid the other way round: A Windows

user may have one or more roles assigned to him.


35/91



However, you need to make sure the Windows users are members of the pre-installed group HP-OVE-

Operators.


36/91



3.12 Self-Management

The Self Manager module

OVO for W indows is an application as any other application on your system and can by monitored by the

agent installed on the management server; OVO has some self-management capabilities built-in. A service

model will be part of the Self Manager. The model instantiation for every Windows managed node is done via

a tool (Synchronize Agent Services Tool) that checks that services from the OVO for Windows agent software

are installed on the managed nodes and then updates the service tree accordingly. The tool is automatically

run upon installation and after that scheduled once a day with the help of a scheduled command policy. The

tool can also be started manually. The set of policies configured to monitor the OVO for W indows related

events, processes and services are automatically deployed.

Self-management Policies:

Windows Eventlog policies configured to monitor OVO for W indows related NT EventLogentries on the management server or managed node. The policies generate messages and

update the status of related OVO for W indows services in the service map.

Advanced Thresholding policies monitor the size of the OVO for Windows data repositories on

the management server and agent and create an alarm if the defined size is over the specified

threshold.

Process Monitors monitor all processes/ services that always have to be running on the OVO

for W indows management server and managed node. This is implemented using the VB Script

capabilities of the Advanced Thresholding policy.

Scheduled Command Policy is used for the resynchronization of the services.

Database Management is provided on the management server and managed nodes to make sure that the

databases do not overflow. History messages older than (by default) 30 days are removed from the database

on the management server (this setting is customizable). On the managed nodes, setting collections at specific

sizes helps to maintain the size of the database.

Heartbeat polling is provided to detect any problems on the managed nodes. It is checked that the intelligent

agent on the managed node is correctly responding.

3.1 3 Securi ty

Installation

To be able to install the management server and the management console on a Windows system, the installing

user must have at least local administrative privileges on the system (It is recommended however to have

Domain Admin privileges for that system).


37/91



NOTE: If it is not possible to obtain Domain Admin privileges you are still able to install the OVO for

Windows. This procedure requires a manual assignment or creation of group and user accounts at the Domain

level prior to the installation. Please refer to the Installation Manual for details.

The installation of the OVO for Windows management server creates two local groups HP-OVE-ADMINS and

HP-OVE-OPERATORS (See the Runtime section below for details on these two groups).

These groups are local to the management server. In addition, the installation procedure prompts for a Domain

Group (the default is HP-OVE-Group) and Domain User account (the default is HP-OVE-User).

To simplify this document this Domain Group will be referenced as its default "HP-OVE-Group", the Domain

User as "HP-OVE-User". The actual names can be specified during the installation of the OVO for W indows

management server and can be any valid W indows group and user name. Even existing groups can be

selected, in this case however it has to be insured that the selected User is a member of the selected group.

Password expiration issues

It is recommended to disable password expiration for the HP-OVE-User. However, if password expiration is amust, OVO for W indows provides a tool to change the password in a consistent way throughout the

installation. The HP-OVE-User should be a service account, i.e. should not be used by any real Windows user

to log onto the system. Upon adding a node the Domain Group HP-OVE-Group is used to grant the OVO for

Windows Management server access to a managed W indows node. The HP-OVE-Group is added to the local

Administrators group of every managed node.

CAUTION: Select the HP-OVE-Group and HP-OVE-User carefully. Once the selection is made, only a

reinstallation of the OVO for W indows Management Server allows you to pick a different name.

The OVO for W indows installation procedure will prompt for the HP-OVE-User account as well as for a

password. If the HP-OVE-User is already available, the installation procedure will prompt for the password and

will verify that the password is valid.

If the HP-OVE-User is not yet available, it will be created automatically as part of the installation procedure.

NOTE: If the HP-OVE-User is not yet created, the installing W indows user has to be a member of the group

Domain Admins. (Windows requires Domain Admin privileges for the creation of Domain Groups and Users)

Managing Windows/ NT/ 2000/ 2003/ XP Nodes

Managing nodes is split into two tasks, which require different privileges:

Adding a managed node: To add a managed node, the user running the Management Console has to have

local Administrative privileges on any node to be managed by OVO for Windows. The easiest way to

accomplish this is for the user to have Domain Admins rights.


38/91



NOTE: Security restrictions may not allow the OVO Admin to have Domain Admins rights: In this case, the HP-

OVE-Group must be added to the local Administrators group of the node to be managed manually (i.e. prior to

adding the node).

If the above requirements are met, a Windows/ NT managed node can be added. The process of adding the

node will add the HP-OVE-Group to the local Administrators group on the managed node (using the toolOveConfig.exe). After pressing "Apply" or "OK" in the Node Configuration Editor, this tool is run

automatically. If the tool succeeds either the HP-OVE-Group is added successfully at the managed node, or this

group is already in place.

If the tool fails, the Console running W indows user does not have enough privileges to add this group to the

Administrator group. In this case, either add the HP-OVE-Group manually using a W indows user with higher

privileges (e.g. a Domain Admin) or re-launch the OVO for Windows Console as this user and re-add the

managed node.

The OveConfig.exe application is also available via Tools at

Tools->Administration->Windows Node Security Setup.

It can be run either to verify if the HP-OVE-Group is set up already, or to add this group. It may be rerun any

time for verification purpose.

To be able to manage a node after the node is added to the management server, it is sufficient for the user

running the Console to be an OVO Admin or OVO Op. Administrative privileges in the Windows context are

not required for both the OVO Admin and the OVO Op. Other tasks such as deploying and removing policies

from the managed node only require that the logged in user be an OVO Admin or an operator that is granted

administrative privileges. The task of starting a tool only requires the user to be an OVO Admin or OVO Op.

Note, it is also possible to preinstall the agent. The management server is then capable to synchronizing itspolicy inventory with whats out there on Windows (and UNIX) managed nodes.

A separate white paper is available that describes management of workgroups and non-trusted domains.

Managing UNIX Nodes (HP-UX, Solaris)

Adding a UNIX managed node: Unlike adding a W indows managed node, adding a UNIX managed node

only requires the user running the management console to be OVO Admin. After the node has been added as

a managed node, the agent software installation has to be performed manually on each UNIX node.

To install the agent software on the UNIX managed node, a root (uid=0) user privilege is required. The UNIX

agent software installation process is always manual and cannot be initiated from the management console.

The installation process creates a regular (non uid=0) user opc_op and a group opcgrp on the UNIX node to

be managed.

Note: If NIS or NIS+ is used on the UNIX managed node, it is recommended to setup an opc_op user and

opcgrp group prior to installing the agent software.


39/91



After installation, the agent will run in the context of the root (uid=0) user.

NOTE: For security sensitive environments, it is possible for the agent processes to run as non-root. Please refer

to the installation instructions in the OVO for Unix Reference Guide for details.

3.14 Commun ication

The MMC console communicates with the management server via WMI / DCOM. The web console uses http

as communication means. The agents communicate via DCE RPCs with the management server. In order to

support firewall environments, OVO for Windows 7.20 added a feature called

DCE RPC communication without endpoint mapper with the following benefits:

Reduce number of required open firewall ports

Hide DCE communication, prevent DCE lookup: It must not be possible to query available endpoints

from outside

The endpoint mapper / portmapper / rpcd / port 135 must not be needed for agent / servercommunication

Endpoint mapper can be stopped on agent if no other apps need it. Still needed on OVO for

W indows management server

Firewall filter can be implemented easier because of fixed ports and eliminated DCE lookup

Applies to messages including annotations, actions and action responses, tools, policy and

instrumentation deployment, agent control (start/ stop/ status), HBP

W hite paper available since May 2003

Communication Setup

RPC server selects the port it is listenting to from the opcinfo file (agent) or registry key (management

server)

RPC server

ovowin_75_tsg

Documents