NNMi 9.1x Release Notes Updates

Last Updated: 24 January, 2014

This document contains updates to the release notes for HP Network Node Manager i-series (NNMi) 9.1x. You can also check for online NNMi 9.1x support matrix updates or the device support matrix.

Other useful links include the following:


The following list contains NNMi 9.1x update information:


11/15/2013: NNMi 9.1x Patch 6 Changes to the trap source address selection methods for SNMPv1 and SNMPv2 traps

The SNMPv1 and SNMPv2 trap handling mechanism in NNMi 9.1x Patch 6 provides an additional option to control the way the trap source address is selected. Normally, for SNMPv1 traps, the agent address in the SNMPv1 trap Protocol Data Unit (PDU) identifies the trap source address. In the case of SNMPv2 traps, the source address is identified by the IP header. However, this trap source address may be overridden by either the override varbinds in the trap or by the NNMi property com.hp.nnm.trapd.useUdpHeaderIpAddress. The source address varbinds in the traps override the property setting. With NNMi 9.1x Patch 6, a new option is added to control the effect of special proxy address varbinds. The new property, com.hp.nnm.trapd.ignoreProxyAddressVarbindOverride, when set to "true", causes the setting of com.hp.nnm.trapd.useUdpHeaderIpAddress to take precedence over the special proxy address varbinds. By default, com.hp.nnm.trapd.ignoreProxyAddressVarbindOverride is set to false.

To change the value for this property, complete the following steps:

  1. Edit the following file:
  2. Search for the following text:
    #! com.hp.nnm.trapd.ignoreProxyAddressVarbindOverride=false
  3. Uncomment the line by removing the leading #! characters and change the value to "true" .

The special proxy address varbinds that are controlled by this new property are:

Also note that this property does not affect the openviewSourceName (.1.3.6.1.4.1.11.2.17.2.2.0) varbind.

In addition to the introduction of the new property, the value for the custom attribute cia.orginalAddress is set such that it contains the original trap source address that was obtained prior to either applying the value from the special proxy source address varbind or choosing the trap source based on the setting of the parameter com.hp.nnm.trapd.useUdpHeaderIpAddress.

The following table that shows the values stored in the custom attributes cia.address and cia.originalAddress, under various scenarios:

Trap NNMi 9.1x Parameter Settings 
  useUdpHeaderIPaddress = false; com.hp.nnm.trapd.ignoreProxyAddressVarbindOverride = false useUdpHeaderIPaddress = true; com.hp.nnm.trapd.ignoreProxyAddressvarbindOverride = false useUdpHeaderIPaddress = true; com.hp.nnm.trapd.ignoreSpecialvarbindOverride = true useUdpHeaderIPaddress = false; com.hp.nnm.trapd.ignoreSpecialvarbindOverride = true
v1 trap

cia.Address  = agent address in snmp PDU

cia.originalAddress =  source address from IP Header

cia.Address  = source address from IP Header

cia.originalAddress = agent address in snmp  PDU

cia.Address  = source address from IP header

cia.originalAddress = agent address in snmp PDU

cia.Address  = agent address in snmp PDU

cia.originalAddress =  source address from IP header
v1 trap with source address varbinds

cia.Address  =  value from the  source address varbind

cia.originalAddress =  agent address in snmp PDU

cia.Address  = snmpTrapAddress varbind value

cia.originalAddress =  source address from IP Header

cia.Address  = source address from IP Header

cia.originalAddress = agent address in snmp  PDU

cia.Address  =  openviewSourceName varbind value (if present, else agent address in snmp PDU)

cia.originalAddress =  source address from IP header
v2 trap

cia.Address  =  source address from IP Header

cia.originalAddress =  source address from IP Header

cia.Address  =  source address from IP Header

cia.originalAddress =  source address from IP Header

cia.Address  =  source address from IP Header

cia.originalAddress =  source address from IP Header

cia.Address  =   source address from IP Header

