Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Network Node Manager i Software10.30

Administer > Modify Default Settings

Modify Default Settings

After you have your NNMi management server functioning, you can optimize several of the NNMi features by modifying default settings.

Modify Access Control Lists for NNMi Folders

You might run across situations that would cause you to modify the user name that runs the NNM Action Server as shown in Set the Action Server Name Parameter. If you change the user name that runs the action server without modifying the user name permissions, the NNM Action Server might not start, and NNMi might not log messages when running incident actions. This section includes actions to take to prevent this from happening.

NNMi (Everest) contains permission changes to the following directories:

/var/opt/OV/log/nnm/public
/var/opt/OV/shared/perfSpi

Although the NNMi Everest out-of-the-box permissions for the
/var/opt/OV/log/nnm/public folder is 755, NNMi uses ACLs to adjust access permissions for the database user (nmsdbmgr), and the nnmaction user (bin). During the NNMi Everest post-installation (part of the installation or upgrade script), the installation script changes the /var/opt/OV/log/nnm/public folder permissions and adds the ACLs.

If the installation script is unable to set the ACLs on the
/var/opt/OV/log/nnm/public folder due to some unexpected error, the script will leave the /var/opt/OV/log/nnm/public folder world-writable and the NNMi installation should complete successfully. Following a successful NNMi installation, if you want to restrict world-write permissions on the /var/opt/OV/log/nnm/public folder, see the system administration documentation for setting up ACLs for the NNMi management server’s operating system.

For the /var/opt/OV/log/nnm/public folder, use Linux ACLs (access control lists) to adjust user access. Configuring ACLs is a useful method to extend the owner/group/other permissions. ACLs are supported on all the following Linux platforms: RedHat and SuSE.

For example, after running the following command, the user depicted by the USER variable obtains write access to the /var/opt/OV/log/nnm/public folder. Without running the following command, the permissions for the /var/opt/OV/log/nnm/public folder are 755, and files within the directory are not writable by anyone other than root.

setfacl -m user:<USER>:rwx /var/opt/OV/log/nnm/public

For information about how to use the setfacl command, see the Linux manpage.

Change the Custom Poller Collections Export Directory

NNMi writes the data from the collections you export into the following directory:

Windows: %NNmDataDir%\shared\nnm\databases\custompoller\export
Linux: $NnmDataDir/shared/nnm/databases/custompoller/export

To change the directory that NNMi writes its custom poller files into, follow these steps:

Edit the following file:
- Windows: %NNM_PROPS%\nms-custompoller.properties
- Linux: $NNM_PROPS/nms-custompoller.properties
Look for the exportdir entry, which is similar to the following line:
```
#!com.hp.nnm.custompoller.exportdir=<base directory to export custom poller metrics>
```
To configure NNMi to write Custom Poller collection information into the C:\CustomPoller directory, change the line as follows:
```
com.hp.nnm.custompoller.exportdir=C:\CustomPoller
```
Restart the NNMi management server.
1. Run the ovstop command on the NNMi management server.
2. Run the ovstart command on the NNMi management server.
Changing the Maximum Amount of Disk Space for Custom Poller Collections Export

To change the maximum amount of disk space that NNMi uses when exporting data to collection_name.csv files, follow these steps:
1. Edit the following file:
  - Windows: %NNM_PROPS%\nms-custompoller.properties
  - Linux: $NNM_PROPS/nms-custompoller.properties
2. Look for the maxdiskspace entry, which is similar to the following line:
```
#!com.hp.nnm.custompoller.maxdiskspace=1000
```
  To configure NNMi to reserve up to 2000 MB (2 GB) of storage space for each collection_name.csv file, change the line as follows:
```
com.hp.nnm.custompoller.maxdiskspace=2000
```
3. Restart the NNMi management server.
  1. Run the ovstop command on the NNMi management server.
  2. Run the ovstart command on the NNMi management server.

Configure Incident Actions

You can configure actions to automatically run at any point in the incident lifecycle. For example, you might want to configure an action to occur when an incident of the type you are configuring is generated. To adjust action parameters, follow the steps shown in the following sections.

To avoid undesirable results (such as unintended memory growth, slower event action processing time), recommends that you do not change the default property values for event action processing.

Set the Number of Simultaneous Actions

To modify the number of simultaneous actions that NNMi can run, follow these steps:

Edit the following file:
- Windows: %NNM_PROPS%\shared\nnmaction.properties
- Linux: $NNM_PROPS/shared/nnmaction.properties
Look for a line the resembles the following:
```
#!com.hp.ov.nms.events.action.numProcess=10
```
To configure NNMi to enable 20 simultaneous actions instead of the default value, change the line as follows:
```
com.hp.ov.nms.events.action.numProcess=20
```
Make sure to remove the #! characters located at the beginning of the line.
Restart the NNMi management server.
1. Run the ovstop command on the NNMi management server.
2. Run the ovstart command on the NNMi management server.

Set the Number of Threads for Jython Actions

To modify the number of threads the action server uses to run jython scripts, follow these steps:

Edit the following file:
- Windows: %NNM_PROPS%\shared\nnmaction.properties
- Linux: $NNM_PROPS/shared/nnmaction.properties
Look for a line that resembles the following:
```
#!com.hp.ov.nms.events.action.numJythonThreads=10
```
To configure NNMi to enable 20 threads for running jython scripts instead of the default value, change the line as follows:
```
com.hp.ov.nms.events.action.numJythonThreads=20
```
Make sure to remove the #! characters located at the beginning of the line.
Restart the NNMi management server.
1. Run the ovstop command on the NNMi management server.
2. Run the ovstart command on the NNMi management server.

Set the Action Server Name Parameter

