EMC Networker KM for PATROL

Release Notes for v2.8.00

Home  Previous  Next

What's New

Fully compatible with BMC ProactiveNet Central Monitoring Administration, a feature supported by BMC ProactiveNet Performance Management version 9.0.00.

Now supports Microsoft Cluster.

Save groups monitoring: Save groups can now be monitored at the client level if EMC NetWorker v.7.6 or higher is used. By default, only the failed save clients are monitored but this setting can be modified through the new KM command Save clients.

In order to easily identify which step the initial discovery is processing, the setup icon now reflects the successive phases:

Upgrading: this information is only available for PATROL Classic Console.

Loading: indicates that commands are being loaded.

Initializing: indicates that KM paths are being initialized.

Discovering: indicates that the monitored application is being monitored.

Cleaning: indicates that the temp files are being cleaned.

Validating: indicates the application paths are being checked.

The NSRDatabaseRetention parameter was added to the NSR_DATABASE_CONTAINER application class to indicate the number of days data will be retained by the database.

New parameters were added to the NSR_LDEVICE application class:

NSRJDeviceSessionCount: displays the number of sessions configured for the jukebox device.

NSRJDeviceSessionMax: Displays the number of maximum sessions configured for the jukebox device.

NSRJDeviceSessionTarget: displays the number of target sessions configured for the jukebox device.

New parameters were added to the NSR_DEVICE application class:

NSRDeviceSessionCount: displays the number of sessions configured for the device.

NSRDeviceSessionMax: displays the maximum number of sessions configured for the device.

NSRDeviceSessionTarget: displays the number of target sessions configured for the device.

The new state 2=Service Mode was added to the NSRJukeboxState parameter. When this state is reached, a warning is triggered on the NSRJukeboxStatus parameter.

Changes and Improvements

All collectors are now automatically refreshed as soon as the KM configuration and the initial discovery are complete.

The default number of instances of Application Classes has been removed. This information can be defined by the user through the Instance Limits menu if required.

Logs:The default log scan limit was increased to 500 KBytes.

When one or more required paths are missing, the setup instance label will now indicate which paths are missing. A message will also be displayed in the System Output Window.

Client and policy monitoring is now enabled by default with an instance limit set to 50.

The NSRRemoveTempFiles parameter was removed since the temporary files are now created and removed by default by the agent user.

The NSRSaveSetErrorFound parameter and the associated KM Command Save Set Error Event Contents were removed.

All previous pconfig variables available under /NSR are now split to /NSR and /Runtime/NSR while upgrading the KM.

Debug Mode:

The time during which the debug information is logged can now be set by the user.

The KM-related messages that are sent to the System Output Window (SOW) are also logged to the NSR.log file available under <PATROL_HOME>/log.

The polling interval for the server discovery has been reduced from 5 minutes to 40 seconds to sooner detectserver-level changes and failures.

The KM failover time has been reduced to sooner detect node issues.

The NSRDatabaseBackupElapsed parameter was moved from the NSR_DATABASE application class to the NSR_DATABASE_CONTAINER application class to avoid duplicate events.

The infobox elements Last Backup Save Set ID, Last Backup Mode, and Last Backup were moved to the NSR_DATABASE_CONTAINER application class.

The mminfo query used for the bootstrap record was modified to improve the KM performance.

Fixed Issues

With some Windows platforms the Debug KM Command was prompting for an OS login to turn the debug on.

The NSRDaemonState parameter was set to "Not Running" when the PATROL Agent could not fork processes, which resulted in invalid alarms on the NSRDaemonStatus parameter.

The NSRSaveGrpText parameter was not properly set on Windows and did not include the client success details.