cia.originalAddress =   source address from IP Header
v2 trap source address varbinds

cia.Address  = value from the  source address varbind

cia.originalAddress =  source address from IP Header

cia.Address  = snmpTrapAddress varbind value

cia.originalAddress =  source address from IP Header

cia.Address  =  source address from IP Header

cia.originalAddress =  source address from IP Header

cia.Address  = openviewSourceName varbind value (if present else source address from IP header)

cia.originalAddress =   source address from IP Header

 


01/25/2013: SNMPv3 USM Privacy Protocol Settings Listed Incorrectly in the NNMi Help

The SNMPv3 USM privacy protocol determines whether encryption is required and indicates the type of privacy protocol used. There are two SNMPv3 USM privacy protocol settings listed incorrectly in the NNMi Help. NNMi supports the following privacy protocols:


01/25/2013: Configure NNMi to consider simultaneous changes to the ifSpeed and ifAlias values of a specific interface to be updates to that interface

In cases where both the ifSpeed and the ifAlias of a specific interface change values between discovery polls, NNMi's default behavior is to consider these value changes to be  complete interface changes. This means that NNMi deletes the old interface from its database and creates a new one. A result of this behavior is that NNMi removes any custom attributes or management state assigned to this interface before creating a new one. For customer environments where a pair of changes like this does not indicate a new interface, you can enable a property to have NNMi consider these value changes as updates to an existing interface.

To configure this property, complete the following steps:

  1. Edit the following file:
  2. Search for the following property name in the nms-disco.properties file: allowSpeedAndIfAliasChangeToUpdateIface.
  3. Follow the instructions in the nms-disco.properties file to set the allowSpeedAndIfAliasChangeToUpdateIface property for your environment.
  4. If you make a change to the nms-disco.properties file, you must restart NNMi for that change to take effect.

01/25/2013: Device Credential Settings are available for additional devices

NNMi uses the Device Credentials settings for the following:


11/14/2012: Beginning with NNMi 9.10, the AES-192, AES-256, and TripleDES protocols are available for selection on the NNMi management server

Use of the TripleDES, AES-192, or AES-256 privacy protocols require the intallation of the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6 library. The NNMi 9.1x Deployment Reference incorrectly states that you must download and install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files library before you can use the TripleDES, AES-192, or AES-256 privacy protocols. Beginning with NNMi 9.10, this library is installed automatically as part of the NNMi installation process. If you do accidentally delete the library, and need to enable NNMi to use the AES-192, AES-256, and TripleDES privacy protocols for SNMPv3 communication, follow these steps:

  1. Download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6 library from the Oracle Technology Network web site for Java developers. For a direct link to the download page, click here
  2. Uncompress the download package, then copy both JAR files (local_policy.jar and US_export_policy.jar) to the following location:
  3. Restart NNMi by running the following commands:
    1. ovstop
    2. ovstart


10/02/2012: Upgrading from NNMi 9.0x to NNMi 9.1x might incorrectly set the HostNameMatchManagementIP property to false

If you plan to upgrade an earlier version of NNMi 9.0x to NNMi 9.1x, and if that same system had been running NNMi 8.1x at some time in the past, the upgrade might incorrectly set the HostNameMatchManagementIP property to false. The HostNameMatchManagementIP property exists in the nms-disco.properties file.

In most cases, you will prefer the value of this property to be true. If you want it to remain true, check this file after the upgrade completes, and correct the value if necessary. The nms-disco.properties file is located in the %NnmDataDir%\shared\nnm\conf\props folder (Windows) or the $NnmDataDir/shared/nnm/conf/props directory (UNIX).

If you change the value of the HostNameMatchManagementIP property, for the changes to take effect, you must restart the NNMi management server as follows:

  1. Run the ovstop command on the NNMi management server.
  2. Run the ovstart command on the NNMi management server.

NOTE: When making file changes under HA, you must make the changes on both nodes in the cluster. For NNMi using HA configurations, if the change requires you to stop and restart the NNMi management server, you must put the nodes in maintenance mode before running the ovstop and ovstart commands.