If you have an NNMi management server running on a Windows operating system, the NNM Action Server runs as a windows service with a Local System account. That means you must use the Local System account to run action server actions.

To modify the user name that runs the NNM Action Server windows service on a Windows NNMi management server, change the LogOn property of the NNM Action Server service.

If you have an NNMi management server running on a Linux operating system, the action server runs with a bin user name. To modify the user name that runs the action server on these operating systems, complete the following steps:

Edit the following file:
```
$NNM_PROPS/nnmaction.properties
```
Look for a line the resembles the following:
```
#!com.hp.ov.nms.events.action.userName=bin
```
To configure NNMi to have root run the action server instead of the default value, change the line as follows:
```
com.hp.ov.nms.events.action.userName=root
```
Make sure to remove the #! characters located at the beginning of the line.
Save your changes.
Restart the action server:
1. Run the ovstop nnmaction command on the NNMi management server.
2. Run the ovstart nnmaction command on the NNMi management server.

Change the Action Server Queue Size

For actions that use a long action command string at a high execution rate, such as responding to a trap storm, the action server can use up a lot of memory. To provide better action server performance, places limits on the memory size to which the action server can grow.

To modify these limits, follow these steps:

Edit the following file:
- %NNM_PROPS%\shared\nnmaction.properties
- $NNM_PROPS/shared/nnmaction.properties
Look for two lines that resemble the following:
- com.hp.ov.nms.events.action.jvmargs.minMemsize=-Xms6m
- com.hp.ov.nms.events.action.jvmargs.maxMemsize=-Xmx30m
The above parameters show the minimum memory size set to 6MB and the maximum set to 30MB. Adjust these parameters to meet your needs.
Save your changes.
Restart the NNMi management server.
1. Run the ovstop command on the NNMi management server.
2. Run the ovstart command on the NNMi management server.

Incident Actions Log

When an action runs, output is logged to the associated Incident Actions Log file. To view the contents of the log for a selected incident, use the Tools > Incident Actions Log menu option. The following table describes the items contained in the log:

Incident Actions Log Items
Item	Description
Command	Script to run when incident occurs
Incident Name	Name of incident as defined in incident configuration
Incident UUID	The UUID of the incident (from Registration tab)
Command Type	Type of command (Jython or ScriptOrExecutable)
Lifecycle State	Lifecycle state of the incident (Registered, In Process, Completed, or Closed)
Exit Code	Return code of the command (similar to an error code)
Standard Output	Standard output of the action
Standard Error	Standard error output
Execution Status	The determined status per the action

Overriding Settings in the server.properties File

Note that a system might have two server.properties files.

The following file is created by the product installer and contains properties that customize the application server for the application instance. This file is not modified by customers and is replaced during code maintenance (upgrades and patches).

Windows: %NnmDataDir%\NNM\server\server.properties

Linux: $NnmDataDir/NNM/server/server.properties

The following file is used by customers to configure the application for their environment and will not be modified by the product during upgrades or patches. This file overrides values configured in other files. So all customizing is done in this file.

Windows:%NnmDataDir%\nmsas\NNM\server.properties

Linux:$NnmDataDir/nmsas/NNM/server.properties

This section describes how to override the following settings in the nmsas/NNM/server.properties file:

Override the Browser Locale Setting
Configure the Locale for Sort Order of User Names when Assigning Incidents
Configure SNMP Set Object Access Privilege
Configure NNMi to Require Encryption for Remote Access

Override the Browser Locale Setting

You can use the following server.properties file to force the given Locale value for all NNMi clients regardless of the browser Locale value:

Windows:%NnmDataDir%\nmsas\NNM\server.properties

Linux:$NnmDataDir/nmsas/NNM/server.properties

When this value is set using the server.properties file, the browser Locale value is ignored.

To override the browser Locale setting:

Open the server.properties file:

Windows:%NnmDataDir%\nmsas\NNM\server.properties

Linux:$NnmDataDir/nmsas/NNM/server.properties
Navigate to nmsas.server.forceClientLocale.
Set nmsas.server.forceClientLocale to either of the following:

nmsas.server.forceClientLocale= <two-letter ISO Language code>

For example, to set the Locale to English using only the ISO Language code, enter the following:
```
nmsas.server.forceClientLocale = en
```
nmsas.server.forceClientLocale= <two-letter ISO Language code>_<two-letter ISO country code>

For example, to set the Locale to English using the ISO Language and Country codes, enter the following:
```
nmsas.server.forceClientLocale = en_US
```
Restart the NNMi ovjboss service:

Run the ovstop ovjboss command on the NNMi management server.

Run the ovstart command on the NNMi management server.

Configure the Locale for Sort Order of User Names when Assigning Incidents

An NNMi administrator can specify the language locale for the NNMi management server that should be used to determine the sort order of user names when assigning incidents.

The configured sort order locale is applied only to the Assign Incidents dialog.

When determining alphabetical order, NNMi uses the user display name rather than the actual login name and does not sort capital letters separately from lowercase.

NNMi uses only the locale configured in sortLocale for determining sort order. The browser locale specified in the forceClientLocale property does not affect the sort order.

When making file changes under High Availability (HA), the location of the server.properties file that you need to update is: <Shared_Disk>/NNM/dataDir/nmsas/NNM/server.properties.

To configure the language locale to use for the sort order for the user names listed when you assign an incident, edit the server.properties file as follows:

Open the following file:
- Windows: %NnmDataDir%\nmsas\NNM\server.properties
- Linux: $NnmDataDir/nmsas/NNM/server.properties
Uncomment the following line in the server.properties file:

#nmsas.server.sortLocale = en_US
Change the default value to the correct locale for your NNMi management server. For example, to change the locale to the Russian language, use the following entry:

nmsas.server.sortLocale = ru_RU
Restart the NNMi management server.
1. Run the ovstop command on the NNMi management server.
2. Run the ovstart command on the NNMi management server.

Configure SNMP Set Object Access Privilege

You can use the following file to configure the Object Access Privilege required for using the SNMP Set feature on the nodes to which users have access:

Windows: %NnmDataDir%\nmsas\NNM\server.properties

Linux: $NnmDataDir/nmsas/NNM/server.properties

See the NNMi Help for Operators for more information about the SNMP Set feature. See the NNMi Help for Administrators for more information about Object Access Privileges.

To configure the Object Access Privilege for the SNMP Set feature:

Open the server.properties file:

Windows:%NnmDataDir%\nmsas\NNM\server.properties

Linux:$NnmDataDir/nmsas/NNM/server.properties
Add the following line:

permission.override.com.hp.nnm.SNMP_SET=<object access role>

Valid values for <object access role> include the following:
```
com.hp.nnm.ADMIN
```
```
com.hp.nnm.LEVEL2
```
```
com.hp.nnm.LEVEL1
```
```
com.hp.nnm.GUEST
```
For example, to enable Object Administrator and Object Operator Level 2 Object Access Privileges to use the SNMP Set feature, type the following:
```
permission.override.com.hp.nnm.SNMP_SET=com.hp.nnm.ADMIN,com.hp.nnm.LEVEL2
```
Include each Object Access Privilege for which you want to enable access.
Restart the NNMi ovjboss service:
1. Run the ovstop ovjboss command on the NNMi management server.
2. Run the ovstart command on the NNMi management server.

Configure NNMi to Require Encryption for Remote Access

An administrator can disable HTTP and other unencrypted access from the network to NNMi.

Before configuring NNMi to permit only encrypted remote access, make sure Global Network Management, NNM iSPIs, and other integrations support SSL. Configure them for SSL before configuring NNMi to permit only encrypted remote access.

Do not perform this task if you want to and are yet to configure the application failover cluster. After setting up the NNMi application failover cluster, you can complete these steps to disable HTTP and other unencrypted access.

To disable HTTP and other unencrypted access from the network to NNMi, edit the server.properties file as follows:

Edit the following file (you may need to create it if it does not exist):
- Windows: %NnmDataDir%\nmsas\NNM\server.properties
- Linux: $NnmDataDir/nmsas/NNM/server.properties

Add the following four lines to the server.properties file:

nmsas.server.net.bind.address = 127.0.0.1

nmsas.server.net.bind.address.ssl = 0.0.0.0

nmsas.server.net.hostname = localhost

nmsas.server.net.hostname.ssl = ${com.hp.ov.nms.fqdn}

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

With the modification just described, NNMi will not “listen” to HTTP requests from a remote system; however, HTTP requests would still be supported for localhost access.

Modify User Interface Properties

This section describes how to set the following user interface properties in the ui.properties file:

Modify NNMi Gauge Titles to Show SNMP MIB Variable Names
Modify MIB Browser Parameters
Enable Level 2 Operators to Delete Nodes and Incidents
Enable Level 2 Operators to Edit Node Group Maps
Enabling Level 1 Operators to Run Status and Configuration Polls

Modify NNMi Gauge Titles to Show SNMP MIB Variable Names

The Node Sensor Gauges and Physical Sensor Gauges tabs in the NNMi analysis pane contains gauges showing the NNMi component name as the MIB OID being polled. This helps you understand which gauge goes with which component. The Node Sensor name helps differentiate gauges if NNMi shows many gauges for a node. For example, if a node contains a large number of CPUs, NNMi shows different names for the individual CPUs.

With this feature disabled, NNMi shows the SNMP MIB variable name to be the same for all CPUs.

If you want to change this property to show gauge titles as SNMP MIB variable names rather than NNMi Node Sensor names, complete the following steps:

Edit the following file:
- Windows: %NNM_PROPS\nms-ui.properties
- Linux: $NNM_PROPS/nms-ui.properties

Locate the text block containing the following line:

com.hp.nnm.ui.analysisGaugeTitleIsNodeComponentName = true

Edit the following line to read as follows:

com.hp.nnm.ui.analysisGaugeTitleIsNodeComponentName = false

Save your changes.
Restart NNMi:
1. Run the ovstart command on the NNMi management server.
2. Run the ovstop command on the NNMi management server.

When making file changes under High Availability (HA), you need to 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.

Modify MIB Browser Parameters

If you use the NNMi MIB browser (Action > MIB Information > Browse MIB menu) to obtain information about a node, and provide an optional SNMP community string for that node, the NNMi MIB browser uses MIB browser parameters located in the nms-ui.properties file for MIB Browser SNMP communication.

If you do not provide a community string when using the MIB Browser, NNMi uses the Communication Configuration settings established for the node (if any). These settings are configured in the NNMi console using the Communications Settings view in the Configuration workspace.

To modify the MIB Browser parameters in the nms-ui.properties file, follow these steps:

Edit the following file:
- Windows: %NNM_PROPS\nms-ui.properties
- Linux: $NNM_PROPS/nms-ui.properties
Locate the text block containing the following line:
```
# MIB Browser Parameters
```
Locate the MIB browser parameters located below # MIB Browser Parameters by searching for lines containing the following text:
```
mibbrowser
```
Modify the MIB browser parameters by following instructions within the nms-ui.properties file.
Save your changes.
Restart NNMi:
1. Run the ovstop command on the NNMi management server.
2. Run the ovstart command on the NNMi management server.

Enable Level 2 Operators to Delete Nodes and Incidents

