HP OpenView Network Node Manager Release B.06.01 Runtime Release Notes

For the Windows NT® 4.0 Operating System
NNM Release B.06.01
Apr 09 1999
Copyright © 1990-1999 Hewlett-Packard Co., All Rights Reserved
To view these Release Notes as one document suitable for printing, click here.
Post-release updates to this document are available at
http://ovweb.external.hp.com/nnm/NNM6.0/relNoteUpd/relNoteUpdate.htm

Congratulations on your purchase of HP OpenView Network Node Manager 6.0 (NNM) for the Windows NT® 4.0 operating system! HP OpenView Network Node Manager is the industry-leading network management solution, and we're proud to have you join the HP OpenView family. We thank you for purchasing HP OpenView Network Node Manager for Windows NT® 4.0, and we hope this product exceeds your network management expectations. Please see the table of contents in the left frame for the topics that are included in these release notes or click here to bring up the frame version of the Release Notes.

We suggest that you use this document in conjunction with our two printed manuals (Managing Your Network with NNM and A Guide to Scalability and Distribution for Network Node Manager). The guidelines detailed below reflect the very latest information we have about the product, some of which was documented after the manuals were printed.

Installation Information

Before installing, please check that your system meets the Pre-Installation requirements.  This links to an online version of the insert included with your NNM installation CD.

Licensing

NNM comes with a 60-day password that is activated during installation. If installing NNM for the first time, only 250 managed nodes are allowed with the initial password. If you already have a previous version of NNM installed and licensed for unlimited managed nodes, unlimited nodes are allowed with the initial password . Before 60 days pass, you must request a permanent password even if you are upgrading from NNM 4.x or 5.x.  To request a permanent password, from the command prompt run ovnnmPassword, or pick [OK] when the NNM user interface prompts you to request your password.

It is advised that you request your permanent password immediately.

The following license types are the available for Network Node Manager 6.x:

When you purchased your media and manuals, you purchased either an "HP OV NNM 6.0 ENTERPRISE" or "HP OV NNM 6.0 250" product. If you bought the "HP OV NNM 6.0 250" product, you can increase the initial 250 managed nodes by purchasing any number of "HP OV NNM 250 NODE INCREMENT" products.

If you want to run HP OpenView Remote Consoles, you do not need an additional  license or password for each remote console as long as the HP OpenView Management Server has a valid password.

If you change the IP address of your management station, you will need to request a new password. Fill in the form:
\OpenView\conf\OVLicense\forms\nnm\C\server_move.txt

Using the Event Correlation Services

The Event Correlation Service (ECS) is integrated into NNM such that events are routed through the ECS engine before they are distributed to applications, such as NNM's Alarm Browser.  This allows correlations to prevent extraneous events from overwhelming the application or network administrator. For more information, see Managing Your Network with NNM.

The following event correlations are included in NNM:

For detailed descriptions of each correlation, bring up the ECS Config/Management GUI:

  1. Open the NNM user interface and select Options:Event Configuration.
  2. Select Edit:Event Correlation.
  3. Highlight any correlation and click the Describe... button.

Additional correlations can be developed by purchasing and using the HP OpenView ECS Designer product.

Using the Data Warehouse System

NNM comes with an embedded SQL data warehouse database that supports ODBC queries. See the Reporting and Data Analysis with Network Node Manager manual for complete information.

The following databases versions are supported with NNM 6.0:

To export NNM's topology, event, or SNMP collected data into the data warehouse, either:

See the ovdwtopo, ovdwevent, and ovdwtrend reference pages in NNM's online help (or the UNIX manpages) for details about these commands. For maintenance of the data warehouse, these commands support query, aggregate, and trim parameters.

See also the ovdwquery reference page in NNM's online help (or the UNIX manpage) for more information.

You can access the data warehouse information using your favorite ODBC tools. The database schemas are described in a series of ASCII files in the OpenView\conf\analysis\sqlScripts  directory.  See tables_topo.solid (topology schema), tables_event.solid (event schema), or tables_trend.solid (SNMP collected data schema).

To help you generate meaningful reports, NNM ships with Microsoft Excel templates.  These templates allow you to easily generate reports based upon the current information in NNM's data warehouse. You can modify the reports within Excel as needed.  The Excel templates request data over the web, so Excel does not need to be running on the same machine as your management station.  The Excel templates and a README file are located in OpenView\conf\analysis\excelTemplates\NNM.  See README_excelTemplates.txt for more information.

The NNM's Report Presenter is available as a contributed application (not supported by HP). This tool serves as a framework for browsing and viewing HTML reports of data warehouse information. See OpenView\contrib\NNM\reportPresenter\README.txt (you must run a "Custom" install to get contributed  program files)  for more information.

Using the HP OpenView Java-Based Web Interface

New with Network Node Manager 6.0 is a Java-based web interface. Using any JDK 1.1 compatible browser you can connect to your NNM management station through NNM's Launcher. You can view topology, alarms, node status, and browse MIBs. NNM's user interface must be running on the management station with the desired map displayed. See Managing Your Network with NNM for information about NNM's new web interface.

The HP OpenView Java-based Web Interface is available at URL:

NNM's web version of the mapping feature is called the Network Presenter. When you access the Network Presenter, a list of submaps is shown in the left scoping pane. In the right scoping pane, you view the selected submap in graphical or tabular format.

You can integrate your own choice of management URLs into NNM's Java-based web interface. See the LauncherRegIntro reference page in NNM's online help (or the UNIX manpage) for more information.  See also Managing Your Network with NNM and the Dynatext version of Creating and Using Registration Files.

The NNM Java-based grapher is available as a contributed application (not supported by HP).  This tool allows you to view the equivalent of NNM's Graph SNMP Data feature (xnmgraph) over the web.  See OpenView\contrib\NNM\javaGrapher\README.txt (you must run a "Custom" install to get contributed program files)  for more information.

The server processes for the HP OpenView Java-Based Web Interface can be located on an HP OpenView Remote Console to offload the management server.  For more information see the Microsoft word document  <DRIVE>:\doc\WhitePapers\WebUIFromRemoteConsoles.doc located on your CD-ROM.

By default, the HP OpenView Java-Based Web Interface has most security mechanisms disabled.  You can enable launcher login by turning on the UserLogin parameter in $OV_CONF/www/session.conf.  You can also enable user roles. For more information see Managing Your Network with NNM. You can control operations which may be performed through the web-based Alarm Browser with options to the ovalarmsrv daemon.  For more information see the ovalarmsrv reference pages.

Using the Automated Backup System