07/27/2012: SNMP MIB Loader issues occur after removing a patch or hotfix

If you install an SNMP MIB Loader hotfix after applying NNMi 9.1x Patch 4 (or later patch), you can load specific MIBs that you could not load prior to installing the SNMP MIB Loader hotfix. After you remove the SNMP MIB Loader hotfix or the patch, you can no longer load or unload a MIB. To avoid this issue, unload all of the MIBs you loaded after applying the patch or installing the SNMP MIB Loader hotfix before you uninstall the patch or hotfix. An alternative approach is to install the newest MIB Loader Hotfix that corresponds to the patch you uninstalled.


07/20/2012: NNMi cannot determine the original trap address from traps sent by a proxy SNMP Gateway

NNM9.1x Patch 4 contains the following new custom incident attribute: cia.originaladdress.

NNMi determines this attribute's meaning in conjunction with the com.hp.nnm.trapd.useUdpHeaderIpAddress property, defined in the $NnmDataDir/shared/nnm/conf/props/nms-jboss.properties file (UNIX) or %NnmDataDir%\shared\nnm\conf\props\nms-jboss.properties file (Windows). The value of the com.hp.nnm.trapd.useUdpHeaderIpAddress parameter is false by default, so NNMi normally ignores the cia.originaladdress attribute. When the value of the com.hp.nnm.trapd.useUdpHeaderIpAddress parameter is false, the cia.address value is the SNMP Agent IP Address. After you set the com.hp.nnm.trapd.useUdpHeaderIpAddress value to true, the cia.originaladdress attribute provides the value of the SNMP Agent Address, and the cia.address value provides the User Datagram Protocol (UDP) header IP Address. Setting the com.hp.nnm.trapd.useUdpHeaderIpAddress value to true is useful when you want to use the UDP header address as the source in NNMi and still require access to the actual SNMP address of the managed device.

When the com.hp.nnm.trapd.useUdpHeaderIpAddress attribute is false (the default setting), the cia.originaladdress and cia.address attributes both contain the same value.


06/07/2012: Configure NNMi to enforce strict SNMPv3 inform processing

You can configure NNMi 9.1x to enforce strict SNMPv3 inform processing. Once you configure this new property, it enables NNMi to enforce strict SNMPv3 inform processing. NNMi does not process any SNMPv3 inform having credentials that do not match those credentials configured in the Trap Forwarding Configuration. This configuration disregards the authentication or privacy configured for a node in the NNMi Communication Configuration screen.

Note: NNMi validates SNMPv3 traps differently than it validates SNMPv3 informs (with this new property). For SNMP traps, NNMi uses the communication configuration currently being used to monitor a node in topology.

To configure the new property, do the following:

  1. Edit the following file:
  2. Add the following line: com.hp.ov.nms.comm.snmp.enforcestrictv3traps=true

If the property you just configured is missing, or is set to false, NNMi does not validate SNMPv3 informs against the configuration set in the Trap Forwarding Configuration (the NNMi behavior before adding this feature). NNMi logs messages related to rejected SNMPv3 informs and traps to the nnm-trace*.log file.

Important: HP might choose to enforce strict SNMPv3 inform processing (set this property to true) by default. This could happen without providing the ability to disable strict SNMPv3 inform processing. This new default behavior could happen without notice for any full release of NNMi, as strict SNMPv3 inform processing is considered a best practice that all customers should follow. HP advises any customer using SNMPv3 informs, traps, or both to configure devices to send those messages with the correct credentials for each type of trap.


06/07/2012: Configure NNMi to use Forwarding Database (FDB) information from switches to derive layer 2 connections rather than using information from discovery protocols