By default, NNMi permits NNMi administrators to create, edit, or delete nodes or incidents in NNMi. You can configure accounts assigned to the NNMi Operator Level 2 (L2) User Group to have the ability to delete nodes or incidents. You can achieve this by using one of the following methods:

(Recommended) Elevate the privileges of the required L2 users to delete the required nodes or incidents. This can be done using the NNMi web console. For more information, see the NNMi Admin help.
Configure NNMi to globally enable L2 users to delete nodes or incidents. This can be done by overriding the default privileges by modifying certain NNMi property files.

Use the override method only for enabling settings globally. Once enabled, you cannot control L2 user access privileges in the NNMi web console.

To enable L2 users to edit or delete nodes, their associated incidents, or both, follow these steps:

Open the following file:

Windows: %NNM_PROPS%\nms-topology.properties

Linux: $NNM_PROPS/nms-topology.properties
Append the following lines as required:
- To enable L2 users to delete nodes, append the following line:
  
  permission.override.com.hp.nnm.DELETE_OBJECT=com.hp.nnm.ADMIN,com.hp.nnm.LEVEL2
- To enable L2 users to delete incidents, append the following line:
  
  permission.override.com.hp.nnm.incident.DELETE=com.hp.nnm.ADMIN,com.hp.nnm.LEVEL2
Save the file.
Restart NNMi.
- Run the ovstop command on the NNMi Management Server.
- Run the ovstart command on the NNMi Management Server.

Enable Level 2 Operators to Edit Node Group Maps

By default, NNMi permits NNMi administrators to edit maps by creating, modifying, and deleting Node Groups. You can configure accounts assigned to the NNMiOperator Level 2 User Group to have this ability as well.

If you must change NNMi to permit User Accounts assigned to the NNMi Operator Level 2 User Group to create, modify, and delete Node Groups on nodes to which they have access, do the following:

Open the following file:

Windows: %NNM_PROPS%\nms-ui.properties

Linux: $NNM_PROPS/nms-ui.properties
Search for the following text block and uncomment it.
```
#!com.hp.nnm.ui.level2MapEditing = true
```
Save your changes.
Restart NNMi:
1. Run the ovstart command on the NNMi management server.
2. Run the ovstop command on the NNMi management server.

After completing step 1 through step 4, the NNMiconsole changes as follows:

The Inventory > Node Group menu shows a create and Delete toolbar icon for the NNMi Operator Level 2.
The Inventory > Node Group menu contains an Action > Delete menu item for the NNMi Operator Level 2.
The All Node Groups folder appears in the Toplogy Maps workspace. See "About Workspaces" in the NNMi online help for more information.
For Node Group maps, the NNMi console contains the Save Layout toolbar button and File > Save Layout menu items.
The behavior of the Save Layout Action menu depends on the whether Node Group Map setting are configured for the Node Group map. If no Node Group Map Setting exists for a Node Group map, you must create one.

You can also configure NNMi so that NNMi Operator Level 2 users have permission to create a Node Group Map Setting:

From the NNMi console, open Topology Maps> Node Group Overview.
Double-click the Node Group of interest.

NNMi opens the Node Group map associated with the selected Node Group.
Open the Node Group Map Settings you want to modify:

Select File > Open Node Group Map Settings.
Set the Minimum NNMi Role to Save Layout to Operator Level 2.
Save your changes.

The NNMi Operator Level 2 can now create, edit and delete Node Group Map Settings from a Node Group Map view.

Enabling Level 1 Operators to Run Status and Configuration Polls

NNMi permits User Accounts assigned to the NNMi Operator Level 2 User Group to run Status Poll and Configuration Poll on nodes to which they have access. You must change the Menu Item configuration in the NNMi console as well as the Object Access Privilege levels in the nms-topology.properties file for each.

To change the Menu Item configuration NNMi to permit User Accounts assigned to the NNMi Operator Level 1 User Group to view the Status Poll menu item, do the following:

Open the Configuration->User Interface->Menu Items->Status Poll form.
From the Menu Items tab, scroll to the Status Poll menu item label.
From the Menu Item Contexts tab, open the entry for each Required NNMi Role and Object Type item you must change.
Change the value of the Required NNMi Role to Operator Level 1 for each object type you want a Level 1 operator to be able to status poll.

This step enables the User Accounts assigned to the NNMi Operator Level 1 User Group to view the Status Poll Action for the Object Type specified.

To change NNMi to permit User Accounts assigned to the NNMi Operator Level 1 User Group to view the Configuration Poll menu item, do the following:

Open the Configuration->User Interface->Menu Items->Configuration Poll form.
From the Menu Item Contexts tab, open the entry for each Required NNMi Role and Object Type item you must change.
Change the value of the Required NNMi Role to Operator Level 1 for each object type you want a Level 1 Operator to be able to configuration poll.

This step enables the User Accounts assigned to the NNMi Operator Level 1 User Group to view the Configuration Poll Action for the Object Type specified.

You must edit the nms-topology.properties file to permit User Accounts assigned to the NNMiOperator Level 1 User Group to run both the Status Poll and Configuration Poll commands from the NNMi console. If you do not complete these steps, NNMi displays the Status Poll and Configuration Poll options in the Actions menu, but the user views an error message when attempting to run the Status Poll or Configuration Poll commands.

To change the level of access required for the status poll and configuration poll (the required Object Access Privilege levels),

Open the following file:

Windows: %NNM_PROPS%\nms-topology.properties

Linux: $NNM_PROPS/nms-topology.properties

Scroll to the bottom of the file, then add the following line for the Status Poll change:

permission.override.com.hp.nnm.STATUS_POLL=com.hp.nnm.ADMIN,com.hp.nnm.LEVEL2,com.hp.nnm.LEVEL1

Add the following line for the Configuation Poll change:

