Configure Flexible Management Policies

1. Open the Policy Templates manager:

   Administration > Monitoring > Policy Templates

   Alternatively, click Policy Templates.

2. In the Policy Template Groups pane, expand Policy Management > Templates grouped by type > Configuration.

3. Click the Flexible Management folder, and then do one of the following:

   • To add a new policy template, in the Policy Templates pane, click the  New Item button, and then click the Add New Policy Template... or the Add New Policy Template (Raw Mode) button.

     The New Flexible Management Template Editor opens.

   • To edit an existing policy template, click the policy template in the Policy Templates pane, click the  Edit Item button, and then click the Edit Policy Template or the Edit Policy Template (Raw Mode) button.

     The Edit Flexible Management Template Editor opens.

A flexible management policy enables you to configure the following:

• You can configure agents to communicate with multiple Operations Manager i servers:

  • Configure agents to send events to different Operations Manager i servers based on the time of day or based on criteria in the event. (See Time Templates and Event Target Rules.)

  • Configure agents to allow actions from several Operations Manager i servers. (See Action-Allowed and Secondary Managers.)

  • Switch the primary event receiver function to another server to manage an expanding network environment, and reduce primary server bottlenecks.

• You can deploy policies to any agent from any server, if the servers are configured to be the agent's primary or secondary server.

  Even though some policies are specific to a particular Operations Manager i server, the events that result from the policies can be sent to any server.

If you want the configuration to apply to all nodes in a given environment, you would develop one policy for all nodes. If you want varying configuration on different nodes, you would develop one policy for each configuration type.

You can use the syntax described in the following sections as a basis for configuring flexible management policies.

• Special Characters Used in the Syntax

  The syntax uses the following special characters:

  • e. Denotes an empty string.
  • # (number sign). Comment. Example: # This is a comment
  • \ (backslash). Escape character. Use a backslash to escape quotation marks in a syntax string. Example: \"quotation\"
• Syntax for Responsible Server Configuration policies

  Use the following syntax for responsible server configuration policies:

  respmgrconfigs ::= <respmgrconfigs> RESPMGRCONFIG DESCRIPTION  <string> <respmgrconds> | e
  respmgrconds   ::= SECONDARYMANAGERS <secondmgrs> ACTIONALLOWMANAGERS <actallowmgrs>  
                     [MSGTARGETRULES <msgtargetrules>]
  secondmgrs     ::= <secondmgrs> SECONDARYMANAGER NODE <node>  [DESCRIPTION <string>] | e
  actallowmgrs   ::= <actallowmgrs> ACTIONALLOWMANAGER NODE <node> [DESCRIPTION <string>] | e
  msgtargetrules ::= <msgtargetrules> MSGTARGETRULE DESCRIPTION <string> <msgtargetrule> | e
  msgtargetrule  ::= MSGTARGETRULECONDS <mtrconditions> MSGTARGETMANAGERS <msgtargetmgrs>
                     | MSGTARGETRULECONDS <mtrconditions> MSGTARGETMANAGERS <msgtargetmgrs> ACKNONLOCALMGR
  mtrconditions  ::= <mtrconditions> MSGTARGETRULECOND DESCRIPTION <string> <mtrcond> | e
  mtrcond        ::= <mtrcond> SEVERITY <severity> |
                     <mtrcond> NODE <nodelist> |
                     <mtrcond> APPLICATION <string> |
                     <mtrcond> MSGGRP <string> |
                     <mtrcond> OBJECT <string> |
                     <mtrcond> MSGTYPE <string> | 
                     <mtrcond> TEXT <pattern> |
                     <mtrcond> SERVICE_NAME <pattern> |
                     <mtrcond> MSGCONDTYPE <msgcondtype> | e
  severity       ::= Unknown | Normal | Warning | Critical | 
                     Minor | Major
  msgcondtype    ::= Match | Suppress
  nodelist       ::= <node> | <nodelist> <node> 
  node           ::= IP <ipaddress> | IP <ipaddress> <string> | IP <ipaddress> <string> ID <string>
  string         ::= "any alphanumeric string"
  ipaddress      ::= <digits>.<digits>.<digits>.<digits>
  pattern        ::= <string> <separators> <icase>
  separators     ::= SEPARATORS <string>
  icase          ::= ICASE
  