In some cases, it is desirable to have NNMi use FDB information from switches to derive layer 2 connections rather than using information from discovery protocols such as CDP, LLDP, and others. The default configuration for NNMi is to use the discovery protocol (xDP) information instead of using FDB information. NNMi has a new property value called fdbOverrideNodeGroup. The fdbOverrideNodeGroup property is not enabled by default. If you set this property to be the name of a node group, then any node belonging to that node group has the potential of having its FDB-based connections override its xDP connections. If NNMi creates a connection using FDB-based information, it shows the type of the connection as FDBH rather than FDB. See the documentation for the fdbOverrideNodeGroup property in the %NnmDataDir%\shared\nnm\conf\props\nms-disco.properties file (Windows) or $NnmDataDir/shared/nnm/conf/props/nms-disco.properties file (UNIX).


06/07/2012: Configure NNMi not to discover IP addresses associated with administratively down interfaces

In some cases, NNMi might (accurately) show many administratively down IP addresses. These IP addresses result in NNMi showing many undesired layer 2 connections on its maps. NNMi has new property value called ignoreAdminDownIPs. NNMi's default configuration sets this new property value to false. If you set this property value to true, NNMi no longer discovers IP addresses that are associated with administratively down interfaces. See the documentation for the ignoreAdminDownIPs property in the %NnmDataDir%\shared\nnm\conf\props\nms-disco.properties file (Windows) or $NnmDataDir/shared/nnm/conf/props/nms-disco.properties file (UNIX).


06/07/2012: Configure NNMi to not consider some firewall and loadbalancer devices as duplicates

Many firewall and loadbalancer devices have duplicated IP addresses, duplicated layer 2 addresses, or both. This is especially true when the device is a virtual instance hosted on a physical device. NNMi often considers such devices to be duplicates of each other when they are not really duplicates. NNMi has new configuration file in which you can list the sysObjectId values of these nodes. Doing so tells NNMi not to consider such nodes to be duplicates when it finds overlapping IP addresses, layer 2 addresses, or both. See the macdedupexceptions.txt.4 reference page, or the UNIX manpage, for more information.


05/10/2012: Important information about the NOT, EXISTS, and NOT EXISTS Payload Filter options.

The NOT, EXISTS, and NOT EXISTS options do not function correctly in the Payload Filter Configuration tab.


05/10/2012: High Availability Environments Only: How can I migrate from a Windows NNMi 9.0x management server with NNM iSPI for MPLS 9.0x running on Windows 2003 to a Windows NNMi 9.10 management server with NNM iSPI for MPLS 9.10 running on Windows 2008?

For instructions about how to do this migration, see http://support.openview.hp.com/selfsolve/document/KM1365577.


04/19/2012: The Autopass License Manager fails, displaying the following exception: SEVERE: Autopass failure (ClassNotFoundException)

If you run the nnmlicense.ovpl script to open the Autopass License Manager, and see an error similar to the following, the HPOVLic package has been removed or damaged:

Apr 13, 2012 4:27:23 AM com.hp.ov.nms.autopass.controller.License initializeAutoPass SEVERE: Autopass failure (ClassNotFoundException): Can not find Autopass classes; autopass functionality will be bypassed: java.lang.ClassNotFoundException: com/hp/ov/lic/sm/Err

To remedy this, do the following:

  1. Copy the HPOvLic package from the NNMi install DVD packages directory to a temporary directory.
  2. Run one of the following commands to make sure the HPOvLic package is completely removed. Note: If the HPOvLic package is already removed, you might encounter an error.
  3. Run one of the following commands to reinstall the HPOvLic package:


04/03/2012: The HP Network Node Manager i Software (HP NNMi)-HP Network Automation Software (HP NA) integration does not support Secure Sockets Layer (SSL)

For NNMi 9.1x, you cannot configure the HP NNMi-HP NA integration for SSL.


03/21/2012: Potential patch installation problem on NNMi management servers configured to use HA