permission.override.com.hp.nnm.CONFIG_POLL=com.hp.nnm.ADMIN,com.hp.nnm.LEVEL2,com.hp.nnm.LEVEL1

Save your changes.
Restart the NNMi management server:
1. Run the ovstop command on the NNMi management server.
2. Run the ovstart command on the NNMi management server.

Configure the Data Payload Size in an ICMP Echo Request Packet

One definition of network latency is the time for an ICMP packet to complete a round trip to the target device and back. A low latency measurement indicates a more efficient network.

One common way to test network latency is to adjust the ICMP polling frequency and ICMP echo request packet data payload size for a management address being managed by NNMi. Considering that a larger packet has a longer network latency than a smaller one, NNMi permits you to experiment with different packet sizes to measure the network latency.

You can configure the size of the data payload NNMi sends in an ICMP echo request packet for IP addresses that belong to nodes in a node group or interfaces in an interface group. For example, you might modify the size of the ICMP echo request packets sent to node groups or interface groups in conjunction with adjusting management address polling times to compare network latency.

To configure a different payload size for addresses that belong to nodes in a node group and interfaces in an interface group, complete the following steps:

Edit the following file:

Windows: %NNM_PROPS%\nms-mon-config.properties

Linux: $NNM_PROPS/nms-mon-config.properties
Locate the text block containing the following:
```
#!com.hp.nnm.icmp.payload.sizeInBytes=4096
```
Uncomment and edit the line to read as follows, changing the 4096 value to the payload value you need:
```
com.hp.nnm.icmp.payload.sizeInBytes=4096
```
The minimum value to use for the sizeInBytes parameter is 12 bytes and the maximum value is 65492 bytes.

Note To configure the data payload size at least one of the group properties must be defined. If neither of the group properties are defined as described in the following steps, NNMi ignores the com.hp.nnm.icmp.payload.sizeInBytes property.

Locate the text block containing the following:
```
#!com.hp.nnm.icmp.nodegroup.name=My Node Group
```
Uncomment and edit the line to read as follows, changing the My Node Group setting to the node group you plan to reference by NNMi monitoring settings:
```
com.hp.nnm.icmp.nodegroup.name=My Node Group
```
Note The node group name you specify needs to be a node group referenced by NNMi monitoring settings.

Locate the text block containing the following:

#!com.hp.nnm.icmp.ifacegroup.name=My Interface Group

Uncomment and edit the line to read as follows, changing the My Interface Group setting to the interface group you plan to reference by NNMi monitoring settings:
```
com.hp.nnm.icmp.ifacegroup.name=My Interface Group
```
Note The interface group name you specify needs to be an interface group referenced by NNMi monitoring settings.
Restart the NNMi management server

Run the ovstop command on the NNMi management server:

Run the ovstart command on the NNMi management server.

Configure how NNMi Determines the Host Name for a Device

You can change the HostNameMatchManagementIP property to false to configure NNMi to use the pre- NNMi 9.0 method of finding a valid host name for a discovered device.

Tip In most cases, keep the default value of this property, which is true. See the nms-disco.properties file for detailed information about the HostNameMatchManagementIP property.

To change the HostNameMatchManagementIP property to false, do the following:

Edit the following file:

Windows: %NNM_PROPS%\nms-disco.properties

Linux: $NNM_PROPS/nms-disco.properties
Search for the text block containing the following property:
```
HostNameMatchManagementIP=true
```
Change the property value as follows:
```
HostNameMatchManagementIP=false
```
Save your work.
Restart the NNMi management server:

Run the ovstop command on the NNMi management server.

Run the ovstart command on the NNMi management server.

NNMi looks up all available IP addresses on loopback interfaces to find a valid host name for a discovered device.

Configure Character Set Encoding Settings for NNMi

Depending on the locale configured for your NNMi management server, you might need to configure the source encoding NNMi uses to interpret SNMP OCTETSTRING data. To do this, edit the nms-jboss.properties file as follows:

Edit the following file:
- Windows: %NNM_PROPS%\nms-jboss.properties
- Linux: $NNM_PROPS/nms-jboss.properties
Search for the text block containing the following line:
```
#!com.hp.nnm.sourceEncoding=UTF-8
```
Uncomment and edit the following line to read as follows:
```
com.hp.nnm.sourceEncoding=UTF-8
```
Modify the UTF-8 property value shown in step 3 using tshe instructions and examples shown in the nms-jboss.properties file.
Save your changes.
Restart the NNMi management server:

Run the ovstop command on the NNMi management server.

Run the ovstart command on the NNMi management server.

When making file changes under High Availability (HA), you need to 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.

Configure the Time NNMi Waits for an NNM iSPI Licensing Request

If you notice a slow or non-response from the NNMi console, and have one or more of the NNM iSPIs installed, you might need to adjust the amount of time NNMi waits for a response from an NNM iSPI licensing request.

The default amount of time NNMi waits for a response from an NNM iSPI licensing request is 20 seconds.

To change this default value, complete the following steps:
1. Open the following file:
  
  Windows: %NNM_PROPS%\nms-jboss.properties
  
  Linux: $NNM_PROPS/nms-jboss.properties
2. Locate the text block containing the following:
```
#!com.hp.ov.nms.licensing.EXTENSION_WAIT_TIMEOUT=20
```
3. Uncomment and modify the line to read as follows:
```
com.hp.ov.nms.licensing.EXTENSION_WAIT_TIMEOUT=<time in seconds>
```
  For example, to change the response time to 25 seconds, enter the following:
```
com.hp.ov.nms.licensing.EXTENSION_WAIT_TIMEOUT=25
```
  Tip Adjusting this parameter to the optimum value could take some experimenting. Adjust the parameter to a higher value for slower responding NNM iSPIs, such as an overly busy NNM iSPI running on a slower server.
