What's New
| • | SharePoint KM for PATROL now supports Microsoft SharePoint 2013. |
| • | SharePoint KM for PATROL is now compatible with BMC ProactiveNet Central Monitoring Administration. This feature is supported by BMC ProactiveNet Performance Management version 9.0.00 and higher. |
| • | WMI queries are now supported on 64-bit Windows. |
| • | Disable Sites Monitoring: This new feature allows administrators to disable the monitoring of all the sites to limit the number of instances created and therefore reduce the system resource consumption. |
Changes and Improvements
| • | The KM performance has been improved. |
| • | A backup of the PATROL Agent configuration is now performed and saved in the $PATROL_HOME/config directory before a Reinitialization of the KM. |
| • | A new configuration variable, maxLockTimeout, is now available to specify the time during which the collect/discovery is locked and no other collect/discovery can be executed. |
| • | In the previous versions of SharePoint KM for PATROL, the LastMatchingEvents parameter listed the last 10 events detected during the last collect. From version 2.0.00, events detected during previous collects are also listed. |
| • | The KM Command Java Settings has been removed. |
| • | The KM Command Restore Component Monitoring has been renamed Restore Monitoring. |
Thresholds Management
In order to optimize the discovery process and improve the scalability of the solution, several important changes have been implemented in the way alert thresholds are managed by the KM.
| • | Default thresholds are set in the agent’s configuration, only once, the first time the KM runs. In previous versions, the KM would set default alert thresholds during each discovery (every hour by default) according to its internal policy, thus overwriting any changes that were made manually by the administrators. Administrators can now customize the default thresholds using the Event Management KM or PCM (PATROL Configuration Manager) and do not need to use the KM’s interface to make sure these customization are overwritten by the discovery of the KM. |
| • | Thresholds are set globally at the class level (or at least for a group of instances). In previous versions, the KM would set alert thresholds for each and every instance of each class, leading to extremely large configuration files (which could cause PCM to crash in some occasions). A limited set of parameters still require alert thresholds to be set at the instance level. This results in a much smaller agent configuration file and vastly improved performance. |
| • | The “Modify Thresholds” KM Commands has been removed as the thresholds can now be managed by PATROL administrators in a standard way through the Event Management KM and PCM (or any other method used in their environment). |
| • | The “Alert After N Times” KM Command has been removed, as this setting can now be managed by PATROL administrators in a standard way through the Event Management KM and PCM. |
| • | To reset the alert thresholds to their default values (as when the KM first runs), the administrator can either use the “Reinitialize KM” KM Command with the “Reset alert thresholds” option enabled or use the Event Management KM or PCM to delete the corresponding configuration variables. The KM resets the threshold configuration variables to their default values when such variables do not exist. |
| • | The “Thresholds Mechanism Selection” KM Command configures the location of the default alert thresholds configuration variables that are set during the first initialization of the KM: either in the /AS or in the /___tuning___ configuration tree. It is recommended to leave this setting to “Automatic” to make sure the thresholds configuration variables are stored in the proper location and avoid instability in the threshold settings. |
 During the upgrade from an earlier version, the KM will remove all of the instance-specific thresholds configuration variables. These numerous identical instance-specific thresholds are replaced with global thresholds at the class level. Thresholds that had been manually customized through the KM interface remain in place.
Fixed Issues
| • | Upon startup, several collect cycles could be required to update all the parameters. |
| • | Password is now encrypted in the Security Settings dialog box. |
| • | 2-pass authentication (Challenge, Kerberos, NTLM) was not handled properly when a specific user name was specified in the KM's Settings. |
SEN_WSS_HTTPAVAILABILITY Application Class
| • | HTTP/401 errors were not properly reported by the Availability and HTTPReturnCode parameters. |
| • | A negative value was sometimes reported for the HTTPResponseTime parameter. |
|