When installing NNMi 9.10x Patches 1, 2 or 3 on NNMi management servers configured to use HA in maintenance mode, the installation might not complete, showing the following error message: Please stop the resource group before proceeding with patch installation.... This problem occurs if you configured maintenance mode using a file named maintenance. To remedy this, configure the maintenance mode using a file named maint_NNM instead of maintenance. This problem is fixed in NNMi 9.10x Patch 4.


03/02/2012: SUSE Linux Information omitted from 9.1x Patch 3 documentation

NNMi 9.1x Patch 3 supports both Red Hat Linux and SUSE Linux operating systems. See the NNMi 9.1x HP Network Node Manager i Software System and Device Support Matrix for the specific supported versions.  The Linux patch package NNM910L_00003.rpm applies to both Red Hat Linux and SUSE Linux operating systems.


02/24/2012: Upgrade Issue with NNMi 9.0x Integrated with NA 9.00.

If you have NNMi 9.0x integrated with NA 9.00 and plan to upgrade NNMi from NNMi 9.0x to NNMi 9.10, you must complete the following steps before upgrading:

  1. Disable the NNMi—NA integration.
  2. Uninstall the NNMi connector. To uninstall the NNMi connector, follow the instructions shown in the Integration Configuration Upgraded from NNMi 9.0x section of the NNMi 9.1x Patch 3 Deployment Reference.
  3. Follow the upgrade instructions shown in the Integration Configuration Upgraded from NNMi 9.0x section of the NNMi 9.1x Patch 3 Deployment Reference.

01/19/2012: NNMi 9.1x patch 3 permits NNM administrators to disable all FDB-based layer 2 connection processing

Suppose you use NNMi to manage a network that mostly contains equipment reporting layer 2 connections using discovery protocols such as CDP and LLDP. For equipment not supporting these discovery protocols, NNMi relies on a neighboring switch's FDB tables to determine connectivity. In some rare situations, such as a network having a large majority of equipment supporting discovery protocols, NNMi using additional FDB information from neighboring switches might result in inaccurate connectivity displayed in NNMi. In these rare situations, you might not want NNMi to use any FDB-based information to discover connectivity for this equipment.

After installing NNMi 9.1x patch 3, you can completely disable all FDB-based layer 2 connection processing. It is important to understand that disabling FDB-based layer 2 connection processing disables this processing for all nodes currently being managed. It is also important to understand that, after disabling all FDB-based layer 2 connection processing, NNMi does not remove connections previously discovered using FDB-based layer 2 connection processing.

To enable the FDB analysis suppression feature, see the instructions contained in the nms-disco.properties file. Look for the nms-disco.properties file in /var/opt/OV/shared/nnm/conf/props (UNIX) or %nnmdatadir%\shared\nnm\conf\props (Windows). You must restart NNMi after making changes to the nms-disco.properties file.

If you need to delete all FDB-based layer 2 connections from the NNMi management server, run the following command: nnml2maint.ovpl deleteAllFDBConnections. Look for the nnml2maint.ovpl script in /opt/OV/support (UNIX) or %nnminstalldir%\support (Windows). You must run the nnml2maint.ovpl script while NNMi is running.


01/19/2012: NNMi 9.1x patch 3 contains a command line tool for adding custom attributes to connected interfaces having endpoints being managed by different regional NNMi management servers

After you install NNMi 9.1x patch 3, you can use the nnmcreateendpointpollingconfig.ovpl script to add custom attributes to connected interfaces that have endpoints being managed by different NNMi regional management servers. After you load these attributes on the regional NNMi management server or servers that manage the nodes containing the interfaces, you can create polling policies to manage these interfaces so that the global NNMi management station shows the connections correctly.

To configure this feature, do the following:

Do the following on each regional NNMi management server:

  1. Copy the CSV file you generated with the nnmcreateendpointpollingconfig.ovpl script to each regional NNMi management server.
  2. Run the nnmloadattributes -t interface -f fileName command, where filename is the name of the file generated when you created the CSV file.
  3. Create a new interface group filtering on customAddrName = com.hp.nnm.capability.iface.forcePolled or customAddrValue = Force Polled.
  4. Create the desired polling configuration on the new interface group (polling unconnected interfaces will typically be needed).

