Connect existing Operations Agent installations

All secondary managers of a node have permission to deploy policies to the node. You can see which policies are installed on a node by running the opr-agt command-line tool with the ‑list_policies option. For details, see opr-agt Command-Line Interface.

To modify OM policies in OMi, download the policies in OM and then upload them to OMi using the ConfigExchange command-line tool. ConfigExchange can also upload instrumentation. Note that OMi policies cannot be uploaded to OM.

An instruction text is usually designed to help operators handle an associated event. It can describe an automatic action, provide details on how to perform an operator-initiated action, or describe steps for resolving a problem when a specified type of event occurs.

Instructions are configured in the policy that generates the event. You can either enter the instruction text directly or configure the instructions to be retrieved from external instruction interfaces (provided the instruction interfaces are configured and known to OM for UNIX or Linux). If a link to an external instruction interface is defined in the OM policy, after the policy has been imported into OMi, the name of the external instruction interface and the specified parameter string appear in the Interface Name and Parameters fields of the Rules > Instructions tab in the Policy Editor.

To initiate the instruction retrieval, you need to create an instruction retrieval Groovy script, provide the mapping to the event filter, and then deploy the policy to a node. OMi triggers the execution of an instruction retrieval script when at least one specified event filter matches the event selected in the Event Browser (the instructions are retrieved when you select the Instructions tab in the Event Details pane). Note that OMi always chooses the first event-matching filter. Therefore you should only define disjunctive event filters, that is, the event filters that do not match the same set of events.

For detailed information on external instruction interfaces, see External Instructions. For more information on Groovy scripts and a sample of an instruction retrieval Groovy script, see Groovy scripts.

Policies can create events that include automatic and operator-initiated actions (also known as commands in OM for Windows):

• Automatic actions can run locally on a managed node when the HPE Operations Agent detects the event.

  HPOM can run automatic actions on the management server or a managed node when the event arrives on the management server. HPOM can also run remote automatic actions. Operators can restart automatic actions manually from the HPOM message browser.

  A remote automatic action is an action that is attached to an event sent by a node and configured to run on another node.

  OMi can run automatic and remote automatic actions on managed nodes. Automatic actions can also run on the OMi server. You can restart an automatic or remote action on any node manually from the OMi Event Browser.

• HPOM operators can start operator-initiated actions manually from the HPOM message browser, after evaluating the details of the event.

  Similarly, OMi users can start operator-initiated actions manually from the OMi Event Browser.

OMi checks the Originating Server event attribute to determine which server should start the action. If the Originating Server attribute is empty, OMi starts the action. If the originating server is an Operations Management server, the action request is transferred to the Operations Management server for execution. The originating server is the server that initially forwarded the original event along the chain of servers configured in a flexible management environment.

When you import policies from OM to OMi, any automatic and operator-initiated actions are included. Actions that include the variable <$OPC_MGMTSV> only run on Operations Management servers, not on OMi servers. To run these actions on the OMi server, replace the variable <$OPC_MGMTSV> with the name of the server.

The following figure shows the architecture of a deployment where both OM and OMi manage an agent:

• OM:

  Is the primary, secondary, and action-allowed manager of an HPE Operations Agent.

  Deploys policies, packages, hotfixes, and instrumentation to the agent.

  Runs actions and tools on the agent.

  Forwards events and topology to OMi.

• OMi:

  Is the secondary and action-allowed manager for the HPE Operations Agent.

  Deploys policies and instrumentation to the agent.

  Forwards event updates to OM.

  Uses OM as the action server for running actions on the agent.

  Uses OM as the instruction text server for retrieving instruction texts from OM policies.

• HPE Operations Agent:

  Accepts configuration from both OM and OMi.

  Sends events and topology to OM only.

• Only HPE Operations Agent version 11.12 or later can be integrated with OMi.

• OM for Windows management servers require patch OMW_00177 (32-bit) or OMW_00178 (64-bit).

  OM for UNIX or Linux management servers do not require a patch for the OM-OMi integration.