New with Network Node Manager 6.0, backing up NNM can be integrated into your regularly scheduled network backup scheme (such as when using HP OpenView OmniBack). The backup happens in the background while your team continues to monitor alarms on your network. NNM temporarily pauses all services (background processes) whose activities result in changes to the NNM databases (such as the ovw, ovwdb and ovtopmd databases), thus ensuring consistency among the NNM databases and minimizing the potential for database corruption.

After the synchronized files are copied to the backup directory, the services resume normal activity. Then the files that do not require services to be in a paused state are copied to the backup directory.

During the backup of synchronized information, your team’s maps are frozen in time, but the Alarm Browser’s list and all Data Collection & Threshold information stay current throughout the backup.

See Managing Your Network with NNM and the ovbackup.ovpl,ovrestore.ovpl,ovpause,and ovresume reference pages in NNM's online help (or the UNIX manpages) for more information.

Configuring Discovery with Custom Installation

See Managing Your Network with NNM, Chapter 5 for information about the choices available for customizing and troubleshooting NNM's discovery process.

If you wish to delay the discovery process until after you decide which configuration choices to implement:

  1. During installation choose "Custom" in the Setup options dialog.
  2. When you get to the dialog box titled "Configure Discovery Options," uncheck "Start network auto-discovery after installation". This will prevent Network Node Manager from starting network auto-discovery. 

When you are ready to run discovery, open NNM's user interface and select Options:Network Polling Configuration. Then enable the IP Discovery:Discover new IP nodes  field. Also, enable the IPX Discovery:Discover new IPX nodes field.

Configuring for HP OpenView Remote Consoles

HP OpenView Remote Consoles allow full-featured access to NNM on the management station from multiple computers. The NNM management station becomes the HP OpenView Management Server and runs the services or background processes that perform network monitoring and maintain the databases.  The HP OpenView Remote Consoles need only install and run the NNM user interface or foreground processes.  This allows more users to simultaneously use one copy of  NNM without needing to start multiple instances of NNM on the management station. See A Guide to Scalability and Distribution for Network Node Manager for more information. (Remote consoles do not run across the WWW.)

If you want to run HP OpenView Remote Consoles, you do not need a license for each computer. A license is only needed for the NNM management station serving as the central HP OpenView Management Server. However, the HP OpenView Management Server and any HP OpenView Remote Consoles must be upgraded to the same version of NNM.

NOTE: If it becomes necessary to modify the port numbers used for various NNM services on the management station, you must modify the port numbers for the corresponding services used on all remote consoles connected to that management station.

The server processes for the HP OpenView Java-Based Web Interface can be located on an HP OpenView Remote Console to offload the management server.  For more information see the Microsoft word document  <DRIVE>:\doc\WhitePapers\WebUIFromRemoteConsoles.doc located on your CD-ROM.

There are three possible configurations:

NOTE: Management server (Windows NT) for remote consoles (UNIX) is not supported.

Management station (Windows NT) for remote consoles (Windows NT)

  1. First install the full version of NNM on the computer that will be the HP OpenView Management Server (Windows NT).
  2. NOTE: It is required that the HP OpenView Management Server's IP name match it's computer name (Net BIOS name) so that HP OpenView Remote Consoles can properly communicate with the HP OpenView Management Server.
  3. Start NNM on the HP OpenView Management Server (Windows NT) and verify correct operation:
  4. On each HP OpenView Remote Console system, insert the NNM installation CD and run setup.exe and pick the "Remote Console Installation". This will remove any databases, log files, or local configuration files, if you had previously installed the full version of NNM. Supply the machine name of the HP OpenView Management Server and the default share name "OpenView".

NOTE: On HP OpenView Remote Consoles, ovstop and ovstart must be run from the command prompt, and you must explicitly name which services to startup or shutdown.

You can now run NNM from the remote console as if you were working directly on the management station.

Management station (UNIX) for remote consoles (Windows NT)

You need to buy a third party NFS product that runs on the Windows NT operating system and install it on each system to be an HP OpenView Remote Console.  The following NFS packages are supported:

  1. First install the full version of NNM on the computer that will be the HP OpenView Management Server (UNIX).
  2. Start NNM on the HP OpenView Management Server (UNIX) and verify correct operation:
  3. On each HP OpenView Remote Console system, insert the NNM installation CD and run setup.exe and pick the "Remote Console Installation". This will remove any databases, log files, or local configuration files, if you had previously installed the full version of NNM. Supply the two mapped drive letters.

NOTE: On HP OpenView Remote Consoles, ovstop and ovstart must be run from the command prompt, and you must explicitly name which services to startup or shutdown.

You can now run NNM from the remote console as if you were working directly on the management station.

Management station (UNIX) for remote consoles (UNIX)

See the ovwsetupclient(1M) manpage for instructions about configuring HP OpenView Remote Consoles.

  1. First install the full version of NNM on the computer that will be the HP OpenView Management Server (UNIX).
  2. On the system to be an HP OpenView Management Server (UNIX), export the /etc/opt/OV/share and /var/opt/OV/share directories to each HP OpenView Remote Console.
  3. On each HP OpenView Remote Console, install the full version of NNM by running ./install.
  4. On each HP OpenView Remote Console, run ovwsetupclient.

NOTE: On HP OpenView Remote Consoles, ovstop and ovstart must be run from the command prompt, and you must explicitly name which services to startup or shutdown.

You can now run NNM from the remote console as if you were working directly on the management station.

Configuring as an HP OpenView Collection Station

An HP OpenView Collection Station runs a complete copy of NNM,  monitors its own designated portion of your network, and forwards topology and alarm information to the central NNM management station. The central management station that is receiving information from HP OpenView Collection Stations must be running NNM 4.1 or greater.  The central NNM management station must have an HP OpenView Network Node Manager Enterprise license. Each collection station must have its own NNM license. To learn more about Distributed Internet Data Monitoring (DIDM), refer to the A Guide to Scalability and Distribution for Network Node Manager manual.

There are four possible configurations:

Configure an SNMP SET-community name for each  HP OpenView Collection Station:

On the central NNM management station:

See the xnmtopoconf reference page in NNM's online help (or the UNIX manpage) for more information. 

Integrating with Microsoft's SMS

There are two mechanisms that integrate NNM with Microsoft's Systems Management Server:

Improving Performance