12/06/2011: Configuring NNMi Group Authentication such that a user has both administrator and client roles results in an "Error - No Data" error from NNM iSPIs

This information pertains to NNMi configured with NNM iSPI Performance for Metrics, NNM iSPI Performance for Quality Assurance, or NNM iSPI Performance for Traffic. Prior to installing NNMi 9.1x patch 1, NNMi did not support assigning a user both administrator and client roles for NNMi Group Authentication. If you configured an NNMi user to have both roles, either remove that user or assign the user only one role.


10/13/2011: NNMi 9.1x and NNM iSPIs affected by Russian time zone changes

For NNMi 9.1x and NNM iSPI customers in the Russian Federation, you might need to update NNMi due to changes in Russian Daylight Savings Time. See http://support.openview.hp.com/selfsolve/document/KM1254990 for more information.


09/07/2011: Do not configure IPv6 discovery on NNMi when using the HP Universal CMDB (UCMDB) integration

If you have IPv6 discovery configured on NNMi, and are using the HP Universal CMDB (UCMDB) integration, the UCMDB HP Discovery and Dependency mapping (DDM) import task fails. You need to disable IPv6 discovery to use the UCMDB integration with NNMi.


08/30/2011: Uninstalling all NNMi 9.1x patches

If the need arises to uninstall all NNMi 9.1x patches from the NNMi management server, you must run the removepatchdata.ovpl script after the uninstall completes. This is necessary to revert post-patch-install data so that you can restart the unpatched NNMi successfully.

For example, you might do the following:
  1. Run ovstop.
  2. Uninstall the NNMi patch(es).
  3. Important: cd /opt/OV/Uninstall/NNM_9.10_patch1 (UNIX) or cd C:\install_dir\Uninstall\NNM_9.10_patch1 (Windows).
  4. Run removepatchdata.ovpl.

There is no need to run the removepatchdata.ovpl script in the following situations:


08/29/2011: NNMi 9.1x and NNM iSPI Performance for Metrics Software must have equivalent versions:


08/05/2011: Before installing or upgrading to NNMi 9.10, import the HP Public Key into the Linux RPM database

If you are installing NNMi 9.10 on a Linux NNMi management server (including both manual and silent installations), you must import the HP public key into the Linux RPM database before installing NNMi 9.10. To do this, follow the instructions at http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPLinuxCodeSigning.


08/05/2011: An interactive version of the NNMi 9.10 Installation Guide is now available

There is now an interactive version of the NNMi 9.10 installation guide located at http://support.openview.hp.com/selfsolve. You will need to supply your HP Passport credentials. To register for an HP Passport user ID, point your browser to the following URL: http://h20229.www2.hp.com/passport-registration.html.


07/13/2011: High Availability Windows 2008 NNMi Management Servers need additional configuration after upgrading to 9.1x

When upgrading from NNMi 9.0x to NNMi 9.10 in an HA configuration, the secondary node might not successfully start up. To avoid problems during startup on the secondary node, run the following command prior to starting the upgrade:

    cluster res <APP resource> /props DeadlockTimeout=1800000

Substitute the actual value of the HA APP resource for the parameter <APP resource>. The APP resource name is available from the Failover Cluster Manager tool.


07/05/2011: NNMi factory-installed automatic incident actions do not work on Linux NNMi management server

NNMi factory-installed automatic incident actions do not work on Linux NNMi management servers. To correct this, add the directory path $NnmDataDir/shared/nnm/actions to the $PATH environment variable for the user that runs ovstart.


07/05/2011: Known Problem - NNMi factory-installed rateCorrelation Management event does not support Enrichment or Suppression

The rateCorrelation Management Event does not support Enrichment or Suppression.


07/05/2011: HP NNMi/HP Arcsight Integration problem with UDP

