NetIQ
®
AppManager
®
for
Microsoft SharePoint Server
Management Guide
Legal Notice
THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE AGREEMENT OR A NON-DISCLOSURE AGREEMENT. EXCEPT AS EXPRESSLY SET FORTH IN SUCH LICENSE AGREEMENT OR NON-DISCLOSURE AGREEMENT, NETIQ CORPORATION PROVIDES THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME STATES DO NOT ALLOW DISCLAIMERS OF EXPRESS OR IMPLIED WARRANTIES IN CERTAIN TRANSACTIONS; THEREFORE, THIS STATEMENT MAY NOT APPLY TO YOU.
For purposes of clarity, any module, adapter or other similar material ("Module") is licensed under the terms and conditions of the End User License Agreement for the applicable version of the NetIQ product or software to which it relates or
interoperates with, and by accessing, copying or using a Module you agree to be bound by such terms. If you do not agree to the terms of the End User License Agreement you are not authorized to use, access or copy a Module and you must destroy all copies of the Module and contact NetIQ for further instructions.
This document and the software described in this document may not be lent, sold, or given away without the prior written permission of NetIQ Corporation, except as otherwise permitted by law. Except as expressly set forth in such license agreement or non-disclosure agreement, no part of this document or the software described in this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise, without the prior written consent of NetIQ Corporation. Some companies, names, and data in this document are used for illustration purposes and may not represent real companies, individuals, or data.
This document could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein. These changes may be incorporated in new editions of this document. NetIQ Corporation may make improvements in or changes to the software described in this document at any time.
U.S. Government Restricted Rights: If the software and documentation are being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), in accordance with 48 C.F.R. 227.7202-4 (for Department of Defense (DOD) acquisitions) and 48 C.F.R. 2.101 and 12.212 (for non-DOD acquisitions), the government’s rights in the software and documentation, including its rights to use, modify, reproduce, release, perform, display or disclose the software or documentation, will be subject in all respects to the commercial license rights and restrictions provided in the license agreement.
© 2013 NetIQ Corporation and its affiliates. All Rights Reserved.
Contents
About this Book and the Library 5
About NetIQ Corporation 7
1 Introducing AppManager for Microsoft SharePoint Server 9
2 Installing AppManager for Microsoft SharePoint Server 11
2.1 System Requirements . . . 11
2.2 Scalability Considerations . . . 12
2.3 Installing the Module . . . 13
2.4 Silently Installing the Module . . . 15
2.5 Post-installation Considerations . . . 15
2.6 Configuring the PowerShell Execution Policy . . . 20
2.7 Changing PowerShell Configuration Settings . . . . 23
2.8 Permissions for Running Knowledge Scripts . . . . 24
2.9 Troubleshooting Configuration Errors . . . 26
2.10 Discovering SharePoint Resources . . . 28
2.11 Deploying the Module with Control Center. . . 28
3 SharePoint Knowledge Scripts 31 3.1 BytesTransfer . . . 32 3.2 ConnectionsInterval . . . 33 3.3 ContentDatabaseAccessibility . . . 35 3.4 ContentManagementEventLog . . . 36 3.5 DBSiteCount . . . 38 3.6 DBSpaceUtil . . . 39 3.7 ExtendedWebApplications . . . 41 3.8 FASTSearchServerStatus . . . 42 3.9 GenericEventLog . . . 44 3.10 HealthAnalyzer . . . 46 3.11 HealthCheck. . . 47 3.12 InfoPathEventLog. . . 49 3.13 IsolatedApps . . . 51 3.14 MailServerStatus . . . 52 3.15 RecycleBinInfo . . . 53 3.16 Report_ServerUptime . . . 56 3.17 Report_SiteInfo . . . 58 3.18 Report_SiteUsage . . . 61 3.19 Report_WebPartInfo . . . 63 3.20 SearchStatus . . . 65 3.21 ServerUptime . . . 66 3.22 SiteCollectionUserCount . . . 67 3.23 SiteEventLog . . . 69 3.24 SiteInfo . . . 70 3.25 SiteUsage. . . 72
3.27 WebApplicationUptime . . . 76 3.28 WebPagePerf . . . 77 3.29 WebPartInfo . . . 79
About this Book and the Library
The NetIQ AppManager product (AppManager) is a comprehensive solution for managing, diagnosing, and analyzing performance, availability, and health for a broad spectrum of operating environments, applications, services, and server hardware.
AppManager provides system administrators with a central, easy-to-use console to view critical server and application resources across the enterprise. With AppManager, administrative staff can monitor computer and application resources, check for potential problems, initiate responsive actions, automate routine tasks, and gather performance data for real-time and historical reporting and analysis.
Intended Audience
This guide provides information for individuals responsible for installing an AppManager module and monitoring specific applications with AppManager.
Other Information in the Library
The library provides the following information resources:
Installation Guide for AppManager
Provides complete information about AppManager pre-installation requirements and step-by-step installation procedures for all AppManager components.
User Guide for AppManager Control Center
Provides complete information about managing groups of computers, including running jobs, responding to events, creating reports, and working with Control Center. A separate guide is available for the AppManager Operator Console.
Administrator Guide for AppManager
Provides information about maintaining an AppManager management site, managing security, using scripts to handle AppManager tasks, and leveraging advanced configuration options.
Upgrade and Migration Guide for AppManager
Provides complete information about how to upgrade from a previous version of AppManager.
Management guides
Provide information about installing and monitoring specific applications with AppManager.
Help
Provides context-sensitive information and step-by-step guidance for common tasks, as well as definitions for each field on each window.
The AppManager library is available in Adobe Acrobat (PDF) format from the AppManager Documentation page of the NetIQ Web site.
About NetIQ Corporation
We are a global, enterprise software company, with a focus on the three persistent challenges in your environment: Change, complexity and risk—and how we can help you control them.
Our Viewpoint
Adapting to change and managing complexity and risk are nothing new
In fact, of all the challenges you face, these are perhaps the most prominent variables that deny you the control you need to securely measure, monitor, and manage your physical, virtual, and cloud computing environments.
Enabling critical business services, better and faster
We believe that providing as much control as possible to IT organizations is the only way to enable timelier and cost effective delivery of services. Persistent pressures like change and complexity will only continue to increase as organizations continue to change and the technologies needed to manage them become inherently more complex.
Our Philosophy
Selling intelligent solutions, not just software
In order to provide reliable control, we first make sure we understand the real-world scenarios in which IT organizations like yours operate — day in and day out. That's the only way we can develop practical, intelligent IT solutions that successfully yield proven, measurable results. And that's so much more rewarding than simply selling software.
Driving your success is our passion
We place your success at the heart of how we do business. From product inception to
deployment, we understand that you need IT solutions that work well and integrate seamlessly with your existing investments; you need ongoing support and training post-deployment; and you need someone that is truly easy to work with — for a change. Ultimately, when you succeed, we all succeed.
Our Solutions
Identity & Access Governance Access Management
Security Management
Systems & Application Management Workload Management
Contacting Sales Support
For questions about products, pricing, and capabilities, contact your local partner. If you cannot contact your partner, contact our Sales Support team.
Contacting Technical Support
For specific product issues, contact our Technical Support team.
Contacting Documentation Support
Our goal is to provide documentation that meets your needs. The documentation for this product is available on the NetIQ Web site in HTML and PDF formats on a page that does not require you to log in. If you have suggestions for documentation improvements, click comment on this topic at the bottom of any page in the HTML version of the documentation posted at www.netiq.com/
documentation. You can also email [email protected]. We value your input and look forward to hearing from you.
Contacting the Online User Community
NetIQ Communities, the NetIQ online community, is a collaborative network connecting you to your peers and NetIQ experts. By providing more immediate information, useful links to helpful
resources, and access to NetIQ experts, NetIQ Communities helps ensure you are mastering the knowledge you need to realize the full potential of IT investments upon which you rely. For more information, visit community.netiq.com.
Worldwide: www.netiq.com/about_netiq/officelocations.asp
United States and Canada: 1-888-323-6768
Email: [email protected]
Web Site: www.netiq.com
Worldwide: www.netiq.com/support/contactinfo.asp
North and South America: 1-713-418-5555
Europe, Middle East, and Africa: +353 (0) 91-782 677
Email: [email protected]
1
1Introducing AppManager for Microsoft
SharePoint Server
AppManager for Microsoft SharePoint Server enables you to identify and monitor the availability and connectivity of your Microsoft SharePoint servers and server databases. This product supports Microsoft SharePoint Server 2013, Microsoft SharePoint Server 2010 and Microsoft Office SharePoint Server 2007. The Knowledge Scripts provide a complete view of how SharePoint performs in your environment.
AppManager for Microsoft SharePoint Server allows you to: Monitor the complete SharePoint Server environment.
Display all available servers within the SharePoint Server environment, including newly added, modified, or deleted servers.
Monitor database space usage by different SharePoint servers.
Monitor the event logs for Infopath Forms, Content Management, and generic error events. Monitor the number of bytes transferred per second to and from a SharePoint Web application. Monitor the status and health of SharePoint services and Web applications, as well as the uptime
of Web applications on the SharePoint server.
Monitor the number of site collections on each SharePoint content database in the server farm, as well as the number of users in a site collection.
Monitor the extended Web applications and the mail server status in the server farm. Monitor the default Search service and crawl status in the SharePoint server farm.
Monitor Recycle Bin usage for all Web applications running on the SharePoint server, and ensure the Recycle Bin does not exceed the site quota.
Track the availability and performance of Web pages in a Web application within the SharePoint Server environment.
Monitor and report on how long the SharePoint server has been running since the last reboot. Monitor and report on space utilization and date information for each Web application on the
SharePoint server.
Monitor and report on the usage information for each Web application on the SharePoint server. Monitor and report on the performance of Web Parts in the SharePoint Server environment. Monitor the accessibility of SharePoint content databases for the Web applications running on
the SharePoint server.
Monitor the status of the SharePoint FAST Search Server. (SharePoint Server 2010)
Monitor the SharePoint Health Analyzer tool, which can automatically check for configuration, performance and usage problems in the SharePoint server farm. (SharePoint Server 2010 or later) Monitor the Visual Mode Site count for each Web application, site collection, and sub-site.
2
2Installing AppManager for Microsoft
SharePoint Server
This chapter provides installation instructions and describes system requirements for AppManager for Microsoft SharePoint Server.
This chapter assumes you have AppManager installed. For more information about installing AppManager or about AppManager system requirements, see the Installation Guide for AppManager, which is available on the AppManager Documentation page.
2.1
System Requirements
For the latest information about supported software versions and the availability of module updates, visit the AppManager Supported Products page. Unless noted otherwise, this module supports all updates, hotfixes, and service packs for the releases listed below.
AppManager for Microsoft SharePoint Server has the following system requirements:
Software/Hardware Version
NetIQ AppManager installed on the AppManager repository (QDB) computers, on the SharePoint computers you want to monitor (AppManager agents), and on all console computers
AppManager 8 Service Pack 2 (8.0.2) or later, or AppManager 7.0.4
The following hotfixes are required for AppManager 7.0.4:
AppManager Repository (QDB) hotfix 72040 and hotfix 72794. AppManager Operator Console hotfix 72212.
AppManager Management Server hotfix 72041.
AppManager Client Communication Manager and NetIQ AppManager Client Resource Monitor hotfix 72616. To support computers running Windows Server 2008,
AppManager Windows Agent hotfix 71704 or later is required.
Important You must install all hotfixes before installing this release
of the module. For more information about hotfixes, see the
AppManager Suite Hotfixes page, or contact NetIQ Technical Support.
Microsoft Windows operating system on agent computers
One of the following: Windows Server 2012 Windows Server 2008 R2
Windows Server 2008 (32-bit or 64-bit) Windows Server 2003 R2 (32-bit or 64-bit)
2.2
Scalability Considerations
Consider the following recommendations before deploying AppManager for Microsoft SharePoint Server:
Use an AppManager agent computer that meets the following minimum requirements: Dual Core/Dual vCPU 2.4 GHz (or higher)
2 GB RAM, in addition to the RAM needed for Microsoft SharePoint on the server Follow these Knowledge Script suggestions:
Use monitoring policies to allow the monitoring jobs to be automatically updated when changes in the environment, such as a new Web application, are discovered.
NOTE: A monitoring policy is applied on the agent and runs an AppManager job for each
Knowledge Script in the KSG. A monitoring policy may apply to many objects, and in the largest environments may not work for configuring AppManager. For assistance with configuring Knowledge Scripts and Knowledge Script Groups in a large environment, contact NetIQ Technical Support.
Ad hoc jobs do not automatically update when changes in the environment, such as a new Web application, are discovered. You must manually update a job to reflect changes to the environment.
Stagger the start time of jobs, especially jobs that monitor Web applications, so they do not all start at the same time. Do this by specifying a daily schedule with a frequency of X minutes with a different start time for each job. For example, to monitor every 5 minutes, specify a daily schedule with a frequency of 5 minutes starting at 12:00:00 for the first job, 12:01:00 for the second job, and so on. Do not specify a schedule of regular intervals every 5
minutes.
Consider the following when collecting data and raising events:
Schedule jobs that monitor Web applications to start during off-peak hours, such as in the evening or on the weekend. This includes the following Knowledge Scripts:
SharePoint_IsolateApps, SharePoint_RecycleBinInfo, SharePoint_SiteInfo, SharePoint_WebPagePerf, and SharePoint_WebPartInfo.
AppManager for Microsoft Windows module installed on repository, agent, and console computers
7.6.170.0 or later. For more information, see the AppManager Module Upgrades & Trials page.
Microsoft SharePoint Server and related applications on the agent computers
One of the following:
Microsoft SharePoint Server 2013 Microsoft SharePoint Server 2010 Microsoft Office SharePoint Server 2007 Microsoft .NET Framework installed on
the agent computers
Version 3.5 or later
Microsoft Windows PowerShell installed on the agent computers
Version 2.0 or later
In large environments, increase the default schedule of the SharePoint_WebPart Info Knowledge Script from every 30 minutes. NetIQ Corporation recommends every 3 hours. For Knowledge Scripts that monitor Web applications and SharePoint content databases,
run these jobs on just one server in the SharePoint Server farm because each job you run will display the same information for every server in the farm.
2.3
Installing the Module
Run the module installer only once on any computer. The module installer automatically identifies and updates all relevant AppManager components on a computer.
Access the AM70-SharePoint-7.x.x.0.msi module installer from the AM70_SharePoint_7.x.x.0 self-extracting installation package on the AppManager Module Upgrades & Trials page.
If you are upgrading from version 7.2, uninstall version 7.2 and perform additional steps to install version 7.4 or later correctly. For more information, see Section 2.3.2, “Upgrading from Version 7.2 or later versions of the Module,” on page 14.
For Windows environments where User Account Control (UAC) is enabled, install the module using an account with administrative privileges. Use one of the following methods:
Log in to the server using the account named Administrator. Then run AM70-SharePoint-7.x.x.0.msi from a command prompt or by double-clicking it.
Log in to the server as a user with administrative privileges and run
AM70-SharePoint.x.x.0.msi as an administrator from a command prompt. To open a command-prompt window at the administrative level, right-click a command-command-prompt icon or a Windows menu item and select Run as administrator.
You can install the Knowledge Scripts into local or remote AppManager repositories (QDBs). Install these components only once per QDB.
The module installer now installs Knowledge Scripts for each module directly into the QDB instead of installing the scripts in the \AppManager\qdb\kp folder as in previous releases of AppManager.
2.3.1
Manually Installing the Module
You can install the module manually, or you can use Control Center to deploy the module on a remote computer where an agent is installed. For more information, see Section 2.11, “Deploying the Module with Control Center,” on page 28. However, if you do use Control Center to deploy the module, Control Center only installs the agent components of the module. The module installer installs the QDB and console components as well as the agent components on the agent computer.
To install the module manually:
1 Double-click the module installer .msi file.
2 Accept the license agreement.
3 Review the results of the pre-installation check. You can expect one of the following three scenarios:
No AppManager agent is present: In this scenario, the pre-installation check fails, and the installer does not install agent components.
An AppManager agent is present, but some other prerequisite fails: In this scenario, the default is to not install agent components because of one or more missing prerequisites.
missing application server for this particular module often causes this scenario. For example, installing the AppManager for Microsoft SharePoint module requires the presence of a Microsoft SharePoint server on the selected computer.
All prerequisites are met: In this scenario, the installer installs the agent components.
4 To install the Knowledge Scripts into the QDB:
4a Select Install Knowledge Scripts to install the repository components, including the Knowledge Scripts, object types, and SQL stored procedures.
4b Specify the SQL Server name of the server hosting the QDB, as well as the case-sensitive QDB name.
5 (Conditional) If you use Control Center 7.x, run the module installer for each QDB attached to Control Center.
6 (Conditional) If you use Control Center 8.x, run the module installer only for the primary QDB, and Control Center will automatically replicate this module to secondary QDBs.
7 Run the module installer on all console computers to install the Help and console extensions.
8 Run the module installer on the Microsoft SharePoint computers you want to monitor (agents) to install the agent components.
9 Perform all required post-installation tasks, such as verifying services and enabling logging. For more information, see Section 2.5, “Post-installation Considerations,” on page 15.
10 (Conditional) If you have not discovered Microsoft SharePoint resources, run the Discovery_SharePoint Knowledge Script on all agent computers where you installed the module. For more information, see Section 2.10, “Discovering SharePoint Resources,” on page 28.
After the installation has completed, the SharePoint_Install.log file, located in the \NetIQ\Temp\NetIQ_Debug\ServerName folder, lists any problems that occurred.
2.3.2
Upgrading from Version 7.2 or later versions of the Module
If you are upgrading from version 7.2 to a more recent version of the module, you need to uninstall version 7.2 and then install the recent version of the module on each SharePoint agent, AppManager repository (QDB), and console.
If you are upgrading from version 7.4 to the recent version of the module, install the recent version on each SharePoint Server agent, AppManager repository (QDB), and console.
Version 7.4 and later versions of the module use PowerShell scripts throughout the module, so you must set the PowerShell execution policy. For more information, see Section 2.6, “Configuring the PowerShell Execution Policy,” on page 20.
This section describes the tasks required to upgrade from version 7.2 or later to version 7.4 or later of the module.
To upgrade from version 7.2 or later to recent version:
1 Stop the ad hoc jobs and remove all SharePoint monitoring policies.
2 (Conditional) To upgrade from version 7.2 to version 7.4 or later, uninstall version 7.2 of the module from agent computers.
3 Install the latest version of the module on all AppManager repositories (QDBs), consoles, and agents. For more information about running the installer, see Section 2.3, “Installing the Module,” on page 13.
4 The module installer automatically runs the Discovery Knowledge Script. If it does not, manually run Discovery_SharePoint. For more information about the Discovery Knowledge Script, see Section 2.10, “Discovering SharePoint Resources,” on page 28.
5 Re-create the ad hoc jobs and create new SharePoint monitoring policies.
2.4
Silently Installing the Module
To silently (without user intervention) install a module using the default settings, run the following command from the folder in which you saved the module installer:
msiexec.exe /i "AM70-SharePoint-7.x.x.0.msi" /qn where x.x is the actual version number of the module installer.
To create a log file that describes the operations of the module installer, add the following flag to the command noted above:
/L* "AM70-SharePoint-7.x.x.0.msi.log"
The log file is created in the folder in which you saved the module installer.
NOTE: To perform a silent install on an AppManager agent running Windows 2008 R2, open a
command prompt at the administrative level and select Run as administrator before you run the silent install command listed above.
To silently install the module on a remote AppManager repository, you can use Windows authentication or SQL authentication.
In a 32-bit environment, the default path to the NetIQ_Debug folder is: C:\Program Files\NetIQ\Temp\
Windows authentication:
msiexec /i "MSIFilePath \AM70-SharePoint-7.x.x.0.msi" /Lv "DebugFolderPath \NetIQ_Debug\SharePoint7.x.x.msi.log" /qn MO_B_QDBINSTALL=1 MO_B_MOINSTALL=0 AM_B_CALLED_FRM_AMSETUP=1 MO_B_SQLSVR_WINAUTH=1 MO_SQLSVR_NAME=SQL Server\Instance MO_QDBNAME=AMRepositoryName
SQL authentication:
msiexec /i "MSIFilePath \AM70-SharePoint-7.x.x.0.msi" /Lv "DebugFolderPath \NetIQ_Debug\SharePoint7.x.x.msi.log" /qn MO_B_QDBINSTALL=1 MO_B_MOINSTALL=0 AM_B_CALLED_FRM_AMSETUP=1 MO_B_SQLSVR_WINAUTH=0 MO_SQLSVR_USER= SQLLogin MO_SQLSVR_PWD=SQLLoginPassword MO_SQLSVR_NAME=SQL Server\Instance
MO_QDBNAME=AMRepositoryName
2.5
Post-installation Considerations
This section describes how to configure AppManager to enable this module to discover and work with your SharePoint environment.
2.5.1
Verifying SharePoint-related Services
The pre-installation checker makes sure the relevant SharePoint-related services are running before you install the module. Based on the type of server you are installing, the SharePoint installation starts the required services.
If you are using SharePoint in a distributed environment, each server will display a list of services specific to the version of SharePoint that the server is running.
Verifying SharePoint Server Services
Use the following steps to verify whether SharePoint-related services are present.
To verify whether the SharePoint-related services are present:
1 From the Control Panel, select Services from the Administrative Tools folder.
2 (Conditional) If the server is running Microsoft SharePoint 2013, the Services window displays the following services in the list:
SharePoint Administration SharePoint Search Host Controller SharePoint Server Search 15 SharePoint Timer Service SharePoint Tracing Service SharePoint User Code Host SharePoint VSS Writer
World Wide Web Publishing Service Forefront Identity Manager Service
Forefront Identity Manager Synchronization Service
3 (Conditional) If the server is running Microsoft SharePoint 2010, the Services window displays the following services in the list:
SharePoint 2010 Administration SharePoint 2010 Timer
SharePoint 2010 Tracing
SharePoint 2010 User Code Host SharePoint 2010 VSS Writer SharePoint Foundation Search V4 SharePoint Server Search 14
World Wide Web Publishing Service Forefront Identity Manager Service
Forefront Identity Manager Synchronization Service
4 (Conditional) If the server is running Microsoft Office SharePoint Server 2007, the Services window displays the following services in the list:
Windows SharePoint Services Administration Windows SharePoint Services Search
Windows SharePoint Services Tracing Windows SharePoint Services VSS Microsoft Single Sign-on Service World Wide Web Publishing Service
2.5.2
Enabling Usage Logging
When you enable usage logging, AppManager for Microsoft SharePoint Server tracks and reports usage data for your SharePoint environment. After you enable usage logging, you can run the SiteUsage and WebPagePerf Knowledge Scripts on a SharePoint server to gather site usage and Web page performance information. To enable usage logging, you must be a member of the Farm
Administrators SharePoint group.
The following sections describe how to enable usage logging for SharePoint Server 2013, SharePoint Server 2010 and SharePoint Server 2007.
Enabling Usage Logging in SharePoint Server 2013
This section describes how to enable usage logging and health data collection for SharePoint Server 2013.
To enable usage logging in SharePoint Server 2013:
1 Open SharePoint Central Administration and click Monitoring.
2 In the Reporting section, click Configure usage and health data collection.
3 In the Usage Data Collection section, select Enable usage data collection. Ensure that the events you want to log are selected in the Event Selection section. By default, all events are selected.
4 (Optional) If you want to log information about specific resources, data, and processes at certain points in time, select Enable health data collection in the Health Data Collection section.
5 Click OK.
Enabling Usage Logging in SharePoint Server 2010
This section describes how to enable usage logging and health data collection for SharePoint Server 2010.
To enable usage logging in SharePoint Server 2010:
1 Open SharePoint Central Administration and click Monitoring.
2 In the Reporting section, click Configure usage and health data collection.
3 In the Usage Data Collection section, select Enable usage data collection. Ensure that the events you want to log are selected in the Event Selection section. By default, all events are selected.
4 (Optional) If you want to log information about specific resources, data, and processes at certain points in time, select Enable health data collection in the Health Data Collection section.
5 Click OK.
6 To verify the settings in Central Administration, click Manage service applications in the
Application Management section. 7 Click WSS_UsageApplication.
Enabling Usage Logging in SharePoint Server 2007
This section describes how to enable usage logging and usage analysis processing for SharePoint Server 2007.
To enable usage logging in SharePoint Server 2007:
1 Open SharePoint Central Administration and click the Operations tab.
2 In the Logging and Reporting section, click Usage analysis processing.
3 In the Logging Settings section, select Enable Logging.
4 In the Log file location field, type the location for the log files. The default location is: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs
5 In the Number of log files to create field, type a number. Valid values are between 1 and 30.
6 In the Processing Settings section, select Enable usage analysis processing.
7 In the Run processing between these times daily fields, specify the time range for running usage processing.
8 Click OK.
2.5.3
Enabling Usage Reporting
By enabling usage reporting, you can create reports that track what users are doing and how they are using a site. After you enable usage reporting, you can run the SiteUsage Knowledge Script on a SharePoint server to gather site usage information.
For SharePoint Server 2010 and later, reporting is enabled by default.
Enabling Usage Reporting in SharePoint Server 2007
Before you can enable usage reporting for Shared Services in SharePoint Server 2007, you must configure the Index Server and the Primary Shared Services Provider.
For more information about configuring the Index Server, see http://technet.microsoft.com/en-us/library/dd256003%28v=office.12%29.aspx.
For more information about configuring the Primary Shared Services Provider, see http:// technet.microsoft.com/en-us/library/cc262649%28v=office.12%29.aspx.
To enable usage reporting from Shared Services in SharePoint Server 2007:
1 Ensure that you have configured the Index Server and the Primary Shared Services Provider. For more information, see the links in the introduction to this section.
2 Open SharePoint Central Administration.
3 In the Shared Services Administration section, click the default shared service.
4 On the Home page of the default shared service, click Usage reporting in the Office SharePoint
Usage Reporting section.
5 In the Processing Settings section, select Enable advanced usage analysis processing.
6 In the Search Query Logging section, select Enable search query logging.
2.5.4
Enabling Web Application Reporting
After you enable reporting on the Microsoft SharePoint server, you can run the SiteUsage Knowledge Script to monitor site usage information.
For SharePoint Server 2010 and later, reporting is enabled by default.
Enabling Web Application Reporting in SharePoint Server 2007
In SharePoint 2007, you activate Web application usage reporting to make the reports available. You can access collected data for reports 24 hours after you enable them.
To enable reporting using Microsoft SharePoint Server 2007: 1 Open SharePoint Central Administration.
2 From the Site Actions tab, click Site Settings.
3 In the Site Collection Administration section, click Site collection features.
4 Scroll down to the Reporting section and click Activate.
2.5.5
Allocating Storage Space for a SharePoint Site Collection
Microsoft SharePoint Server allows you to allocate storage space for the SharePoint site collection. You can also calculate the amount of space used by the Recycle Bin. After you allocate site quota for a SharePoint site collection, you can run the RecycleBinInfo Knowledge Script on a SharePoint server.
To allocate site quota for a SharePoint site collection: 1 Open SharePoint Central Administration.
2 Click Application Management and do one of the following:
(Conditional) If you are running SharePoint Server 2010 or later, in the Site Collections section, click Configure quotas and locks.
(Conditional) If you are running SharePoint Server 2007, in the SharePoint Site
Management section, click Site collection quotas and locks. 3 In the Site Collection section, select the URL for your site collection.
4 In the Site Quota Information section, in the Current quota template box, select Individual
Quota.
5 Click OK. By default, the storage limit of a personal site is 100 MB.
6 Modify settings for a personal site by doing one of the following:
(Conditional) If you are running SharePoint Server 2010 or later, select Specify quota
templates in the SharePoint Site Collections section.
(Conditional) If you are running SharePoint Server 2007, select Quota templates in the
SharePoint Site Management section.
7 On the Quota Templates page, in the Template Name section, edit an existing quota template or create a new template.
8 In the Storage Limit Values section, in the Limit site storage to a maximum of field, specify the maximum amount of storage space to allocate.
2.6
Configuring the PowerShell Execution Policy
This section describes the procedure for configuring the Microsoft PowerShell Execution Policy. The PowerShell Execution Policy determines whether PowerShell scripts are allowed to run.
2.6.1
Understanding PowerShell Cmdlets
Microsoft SharePoint 2010 and later uses the Microsoft scripting and command environment known as PowerShell. PowerShell is made up of hundreds of executable objects called cmdlets, pronounced
command-lets.
When running the SharePoint category of Knowledge Scripts, AppManager makes a series of calls to PowerShell and the SharePoint 2010 or later cmdlets. AppManager executes the cmdlets to
manipulate SharePoint 2010 or later objects. For SharePoint 2007 objects, AppManager uses PowerShell scripts to call the SharePoint 2007 Application Programming Interface (API). For more information about using PowerShell, see your Microsoft PowerShell documentation.
2.6.2
Configuring the PowerShell Execution Policy
The PowerShell Execution Policy determines whether PowerShell scripts are allowed to run. By default, the Execution Policy is set to Restricted. If you try to run scripts under the Restricted policy, AppManager generates error messages.
The Execution Policy directly affects the SharePoint Knowledge Scripts. Although the scripts that ship with SharePoint 2007, or later are written in VBScript and installed as scriptname.qml, the logic for the scripts is contained in complementary PowerShell scripts that are installed on the agent computer along with the module. The PowerShell scripts use the same name as the SharePoint Knowledge Scripts, but with a .ps1 extension.
NOTE: The digital signature encoded in an SharePoint Knowledge Script is tied to the contents of the
script. If you change the script, the signature is no longer valid and you cannot execute the script. If you change a SharePoint Knowledge Script, you must do one of the following:
Re-sign the scripts using your own digital certificate.
Change the Execution Policy to either RemoteSigned or Unrestricted. A group policy that governs script execution overrides any policy changes you make with the
Set-ExecutionPolicy cmdlet. For example, if the group policy forbids script execution, you cannot change the policy by running Set-ExecutionPolicy. First change the group policy to allow script execution, and then run Set-ExecutionPolicy to select a specific Execution Policy. Before AppManager can execute the PowerShell scripts, you must change the Execution Policy from
Restricted to one of the following policy options:
AllSigned, which allows execution of scripts that have been digitally signed by a trusted publisher. If you select the AllSigned policy, perform the steps outlined in Section 2.6.3, “Trusting SharePoint PowerShell Scripts,” on page 21.
RemoteSigned, which allows local scripts to run regardless of signature, and requires trusted digital signatures only for remote scripts. SharePoint Knowledge Scripts are local scripts. Unrestricted, which allows both local and remote scripts to run, regardless of signature.
To change the PowerShell Execution Policy:
1 Open the SharePoint Command Shell on the agent computer.
2 Run the following cmdlet: Set-ExecutionPolicy policy
where policy is the name of the Execution Policy you choose.
3 Repeat Step 1 and Step 2 on all agent computers that are members of the SharePoint server farm.
2.6.3
Trusting SharePoint PowerShell Scripts
When a PowerShell script is executed under an AllSigned policy, PowerShell verifies that the script contains a digital signature and that the signature is associated with a trusted publisher. NetIQ Corporation signs the SharePoint PowerShell scripts. If you use the AllSigned policy, you must choose to trust NetIQ Corporation by importing the NetIQ Corporation digital certificate into the local certificate store on each SharePoint server in your environment.
You can import the digital certificate by running one of the SharePoint PowerShell scripts from the command line.
To import the digital certificate:
1 Open the Windows PowerShell Command Shell on the agent computer.
2 Change to the AppManager\bin\PowerShell\Scripts directory.
3 Type .\SharePoint_GenericEventLog.ps1
4 Press Enter.
5 Type A at the prompt asking whether the script should be allowed to run.
6 Press Enter.
These steps allow the NetIQ Corporation digital certificate to be imported into the certificate store for the user running the script. Run any script once to establish trust.
At this point, trust is established only between NetIQ Corporation and the user running the script.
Trust is not established for any other user. If the AppManager agent runs under a different user account
such as Local System, a domain account, or a local computer account, the agent will not have a trust relationship and will not be allowed to execute the SharePoint PowerShell scripts.
To extend trust to all other user accounts, see Section 2.6.4, “Extending Trust to All User Accounts,” on page 21.
2.6.4
Extending Trust to All User Accounts
To execute PowerShell scripts under the AllSigned Execution Policy, extend trust to all user accounts. Extending trust is a two-phase process that involves exporting the digital certificate from the current user and importing the digital certificate to all users on the local computer.
Exporting the NetIQ Corporation Digital Signature Certificate
To extend trust to all user accounts, first export the NetIQ Corporation digital signature certificate from the current user using the Microsoft Management Console.
To export the NetIQ Corporation digital signature certificate from the current user: 1 On the Start menu, click Run.
2 In the Open field, type mmc.exe, and click OK.
3 On the File menu in the Microsoft Management Console window, click Add/Remove Snap-in.
4 Click Add and then select the Certificates snap-in.
5 Click Add, select My user account, and then click Finish.
6 Click Close and then click OK. The Certificates-Current User node is displayed in the tree view of the Console window.
7 Expand Certificates - Current User.
8 Expand Trusted Publishers and select Certificates.
9 In the right pane, right-click the NetIQ certificate, select All Tasks, and then select Export.
10 Click Next in the Certificate Export Wizard.
11 Select DER encoded binary and then click Next.
12 Click Browse, select the Desktop icon, type NetIQ in the File name field, and then click Save.
13 Click Next, and then click Finish.
Importing the NetIQ Corporation Digital Signature
The next phase of extending trust to all user accounts involves importing the NetIQ Corporation digital signature to all users on the local computer. Use the Microsoft Management Console to execute the import procedure.
To import the NetIQ Corporation digital certificate to all users on the local computer:
1 On the File menu in the Microsoft Management Console window, click Add/Remove Snap-in.
2 Click Add and then select the Certificates snap-in.
3 Click Add, select Computer account, and then click Next.
4 Select Local computer and then click Finish.
5 Click Close and then click OK.
6 Expand Certificates (Local Computer) and select Trusted Publishers.
7 Right-click in the right pane, select All Tasks, and then select Import.
8 Click Next in the Certificate Import Wizard.
9 Click Browse, click the Desktop icon, select NetIQ.cer, and then click Open.
10 Click Next in the wizard.
11 Select Place all certificates in the following store.
12 Click Browse and then select Show physical stores.
13 Expand Trusted Publishers and select Local Computer.
14 Click OK.
After you complete both the phases of the trust process, the NetIQ Corporation certificate is
contained in the certificate store for the local computer, allowing all users to execute the PowerShell scripts.
2.7
Changing PowerShell Configuration Settings
AppManager for Microsoft SharePoint Server includes the following components:
A client object, MCPSHostClient.dll, which runs within the AppManager agent. This client object starts the server program and asks it to run jobs.
A server program, MCPSHostServer.exe, which provides the PowerShell environment in which the SharePoint scripts are executed.
Both components have associated configuration files that define certain operational parameters. You can modify these settings to fine-tune performance or to specify resource usage limits.
The configuration files are in XML format. After making changes, ensure that the files retain their well-formed XML format. Also do not remove or change settings other than those documented here. NetIQ Corporation strongly recommends that you create backup copies of these files before
modifying them.
NOTE: This topic does not discuss all configuration settings. As a rule, if a configuration setting is
not discussed in this topic, you should not change the value of that setting.
2.7.1
Client Configuration Settings
The client configuration file, MCPSHostClient.dll.config, resides in the AppManager\bin\PowerShell directory. You can change the following settings. In the <appSettings> section:
maxActiveServers Use this setting to specify the maximum number of MSPSHostServer.exe instances that can be active at any time. Use this setting in conjunction with maxMemoryUsage to specify a lower memory threshold with an increased number of servers that can be used. This combination is beneficial for situations in which a server exceeds the memory limitation and has to shut down. If only one server can be active at a time, job requests are blocked until the server restarts. If you allow more than one server to be active, job requests can be executed in other server processes or on new servers if the current number of active servers is less than
maxActiveServers.
serverStartupTimeout Use this setting to specify the number of seconds a job will wait in the client for an opening to become available in a server so that the job can run. A job must wait if
maxActiveServers are already running, and if each of those servers is hosting maxActiveClients
jobs, otherwise the job will be run in an active server (if an active server exists that is not hosting
maxActiveClients), or a new server will be started to host the job.
In the <log4net> section:
file Use this setting to specify the pathname of the log file. If the pathname is a relative path, it is considered to be relative to the \AppManager\bin\PowerShell directory.
appendToFile Use this setting to indicate whether the client overwrites the existing log file or appends to it, at the time the client is loaded into the AppManager agent.
maxSizeRollBackups Use this setting to specify the number of old log files you want to retain. maximumFileSize Use this setting to specify the maximum size of a log file. After a log file
reaches this size, it is deleted, or renamed if the maxSizeRollBackups value is greater than 0.
2.7.2
Server Configuration Settings
The server configuration file, MCPSHostServer.exe.config, resides in the AppManager\bin\PowerShell directory. You can change the following settings. In the <appSettings> section:
serverShutdownTimeout Use this setting to specify the number of seconds that the server will remain running while idle, with no jobs executing within it. For example, if you set this option to 1, each MCPSHostServer.exe instance will shut down one second after it enters a state where no jobs are running within it. As long as a single job is running in a server, the server will stay running. When the job count drops to zero, the shutdown timer starts, and when a new job starts running the shutdown timer is turned off and reset.
maxActiveClients Use this setting to determine the maximum number of jobs that can run in a single server at the same time. Only jobs that are actively running are taken into account; jobs that are between iterations do not count.
maxMemoryUsage Use this setting to specify the maximum amount of memory, in megabytes, that a server will use before it stops accepting new jobs and shuts down. The server will finish executing all jobs currently running on it before the shutdown.
NOTE: If you raise the values for maxMemoryUsage and maxActiveClients, you can decrease
the value for maxActiveServers, because many clients can run in a single server. In the <log4net> section:
file Use this setting to specify the path of the log file. If the path is relative, it is considered to be relative to the \AppManager\bin\PowerShell directory.
appendToFile Use this setting to indicate whether the client overwrites the existing log file or appends to it, at the time the client is loaded into the AppManager agent.
maxSizeRollBackups Use this setting to specify the number of old log files you want to retain. maximumFileSize Use this setting to specify the maximum size of a log file. After a log file
reaches this size, it is deleted, or renamed if the maxSizeRollBackups value is greater than 0.
2.8
Permissions for Running Knowledge Scripts
AppManager for Microsoft SharePoint Server requires that the NetIQ AppManager Client Resource Monitor (netiqmc) and the NetIQ AppManager Client Communication Manager (netiqccm) agent services use one of the following account types:
Agent User account Domain account
2.8.1
Changing Account Types of Agent Services
You can change the account type for the netiqmc and netiqccm agent services. If you use the farm setup account, you do not need to do any additional configuration for the account type.
For information about creating an Agent User account and a Domain account, see Section 2.8.2, “Creating an Agent User Account,” on page 25 and Section 2.8.3, “Creating a Domain Account,” on page 26.
To change the account type of the agent services:
1 Start the Services Administrative Tool. To do this, you can open the Administrative Tools folder in the Control Panel.
2 Right-click the NetIQ AppManager Client Communication Manager (netiqccm) service in the list of services, and select Properties.
3 On the Logon tab, specify the appropriate account to use.
4 Click OK.
5 Repeat Step 2 through Step 4 for the NetIQ AppManager Client Resource Monitor (netiqmc) service.
6 Restart both services.
2.8.2
Creating an Agent User Account
You can create a new local user called Agent User for the netiqmc and netiqccm agent services.
To create the Agent User:
1 Create a new local user named Agent User on the agent computer, and give the Agent User local administrator permissions for that computer.
2 Repeat Step 1 for each SharePoint server in the farm.
3 On the SQL Server computer, create a new local user named Agent User, and give the Agent User normal user permissions (non-administrator).
4 On the SQL Server computer, add Agent User to the database logins.
5 On the SharePoint configuration database, add Agent User to the Users, and add the following Role memberships:
db_datareader db_denydatawriter
SharePoint_Shell_Access (SharePoint Server 2010 and later.)
WSS_Content_Application_Pools (needed to run stored procedures, or sprocs)
6 For each SharePoint content database, add Agent User to the list of Users.
7 (Conditional) If you are running SharePoint Server 2010 or later, for the logging database, give Agent User the following Role memberships (this allows the WebPagePerf Knowledge Script to run):
db_denydatawriter db_owner
8 For each SharePoint content database, give Agent User the following Role memberships: db_denydatawriter
9 (Conditional) If you are running SharePoint Server 2010 or later, set up the account as a site collection administrator by running the following command: Set-SPSite -Identity "SiteCollectionURL" -SecondaryOwnerAlias "ComputerName\Username"
10 Repeat Step 9 for all site collections.
2.8.3
Creating a Domain Account
If you are running SharePoint Server 2010 or later, you can create a new domain account for the netiqmc and netiqccm agent services.
To create the domain account:
1 Click Start > Programs > Administrative Tools > Active Directory Users and Computers.
2 Create a new domain account, such as MyDomain\SharePoint, and give the new domain account administrator permissions for each SharePoint server in the farm.
NOTE: You do not need grant any permissions on the SQL server computer.
3 Log on to any SharePoint server with the farm setup account (the user account used to set up the SharePoint server).
4 Open the SharePoint Management shell.
5 At the Windows PowerShell command prompt, type the following commands to assign the account to the SharePoint_Shell_Access role on the SharePoint content databases, and to make the account a member of the WSS_ADMIN_WPG local group on all servers in the farm: $db = get-SPContentDatabase "ContentDBName"
Add-SPShellAdmin -Username "Domain\Username" -database $db
6 Set up the account as a site collection administrator by running the following command: Set-SPSite -Identity "SiteCollectionURL" -SecondaryOwnerAlias "Domain\Username"
7 Repeat Step 6 for all site collections.
8 For the logging database, give Agent User the following Role memberships (this allows the WebPagePerf Knowledge Script to run):
db_denydatawriter db_owner
2.9
Troubleshooting Configuration Errors
This section provides solutions for PowerShell error messages you may encounter.
2.9.1
PowerShell Execution Errors
Knowledge Scripts in the SharePoint category may raise events such as “PowerShell script failed to run to completion” or “Error executing PowerShell script.” These errors can occur when Knowledge Scripts take a long time to run, or when there is contention for access to the server that executes the PowerShell scripts, MCPSHostServer.exe. The following are some
recommendations for resolving these issues:
Increase the amount of memory that can be used by MCPSHostServer.exe. Increasing the memory limit reduces the frequency with which the server restarts due to excessive memory usage. Increasing the memory limit also reduces the number of PowerShell errors; each time the
server recognizes that it is exceeding its memory usage threshold, the server prevents new jobs from executing until all existing jobs have completed and the server restarts. If existing jobs take a significant amount of time to complete, the waiting jobs may time out and return errors. To increase the amount of memory MCPSHostServer.exe can use, modify the value of the
maxMemoryUsage setting. For more information, see Section 2.7, “Changing PowerShell Configuration Settings,” on page 23.
Increase the number of PowerShell execution environments, or runspaces, that
MCPSHostServer.exe can host. If you attempt to run more jobs than the available number of
runspaces on the server, the most recent jobs are held back until runspaces become available as existing jobs complete their iterations. Being held back in this manner increases the chance that jobs will time out before running or before completing their iteration. To increase the number of available runspaces, modify the maxActiveClients setting. For more information, see
Section 2.7, “Changing PowerShell Configuration Settings,” on page 23.
NOTE: The client’s maxActiveServers configuration option specifies the maximum number of
servers that can be active at any time (the default is five). The maxActiveServers configuration value and the maxActiveClients server configuration value determine the total number of jobs that can be serviced at any one time. You can have more than this number of jobs in the “Running” state in AppManager, but only if some of the jobs are between iterations, and not actually running at the same time.
2.9.2
PowerShell Initialization Error
Knowledge Scripts in the SharePoint category may also raise events such as “Failed to initialize MCPSHostServer PowerShell session.”
The following settings in the server configuration file, MCPSHostServer.exe.config, determine the number of MCPSHostServers running:
maxActiveServers maxActiveClients maxMemoryUsage
When a job runs, the client, MCPSHostClient, checks if there is a server that does not already have the maximum number of jobs running (maxActiveClients), and is not in shutdown mode because of exceeding its maximum amount of memory (maxMemoryUsage). If there is a server that meets the criteria, the client uses that server to run the job.
If no server meets the criteria, the client checks whether the maximum number of
MSPSHostServer.exe instances (maxActiveServers) is already running. If it is not, the client starts a new server and submits the job to that server. If the maximum number of instances
(maxActiveServers) is already running, and all instances have the maximum number of jobs running (maxActiveClients), then the client holds the job until a server becomes available.
To resolve a PowerShell initialization issue, you can modify maxActiveServers, maxActiveClients, and maxMemoryUsage. For example, by raising the values of maxMemoryUsage and
maxActiveClients, you are allowing many clients to run on a single server. In that case, you can
decrease the value of maxActiveServers. For more information about these settings, see Section 2.7, “Changing PowerShell Configuration Settings,” on page 23.
2.10
Discovering SharePoint Resources
Use the Discovery_SharePoint Knowledge Script to discover configuration and resource information for SharePoint Servers. The Discovery_SharePoint script also tracks, displays, and provides various alerts about SharePoint services.
If you are running Microsoft SharePoint Server on multiple servers as part of your SharePoint server farm, run Discovery_SharePoint on each server in the farm. Each server from the farm is displayed individually, not as a group, in the Control Center Navigation pane and the Operator Console TreeView.
To ensure the functionality of the SiteUsage and WebPagePerf Knowledge Scripts, enable SharePoint logging so that log files are created. For more information, see Section 2.5.2, “Enabling Usage Logging,” on page 17.
By default, this script runs once for each computer.
NOTE: Run this script on a scheduled basis to discover new SharePoint resources, such as Web
applications.
Set the Values tab parameters as needed.
2.11
Deploying the Module with Control Center
You can use Control Center to deploy the module on a remote computer where an agent is installed. This topic briefly describes the steps involved in deploying a module and provides instructions for checking in the module installation package. For more information, see the Control Center User Guide
for AppManager, which is available on the AppManager Documentation page.
2.11.1
Deployment Overview
This section describes the tasks required to deploy the module on an agent computer.
To deploy the module on an agent computer: 1 Verify the default deployment credentials.
Description How to Set It
Raise event when the discovery succeeds?
Select Yes to raise an event if this script successfully discovers SharePoint resources. The default is unselected.
Event severity when the discovery succeeds
Set the event severity level, from 1 to 40, to reflect the importance when this script successfully discovers SharePoint resources. The default is 25. Raise event when the discovery
fails?
Select Yes to raise an event in which this script does not successfully discover SharePoint resources. The default is Yes.
Event severity when the discovery fails
Set the event severity level, from 1 to 40, to reflect the importance when the script fails to discover SharePoint resources. The default is 5.
Raise event when the discovery partially succeeds?
Select Yes to raise an event in which this script only partially discovers SharePoint resources. The default is Yes.
Event severity when the discovery partially succeeds
Set the event severity level, from 1 to 40, to reflect the importance when the script only partially discovers SharePoint resources. The default is 10.
2 Check in an installation package. For more information, see Section 2.11.2, “Checking In the Installation Package,” on page 29.
3 Configure an e-mail address to receive notification of a deployment.
4 Create a deployment rule or modify an out-of-the-box deployment rule.
5 Approve the deployment task.
6 View the results.
2.11.2
Checking In the Installation Package
You must check in the installation package, AM70-SharePoint-7.x.x.0.xml, before you can deploy the module on an agent computer.
To check in a module installation package:
1 Log on to Control Center using an account that is a member of a user group with deployment permissions.
2 Navigate to the Deployment tab (for AppManager 8.x) or Administration tab (for AppManager 7.x).
3 In the Deployment folder, select Packages.
4 On the Tasks pane, click Check in Deployment Packages (for AppManager 8.x) or Check in
Packages (for AppManager 7.x).
5 Navigate to the folder where you saved AM70-SharePoint-7.x.x.0.xml and select the file.
6 Click Open. The Deployment Package Check in Status window displays the status of the package check in.
3
3SharePoint Knowledge Scripts
AppManager for Microsoft SharePoint Server provides the following Knowledge Scripts for
monitoring Microsoft SharePoint resources. From the Knowledge Script view of Control Center, you can access more information about any NetIQ-supported Knowledge Script by selecting it and clicking Help. In the Operator Console, click any Knowledge Script in the Knowledge Script pane and press F1.
Knowledge Script What It Does
BytesTransfer Monitors the total number of bytes transferred per second to and from a Web application.
ConnectionsInterval Monitors the number of Web application connections.
ContentDatabaseAccessibility Monitors the accessibility of SharePoint content databases for the Web applications running on the SharePoint server.
ContentManagementEventLog Monitors the event log for Content Management error events generated by SharePoint.
DBSiteCount Monitors the number of site collections on each SharePoint content database in the server farm.
DBSpaceUtil Monitors the amount of space used by the SharePoint content database.
ExtendedWebApplications Monitors the extended Web applications in the SharePoint server farm.
FASTSearchServerStatus Monitors the status of the SharePoint FAST Search Server, including availability of the server, the number of queries per minute, and the number of searches per second. (SharePoint Server 2010 only.)
GenericEventLog Monitors the event log for generic error events generated by SharePoint.
HealthAnalyzer Monitors the SharePoint Health Analyzer tool, which allows you to schedule automatic checks for configuration, performance, and usage problems in the SharePoint server farm. (SharePoint Server 2010 and later.)
HealthCheck Monitors the operational status of active SharePoint services and Web applications.
InfoPathEventLog Monitors the event log for InfoPath Forms error events generated by SharePoint.
IsolatedApps Monitors isolated applications in a SharePoint 2007 environment. (SharePoint Server 2007 and IIS 6.0 only.)
3.1
BytesTransfer
Use this Knowledge Script to monitor the total number of bytes transferred per second to and from a Web application. This script raises an event if the total number of transferred bytes exceeds the threshold you set.
3.1.1
Resource Objects
SharePoint Server: Web Applications
3.1.2
Default Schedule
The default interval for this script is every 30 minutes.
RecycleBinInfo Monitors the Recycle Bin usage for all Web applications running on the SharePoint server.
Report_ServerUptime Generates a report about the number of hours the SharePoint server has been operational since the last reboot.
Report_SiteInfo Generates a report about the space utilization and date information for each Web application on the SharePoint server.
Report_SiteUsage Generates a report that contains usage information about each Web application on the SharePoint server.
Report_WebPartInfo Generates a report about the status and availability of Web Parts used by the SharePoint server.
SearchStatus Monitors the Search service and crawl status in the SharePoint server farm.
ServerUptime Monitors the number of hours the SharePoint server has been operational since the last reboot.
SiteCollectionUserCount Monitors the number of users in a site collection.
SiteEventLog Monitors the event log for events on the Web application usage.
SiteInfo Monitors space utilization and date information for each Web
application on the SharePoint server.
SiteUsage Monitors usage information about each Web application on the
SharePoint server.
VisualModeSiteCount Monitors the Visual Mode Site count for each Web application, site collection, and sub-site on a SharePoint server. (SharePoint Server 2010 and later.)
WebApplicationUptime Monitors the uptime of Web applications on the SharePoint server.
WebPagePerf Monitors the availability and performance of a Web application’s Web pages on the SharePoint server.
WebPartInfo Monitors the status and availability of Web Parts used by the SharePoint server.
3.1.3
Setting Parameter Values
Set the following parameters as needed:
3.2
ConnectionsInterval
Use this Knowledge Script to monitor the number of Web application connections and the total connections for all Web applications from anonymous and user (non-anonymous) accounts during the monitoring interval. This script raises an event if the number of connections exceeds the threshold you set.
NOTE: If anonymous access is not enabled for the Web applications in the SharePoint site collection,
this script raises events only for maximum connections to Web applications from user (non-anonymous) accounts that exceed the threshold.
3.2.1
Resource Objects
SharePoint Server: Web Applications
3.2.2
Default Schedule
Description How to Set It General Settings
Job failure event notification
Event severity when job fails Set the event severity level, from 1 to 40, to indicate the importance of an event in which the job fails to monitor the transferred bytes. The default is 5.
Monitor Byte Transfer Event Notification
Raise event if number of bytes transferred per second exceeds a threshold?
Select Yes to raise an event if the number of bytes transferred per second exceeds the threshold you specify. The default is Yes.
Event severity when the number of bytes transferred exceeds the threshold
Set the event severity level, from 1 to 40, to indicate the importance of an event in which the number of bytes sent or received exceeds the threshold you set. The default is 10.
Threshold -- Maximum bytes received per second
Specify the maximum number of bytes the server can receive before an event is raised. The default is 64000 bytes per second.
Threshold -- Maximum bytes sent per second
Specify the maximum number of bytes the server can send before an event is raised. The default is 64000 bytes per second.
Data Collection
Collect data for current transfer rate (bytes sent, bytes received)?
Select Yes to collect byte transfer data for charts and reports. If enabled, data collection returns byte transfer rate (sent and received) data for the server. The default is unselected.