You can improve the performance of your NNM management system in several ways:

  1. Ensure that your management station does not swap memory.
    You can monitor how much swapping is being done via the Windows NT Programs:Administrative Tools->Performance Monitor.
    Pick Edit:Add to Chart.
    Select Object:Memory,  Counter:Available Bytes, and click Add, then Counter:Pages/sec and click Add.
    This graph will help you determine how much memory you are using, and if you are low on memory.
  2. Check your tasking model and ensure that foreground processes have highest priority.
    From Settings:Control Panel, open the System applet. Pick the "Performance" tab. Ensure that the slider in on Maximum (Windows NT's default).
  3. Install a high quality video card.
    NNM is a very graphical application. Fast video cards will allow operations like panning and zooming on the map to perform better.
  4. Enable maximum throughput.
    If you are running the Windows NT Server software, from Settings:Control Panel, open the Network applet. Pick the "Services" tab. Select "Server" and pick "Properties". Enable the Maximize Throughput for Network Application field.
  5. Reduce DNS and NETBIOS lookup delays.
    Discovery may proceed slowly in environments where the IP addresses do not resolve to hostnames. This may be caused by DNS and NETBIOS lookup delays. These can be reduced by putting a caching name server on the NNM system and by adjusting the following NETBIOS configuration entries in the registry under \My Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters:

    For complete details about configuring these parameters, see the Microsoft TechNet article "Microsoft Windows NT 3.5, 3.51, 4.0 - TCP/IP Implementation Details".

  6. Customize polling intervals to reduce the amount of network traffic used
    See Chapter 6 in Managing Your Network with NNM for more information.
  7. Customize discovery options to eliminate or reduce the amount of network traffic used.
    See Chapter 5 in Managing Your Network with NNM for information.

A very good discussion on tuning your Windows NT system can be found on the Microsoft TechNet CD entitled "Optimizing and Tuning of Windows NT" by Scott B. Suhy. This discusses using Performance Monitor and optimizing your memory, processor, and I/O system resources. This article also talks about how to use Perf2Mib.EXE to instrument these values for SNMP so that NNM can monitor the variables. Additional information can be found in the NNM Performance and Configuration Guide, which is located on NNM's installation CD in doc\WhitePapers\perfGuide.wri.

You can improve Windows NT operating system's swap performance by correctly configuring the initial paging file size, you will get better performance than if Windows NT needs to grow the paging file. If you have multiple hard disks, splitting up the paging file is a good idea, as it will speed up the access time. If you have two hard disks, and you split the paging file, both hard disks can be accessing information simultaneously, greatly increasing the throughput. However, if you have two hard disks, and one hard disk is faster than the other, it may be more effective to store the paging file on only the faster hard disk. Some experimentation may be necessary to arrive at the best configuration for your system.

NOTE: There is no point in splitting up the paging file between multiple partitions of the same disk as it does not increase the ability of the hard disk to access the paging file. This may be a good idea, however, if your logical drives aren't large enough for the entire paging file.

A good guideline for virtual memory paging file size is to have double the size of your physical memory. For example: RAM=128MB paging file=256MB. If you don't have a large amount of RAM, it may be useful for the paging file to be four times the size of your existing RAM.

The latest version of the HP OpenView Performance and Configuration guide is available at:
    http://ovweb.external.hp.com/nnm/NNM6.0/perfConfigGuide.htm.

Printable Documentation

NNM includes a library of detailed reference materials for your use. Some are provided in printed form, some are provided online in the DynaText collection, and some are provided in both formats. DynaText allows you to search multiple manuals, and print or view manuals in the NNM online library. The following manuals are provided with NNM.

To access the online manuals shipped with NNM, use the Help menu. When you choose Online Manuals, a Dynatext browser window appears. Choose the manual you want to view, and follow the instructions in the viewer. If you do not see the manual that you want, insert the installation CD-ROM and use the “Custom Installation” feature. Follow the directions in the dialog boxes to indicate that you want to install only the online manuals. Numerous additional HP OpenView online manuals are available at the following web sites:

"Get Acquainted with HP OpenView Network Node Manager" CBT

Included with your NNM product is a separate CD-ROM, entitled Get Acquainted with HP OpenView Network Node Manager: Training for NNM Operators.

All new users are encouraged to take advantage of this convenient and focused computer-based training (CBT) to acquire essential expertise with the NNM software. Build the foundation concepts and skills you need, develop a broad understanding of NNM's functionality and operation, and learn the basic tactics of fault identification and isolation.

Just follow the easy installation instructions on the CD sleeve.  This CBT runs under reasonably current versions of any Microsoft Windows operating system (excluding Windows 3.x).

For in-depth information about administrative and advanced tasks (such as configuration or customization), see the NNM documentation.  Also, explore NNM's extensive online help system for information about specific tasks and procedures.  Comprehensive classroom training on NNM is regularly available; visit http://openview.hp.com/training/ for detailed information and schedules.

Uninstalling (and Manual Product Removal)

If you only want to repeat initial discovery, you can remove only your topology databases and re-discover. See Chapter 5 of Managing Your Network with NNM for instructions.

To fully uninstall the product:

To be completely sure you have removed everything, in the event your uninstall was unsuccessful, you can follow the manual removal instructions.

Migration from Past Versions

You can migrate directly from NNM 4.11, NNM 5.x or NNM 6.0 to NNM 6.01.   Hewlett-Packard recommends that you backup your system and have the latest patches for your release before migrating to NNM 6.01.

oid_to_sym File Issue

The oid_to_sym file controls which symbol is used on NNM's maps for each SNMP OID. Starting with NNM 5.01, the oid_to_sym file became language independent, so it moved out of the "C" directory:
Old location: \OpenView\conf\C\oid_to_sym
New location: \OpenView\conf\oid_to_sym

Compatibility with Third-Party OpenView Applications

Network Node Manager 6.01 has been tested with the current version of many third-party OpenView applications. Most of the tested applications work on NNM 6.01 just as they do on NNM 4.11 and/or NNM 5.01. To view a complete list of which applications/versions run on which operating systems, go to http://ovweb2.external.hp.com/solutions/technical. Special instructions are also shown where applicable.

Copyright Information

Copyright © 1990-1999 Hewlett-Packard Co., All Rights Reserved
Copyright © 1996 AirMedia, Inc.

What's New in OpenView Network Node Manager

What's New in Network Node Manager 6.01 Runtime Release

For more details about the following features, see the NNM documentation set or the extensive information under NNM's Help menu item.

NNM 6.01

NNM 6.0

NNM 5.02

NNM 5.01

NNM 5.0

HP OpenView Network Node Manager Defect Fixes

Fixes Since Version 6.0

The following defects have been fixed since version 6.0 was released.

NT only fixes:

Solaris only fixes:

HP-UX 10.x, HP-UX 11.x, Solaris only fixes (no NT): 

Symptoms:
	NNM_00159:
	Cumulative Consolidated Patch
	NNM_00155:
	On Japanese NT systems, the default menu for an xnmbuilder
	application was
	  "{Japanese characters for "Configuration"}->".
	If you used this menu for an application, it resulted in an
	extra "Configuration" menu on ovw, the only difference being
	was that it didn't have the mnemonic "(C)".  This was not a
	problem on Unix systems.
	NNM_00154:
	Errors are reported back by the ovEvent stack ( pmd ),
	ovactiond, and other programs when a trap uses FORWARD and
	the file specified is empty.  The man page says that this is
	allowed, and there are cases, such as installation, where
	this is needed.
	This fix is to allow for empty files to be used.
	NNM_00146:
	snmpColDump -tTI did not return years as 4 digits.  This
	patch forces years to 4 digits.  Customers who use scripts
	that rely on 2 digit years should change their scripts.
	This is for Y2K compliance.
	NNM_00145:
	If the ECS config gui is brought up directly from the URL,
	http://hostname/OvDocs/C/ecs/ecscmg.html,
	the login page is bypassed if security is turned on.  Even
	if security is turned off, the ECS config gui
	will come up when the session manager is not running.  This
	is in error.
	NNM_00144:
	Double-clicking on a symbol in an existing submap will
	end up selecting any underlying symbol in the child
	submap that gets loaded as a result of the double-click.
	NNM_00143:
	During startup of the _debuggable_ version of jovw.jar,
	an "IllegalAccessError" is thrown and a stack trace
	is printed to the Java console in the browser.  Network
	Presenter "Initializing..." progress window remains at 40%.
	Network Presenter never comes up.
	NNM_00142:
	Network Presenter does not allow navigation to submaps
	associated with connections or meta-connections.
	Meta-connections are not represented in scope pane.
	Network Presenter does not sort items in scope pane or
	tabular view.  '+' indicator does not disappear after
	moving the location cursor (via click or keyboard
	navigation) to a non-expandable entry (one with no submap
	or containing no children) in the scope pane.
	Location cursor in scope pane can be disassociated from
	actual submap represented in content pane.
	Navigation in scope pane is inadequate and incorrect.
	NNM_00141:
	Network Presenter map does not represent line types and
	special graphics found in ovw.  Dashed/dotted lines and
	those with graphics (fiber links, tcarriers) will show
	up as plain solid lines.
	NNM_00140:
	On Japanese Unix systems, the Fault->Ping,
	Fault->Network Connectivity->Poll Node,
	Fault->Remote Ping dialog boxes were too wide (filled
	the entire width of the display.)  This was not
	a problem if LANG=C or on NT.
	NNM_00138:
	When hiding a connection symbol (metaconnection) without a
	symbol label ovw would core dump on solaris.
	NNM_00137:
	Missing a data point in the Collector db every time any
	agent's counter wraps..  snmpCollect assumes that the
	agent was reset, when that is only 1 of the possibilities.
	Other case we should be looking for is when the counter
	has reached the maximum and he wraps it.
	This patch tries to make a reasonable guess as to whether
	it wrapped (in which case calculate the counter assuming it
	wrapped), or whether it was reset (in which case blow away
	one data point as we did before).
	Info from customer: They had FDDI cards and were collecting
	on ifInOctets, which were racking up at around 2.5MB/sec.
	At this rate, the old 32-bit SNMPv1 counter wraps in 30 min!
	Note the newer SNMPv2 64-bit counters will alleviate this.
	NNM_00135:
	Customer could not enter ip addresses or ip wildcards as an
	event source.
	NNM_00134:
	Given certain operations such as save and restore of the
	state file, ovalarmsrv would grow in size.  This is due to a
	string not being freed along with its parent structure.
	NNM_00133:
	1. Certain network devices (have seen some from Cabletron
	   and 3Com) can never get discovered.
	2. When setting the status polling interval to an extremely
	   large value (~ 3000 weeks), netmon would flood interfaces
	   with status polls.
	3. If you turn on snmp tracing, you will see netmon doing
	   level 2 interface status polls on unmanaged interfaces.
	4. If NNM is managing a Dell MSCS cluster (High availability
	   cluster), and the cluster IP address migrates from one
	   node to another within the cluster, sometimes NNM will
	   rename the old clusternode to have the name of the
	   cluster IP address, and the node currently supporting the
	   cluster IP will not show it on the map.
	5. Selecting node on map and pulling up web browser on
	   management URL may give not-found error.
	6. Netmon process may dump core in HSRP environment.
	7. Non-IP interfaces are not status-polled when node is
	   newly discovered.
	8. NNM does not reschedule topology poll for switch device
	   that generates a spanning tree protocol trap.
	9. There is no way to tell NNM to not discover L2Nets.
	10.There is no way to tell NNM to not schedule SNMP polls
	   for status checks on non-IP interfaces.
	11.When IP address comes up on certain nodes, a configration
	   poll is supposed to be scheduled, but isn't.
	12.There is a lot of console output when using ECS Router
	   Down.
	NNM_00132:
	Generally this is a defect seen only by devlopers, as it
	would be caught early on in the development phase.
	Symptoms will vary depending on submap type used.
	SegSub::queryAddNode: getSegmentById() failed
	The above error was seen by a developer in nettl.LOG00.
	This occured when he tried to add a node to his submap.  We
	see the error was in a method of the segment submap class.
	The developer was using a submap type of 4 which to ipmap
	is a segment submap.  Since ipmap did not create this
	submap initially it should not be of type segment submap
	IPMap can take a (relatively) long time to synchronize maps
	with network devices with lots of interfaces.
	NNM_00116:
	When binary datafiles are recreated using reading of data
	from stdin, the IP addresses get reversed on NT.  This is
	due to the behavior of the inet_addr function.  An example
	is that 15.2.117.131 becomes 131.117.2.15 in the file.
	When the following sequence is performed, xnmgraph would
	give an exception.
	   1.Data collection setting:
	               store, no threshold
	                instance: all.
	                polling interval: 10s
	   2. peformance->graph SNMP data -> all
	   3. then, data renewal by clicking on "Update
	Data"              menu.
	  If user keeps repeating the 3-rd step, grapher would
	  crash.
	The Object Properties/Attributes dialog box now sorts the
	attributes
	for both Name and Value.  Clicking on the "Name" header
	sorts/
	reverse sorts the attributes by name, and clicking on the
	"Value"
	header sorts/reverse sorts the attributes by their values.
	If you used the panner on a submap, then closed the panner
	and
	opened a new window, on occasion, there would be garbage/
	transparent regions where scroll bars might go if they were
	needed.  This problem only happened on NT.
	xnmsnmpconf wrongly displays time indications, and can
	update wrongly. When the user enters a time for "default
	polling" ( eg ), in units less than those it could be
	displayed in ( eg 28 hours ~ 1 day, or 10 days ~ 1 week ),
	xnmsnmpconf when redisplaying the data will display it in
	the larger units, but as an integer number. This is fine,
	PROVIDING, no other data field is updated and the form
	 will  be saved to the file, overwriting the original 28
	hours or 10 days.
	In NNM/NT, ovw can't run a registered application
	if a directory in the command path contains spaces,
	for example "Program Files".
	trapd.log on NT has occasional entries looking like:
	 ... [1] private.enterprises (IpAddress): 177.113.2.15 ...
	The IP address should appear as "15.2.113.117" instead.
	This happens whenever an incoming trap contains a VARBIND
	of type "IPADDRESS".
	 ... [1] private.enterprises (IpAddress): 177.113.2.15 ...
	The IP address should appear as "15.2.113.117" instead.
	This happens whenever an incoming trap contains a VARBIND
	of type "IPADDRESS".
	On Japanese systems, the dates for events in the xnmevents
	browser were wrong, sometimes having extra parentheses as
	well as missing the characters for month (gatsu) and/or day
	(nichi).
	Upon startup of ovw, some submaps with autolayout turned off
	would have their symbols re-laid out anyway
	Synchronization failure in ovspmd's SIGCHLD handler
	sometimes causes updates to ovspmd's tables to be
	interrupted.
	NNM_00115:
	Ovfiltertest will coredump or get an out-of-memory condition
	when testing filter with certain size databases.  There is
	no relation to the filter being used.  This is due to
	topology objects loaded not being freed.
	OV_BACKGROUNS_PATH should have been OV_BACKGROUNDS_PATH.
	If NNM is managing a Dell MSCS cluster (High availability
	cluster), and the cluster IP address migrates from one node
	to another within the cluster, sometimes NNM will rename the
	old clusternode to have the name of the cluster IP address,
	and the node currently supporting the cluster IP will not
	show it on the map.
	In using the "Set Filters" dialog, the buttons are not
	disabled during processing of buttons already depressed.
	Given this, it is possible to queue up the buttons (
	multiple X events ).  The code did not account for this and
	it tried to use a structure that was freed by the processing
	of a prior button being depressed.
	snmpwalk of remote console will return snmp information from
	the server.  If the management station is x, and the remote
	console is y, then running snmpwalk y system on y will
	return snmp information from system x.  This is due to
	invalid value returned from function to see if localhost
	should be used.
	If an application used OVwRemovePopupMenuItemFunction() to
	remove a menu item from the popup menu, ovw would
	occasionally
	core dump upon exit or opening a different map.
	When setting the status polling interval to an extremely
	large value (~ 3000 weeks), netmon would flood interfaces
	with status polls.
	User selects unmanaged node on map which has multiple
	interfaces, and manages that node.  Netmon may later
	unmanage some of the interfaces when it should not.  Mostly
	happens on Japanese NNM.
Defect Description:
	NNM_00159:
	Cumulative Consolidated Patch
	Resolution:
	Cumulative Consolidated Patch
	NNM_00155:
	The default menu should have been
	"{Japanese characters for "Configuration"}(C)->"
	NNM_00154:
	The defect is that the man page and the behavior of the
	trapd.conf reading routines are different.  It appears that
	there are justifiable reasons for having empty FORWARD
	files, so the code should have allowed them.
	HPUX 11.X changed the format of the message header for the
	size of the uid field.  This causes a coredump due to
	improperly processing the data segment of the message by
	netfmt.
	ovdwevent -trim did not use the default values for deleting
	the detail records and aggregate records.
	ovdwquery -sep causes coredump.  This is due to printing out
	the the character was being done using %s instead of %c.
	remote consoles are not supposed to be using ov.conf file
	for address resolution.
	nmdemandpoll on remote console should have not have used the
	ov.conf file.
	snmpColDump should have printed date using 4-digit year.
	Map customization will stop if unknown symbol type is found.
	This should have been a warning and the code should have
	continued.
	ovfiltertest would coredump due to running out of memory.
	This was due to not freeing topology objects after using
	them.
	Allow empty forward files for trapd.conf.  This is needed
	for applications that add traps with the FORWARD parameter
	specified.
	NNM_00146:
	strftime with the %x option returns mm/dd/yy for LANG=C.
	This needs to be mm/dd/yyyy for Y2K compliance.
	NNM_00145:
	None
	NNM_00144:
	Event handler was allowing further processing of the
	event after the double-click.
	NNM_00143:
	The problem is due to a data member being declared as
	private and then is accessed by an inner class (should
	be legal, but the Java VM in Internet Explorer and
	Netscape Communicator do not like it).
	NNM_00142:
	Features were simply not implemented in original code.
	NNM_00141:
	Features were simply not implemented in original code.
	NNM_00140:
	One of the input fields did not take into
	consideration multibyte characters.
	NNM_00138:
	ovw assumed there would always be a connection label so
	when it did a strcasecompare on solaris with a NULL entry
	it core dumped.
	NNM_00137:
	None
	NNM_00135:
	Customer could not enter ip addresses or ip wildcards as an
	event source.  Customer can now use ip addresses as event
	sources.  Wildcards will also work, including the following
	types:
	15.*.*.*
	15.1-255.1-255.1-255
	NNM_00134:
	None
	NNM_00133:
	1. If the device reports its only IP address as associated
	   with an interface whose ifType is softwareLoopback
	   (value 24), then that interface will not be connected to
	   any network. Since it is the only IP address, NNM can not
	   handle a device that is not connected anywhere, and the
	   discovery fails. This patch provides a new oid_to_type
	   flag that can be used to indicate that nodes of this
	   type need to have their software loopback interfaces
	   treated as if they were a normal interface, and hence
	   are left connected to the network.  The new flag is the
	   L flag.
	2. The status polling interval was not being checked, when
	   calculating with this value MAXINT could be exceeded
	   resulting in a negative time.  This caused netmon to ping
	   the machine continuosly.
	3. Netmon was using the node status to decide whether or not
	   to do level 2 interface polls.
	4. NNM is not reacting nicely to the fact that the Microsoft
	   SNMP agent has an entry in the ip.ipAddrTable for IP
	   address 0.0.0.0 on MSCS cluster nodes.  This change will
	   cause NNM to ignore such entries in the ip.ipAddrTable.
	5. Netmon was adding an extra / to the end of the management
	   URL stored in the ovwdb.
	6. There is a timing condition where netmon could discover
	   an HSRP interface on a Cisco router, which would cause
	   the router to be deleted and re-added, and then cause
	   netmon to abort with a core dump.
	8. Spanning tree traps were not making it into the netmon
	   process.
	9. The discoverLevel2Nets command line option has been
	   implemented for netmon.  See the netmon man page.
	10.The nonIPStatusPolls command line option has been
	   implemented for netmon.  See the netmon man page.
	11.Netmon was making a wrong decision regarding the re-
	   scheduling of the configuration poll for a node when
	   one of its interfaces came up.
	12.There were a lot of debug statements left in the ECS
	   Router Down code.
	NNM_00132:
	Upon synchronization ipmap would try to create submaps of
	type submapType regardless of whether ipmap was the
	original creator of the submap.
	If a node with multiple interfaces had one interface change
	while the map was closed, it would appear as if all the
	interfaces had changed.
	NNM_00116:
	The "Data Update" option when called does an opendir() and
	readdir() repeatedly upto a maximum 'maxlines' times.
	opendir() in the portability layer was setting a limit to
	the MAXDIR that can be opened to 64. This is too less when
	there are a large number of data files  in the
	SNMPCOLLECTDIR.
	The functions for determining the window size were getting
	called with the wrong values.
	The Poll interval is an integer so the conversion to the
	larger units is wrong. Also whenever any field in the GUI is
	modified, a function is wrongly called which converts the
	new displayed larger units into seconds and stores the
	values in the file. So the original value is lost.
	It is not possible to quote paths within the command
	definition. Code has been changed so that paths
	quoted as follows work correctly:
	    Command -initial "\"C:/test test/notepad.exe\"";
	xnmevents was not using the correct format for the
	date for each three platforms.
	a map customization feature was forcing the autolayout of
	symbols when autolayout was specifically off.
	NNM_00115:
	NNM is not reacting nicely to the fact that the Microsoft
	SNMP agent has an entry in the ip.ipAddrTable for IP address
	0.0.0.0 on MSCS cluster nodes.  THis change will cause NNM
	to ignore such entries in the ip.ipAddrTable.
	The status polling interval was not being checked, when
	calculating with this value MAXINT could be exceeded
	resulting in a negative time.  This caused netmon to ping
	the machine continuosly.
	The exit code that cleaned up the menus was causing a
	NULL pointer dereference
	Netmon is not properly clearing an internal flag, which
	causes it to update information in the topology database
	incorrectly, including marking a managed interface as
	unmanaged.
Symptoms:
        PHSS_16454:
        Generally this is a defect seen only by devlopers, as it
        would be caught early on in the development phase.
        Symptoms will vary depending on submap type used.
        SegSub::queryAddNode: getSegmentById() failed
        The above error was seen by a developer in nettl.LOG00.
        This occured when he tried to add a node to his submap.  We
        see the error was in a method of the segment submap class.
        The developer was using a submap type of 4 which to ipmap
        is a segment submap.  Since ipmap did not create this
        submap initially it should not be of type segment submap.

        Ipmap will allow symbols for remote versions of objects
        become either unmanaged or managed while the objects in the
        topology do not change.

        1. Selecting node on map and pulling up web browser on
           management URL may give not-found error.
        2. Netmon process may dump core in HSRP environment.
        3. Non-IP interfaces are not status-polled when node is
           newly discovered.

        If a submap property (e.g. context) changed, any application
        listening for ovwSubmapChange would get two callbacks.

        ovrepld is limited to the soft limit number of file
        descriptors

        If you turn on snmp tracing, you will see netmon doing
        level 2 interface status polls on unmanaged interfaces.

        When a secondary version of a node becomes the primary
        version, the status of the node may not be set properly.

        With LANG=ja_JP.SJIS, the Event Object Identifier editable
        field was missing from the Event Configurator dialog box.

        Dragging symbols of certain types caused ovw to core dump or
        use a generic drag cursor.  The symbol type in question had
        a
        bitmap file named "root" that is the same as the "root"
        toolbar button bitmap name.  The symbol also had the toolbar
        bitmap instead of its own bitmap.

        1.  If a submap's background graphic file is an invalid
            pathname with no "/" in it, ovw will dump core when
            you try to open that submap.
        2.  If a symbol has an invalid symbol type, ovw will
            dump core when you try to display its popup menu.
        3.  Can't paste text into ovw dialog text fields (intro-
            duced in patches PHSS_15927/PHSS_15926/PSOV_02061)

        The Locate->Objects->By Selection Name... dialog box
        would grow in width every time you selected the "Apply"
        button.  This especially happened with objects who had
        more than three entries in the list.

        The Describe/Modify dialog reads in all the object's field
        values when it comes up. When the user OKs the dialog, it
        writes out all the object's field values, whether any have
        changed or not. It should only write out values that have
        either been changed by the user or an enrolled application,
        or on which the modified flag has been set.

        Any ovw menu that invokes xnmappmon will show the problem
        when the xnmappmon File->Save menu is selected.  When the
        operation is done, the file saved is always zero-length.
        This started happening with the latest Consolidated Patch.

        Customer had a huge /etc/services file, and it was located
        on a different system.  Any app using SNMP (for example,
        snmpwalk, snmpget, etc.) was taking an extra 5 or 6 seconds
        each time it started up.  This is due to the SNMP library
        always checking /etc/services, even when there are shortcuts
        it can use to avoid taking this performance hit.

        Several NNM modules (usually xnmevents is first) complain
        about a corrupt trapd.log.  Examining the log will show that
        at least one entry has been split into 2 lines just before
        the semicolon (all trapd.log entries must be just one long
        line .... there is always a semicolon separating the last
        3 fields in the line from all those before).  This happens
        because a newline character was not properly filtered out
        of the message that appeared just before the semicolon.
        The only time this problem has been seen is when pmd is
        running and the trapd.conf file is moved/removed and then
        "xnmevents -event" is run while the file is missing.  Then
        try (re-)starting the xnmevents window.

        (SOLARIS) snmpCollect coredumps in libovutil due to a NULL
        varbind for sysUpTime in an incoming PDU from some PC with
        a bad agent.

        User modified a vers. of $OV_CONTRIB/NNM/setStatus/setStatus
        to add a VARBIND to override the Category to "LOGONLY" :
          .1.3.6.1.4.1.11.2.17.2.6.0 octetstring "LOGONLY"
        This should have caused the event to not appear in the Event
        Browser (xnmevents), but it still did.
        Reported on NNM4.01, but patches needed for 4.11 & 5.01 too.

        xnmtrap cores on SOLARIS w/ blank format string.
        It also corrupts trapd.conf as it cores.
        To reproduce problem:
         -Warning!! : before testing, backup $OV_CONF/C/trapd.conf
         -Run xnmtrap on SOLARIS 4.11
         -Click on any Enterprise Name
         -Doubleclick on any Event Name under that
         -Blank out the Event Log Message line
         -Set Category to Don't log or display
         -OK
         -File->Save .... this will cause the coredump.

        On Solaris, after starting approximately 60 ovw sessions
        or 255 ovwdb connections (via an application), subsequent
        connections are refused.

        Certain network devices (have seen some from Cabletron and
        3Com) can never get discovered unless the I flag is set for
        them in the oid_to_type file.

        This has different symptoms on different systems.  In
        Solaris, this may cause a coredump or the message "Cannot
        connect to ovtopmd".  On HPUX, this can cause the message
        "Cannot connect to ovtopmd" or problems updating status of
        related objects ( e.g. a set of interfaces for a particular
        node ).

        The program mibtable run against a non-existent nodename
        will coredump.  This is due to not validating that a snmp
        session was actually created.

        Certain 3rd party applications stop working after applying a
        patch for the large value_info.pag file.

