In a previous post, I explained how to import policies from Hewlett Packard Operations Manager (HPOM) for Windows, HP-UX, Solaris or Linux into Operations Manager i (OMi).

Today, I want to have a closer look at the –check option of the policy import, as the number of warnings it sometimes produces has confused some people.

I will explain what types of warnings the tool creates and how to address each warning type.

To cut a long story short, a warning does not always mean that you can’t import or use the policy or that you have to edit it!

Furthermore, quite often warnings in hundreds of policies can be addressed by a mass “search and replace” or by a single configuration step on the OMi server.

So hundreds of warnings don’t mean that you have to edit hundreds of policies!

Therefore if the check reports a low percentage of policies without warnings, don’t worry!

The –check option

The Operations Bridge Evolution Guide available from the Operations Bridge Evolution Resources page recommends checking the downloaded HPE Operations Manager (HPEOM) policies for incompatibilities before doing an upload, so that you are able to address warnings by using a mass search and replace in all the downloaded policy files. This is much faster than changing each policy in OMi after an upload.

The check is done using the ConfigExchange –check option. The results are written into a policy report log file.

The policy report

The first thing you will see in the report is how many policies have no problem at all.

Let me start with the two warnings that occurred the most in my example:

Pattern Warnings

There are slight differences between the supported patterns in OMi and HPOM.

1. OMi does not yet support a case-insensitive check when closing messages using message keys.

Although the case-sensitive check is the default in HPOM, HPOM allows a case-insensitive check as well. Many SPIs use case-insensitive checks per default, so if you followed that practice of always using case-insensitive checks, then you might see a lot of those policy warnings.

However, in most cases the check will just work as before, even if checked case-sensitive, as typically the same variables are used for the message key and the message key relation pattern.

For example, if the pattern closes all messages using the pattern

<$NAME>:<$MSG_NODE_NAME>:<$MSG_OBJECT>:<*>

Then the message key is usually constructed using the same variables: <$NAME>:<$MSG_NODE_NAME>:<$MSG_OBJECT>:<some other variable or identifier>

That means whatever case was used in the key is probably used in the pattern as well, therefore a case-sensitive check works just as well as a case-insensitive check.

Therefore I recommend that you import the policies as they are, but keep this in mind in case you find events that should have closed old events.

For example this could happen if the node names appear in the same log file in variations, sometimes in upper-case letters, sometimes in lower-case letters. In this case, the message that used the upper-case node name in its message key cannot be closed by a message that uses the lower-case node name in the message key relation pattern (or vice versa). In such a case, consider using an EPI script that converts either the key or pattern to lower case, for example using

To avoid that this change messes up the keys of other events, make sure to use a specific event filter so that this script is only called when necessary.Note: Do not remove the ICASE keyword from the downloaded policy files as OMi might add support for this in a future release.

2. OMi does not support the whitespace pattern <S> (which was deprecated a long time ago in HPOM)

To fix it replace <S> by <_>, <1S> by <1_>, <2S> by <2_> ... in all downloaded policy files.

Note: The Evolution Guide recommends downloading and importing policies in chunks to avoid duplication and to make sure that only those policies are imported that are actually in use. It is not recommended to download all policies from HPOM!Therefore you might need to do search and replace operations multiple times, replacing the same patterns again and again. So it might make sense to write a little script, for example in perl, for repeating replacements.Otherwise I recommend using tools like notepad++ or standard Linux tools like sed and awk to search & replace text strings in multiple files in a directory structure.

You can replace such a pattern by fixing values separated by |.For example: <25 -lt <#> -lt 30> can be replaced by [26|27|28|29]

Instruction Text Interface Warnings

This warning only occurs when importing policies from HPOM for HP-UX, Solaris or Linux and if the instruction text interface was used. It tells you that a policy uses that instruction text interface, and that you need to setup a corresponding instruction text lookup script on the OMi server in case you want to keep using this instruction text interface.

So there is no need to edit the policy if you get this warning.

The only configuration that needs to be done is to setup a corresponding External instruction lookup script in OMi.

Let me give you an example: You might have an Apache Knowledge Base lookup script configured like this in HPOM:

Inside a HPOM policy this instruction text interface is then called using an event parameter <ErrorCode> like this:

In a similar way you might have a lookup script for a Microsoft Knowledge Base.