• Policy synchronization in OM for Windows:

  OM for Windows management servers can synchronize their policy inventory with nodes that are managed by both OM for Windows and OMi. If such nodes have parameterized OMi policy templates, the OM server associates these policies with the policy type "Unknown". The OM server does not receive the contents of the policy, so the policies cannot be changed, enabled, disabled, removed, or deployed to other nodes.

This task describes how to configure an existing HPE Operations Agent to be managed by both OM and OMi:

1. Prerequisite. Make sure the Operations management server is integrated with the OMi server. If it is not, follow the instructions in the Integrate section to integrate both products.

2. Update the trusted certificates on the nodes. The tools in the following procedure retrieve the currently trusted certificates from the certificate server and install them as trusted certificates on the nodes.

   Operations Manager for Windows managed nodes:

   1. In the console tree, click Tools > Operations Manager Tools > Certificate Management.

   2. In the details pane, double-click Update trusted certificates. A dialog box opens, which lists nodes and services.

   3. Select the nodes on which to update the trusted certificates. To update trusted certificates on all existing nodes, select the Nodes check box. Alternatively, you can select check boxes for individual nodes or node groups.

   4. Click Launch.... The Tool Status dialog box opens and shows progress.

   Operations Manager for UNIX or Linux managed nodes:

   In the Operator UI, right-click the managed nodes on which to update the trusted certificates and select Start > Certificate Tools > Update Trusts from the context menu. The output of the tool displays in a new workspace pane window.

3. Optional. Import OM policies and instrumentation into OMi. Once the OM policies are available in OMi, you can apply the advanced monitoring features of OMi to them (for example, parameterization, management templates, and aspects). For details, see Import configuration data from Operations Manager.

4. Configure and deploy an agent-based flexible management policy in OM:

   1. Create or edit an agent-based flexible management policy in OM. Add both the OMi gateway server or load balancer and the Operations Management server as secondary and action-allowed servers. $OPC_ALWAYS and $OPC_PRIMARY_MGR configure the agent to always send events to the current primary event receiver (that is, the Operations Management server).

      Hostname and IP address in flexible management policies:

      You can specify either the IP address or host name of each server. If you are specifying only a host name, enter the IP address 0.0.0.0.

      For Operations Management servers in clusters, specify the IP address or host name of the virtual management server. Also, add the core ID of the virtual management server.

      Core ID in flexible management policies:

      You must add the core ID for standalone Operations Management servers if you have not set up a node to represent these Operations Management servers on the management server from which you intend to deploy the policy.

      To get an Operations Management server's core ID, open a command prompt on that management server and type the following command:

      ovcoreid -ovrg server

      If the management server is in a cluster, make sure that you start the above command on the cluster node that is currently active.

      Example:

      TIMETEMPLATES
      #none
      RESPMGRCONFIGS
         RESPMGRCONFIG
            DESCRIPTION "Defines OM and OMi as responsible servers"
            SECONDARYMANAGERS
               SECONDARYMANAGER
                  NODE IP 0.0.0.0 "om.example.com" ID "e11fd362-cc28-754b-1bdd-936b7e932019"
                  DESCRIPTION "FQDN of OM management server"
               SECONDARYMANAGER
                  NODE IP 0.0.0.0 "omi.example.com" ID "814aee82-84d3-754b-1acd-8c4ca610810d"
                  DESCRIPTION "OMi server: FQDN of gateway server or load balancer"
            ACTIONALLOWMANAGERS
               ACTIONALLOWMANAGER
                  NODE IP 0.0.0.0 "om.example.com" ID "e11fd362-cc28-754b-1bdd-936b7e932019"
                  DESCRIPTION "FQDN of OM management server"
               ACTIONALLOWMANAGER
                  NODE IP 0.0.0.0 "omi.example.com" ID "814aee82-84d3-754b-1acd-8c4ca610810d"
                  DESCRIPTION "OMi server: FQDN of gateway server or load balancer"
         MSGTARGETRULES
            MSGTARGETRULE
               DESCRIPTION "always send all messages to current primary manager"
               MSGTARGETRULECONDS
               MSGTARGETMANAGERS
                  MSGTARGETMANAGER
                     TIMETEMPLATE "$OPC_ALWAYS"
                     OPCMGR IP 0.0.0.0 "$OPC_PRIMARY_MGR"

      For more information on creating a flexible management policy in OM, see the OM documentation.

   2. Deploy the flexible management policy to the nodes that you want to co-manage with OMi.