Defect Description:
        PHSS_16454:
        ipmap upon synchronization would try to create submaps of
        type submapType regardless of whether ipmap was the
        original creator of the submap.

        Ipmap was allowing the managed state of map objects change
        when there is no way to propagate the information to the
        remote collection station.

        1. Netmon was adding an extra / to the end of the management
           URL stored in the ovwdb.
        2. There is a timing condition where netmon could discover
           an HSRP interface on a Cisco router, which would cause
           the router to be deleted and re-added, and then cause
           netmon to abort with a core dump.

        The background graphics code sent out an extra event even
        if the submap background was not changed.

        No steps were taken to increase the number of file
        descriptors available beyond the soft limit set by the
        kernel.

        Netmon was using the node status to decide whether or not
        to do level 2 interface polls.

        The counts of up and down interfaces were not being reset
        properly.

        This was caused to an incorrect buffer length.

        ovw was using the toolbar bitmap file instead of the symbol
        type's bitmap files, even though the symbol type had all the
        appropriate bitmap files in the $OV_BITMAPS/$LANG directory.
        As a result, ovw couldn't properly compute the drag cursor
        for the symbol and core dumped.

        1.  ovw dereferences null pointer in this case.
        2.  ovw dereferences null pointer in this case.
        3.  Disabling drag (button 2) on text widgets also
            disables paste (button 2).

        The dialog box inadvertently resized when the list
        was updated.

        ovw wasn't checking whether the fields it writes out had
        been modified.

        The underlying communications code for NNM uses the fdopen()
        system call.  On Solaris, this call fails on file
        descriptors greater than 255.

        If the device reports its only IP address as associated with
        an interface whose ifType is softwareLoopback (value 24),
        then that interface will not be connected to any network.
        Since it is the only IP address, NNM can not handle a device
        that is not connected anywhere, and the discovery fails.
        This patch provides a new oid_to_type flag that can be used
        to indicate that nodes of this type need to have their
        software loopback interfaces treated as if they were a
        normal interface, and hence are left connected to the
        network.

        Certain previous patches caused the "TopM Interface List"
        field values to be removed from ovwdb, thus allowing it to
        run with a smaller value_info.pag file.  Some applications
        depend upon this field being in the database.  This patch
        will change the default behavior of ovtopmd such that the
        field will be restored in ovwdb.  If the customer requires
        the field to be removed to save database space, and does not
        depend upon the failing applications, then the behavior may
        be reinstated by adding the -U option to ovtopmd in
        ovtopmd.lrf.