To implement the same in OMi, a corresponding External Instructions lookup script has to be configured, see Administration Guide > Operations Console > External Instructions and Extensibility Guide > Groovy Scripts > Development and Deployment of Scripts > External Instruction Retrieval Scripts for all the details.

In our example the event filter used in such a lookup script should match those events where the instruction interface name (set by the policy) is either Apache KB or Microsoft KB:

Instead of calling an external command you could of course also query the knowledge base inside the groovy script – groovy offers various modules to query databases, web pages etc.

Note: The policy check is unable to check if a corresponding script has already been setup on the OMi server or not. It will always print a warning if the instruction text interface is used.

MSI warnings

As for the instruction interface warnings above, these warnings do not mean that you have to edit your policies or that you can’t use them.

They just indicate that the Server MSI is referenced in the policy (you don’t get any warning if the Agent MSI is referenced, as this still can be used). On the server side, there is a difference in how OMi implements event enrichment and automation compared to HPOM.

Instead of Server MSI, OMi offers:

Server-Side Stream-Based Event Correlation (SBEC)

Topology-Based Event Correlation (TBEC)

Event suppression

Event web service interface

Event Processing Interface (EPI)

So depending on the use case of the MSI call, use one of these techniques. If the MSI application is used to suppress events, use event suppression rules instead. If an MSI application is taking a feed for external purposes, then consider implementing it in OMi using the Event Web Service interface or forward events to external event processing using a forwarding rule.

If the MSI application is used to process multiple events then SBEC could be a suitable replacement.

In any case, you don’t have to edit the policies that refer to the old MSI interface. Server-side MSI keywords inside the policy are ignored by OMi – there is no need to remove them.

Please see the Operations Bridge Evolution Guide available from the Operations Bridge Evolution Resources page for more details about how to use the SBEC, TBEC and EPI scripts to replace different types of ECS policies.

Encrypted password in action warning

HPOM allows defining actions that are executed under a specific user and allows to store the user password in an encrypted form inside the policy. However, on an OMi system the recommendation is not to store the password inside the policy—because this would require a policy change each time the password is changed.

Instead, use the parameterization capabilities of OMi, which didn’t exist on HPOM. Introduce a password parameter to the policy and store the actual value of the password in a management template or aspect or you can also specify it during the assignment. This parameterization allows you to change the password afterwards, without editing or deploying the policy again. Management templates for different groups of CIs allow different passwords without having to maintain multiple copies of policies.

See the OMi tutorial "How to add a parameter to a policy template" available from the tutorials page for details.

Other Action and Instruction Text warnings

If we look at all the remaining warnings that might occur, then they have one thing in common: They refer to executables or variables that only exist on an HPOM system.

So of course you get a warning when you try to import those policies on an OMi system.

The first question you should ask yourself is: What is the use case for these policies?

What is it that the action triggers? Is that still a valid or necessary use case on an OMi system? Or would you use another technology instead?

For example, some customers use actions in HPOM policies to automatically add nodes to a certain node group in HPOM, as the node group membership defines which operator will see the event. For this the action calls the opc_node CLI on the HPOM server. In OMi however, permissions are typically not assigned based on node group membership, therefore the specific use case for this action does not apply any more.

Similarly, other automation use cases that made perfect sense on an HPOM system, might - in the best case - not be required any more or might be better addressed using other technologies like discovery, downtime management or enrichment rules.

Without knowing the use case it’s impossible to give a general statement on which technology should be used instead, but my assumption is that there are only very few use cases which will still need to be addressed by policy-based actions that run on the OMi server.

So in these cases, you will have to edit those few policies and replace the executables and variables used on an HPOM server by corresponding executables and variables that exist on an OMi server.

Note: The Evolution Guide provides some tips how to replace the $OPC_MGMTSV variable. See OMi Solutions for $OPC_MGMTSV Actions in the Evolution Guide.

823 warnings were addressed by doing nothing ;) – well, ok, I quickly looked at the used patterns and because they are all based on policy variables it’s unlikely that the case sensitive check will create problems, so I ignored the warning. The remaining

3 warnings turned out to be calls that are no longer necessary on OMi because the use case no longer applied.

I hope that this information helps you to understand why there might be so many warnings, but as you have seen, this does not mean that there is huge effort necessary to address those warnings.

My advice is to stay calm, and walk through the steps above to solve the warnings. Don’t panic if there are a lot of them.

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.