4. Restart the NNMi management server
  
  Run the ovstop command on the NNMi management server.
  
  Run the ovstart command on the NNMi management server
Modify NNMi Normalization Properties

NNMi stores both hostnames and node names in case-sensitive form. This means that all searches, sorts, and filters that the NNMi console provides return case-sensitive results. If the DNS servers you use return a variety of case-preserving node names and hostnames, including all uppercase, all lowercase, and a mixture of uppercase and lowercase, this can cause less-than-optimal results.

You can change several NNMi normalization properties to meet your specific needs. A good practice is to make these changes before seeding NNMi for its initial discovery. recommends that you adjust the settings in this section during deployment, but before running the initial discovery.

If you run an initial discovery, then decide to change the normalization properties later, you can run the nnmnoderediscover.ovpl -all script to initiate a full discovery. See the nnmnoderediscover.ovpl reference page, or the Linux manpage, for more information.

You can change the following properties:
- Normalize discovered node names to UPPERCASE, LOWERCASE, or OFF.
- Normalize discovered hostnames to UPPERCASE, LOWERCASE, or OFF.
To change normalization properties follow these steps:
1. Edit the following file:
  - Windows: %NNM_PROPS%\nms-topology.properties
  - Linux: $NNM_PROPS/nms-topology.properties
2. To configure NNMi to normalize discovered names, look for a line the resembles the following:
```
#!com.hp.ov.nms.topo.NAME_NORMALIZATION=OFF
```
  1. Un-comment the property:
```
com.hp.ov.nms.topo.NAME_NORMALIZATION=OFF
```
    Note To un-comment a property, remove the #! characters from the beginning of a line.
  2. Change OFF to LOWERCASE or UPPERCASE.
  3. Save your changes.
3. To configure NNMi to normalize discovered hostnames, look for a line the resembles the following:
```
#!com.hp.ov.nms.topo.HOSTNAME_NORMALIZATION=OFF
```
  1. Un-comment the property:
```
com.hp.ov.nms.topo.HOSTNAME_NORMALIZATION=OFF
```
  2. Change OFF to LOWERCASE or UPPERCASE.
  3. Save your changes.
4. Restart the NNMi management server.
  1. Run the ovstop command on the NNMi management server.
  2. Run the ovstart command on the NNMi management server.
When making file changes under High Availability (HA), you need to 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.

Suppress the Use of Discovery Protocols for Specific Nodes

NNMiuses several protocols to discover layer 2 connectivity between and among network devices. There are many defined discovery protocols. For example, Link Layer Discovery Protocol (LLDP) is an industry standard protocol, while there are many vendor-specific protocols like Cisco Discovery Protocol (CDP) for Cisco devices.

You can configure NNMi to suppress discovery protocol collections for devices you specify. There are special circumstances that might be remedied by suppressing discovery protocol collections.

If you want to suppress this discovery protocol collection, follow these steps:

Create the following file:
- Windows: %NnmDataDir%\shared\nnm\conf\disco\disco.SkipXdpProcessing
- Linux: $NnmDataDir/shared/nnm/conf/disco/disco.SkipXdpProcessing
The disco.SkipXdpProcessing file is case-sensitive.
Add the device IP addresses to the disco.SkipXdpProcessing file for all of the devices you want to suppress protocol collection for. Follow the instructions show in the disco.SkipXdpProcessing reference page, or the Linux manpage.
Restart the NNMi management server.
1. Run the ovstop command on the NNMi management server.
2. Run the ovstart command on the NNMi management server.
Suppressing the discovery protocol processing of a node or nodes might cause some inaccuracies in the layer 2 layout of the managed network. is not responsible for these inaccuracies.

The ovjboss service reads the disco.SkipXdpProcessing file on startup. If you make any changes after starting NNMi, restart NNMi as shown in this step.

If you ran the setsnmp timefilter break command on any Enterasys devices, remove the device addresses from the disco.SkipXdpProcessing file, then restart NNMi as shown in this step. NNMi displays more accurate layer 2 maps when it uses discovery protocols.

See the disco.SkipXdpProcessing reference page, or the Linux man page, for more information.

Suppress the Monitoring of IP Addresses on Administrative Down Interfaces

NNMi users commonly configure multiple interfaces with the same IP addresses, where one interface is administratively up and its address is responding to ICMP requests, and the other interface is administratively down and not responding to ICMP requests. In such cases, these administratively down interfaces and their IP addresses should not affect node status.

By default,NNMi suppresses the monitoring of IP addresses on interfaces that are administratively down, thereby preventing node status changes.

You can configure whether the monitoring of IP addresses on administratively down interfaces is performed by doing the following:

Open the nms-disco.properties file in the following location:

Windows: %NnmDataDir%\shared\nnm\conf\props\nms-disco.properties

Linux: $NnmDataDir/shared/nnm/conf/props/nms-disco.properties

Look for a section in the file that resembles the following:

#!com.hp.ov.nms.disco.suppressMonitoringOfAddressOnAdminDownInterface=true

You can configure the property as follows:

To suppress monitoring of IP addressees on interfaces that are administratively down, uncomment the line to set the property to true (the default setting). The line should resemble the following:
```
com.hp.ov.nms.disco.suppressMonitoringOfAddressOnAdminDownInterface=true
```
To have NNMi monitor IP addresses on interfaces that are administratively down, uncomment the line and edit the property value as follows:
```
com.hp.ov.nms.disco.suppressMonitoringOfAddressOnAdminDownInterface=false
```
Save your changes to the nms-disco.properties file.
Restart the NNMi management server:

Run the ovstop command on the NNMi management server.