Symptoms:
        PSOV_02166:
        When tracing in ipmap is used, it will core on Solaris if
        certain submaps are opened.  This is due to the formatting
        of submap information not checking for app_name (
        meta-connections ) and background graphics not having
        values.

Defects:
        PSOV_02166:
        None











HP OpenView Network Node Manager Known Problems





Network Node Manager 6.01 Runtime Known Problems and Workarounds



For the Windows NT® 4.0 Operating System






General Information



Listed below are solutions and workarounds  to problems that have been encountered
while using Network Node Manager 6.0 (NNM).



Please also visit the Release Notes addendum at http://ovweb.external.hp.com/nnm/NNM6.0/relNoteUpd/relNoteUpdate.htm
for any more recent updates or workarounds.



There is also a troubleshooting section below.






Known Problems



Below are the known problems and workarounds for the following modules:





Installation






Licensing





How to get a JDK 1.1 Compliant Web
Browser





Known Problems with Web Browsers






  The following table lists the known problems with various
  browsers, and which platform is recommended for each browser.  For the latest update
  on this table, please visit http://ovweb.external.hp.com/nnm/NNM6.0/relNoteUpd/relNoteUpdate.htm
  

    Operating System
    Browser
    Browser Information
  

  

    Solaris 2.5.1
     
    Use Netscape browser for best results
  

  

     
    Netscape 4.06
    Netscape may crash when first brought up.  See Netscape README file
    for required operating system patches.
  

  

     
    Internet Explorer 4.01
    UNIX Microsoft Internet Explorer displays error when launching NNM Java
    applets.