The Integration between HP NNMi and HP ArcSight currently intermittently drops Syslog messages flowing from Logger into NNMi through the Logger Forwarding NNMi Connector. It is highly recommended that you use TCP as the protocol for the communication between Logger and the Logger Forwarding NNMi Connector.


07/05/2011: Database Index Improvement Steps

These are steps to add indexes to the database that improve GUI performance and resolves contention between parts of ovjboss. There is also a separate script to delete the indexes in the case of issues. While it is not necessary to stop ovjboss during this process, it is recommended that ovjboss be stopped in order to avoid potential database contention when adding or deleting the indexes. For App Failover customers, only the active node needs to have the fix applied.

In order to apply the indexes to Postgres, run the following commands(note, running the ANALYZE command can take many minutes to execute):

  1. Unix:

  2. Windows:

To apply the indexes to the Oracle database:

  1. Copy $NnmInstallDir/support/database/nnmi.910.newindexes.sql file to the Oracle database server and run:

While very unlikely, it is possible that database corruption issues might exist due to the missing indexes. Applying the indexes might cause ovjboss to have problems resulting in with high CPU or very poor GUI performance if database corruption has occurred. To remove the indexes, do the following:

In the event of issues after applying the index fix, contact HP Support to analyze the database corruption issues.

07/05/2011: NNMi may show phantom connections with a connection source of FDB

NNMi 9.1x Patch 1 includes some changes that prevent the creation of phantom connections with connection source FDB.  However, those connections that already exist in the database will remain. The following steps clean out and re-calculate all FDB connections in an effort to remove those phantom connections.

In order to remove these phantom connections, do the following steps using the new script nnml2maint.ovpl (found in /opt/OV/support on Unix, and %NnmInstallDir%\support on Windows):

  1. nnml2maint.ovpl deleteAllFDBConnections
  2. nnml2maint.ovpl reAnalyzeAllWorkingSets

The first script example removes all existing FDB connections in the NNMi database. The second script example schedules the FDB connections to be recalculated. This recalculation may take from 15 minutes up to a few hours to complete, depending on the size of the NNMi database.


05/02/2011: NNMi 9.0x Patch 3 fails installation on Unix High Availability Systems

NNMi 9.0x Patch 3 fails to install on Unix High Availability Systems. The Patch 3 install does not correctly check for the maintenance file when installing. To fix this, create the following files:

Once Patch 3 is installed, these files can be removed.


04/21/2011: NNMi 9.0x can hang if /etc/hosts is not configured for 127.0.0.1

The installation of NNMi can hang if the loopback entry for 127.0.0.1 is not in the /etc/hosts file. This is mostly on Linux operating systems. To correct this, add an entry:

    127.0.0.1 loopback

at the top of the /etc/hosts file and reinstall the product.


04/27/2011: Upgrading from NNMi 9.0x to NNMi 9.10 on HP-UX can cause "empty" database if iSPIs are installed on the system (QCCR1B87930)

During upgrade from NNMi 9.0x to 9.10, on the HPUX platform only, the embedded database is upgraded from a 32-bit version to a 64-bit version. Prior to install, the database is backed up, using the NNMi 9.0 (32-bit) binaries. After install the database is re-loaded using the new (64-bit) binaries. This re-load fails if iSPIs are also installed on the same system.

The symptom is that when NNM is restarted after the upgrade, nothing is displayed in the UI and the database is "empty". If this problem occurs, contact HP Support to obtain a hotfix to fix this issue (QCCR1B87930).


04/21/2011: NNMi 9.10 can hang if /etc/hosts is not configured for 127.0.0.1

The installation of NNMi can hang if the loopback entry for 127.0.0.1 is not in the /etc/hosts file. This is mostly on Linux operating systems. To correct this, add an entry:

    127.0.0.1 loopback

at the top of the /etc/hosts file and reinstall the product.


04/21/2011: NNMi 9.10 will fail to create the embedded database if insufficient shared memory