This task describes how to switch the primary event receiver of an HPE Operations Agent that is managed by OMi to another OMi server:

1. Prerequisites. Configure trust and a flexible management policy:

   1. Exchange trusted certificates between the OMi servers and update the trusted certificates on the agents.

      For details on exchanging trusted certificates between the OMi servers, see Establish a trust relationship for a server connection.

      To update the trusted certificates on the nodes, run ovcert -updatetrusted on each agent system. The command retrieves the currently trusted certificates from the certificate server and installs them as trusted certificates on the node.

   2. Configure the new primary event receiver as a secondary and action-allowed server of the nodes. You do this by deploying a flexible management policy to the nodes from the current primary server.

      Host name and IP address in flexible management policies:

      You can specify either the IP address or host name of each server. If you are specifying only a host name, enter the IP address 0.0.0.0.

      Core ID in flexible management policies:

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

      ovcoreid -ovrg server

      Example:

       RESPMGRCONFIGS
            RESPMGRCONFIG DESCRIPTION "Prepare for primary manager switch"
            SECONDARYMANAGERS
                  SECONDARYMANAGER NODE IP 0.0.0.0 "oldserver.example.com" 
                                        ID "e77b4992-5d78-753f-1387-c01230fe2648"
                  SECONDARYMANAGER NODE IP 0.0.0.0 "newserver.example.com" 
                                        ID "68f01602-8bfa-7557-0403-8467ba97477a"
            ACTIONALLOWMANAGERS 
                  ACTIONALLOWMANAGER NODE IP 0.0.0.0 "oldserver.example.com" 
                                          ID "e77b4992-5d78-753f-1387-c01230fe2648"
                  ACTIONALLOWMANAGER NODE IP 0.0.0.0 "newserver.example.com" 
                                          ID "68f01602-8bfa-7557-0403-8467ba97477a" 
            MSGTARGETRULES
                  MSGTARGETRULE
                        DESCRIPTION "always send all events to current primary manager"    
                  MSGTARGETRULECONDS
                  MSGTARGETMANAGERS
                        MSGTARGETMANAGER
                              TIMETEMPLATE "$OPC_ALWAYS"
                              OPCMGR IP 0.0.0.0 "$OPC_PRIMARY_MGR"

      This policy configures the following:

      • The SECONDARYMANAGERS and ACTIONALLOWMANAGERS sections configure the servers that are authorized to access and to run actions on the node. In this example, the policy configures "oldserver.example.com" and "newserver.example.com" as secondary and action-allowed managers.

      • The section MSGTARGETRULES configures the server to which the agent sends events. In this example, the keyword $OPC_ALWAYS configures the agent to always send events to the agent's primary event receiver ($OPC_PRIMARY_MGR).

      For more information on the syntax used in flexible management policies, see Configure Flexible Management Policies.

2. Set the node's primary manager for event reception. Run the opr-agt command-line tool on the OMi server (any gateway or data processing server) that currently manages the agents:

   opr-agt <authentication> <target_nodes> -set_primary_manager -manager <FQDN_of_new_OMi_server>

   The value of <FQDN_of_new_OMi_server> is the fully qualified domain name of the OMi server. In distributed environments, it is the fully qualified domain name of the gateway server or load balancer.

   Example:

   opr-agt -username myU -password myPwd -node_list "node1.example.com,node2.example.com" -set_primary_manager -manager newserver.example.com

   If an open message interface policy is deployed to the node, you can send a message to the open message interface on the node and check that the corresponding event arrives in the Event Browser on the new server.

   Note When primary event receiver is switched in a way other than by using the opr-agt -set_primary_manager command, you must restart the message agent after the switch by using the ovc –restart opcmsga command. Otherwise health check stops working for up to 24 hours. After the message agent restart, health check is performed based on the configuration of the new primary event receiver.