Microsoft Internet Explorer on Solaris --Menus not displaying properly.  A
    possible workaround is to run /usr/openwin/bin/xlsfonts -o utopia-regular
    >/dev/null

  

  

    Solaris 2.6
     
    Use Netscape browser for best results
  

  

     
    Internet Explorer 4.01
    MS Explorer on Solaris--Menus not displaying properly. A possible
    workaround is to run /usr/openwin/bin/xlsfonts -o utopia-regular >/dev/null
  

  

     
    Netscape 4.06
    Solaris 2.6 Netscape has corrupt local display with release notes loaded
    due to not rendering text fonts correctly.  See the Netscape README for the two xset
    commands to work around this.
  

  

    Windows NT 4.0
     
    Use Internet Explorer browser for best results
  

  

     
    Internet Explorer 4.01 SP1

    or Netscape 4.06		
    Java applications returning HTTP/1.0 500 Server Error and not loading. The
    workaround is to reinstall Windows NT Service Pack 3.
  

  

    Windows 95/Windows 98
     
    No browser has yet been fully qualified for these
    platforms
  

  

    HP-UX 10.20
     
    Use Netscape browser for any results
  

  

     
    Netscape 4.06
    <NONE>
  

  

     
     
    There are many incompatibility issues between NNM and Microsoft Internet
    Explorer for HP-UX.
  

  

    HP-UX 11.0
     
    Use Netscape browser for any results
  

  

     
    Netscape 4.06 for HP-UX 10.20
    HP-UX 11.0 is not officially supported by Netscape but seems to work on 32
    bit hardware.
  

  

    I
    Internet Explorer 4.01 (pre-release)
    There are many incompatibility issues between NNM and Microsoft Internet
    Explorer for HP-UX.
  







 



