The Management Pack automatically discovers instances of SharePoint Office Service running within the Operations Manager 2007 management group, and deploys the SharePoint monitoring agent to those servers (aka Monitored Systems). Once the agents have been deployed, they automatically begin monitoring SharePoint applications for performance and exception issues.
The agent monitors for problems in the .NET elements of SharePoint applications, as indicated on the diagram by . With the AVIcode .NET MP also installed, you can monitor .NET Windows Services, Web Services and COM+ components that your SharePoint application communicates with, or any other ASP.NET application hosted under IIS.
The management pack discovers MOSS servers and automatically starts monitoring Microsoft Office SharePoint Web applications, IIS Web Sites, Excel Calculation Services and Enterprise Search.
Once the Application Management Pack has been installed, it initiates a 4-level discovery process for SharePoint servers and components:
Information about SharePoint web applications, IIS web sites and site collections is stored in the SharePoint database. In order for the discovery script to access this information, it must have access to the database server and the SharePoint database. Because the discovery script normally runs under the local system (action) account, it may not have the appropriate permissions to access the database, but can be granted access by correctly configuring the 'Run As' profile. If discovery does fail, correct the Run As account information, and force discovery to take place (see below for information on how to know when discovery has failed and about forcing discovery to take place).
The members of the .NET Enterprise Agent Deployment Group were selected when the Management Pack was installed. To modify the group membership:
Determining Discovery Success/Failure
You can determine whether discovery for some SharePoint components has failed if:
If discovery fails for SharePoint components, several methods can be used to correct the configuration of the discovery account. There are two methods for ensuring that there are sufficient permissions to complete the discovery process: Configure a run-as account, or add permissions to the local computer (action) account.
You will need to use an account from either the SharePoint Operators Group or the SharePoint Administrators Group to configure as the 'Run As' profile for SharePoint discovery. You may: 1) select an existing domain account from one of the groups, or 2) create a new domain account and add it to one of the groups.
To configure the 'Run As' profile to use the selected account:
To add permissions to the action account, you can either make the action account a member of either the SharePoint Operators Group or the SharePoint Administrators Group, or give the action account permissions for the SharePoint management database.
If the action account is the Local System account, then use the computer account when adding permissions.
The required rights are:
To grant additional user rights:
If discovery for any SharePoint components fails, it will normally take 24 hours before a new discovery attempt takes place unless discovery is forced.
Forcing Discovery Method #1
Forcing Discovery Method #2
This method requires changing the discovery interval to 1 minute (for example), waiting for the next discovery, and then changing the discovery interval back to 24 hours. This method is much longer, but no any harmful operation is done during it.
Application health is measured by user-specified performance and exception thresholds that are configured during the monitoring activation process. By default, the Management Pack monitors SharePoint applications for Handled and Unhandled exceptions
The SLA threshold is set to a very high value out of the box to avoid the possibility of generating too many events when monitoring is automatically started. Read the following sections for instructions to fine tune data collection.
The agents may be configured via the actions in the Operations Console.
If the actions are not visible, select 'View''Actions' in the Operations Console.
To select an object to apply an action to:
"SharePoint Server State View"
"SharePoint IIS Web Sites State View"
SharePoint Servers and SharePoint IIS Web Sites are the only state objects with associated tasks because they are only physical (vs. logical) objects that actions can be applied against. Actions do not apply to SharePoint state items for Excel Services, Search Services, Web Application or Web Site Collection.
Add user to WSS_WPG group
The 'Run As' profile must be configured as a domain account, and that domain account must belong to the 'WSS_WPG' group. 'Add user to WSS_WPG group' allows you to perform this task for all monitored servers in one action.
Pause [Resume] monitoring
This option is the equivalent of the 'Monitor All Web Applications by Default' option in the Intercept MMC. When this option 'resumes', all applications running under IIS will be monitored. When this option is 'paused', only specifically configured applications will be monitored.
This action performs an IIS Reset command.
Enable [Disable] Exception Diagnostic Data
This task enables/disables collecting exception diagnostic data in the monitored application. It adds All Namespaces into the list of monitored namespaces in order to collect functional parameters and member variables for custom namespaces in the exception event.
This action requires a service restart.
Enable [Disable] Performance Diagnostic Data
This task adds All Namespaces to collected information in the monitored application (or disables collecting performance diagnostic data in the monitored application). This option will cause the agent to start monitoring all functions except namespaces, classes and functions that are explicitly excluded from monitoring.
The '[All Namespaces]' item should be used judiciously as it will increase the amount of data collected.
Pause [Resume] Monitoring Application
This option starts/stops monitoring for a specific web site.
Set Alerting Threshold
An SLA threshold is used by the operations monitoring agent to define if an event needs to be reported. The operations monitor detects all requests that exceed this threshold and reports them. If the execution time for a request exceeds the alerting threshold, then the agent collects information about the request and reports it, otherwise the agent disposes the event data.
Set Sensitivity Threshold
The threshold for the execution time of a call to external resources (such as SQL queries or web service calls) is called the 'Sensitivity Threshold'. The sensitivity threshold for a resource call should never exceed the alerting threshold of the page or function it was called from. In a staging or test environment, setting the sensitivity threshold to zero will allow Intercept to report performance information on all resource calls, including those that took no time. In a production environment however, you should reduce overhead by eliminating the reporting of resource calls that took a negligible amount of time. This will help to eliminate extraneous information, which is of no interest in the alert.
Additional configuration options are available through the Intercept Management Console and through the agent configuration files. Details are available in the "Intercept Studio User Manual" .
Last update: Thursday, December 09, 2010 02:05:11 PM