9 times out of 10, the problem here is what Marco described - specifically, that events have been buffered in the /usr/nr/var/nrdirmap.buffer.txt file. Did you have a file there and did you delete it? The presense of a buffer file indicates that you are receiving alarms faster than the director can handle them. Therefore, if you see an nrdirmap buffer file, you should look through the file to determine what types of alarms are being sent, then reconfigure the Sensor to stop sending the false positives.
Once you have reconfigured the sensor to stop sending all the false positives, delete all the alarm icons from the OpenView map, then shut down ovw, then delete the nrdirmap.buffer file, then bring the user interface back up and see what happens.
If you still get lots of alarms in the display after all this, then there are two possible causes:
1) The sensor is still sending reams of events to the Director. To test this, look at the log files in the /usr/nr/var directory. If there are lots of large files here that are getting created at short intervals, then the Sensor is still to blame. If you don't know how to configure the sensor to reduce the alarm load, you could reconfigure the Director to only display, say, level 5 alarms. To do this, click on the "packetd" icon in the openview display, and then select "object properties" or "modify/describe object" (depends on the version of openview you are using). Set the "minimum marginal severity status" and "minimum critical severity status" levels to 5, and then press OK.
This should cause OpenView to display only 5 and higher alarms from this sensor. This might help reduce the clutter on the screen.
2) If alarms keep coming on the screen and you are sure that the sensor isn't sending any new events, then there is only one other possible cause: You have multiple OpenView maps, and you are deleting the alarms from one map but not from all maps. To test this theory, go to the command line and type:
ovwls
If you get multiple lines here, then it means that you have multiple maps defined. If the alarms exist on more than one map, then the act of deleting the alarms from one map will not delete them from the database. To delete them from the database, you have to delete them from all maps.
The method for doing all this is complicated, but in short you have to launch each map individually with from the command line with the command:
ovw -m
and then select the alarms and then delete them.
A few comments about multiple maps:
A) If you can avoid having multiple maps, then only use a single map. If you feel like you only need one map, bring up openview and use the File->Delete Map menu function to delete all the other extraneous maps. This reduces disk usage and improves performance.
B) Generally, having multiple maps should not cause the alarms to pop back up on a single map.... This should only occur if there is something strange going on on your machine. For example, if the system time is set incorrectly on your machine, then that could do it (go to the command line and type "date" - if the date is wrong, reset the date to the right value and then shut down the openview user interface and daemons and bring it back up). Also, if someone added a "-f" (force) option to your nrdirmap's registration file (in $OV_REGISTRATION/C), then this could cause the alarms to come back after deletion. If someone added this -f option to the nrdirmap registration file, remove it then shut down and restart the ovw user interface.
*****
A few final comments:
The alarm handling capability in Cisco's CSPM (Cisco Secure Policy Manager) is far superior to that of the OpenView NetRanger Director. If you have not had a CSPM demo, I highly recommend that you get a demo. It is far, far, far better than the OpenView director. There are some fundamental limitations in the OpenView database that cause alarm handling to be less than optimal.
If you refuse to use CSPM (because it is an NT-only product), then I highly recommend that you look into Cisco's MDC (multi-device controller) IDS management software that should be ready for release within the next few months. It is web-based (so therefore works on NT and Unix) and uses a kick-ass and reliable relational database for alarm storage. This product will be the mother of all event viewing user interfaces and will simply blow you away. Please ask your Cisco IDS representative for a demo of this MDC product.
Good luck.
-JB