Java-based Web Interface -
HP OpenView Launcher






  
Do Not Close Launcher Window







Java-based Web Interface -
Network Presenter





Java-based Web Interface -
SNMP Data Presenter





Java-based Web Interface - Alarm
Browser





Web Event
Correlation Configuration (ECS) Management GUI





Web Server







You may replace the NNM Web Server with your own web server by following the
instructions on the CD in doc/WhitePapers/changeWebServer.txt



Network Discovery
(netmon/ipmap/ovtopmd)




  
ERROR: "Cannot look up field id for name field IP Address" appears in the
  Alarm Browser (NSMfc11943)






  

    
If ovtopmd is started after clearing the databases in $OV_DB/openview, this error
    message will appear in the alarm browser:  This is a harmless error message which can
    be avoided in the future by performing the following steps after clearing out the NNM
    databases:

        ovstart ovwdb

        ovw -fields

  

  
ERROR: ipmap reports number of licensed connectors as -1 (NSMfc10339)

  

    
If you select the Internet symbol and look at the Object Properties ->IPmap there is
    an entry for the number of licensed connectors. When the unlimited license is installed
    this field will contain the value "-1". When any other license is installed, the
    number of licensed connectors will appear: i.e. 250 for the instant on license.  You
    can safely ignore this message.

  

  
