Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

Evolve to OMi: How to smoothly move hundreds of Operations Agents to OMi

Micro Focus Expert
Micro Focus Expert
3 3 4,321

In a previous post, I explained why it makes sense for customers using HP Operations Manager (HPOM) for Windows, HP-UX, Solaris or Linux to move to Operations Manager i (OMi) for a single pane of glass view. I also provided an overview of the recommended technical steps to take, and I outlined how to import and reuse existing HPOM policies in OMi.


Today I want to have a closer look at when and how to switch Operations Agents to OMi, because that’s one of the necessary steps in the Evolution.




You can find complete details for moving Operations Agents to OMi in the Operations Bridge Evolution Guide available from the Operations Bridge Evolution Resource page, but here is a quick overview of the five recommended steps:


  1. Start by configuring all agents in your existing HPOM environment with a flexible management template that allows the new OMi server to configure your agents.
  2. Next, choose a group or type of nodes to move over, for example, all your Oracle Database systems
    1. Test policy and aspect deployment and tool execution from OMi on a representative node of that type. This might include importing HPOM policies and creating OMi aspects and management templates as I have outlined in one of my previous posts.
    2. After a successful test, roll out the configuration to the remaining nodes of that type, either manually or by using automatic assignment rules.
  3. Switch the primary manager and target server to OMi. Doing so still allows configuration from both OMi and HPOM servers. This is the first “switch” of agents.
  4. Repeat steps 2–3 until all nodes are managed by OMi.
  5. Before switching off the HPOM server, switch the agents to OMi completely, and clean up old HPOM policies if necessary. This is the second and final switch of agents.


Let me explain each these steps a little bit more.


Step 1: Configure all agents with a Flexible Management template


Flexible management templates define which management servers are authorized by the agent. We use the same concept now to grant the OMi server the permission to configure the existing Operations Agents.

  1. Create a policy like the following ON THE HPOM SERVER. You can use the ManagementResponsibilitySwitch example as starting point:

Of course you have to replace hpom.example.net and omi.example.net with your server names


# Configuration file 
# defines management responsibility switching
        DESCRIPTION "OM and OMi as responsible mgrs"
                NODE IP "omi.example.net"
                DESCRIPTION "OMi"
                NODE IP "hpom.example.net"
                DESCRIPTION "OM"
                NODE IP "hpom.example.net"
                DESCRIPTION "OM"
                NODE IP "omi.example.net"
                DESCRIPTION "OMi"
                NODE IP "$OPC_PRIMARY_MGR"
                DESCRIPTION "current primary manager"
            DESCRIPTION "always send all messages to current primary manager"
                    TIMETEMPLATE "$OPC_ALWAYS"
                    OPCMGR IP "$OPC_PRIMARY_MGR"



2. Deploy the policy from the HPOM server to all nodes. With that the OMi server can configure all the existing Operations Agents.


Step 2: Test and roll out configuration from OMi

These steps are about the assignment of aspects from OMi, first to one node and then to multiple nodes. For details, please see the Operations Bridge Evolution Guide available from the Operations Bridge Evolution Resource page or my previous post (in which I partially covered this aspect as well).


Let me point out an important fact here: The test and rollout can be done while the old policies deployed from HPOM are still active. This assures ongoing monitoring of your business critical applications! New policies deployed from OMi that have the same name replace the existing policies from HPOM.


Step 3: Switch the primary manager and target server

To verify that all server-based correlation features of OMi are working as expected, including duplicate suppression and event storm suppression, it is recommended that you change the target server for events to OMi as well.  

With the earlier mentioned flexible management policy, you can switch the target server by switching the primary manager of a node, because the flexible management policy contains the following as message target rule:

                    TIMETEMPLATE "$OPC_ALWAYS"
                    OPCMGR IP "$OPC_PRIMARY_MGR"


You can switch the primary manager from OMi using:

opr-ragt -username admin -primmgr <node selection>

<node selection> can be a comma-separated list of nodes, a node group or a view. For example, if in step 2b you used a view MyOracleSystems to deploy configuration to all nodes running Oracle, then you can use that same view to switch the primary manager of those nodes:

opr-ragt -username admin –primmgr –view_name MyOracleSystems

Step 4: Repeat for other types of nodes

Repeat steps two and three until all nodes are managed by OMi. You might also want to delete the node from Operations Manager, or at least disable heart beat polling since health checks should be completed by OMi now.


When this step is completed, all nodes are configured by OMi and send their events to OMi directly.


Step 4: Switch the agent

To be able to switch off the HPOM server, the agents need to be reconfigured so that they use the OMi server as their server, even when the flexible management template is removed. This can be done using the opr-agt -switch_manager option. It changes the following settings on the agent:

sec.core.auth MANAGER
sec.core.auth MANAGER_ID
eaagt.lic.mgrs GENERAL_LICMGR



Again, you can use a view name to switch certain nodes, for example, from OMi you could use something like:

opr-agt -switch_manager –view_name All_agents_mgd_by_OMi -username admin Make sure that this view only contains those nodes you want to switch. Especially make sure that the HPOM server node is not part of that view. As an alternative use the –node_list option:

opr-agt -switch_manager –node_list node1fqdn,node2fqdn,node3fqdn

Optional Step: clean up old HPOM policies

In case you decided not to reuse all HPOM policies, there might be some old HPOM policies still installed on the nodes. To remove these, simply call this command on your OMi server:

opr-agt –deploy -clean <node selection> -username admin

This deletes all existing policies on the nodes, including the flexible management template that grants rights to both OMi and HPOM servers, and then deploys all policies that are assigned to the nodes in OMi.

The result of a –switch_manager call followed by a –clean call is that the agent is completely managed by OMi.

Learn more about switching to OMi

I hope this short overview of how to move an agent to OMi was useful.

Please let me know if you have questions about this process. Simply post a comment below and I will try to address it in my reply or in an upcoming blog post.


Learn more about Operations Manager and Operations Manager i here.

You can also download trials of the software to experience them for yourself.

The OM-to-Opsbridge evolution program including license exchange details is now live. Search on the tag OM2OpsBridge to find blogs discussing this program and evolution to OpsBridge. Search on OMiContent for other blogs on management packs and connectors.

Mohammed Izaz Haseeb
Not applicable

I want to migrate OMW to OMi on production In OMW, wenever there is an event email notification is sent to respective team. Now if I am moving nodes to OMi by upgrading agent as soon as it reaches OMI the same email notificatiob policy should be ready in case it receives any alert. Please help

Outstanding Contributor.. JimiT Outstanding Contributor..
Outstanding Contributor..

Hi Mohammed,

There would be a number of ways in OMW to send email notification on any given alerts, ie via agent policy using the automatic action, or from OMW server policy using WMI query - there are other ways but these are the two most common  ways in OMW. If you are using the agent policy automatic action, then there is nothing more to do but plan to migrate to use the OMi Notification Rules instead.  If email notification in OMW is via an WMI policy running on the OMW server agent then you will need to create Notification Rules in OMi. 

Creating Notification Rules in OMi is relatively simple to do...

Create a new Rule, (Enter the Display name of the Notification rule, create the Event filter conditions, and then select the receipients from the list).

It's as simple as that!


Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

Hi Volker,

This manual is really useful for all, thank you very much. The only thing I don't see is any reference about automatic creation of the Monitored Node on OMi. It is supposed to be added manually on OMi during the migration? Or is the creation triggered by some of the step (i.e. the primary manager command).

I have tried to execute "ovagtrep -publish on the node" right after deploying the Flexible Management policy, but since it has no discovery policy it doesn't seem to send any topologic information to OMi.

Thank you very much!

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.