Before installing NNMi, review the HP Network Node Manager i Software System and Device Support Matrix for shared memory requirements. NNMi might not create the embedded database if there is insufficient shared memory.


03/28/2011: NNMi displays the incorrect version of the Causal Engine Core component

When using the Help > System Information > Component Versions menu to view component versions, NNMi shows the Causal Engine Core component as version 09.00.010.031. This is incorrect, as NNMi contains Causal Engine Core component version 09.10.000.031.


03/28/2011: Upgrading from NNMi 9.0x to NNMi 9.10 does not migrate all Custom Poller Collection configurations

During an upgrade to NNMi 9.10, Custom Poller collections with threshold settings that contain either high or low thresholds, but not both or neither, do not migrate to the NNMi management server being upgraded. If this issue occurs during the upgrade, the upgrade script displays an error stating that the database schema was successfully upgraded, but that some configuration data might not have upgraded successfully. To avoid this issue, record the threshold settings for each of these Custom Poller collections before upgrading to NNMi 9.10, as they will be lost during the migration. After the migration, open each of these Custom Poller collections and re-enter the threshold values. When you re-enter the threshold values into NNMi 9.10, notice that the form is slightly different. Make sure to set the Threshold Setting Type to Count when re-entering the threshold values. Make sure to select the Enable Custom Poller selection box from the Custom Poller Configuration screen. Save your changes.


03/24/2011: Upgrading from NNMi 9.0x to NNMi 9.10 changes parameters in the ovjboss.jvmargs file

During an upgrade from NNMi 9.0x to 9.10, one or more of the parameters contained in the %NnmDataDir%\shared\nnm\conf\props\ovjboss.jvmargs (Windows) or $NnmDataDir/shared/nnm/conf/props/ovjboss.jvmargs (UNIX) file are reverted back to their default values. Before upgrading to NNMi 9.10, save a copy of the ovjboss.jvmargs file. After completing the upgrade, list the differences between the ovjboss.jvmargs file from the upgrade and the saved version of the ovjboss.jvmargs file, then make the necessary changes to the ovjboss.jvmargs file from the upgrade.


03/23/2011: Pop-up dialog issues when using Internet Explorer 8 and the Internet Explorer ESC (Enhanced Security Configuration)

Windows 2003 and Windows 2008 server offer a feature called Internet ESC (Explorer Enhanced Security Configuration) in Internet Explorer 8. After this feature is enabled (which is the case by default) all pop-up dialogs and windows are tested against a list of trusted sites. If the URL associated with the pop-up is not in the list of trusted sites, all of the controls in the dialog or window are disabled. For example, when this happens, clicking on the OK, Apply, and Cancel buttons will have no effect.

Generally, with ESC enabled, whenever the user opens a dialog, the user is prompted as to whether the URL associated with pop-up should be allow as a trusted site. The user must allow the URL. If the user does not allow the URL, the dialog controls will not work and the prompt will be seen whenever the dialog or window is opened. Eventually the nagging ceases because all important URLs will have been added to the list of Trusted Sites. One special URL that must be placed in the list is about:blank.

It is possible for the user to get into a situation where the NNMi Console will not work. If, at some point, the user clicks the Don’t show me this message again checkbox in the Trusted Sites prompt, subsequent prompts will not be issued. If the user had done this before installing NNMi, the NNMi Console will hardly function. Dialogs will pop up, but the controls in the dialog will not work. For example, if the user opens the Help->About dialog, the OK button will not close the dialog. Also, all table view filter dialogs will not work. In the latter case, this is because the about:blank URL is not in the list of Trusted Sites.

The are several ways to recover from this:


03/23/2011: Show mismatched connections functionality no longer requires an NNM iSPI NET license

The show mismatched connections functionality now enabled by the HP NNMi-HP NA integration no longer requires an NNM iSPI NET license. The NNM iSPI NET Planning and Installation Guide incorrectly says that an NNM iSPI NET license enables this functionality.


©Copyright 1990-2011 Hewlett-Packard Development Company, L.P.