Run the ovstart command on theNNMi management server.

Suppress the Use of VLAN-indexing for Large Switches

One of the methods NNMi uses to learn layer 2 connectivity between and among switch devices in a managed network is to retrieve the dot1dTpFdbTable (FDB) from the switches. However, for Cisco switches, NNMi must use a VLAN-indexing method to retrieve the entire FDB. If there is a large number of VLANs configured on each device, retrieving the FDB with VLAN-indexing might take hours to complete.

Cisco switches are often configured to use the Cisco Discovery Protocol (CDP). CDP is considered to be a superior method for learning Layer 2 connectivity. Large switches located in the in the core of the network might contain many VLANs. These switches typically do not have end nodes connected directly to them. If the switches you want to manage do not have end nodes connected directly to them, you might want to suppress the collection of the FDB on these large switches. NNMi still completes the Layer 2 discovery using data collected from CDP. These large switches are prime candidates for suppression of VLAN-indexing. Do not suppress VLAN-indexing on smaller switches located at the network's edge (often known as access switches) that have many end nodes attached to them.

You can configure NNMi to suppress VLAN-indexing. To do this, the NNMiadministrator needs to create and add management addresses or address ranges of the large switches to the disco.NoVLANIndexing file. The ovjboss service reads the disco.NoVLANIndexing file when it starts. If the NNMi administrator makes changes to the disco.NoVLANIndexing file after the ovjboss service starts, those changes will not take effect until the next time the ovjboss service starts. By default, the disco.NoVLANIndexing file does not exist. If the disco.NoVLANIndexing does not exist, this feature is disabled and NNMi attempts to use VLAN-indexing to collect the entire FDB table on all devices.

If you want to disable this vlan-indexing, follow these steps:

Note Suppressing vlan-indexing of a node or nodes might cause some inaccuracies in the layer 2 layout of the managed network. is not responsible for these inaccuracies.

Create the following file:
- Windows: %NnmDataDir%\shared\nnm\conf\disco\disco.NoVLANIndexing
- Linux: $NnmDataDir/shared/nnm/conf/disco/disco.NoVLANIndexing
The disco.NoVLANIndexing file is case-sensitive.
Add the device IP addresses or address ranges to the disco.NoVLANIndexing file for all of the devices you want to disable vlan-indexing for. Follow the instructions show in the disco.NoVLANIndexing reference page, or the UNIX manpage.
Restart the NNMi management server.
1. Run the ovstop command on the NNMi management server.
2. Run the ovstart command on the NNMi management server.
The ovjboss service reads the disco.NoVLANIndexing file on startup.

See the disco.Disco.NoVLANIndexing reference page or the Linux man page for more information.

Suppress the Monitoring of IP Addresses on Administrative Down Interfaces

By default,NNMi suppresses the monitoring of IP addresses on interfaces that are administratively down, thereby preventing node status changes.

You can configure whether the monitoring of IP addresses on administratively down interfaces is performed by doing the following:

Open the nms-disco.properties file in the following location:

Windows: %NnmDataDir%\shared\nnm\conf\props\nms-disco.properties

Linux: $NnmDataDir/shared/nnm/conf/props/nms-disco.properties

Look for a section in the file that resembles the following:

#!com.hp.ov.nms.disco.suppressMonitoringOfAddressOnAdminDownInterface=true

You can configure the property as follows:

To suppress monitoring of IP addressees on interfaces that are administratively down, uncomment the line to set the property to true (the default setting). The line should resemble the following:
```
com.hp.ov.nms.disco.suppressMonitoringOfAddressOnAdminDownInterface=true
```
To have NNMi monitor IP addresses on interfaces that are administratively down, uncomment the line and edit the property value as follows:
```
com.hp.ov.nms.disco.suppressMonitoringOfAddressOnAdminDownInterface=false
```
Save your changes to the nms-disco.properties file.
Restart the NNMi management server:

Run the ovstop command on the NNMi management server.

Run the ovstart command on theNNMi management server.

Configure Sensor Status

NNMi includes the following physical sensors and node sensors, which can be monitored to help determine status:

Physical Sensors and Node Sensors
Physical Sensors	Propagates Status to Physical Component by Default?	Node Sensors	Propagates Status to Node by Default?
FAN	Yes	CPU	No
POWER_SUPPLY	Yes	MEMORY	Yes
TEMPERATURE	No	BUFFERS	No
VOLTAGE	No	DISK_SPACE	No
BACK_PLANE	Yes

By default, FAN, POWER_SUPPLY, BACK_PLANE, and MEMORY, propagate their status to the physical component level. For example, if a fan has a red status indicator, its corresponding physical component (chassis) receives a status indicator of yellow. A user, in this case, viewing the status of a chassis would be alerted to the fact that a component of that chassis has some kind of failure.

You can make the following status propagation changes by modifying properties files:

Propagate Physical Sensor Status to a Physical Component
Configure Physical Sensor Status to not Propagate to the Physical Component
Override Physical Sensor Status Values
Propagate Node Sensor Status to a Node
Configure a Node Sensor’s Status to not Propagate to the Node
Override Node Component Status Values

Propagate Physical Sensor Status to a Physical Component

If not already present, create a new properties file with the name nms-apa.properties in the following directory:

Windows: %NnmDataDir%\shared\nnm\conf\props

Linux: $NnmDataDir/shared/nnm/conf/props

Within the properties file, use a text editor to include the following text:

com.hp.ov.nms.apa.PhysSensorPropagateToPhysicalComponentStatus_<Type>=true

com.hp.ov.nms.apa.PhysSensorNoPropagateToPhysicalComponentStatus_<Type>=false

where <Type> is a Physical Sensor.

Save the properties file.
Restart the NNMi management server:

Run the ovstop command on the NNMi management server

Run the ovstart command on the NNMi management server.

Configure Physical Sensor Status to not Propagate to the Physical Component

If not already present, create a new properties file with the name nms-apa.properties in the following directory:

Windows: %NnmDataDir%\shared\nnm\conf\props

Linux: $NnmDataDir/shared/nnm/conf/props

Within the properties file, use a text editor to include the following text:

com.hp.ov.nms.apa.PhysSensorPropagateToPhysicalComponentStatus_<Type>=false

com.hp.ov.nms.apa.PhysSensorNoPropagateToPhysicalComponentStatus_<Type>=true

where <Type> is a Physical Sensor.

Save the properties file.
Restart the NNMi management server:

Run the ovstop command on the NNMi management server.

Run the ovstart command on theNNMi management server.

Override Physical Sensor Status Values

By default, three sensor state values (None, Warning, and Unavailable) map up to a Normal status by the Causal Engine. You can override these default state mappings such that None, Warning, and Unavailable map to Critical.

To override physical sensor status values:

If not already present, create a new properties file with the name nms-apa.properties in the following directory:

Windows: %NnmDataDir%\shared\nnm\conf\props

Linux: $NnmDataDir/shared/nnm/conf/props

Within the properties file, use a text editor to include one, two, or all three of the following lines, as applicable:

com.hp.ov.nms.apa.PhysSensorValueReMappedToDown_NONE=true

com.hp.ov.nms.apa.PhysSensorValueReMappedToDown_Warning=true

com.hp.ov.nms.apa.PhysSensorValueReMappedToDown_Unavailable= true

Save the properties file.
Restart the NNMi management server

Run the ovstop command on the NNMi management server.

Run the ovstart command on the NNMi management server.

You can map an Unavailable state to an Unpolled status (since Unavailable means that the measurement facility is not available). This situation can often occur because the sensor is non-functional as opposed to the component being non-functional. To map Unavailable to Unpolled, use the same procedure as just described, except in step 2, use the following text:

com.hp.ov.nms.apa.PhysSensorValueReMappedToUnpolled_Unavailable= true

Propagate Node Sensor Status to a Node

If not already present, create a new properties file with the name nms-apa.properties in the following directory:

Windows: %NnmDataDir%\shared\nnm\conf\props

Linux: $NnmDataDir/shared/nnm/conf/props

Within the properties file, use a text editor to include the following text:

com.hp.ov.nms.apa.NodeSensorPropagateToNodeStatus_<Type>=true

com.hp.ov.nms.apa.NodeSensorNoPropagateToNodeStatus_<Type>=false

where <Type> is a Node Sensor.

Save the properties file.
Restart the NNMi management server:

Run the ovstop command on the NNMi management server.

Run the ovstart command on the NNMi management server.

Configure a Node Sensor’s Status to not Propagate to the Node

If not already present, create a new properties file with the name nms-apa.properties in the following directory:

Windows: %NnmDataDir%\shared\nnm\conf\props

Linux: $NnmDataDir/shared/nnm/conf/props

Within the properties file, use a text editor to include the following text:

com.hp.ov.nms.apa.NodeSensorPropagateToNodeStatus_<Type>=false

com.hp.ov.nms.apa.NodeSensorNoPropagateToNodeStatus_<Type>=true

where <Type> is a Node Sensor.

Save the properties file.
Restart the NNMi management server:

Run the ovstop command on the NNMi management server

Run the ovstart command on the NNMi management server.

Override Node Component Status Values

By default, three node component state values (None, Warning, and Unavailable) map up to a Normal status by the Causal Engine. You can override these default state mappings such that None, Warning, and Unavailable map to Critical.

To override node component status values:

If not already present, create a new properties file with the name nms-apa.properties in the following directory:
- Windows: %NnmDataDir%\shared\nnm\conf\props
- Linux: $NnmDataDir/shared/nnm/conf/props
Within the properties file, use a text editor to include one, two, or all three of the following lines, as applicable:
```
com.hp.ov.nms.apa.NodeComponentValueReMappedToDown_NONE=true
```
```
com.hp.ov.nms.apa.NodeComponentValueReMappedToDown_Warning=true
```
```
com.hp.ov.nms.apa.NodeComponentValueReMappedToDown_Unavailable=true 
```
You can map an Unavailable state to an Unpolled status (since Unavailable means that the measurement facility is not available). This situation can often occur because the sensor is non-functional as opposed to the component being non-functional. To map Unavailable to Unpolled, use the following text:
```
com.hp.ov.nms.apa.NodeComponentValueReMappedToUnpolled_Unavailable: true
```
Save the properties file.
Restart the NNMi management server:

Run the ovstop command on the NNMi management server

Run the ovstart command on the NNMi management server.

When making file changes under High Availability (HA), you need to 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.

Send Help Center feedback

Modify Default Settings

Modify Access Control Lists for NNMi Folders

Change the Custom Poller Collections Export Directory

Changing the Maximum Amount of Disk Space for Custom Poller Collections Export

Configure Incident Actions

Overriding Settings in the server.properties File

Modify User Interface Properties

Configure the Data Payload Size in an ICMP Echo Request Packet

Configure how NNMi Determines the Host Name for a Device

Configure Character Set Encoding Settings for NNMi

Configure the Time NNMi Waits for an NNM iSPI Licensing Request

Modify NNMi Normalization Properties

Suppress the Use of Discovery Protocols for Specific Nodes

Suppress the Monitoring of IP Addresses on Administrative Down Interfaces

Suppress the Use of VLAN-indexing for Large Switches

Suppress the Monitoring of IP Addresses on Administrative Down Interfaces

Configure Sensor Status