ERROR: You remove a symbol from the map, yet it remains on the map. (NSMfc12765)

  

    
Timing conditions while manually adding 250th node to a system licensed to have only
    250 managed nodes while discovery is active may cause a  'removed symbol' to remain
    on the map. This results from both the user and netmon attempting to add the last managed
    node, but in this case netmon wins. To prevent the problem from happening, turn off
    discovery using "Options->Network Polling Configuration" menu item,
    delete or unmanage nodes to bring the managed node count below 250, manually add the
    desired nodes, and re-enable discovery. To clean up the map, run ovtopofix (see
    the ovtopofix man/reference page for details)

  





Native Alarm Browser (xnmevents)




  
New Non-Web Alarm Browser (xnmevents) Behavior

  All operator actions, Acknowledge, UnAcknowledge, Delete, Assign Severity, Assign
  Category, are global (affecting all browsers).

  
Alarm Browser (xnmevents) no longer maintains per user state files. There is
  only one common state file. Old per user state files are not compatible with NNM 6.01 and
  will be ignored.

  
Some correlated events, from the PairWise correlation, will cause the Alarm Browser to
  redraw twice on Windows NT. In the rare situations where this occurs, this could take up
  to 16 seconds of time.  (NSMfc12850)







Data Warehouse



    
  
    When using databases other than the embedded database, the user needs to manually
  instantiate the data warehouse schemas using ovdwsetup.ovpl before using the data
  warehouse.
    
  
    Using Oracle:
    
  
    All export tools are enabled for ODBC.  To use Oracle, sql*net must be
  installed and configured.  A default datasource has been configured in the /etc/opt/OV/share/conf/analysis/system_odbc.ini
  file, OVoracle.  To switch over, change the "ServerName" parameter
  in that file to your server as defined in tnsnames.ora. 
    
  Then run:
    
  
    
  
    Interrupting Data Warehouse Commands
    
  
    During our testing, we have experienced situations where killing or interrupting the
  database client program can have an adverse effect on some database servers.While this is
  still being investigated it appears that some versions of Microsoft SQL Server will fail
  when the client is canceled via "Control-C".
    
  
    If you are using the NNM embedded database technology, you may also experience a
  behavior where for a short time after interruption, the database server may think the
  client is still active. This could result in "primary key contraint violations" or
  some type of concurrency problem, if the same command is immediately restarted. However
  this should clear up within 30 seconds and future access to the database will not be
  effected.
    

  
    Clicking on the Stop button in the "Tools/Data Warehouse/Export Trend
  Data" dialog window will not interrupt the trend export process. It will
  finish to completion.
  
    
  
    Reinstall Service Packs
    
  
    You must reinstall your Windows NT service pack after adding any Microsoft
  Components such as Microsoft Peer Web Services, or you will see the following error (or an
  SNMP error).
    
  
    ODBC Version Mismatch dialog:
    
  
    You may get an "ODBC Driver Manager" popup window for a version mismatch for
  various ODBC utilities such as: 
    
          The ODBC resource DLL
  (C:\WINNT40\System32\odbcint.dll) is a different 
    
       version than the ODBC driver manager
  (C:\WINNNT40\System32\ODBC32.dll).
    
  
    You need to reinstall the ODBC components to ensure proper operation. This happens if
  you install *any* application which supplies ODBC components, not necessarily just
  NNM.  The only way to prevent  this popup is to reinstall your last Service
  Pack. NNM does NOT include any Windows NT ODBC components. This mismatched DLL problem is
  a known issue with Windows NT.  Further information can be retrieved from Microsoft
  Article PSS ID Number: Q170769. 
    
  
    Using ovbackup and the NNM Data Warehouse
    
  
    If you are using ovbackup.ovpl and are using the NNM Data Warehouse, when the
  ovbackup.ovpl command is executed, it will also instruct the Embedded Database server to
  initiate the online backup. In order to allow a roll-forward recovery the default backup
  schedule must be deactivated. The process for doing this is:
    
  
    
    
      
      
    1. copy the $OV_DB/analysis/default/solid.ini file to $OV_DB/analysis/default/solid.ini.old
        file.
      2. 
      
    2. Edit the $OV_DB/analysis/default/solid.ini file.
      3. 
      
    3. Comment out the "At=<time> backup" entry, by inserting a ";"
        at the beginning of the line. An example would be:
      
        ;At=01:00 backup
      4. 
      
    4. Save the $OV_DB/analysis/default/solid.ini file.
      5. 
    
    
  
    
  
    The embedded database will now be backed up only when the ovbackup.ovpl command is run.
  If use of ovbackup.ovpl is stopped at a future this, the default backup should be
  reinstated by copying the $OV_DB/analysis/default/solid.ini.old back to $OV_DB/analysis/default/solid.ini.
    




Remote Consoles



For Japanese NT Remote Consoles connecting to HP-UX or Solaris Management Stations, the
3rd party NT NFS product must be able to resolve the Japanese_Japan.932 symbolic links in
the registration, symbols, and conf subdirectories. If the ovw menus and symbols on the
Remote Console are in English, this means that the symbolic links are not working
correctly. For the third party NFS product Disk Access, you need to enable symbolic links
from the Disk Access applet in the Control Panel, not from the Administrator Utility.
  The default for Disk Access is to not enable symbolic links.



Allowing Enough Color Resources





  
No known problems on Windows NT.





Online Manuals





  
No known problems on Windows NT.





Event Configuration




  
(NSMfc13038)

  The following procedure will cause the Event Configuration window to hang: 
    
    
  1. start the Event Configuration Window from NNM's user interface, select:
    
      Options->Event Configuration 
    2. 
    
  2. pause NNM for back up (ovpause portion of the backup script)
    3. 
    
  3. Edit an the event source using "Add From Map":
    
      Edit->Add->Event->Add From Map
    4. 
  

  
The workaround is to not perform "Add From Map" during the paused portion of
  NNM's backup procedure. Or, if it's already paused and you cannot wait until backup has
  finished, from the command prompt:





SNMP Agent Issues






Internationalization (I18N)






  






Netscape Defect