• Syntax for Time Templates

  Use the following syntax for time templates:

  timetmpls      ::= <timetmpls> TIMETEMPLATE <string> 
                     DESCRIPTION 
                     <string> <conditions> | e
  conditions     ::= TIMETMPLCONDS <timetmplconds> | e
  timetmplconds  ::= <timetmplconds> TIMETMPLCOND <timetmplcond>
  timetmplcond   ::= [TIMECONDTYPE <timecondtype>] [TIME FROM 
                     <time> TO <time>] [WEEKDAY <weekday>] 
                     [DATE <exact_date>] | e
  timecondtype   ::= Match | Suppress
  time           ::= <hh>:<mm>
  weekday        ::= ON <day> | FROM <day> TO <day>
  exact_date     ::= ON <date> | FROM <date> TO <date>
  day            ::= Monday | Tuesday | Wednesday | Thursday 
                     | Friday | Saturday | Sunday
  date           ::= <mm>/<dd>/<yyyy> |<mm>/<dd>/*

  Note The time template is compared with the creation time of the event on the node. Event creation time is always defined in GMT.

• Syntax for Management Responsibility Switching

  Use the following syntax for templates that switch server responsibility:

  configfile     ::= [TIMETEMPLATES <timetmpls>] RESPMGRCONFIGS 
                     <respmgrconfigs>

• Syntax for Message Target Rules

  Use the following syntax for templates that define message target rules:

  msgtargetmgrs  ::= <msgtargetmgrs> MSGTARGETMANAGER 
                     TIMETEMPLATE <string> OPCMGR <node> | 
                     <msgtargetmgrs> MSGTARGETMANAGER 
                     TIMETEMPLATE <string> OPCMGR <node> 
                     MSGCONTROLLINGMGR | <msgtargetmgrs> 
                     MSGTARGETMANAGER TIMETEMPLATE <string> 
                     OPCMGR <node> NOTIFYMGR | e

  Note You can replace <string> with $OPC_ALWAYS to specify that the time condition is always true. To specify that the current primary server is always used as the event target server, replace <node> with $OPC_PRIMARY_MGR. Pattern matching is only available in <string>.

• Keywords in Flexible Management Policies

  Keyword	Definition
  RESPMGRCONFIG	Responsible manager configuration.
  DESCRIPTION	Short description of the manager.
  SECONDARYMANAGERS	Secondary managers of an agent. Each of these servers have permission to take over responsibility and become the primary manager for an agent. SECONDARYMANAGER: Name of the secondary manager. NODE <node>: Node name of the secondary manager. DESCRIPTION: Description of the secondary manager.
  ACTIONALLOWMANAGERS	Servers that are allowed to execute actions on the node. The action response is sent to this manager. Only the primary manager can configure action-allowed managers for an agent. ACTIONALLOWMANAGER: Name of the manager allowed to execute actions on the node. NODE: Node name of the action-allowed manager. You can use the variable $OPC_PRIMARY_MGR to specify that this node name is always the node name of the primary manager. DESCRIPTION: Short description of the action-allowed manager.
  MSGTARGETRULES	Event target rules. MSGTARGETRULE: Rule to configure the event target conditions and the event target manager. DESCRIPTION: Description of the event target rule.
  MSGTARGETMANAGERS	Event target managers. Server to which the agents send events, as well as the action, responses to those events. The result of an event is sent to only one server. The keyword is also used to escalate events from one server to another. MSGTARGETMANAGER: Event target manager. Server to which you forward an event. Always specify the IP address of the target server as 0.0.0.0. The real IP address is then resolved by the domain name server (DNS). TIMETEMPLATE: Time template. Name of the time template corresponding to the target manager. If the time condition is always true, you can use the variable $OPC_ALWAYS. If you use this keyword, events transferred to the target manager will not depend on the time. OPCMGR: Node name of the target manager. You can use the keyword $OPC_PRIMARY_MGR to indicate that this will always be the primary manager. MSGCONTROLLINGMGR: Event-controlling manager. Enables event target manager to transfer control of a message. Modifications on the target server will synchronized back to all the other management servers. NOTIFYMGR: Notify manager. Enables the event target manager to notify itself. This attribute is set by default if no attribute is defined for the event target manager. Modifications (including acknowledge) are not synchronized back to the origin server. ACKNONLOCALMGR: Enables an event rule to force a direct acknowledgment of a notification event on a source server.
  MSGTARGETRULECONDS	Event target rule conditions. MSGTARGETRULECOND: Condition that tells the agent to which server to send specific events. Events are sent based on event attributes or time. The agent evaluates the event target conditions by reading the file mgrconf. If the mgrconf file does not exist, the events are sent to the server name stored in the primmgr file. If the primmgr file does not exist, events are sent according to instructions set using the ovconfchg command-line tool. DESCRIPTION: Description of the event target rule condition. SEVERITY: Severity level of the event. Can be Unknown, Normal, Warning, Minor, Major, Critical. NODE <node>: One or more node names, separated by spaces. You can specify a node in different ways (for example, NODE IP 0.0.0.0 hpbbn). If the node is defined using the format IP <ipaddress> or IP <ipaddress> <string>, you should use the IP address "0.0.0.0." The real IP address is then resolved by the domain name server (DNS). APPLICATION: Application name. MSGGRP: Category name (also known as message group name in HPE Operations Manager). OBJECT: Object name. MSGTYPE: Description of the type. MSGCONDTYPE: Event condition type: Match Condition is true if the specified attributes are matched. Suppress Condition is true if the specified attributes are not matched. TEXT: A string containing all or part of the event title. Pattern-matching may be used. SERVICE_NAME: A string containing the unique identifier of the service. Pattern-matching may be used, for example: SERVICE_NAME "Service<*> [A|B]" ICASE

A time template is a set of conditions (or rules) that tells the agent to which server and at what time a given node should send specific events. You create time conditions and save them in time templates. You can combine simple rules to set up more complex constructions (for example, "on Monday, Wednesday and Thursday from 10 am to 11:35 am from January to March"). Time conditions are defined using the 24-hour clock notation (for example, for 1:00 p.m., you would enter "13:00").

• Setting Time Intervals

  You can set several different time intervals as follows:

  • No Time. If you specify no particular time, day of the week, or year, HPE Operations Agent assumes you want the condition to be true from 00:00 to 24:00 every day of the year, every year. If you specify a condition, HPE Operations Agent assumes the condition should apply continually for the time and day specified.

    For example, specifying "Tuesdays" triggers a condition every Tuesday from 00:00 to 24:00 throughout the year, every year.

  • Span of Time. Specify a time range (for example, "from 7:00 to 17:00").

  • Wildcard (*) Date or Period. Use wildcards (*) in dates or periods of time (for example, to set a condition for January 31 every year, you would enter "1/31/*").

• Configuring Time-Indifferent Templates

  HPE Operations Agent requires that you set up a time template for the event target rules even if your scheduled action is time-indifferent. Use the variable $OPC_ALWAYS to configure time-indifferent templates.

You can use a list of event target rules to determine to which server an event should be sent.

An event target rule consists of three parts:

• Event attribute rule

• Time template

• Defined server

• Example of an Event Target Rule for Printing Group

  An event target rule for a printing group would have the following conceptual structure:

  Example:

  category = "printing"

  current time fits time template 2 ............(event) --> mgr 2

  current time fits time template 1 ............(event) --> mgr 1

  current time fits time template 3 ............(event) --> mgr 3

  In this example, HPE Operations Agent forwards all events with the category "printing" that meet the time conditions in template 1 to the server 1. All events that meet the time conditions in template 2 will be forwarded to server 2. Time template 3 functions the same.

• Example of an Event Target Rule for a Database Group

  An event target rule for a database group would have the following conceptual structure:

  Example:

  category = "database"

  current time fits time template 1 ............(event) --> mgr 2

  current time fits time template 2 ............(event) --> mgr 3

  current time fits time template 3 ............(event) --> mgr 1

  In this example, HPE Operations Agent forwards all events with the category "database" that meet the time conditions in template 1 to the server 2. All events that meet the time conditions in template 2 are sent to the server 3. And so on.

By default, only the node's primary manager for event reception (primary event receiver) can start actions on the node. To enable other servers to start actions on a node, you must specify action-allowed servers in a flexible management policy and deploy it to the node. This policy is important if you forward events that have automatic and operator-initiated actions to other servers.

The primary event receiver is initially set during the agent installation. To enable other servers to become a node's primary manager, you can specify secondary managers in the same policy. Secondary managers can deploy policies and packages to the node, without first becoming the primary management server.

A flexible management policy that configures action-allowed and secondary managers must contain the following statements:

 RESPMGRCONFIGS
      RESPMGRCONFIG DESCRIPTION "Policy description"
      SECONDARYMANAGERS
      ACTIONALLOWMANAGERS 

You can add to this minimal policy as many secondary and action-allowed managers as you need. You can specify the IP address or host name, followed by the core ID of each server. To specify only a host name, use the IP address 0.0.0.0.

To get a server's core ID, open a command prompt and then type the following command:

bbcutil -ping <server>

The response includes the core ID of the server.

 RESPMGRCONFIGS
      RESPMGRCONFIG DESCRIPTION "Enable manager1, manager2, and 192.168.1.3"
      SECONDARYMANAGERS
            SECONDARYMANAGER NODE IP 0.0.0.0 "manager1.example.com" 
                                  ID "e77b4992-5d78-753f-1387-c01230fe2648"
            SECONDARYMANAGER NODE IP 0.0.0.0 "manager2.example.com" 
                                  ID "68f01602-8bfa-7557-0403-8467ba97477a"
      ACTIONALLOWMANAGERS 
            ACTIONALLOWMANAGER NODE IP 0.0.0.0 "manager1.example.com" 
                                    ID "e77b4992-5d78-753f-1387-c01230fe2648"
            ACTIONALLOWMANAGER NODE IP 0.0.0.0 "manager2.example.com" 
                                    ID "68f01602-8bfa-7557-0403-8467ba97477a"
            ACTIONALLOWMANAGER NODE IP 192.168.1.3 
                                    ID "bc180332-d338-7557-0384-a10be68caa36"

The example policy specifies manager1.example.com and manager2.example.com as secondary and action-allowed managers. It also specifies that the server with the IP address 192.168.1.3 is an action-allowed manager.

1. In the Flexible Management Policy Editor, in the Properties page, type a Name for the policy.

   Optional. Provide a description of the policy (Description), select the instrumentation that will be deployed with the policy onto the host system where the agent is running (Instrumentation), and select the operating systems with which the policy is compatible (OS Types).

   For more information, see Properties Page.

2. In the Policy Data page, type the flexible management policy data using the flexible management policy syntax. If you are creating a new policy, copy and paste template data from an existing policy template. Alternatively, click the button to load policy data from a policy template file on your computer.

   For details, see Flexible Management Policy Syntax and Keywords.

   You can also use policy parameters. For more details, see Policy Parameters Tab.

3. Click Save and Close to save the policy template and exit the wizard.