Microsoft SharePoint 2010 Administration: Monitoring and Reporting

Exclusive offer: get 50% off this eBook here
Microsoft SharePoint 2010 Administration Cookbook

Microsoft SharePoint 2010 Administration Cookbook — Save 50%

Over 90 simple but incredibly effective recipes to administer your Microsoft SharePoint 2010 applications with this book and eBook

$26.99    $13.50
by Peter Serzo | January 2011 | Cookbooks Enterprise Articles Microsoft

This article on Monitoring and Reporting covers recipes involving the different tools in SharePoint 2010 that assist the administrator in managing SharePoint. These tools are critical to knowing how the SharePoint 2010 installation operates. The recipes show how to manage the tools.

In this article by Peter Serzo, author of Microsoft SharePoint 2010 Administration Cookbook, we will cover:

  • Accessing the SharePoint 2010 logging database
  • Configuring what gets logged
  • Editing rule definitions in the health analyzer
  • Viewing web analytics reports
  • Troubleshooting with correlation IDs
  • Enabling the Developer Dashboard

 

Microsoft SharePoint 2010 Administration Cookbook

Microsoft SharePoint 2010 Administration Cookbook

Over 90 simple but incredibly effective recipes to administer your SharePoint applications

  • Solutions to the most common problems encountered while administering SharePoint in book and eBook formats
  • Upgrade, configure, secure, and back up your SharePoint applications with ease
  • Packed with many recipes for improving collaboration and content management with SharePoint
  • Part of Packt's Cookbook series: Each recipe is a carefully organized sequence of instructions to complete the task as efficiently as possible
        Read more about this book      

(For more resources on MicroSoft SharePoint, see here.)

Introduction

SharePoint 2010 has been architected to be a proactive system that provides many tools to the administrators. The goal is to catch issues before they occur. If they do occur, the system should give the administrator the capability to debug the issues with the least amount of resistance.

One example of this is the new logging database. It collects information from disparate servers and collates this information into the database. For instance, the Unified Logging Service (ULS) logs collect information that is useful in troubleshooting issues. These logs are found on every SharePoint Server. These ULS logs are collected from all servers and the event logs. This makes the logging database a valuable tool. It is must-have knowledge for SharePoint administrators and covered in one of the recipes.

Reporting is another area where SharePoint 2010 has been given focus. Reports are more robust and present better information down at the site level. This gives administrators a better idea about how their site is being utilized, what they are searching for, and uncovers where functionality is lacking.

When it comes to monitoring and being proactive, SharePoint offers another level of service — self-correcting health monitoring. SharePoint 2010 health monitoring jobs have the ability to uncover issues, report them, and then SharePoint is able to automatically correct the issue (in some cases).

Finally, SharePoint 2010 delivers a tool that can give details on the performance of a page. Currently, we have to use a tool such as Microsoft Visual Round Trip Analyzer. This is now an innate built-in capability of the infrastructure. The last recipe in this chapter shows how to use this tool.

The monitoring and reporting capabilities combined together empower the administrator to be proactive with regards to the health of the SharePoint farm. These capabilities can be leveraged with other SharePoint functions such as alerts, so that the team managing the SharePoint farm should be well versed in the performance of the installation.

Accessing the SharePoint 2010 logging database

As mentioned in the introduction, the SharePoint 2010 logging database is a major enhancement to monitoring, debugging, and protecting the health of the farm.

By default, the database is called WSS_Logging . This database should be the starting point for administrators to collect and analyze information.

In this recipe, we will access the database and run a view (that already is installed) against it.

Getting ready

You must have farm-level administrative permissions to the Central Administration site. You must have read and execute permissions as well to the WSS_Logging database in order to open and execute views.

How to do it...

  1. Open up SQL Server Management Studio.
  2. When asked for authentication, log in to the correct instance where SharePoint is running using your windows authentication credentials. If SQL authentication is the preferred method of connecting, use the appropriate User ID/Password.
  3. Navigate to the WSS_Logging database and click on the plus sign to expand it.
  4. Under the toolbar at the top, click on the New Query button.
  5. In the new query window, type in the following query: Select * from RequestUsage.
  6. Click Execute. Results are populated in the window pane below the query, as seen in the following screenshot:

How it works...

In the above recipe a view called RequestUsage was executed. This is an out of the box view that provides site usage information. It provides information such as the referring URL, the browser being used, the site ID, the web ID, the server URL, the request type, and when it was done.

The logging database contains, but is not limited to, the following information:

SharePoint 2010 Monitoring and Reporting

It is a place where information is aggregated from across the farm. For instance, all ULS logs, from every SharePoint server, are collected within this database.

There are 26 views installed by default. However, the purpose of this database is to give administrators and developers a place to log information based on processes. These are typically custom processes. Views can be created to meet an organization's needs.

There's more...

The location of the logging database is not a setting that can be done through the user interface in Central Administration. Because of all the data that is collected in this database, it can grow quite large. Additionally, as SharePoint-integrated applications are created, developers can utilize this database to communicate issues.

Therefore, due to size and usage, it is a wise idea to move the database to another physical location such as a dedicated disk. This can be done only via PowerShell, using the following command:

Set-SPUsageApplication -DatabaseServer <DB Server Name> -DatabaseName
<DB Name> [-DatabaseUsername <User Name>] [-DatabasePassword <Password>]

More info

The ULS logs are present on every WFE. It is important for an Administrator to know where to find these logs manually. They are located at the following location: \Common Files\Microsoft Shared\Web Server Extensions\14\Logs.

Configuring what gets logged

The SharePoint 2010 logging database covered in the previous recipe captures information that can be modified via the Central Administration interface. The advantage of this being that the collection of information can be voluminous, which can also be the disadvantage.

Disk space, I/O, and just the amount of data needed to retain this information can become an issue. Being able to reduce the type of information that gets captured is critical to the wellness of your farm.

In this recipe, we will cover how to change what gets captured and put into the logging database.

Getting ready

You must have farm-level administrative permissions to the Central Administration site.

How to do it...

  1. Open the SharePoint 2010 Central Administration website.
  2. Click Monitoring.
  3. Under the Reporting section, click Configure usage and health data collection.
  4. The following form appears for configuration:

    Fill in the following details:

    • Usage Data Collection: This is enabled by default.
    • Event Selection: These are specific events that are being logged. Use the check box to enable or disable them.
    • Usage data collection settings: In this section, the location of the ULS logs are set. Also, there is a setting to limit the size of the log file.
    • Health data collection: This is enabled by default.
    • Log Collection Schedule: Administrator has the ability to change the schedule.
  5. Modify the settings in step 4 and click OK.

How it works...

The options presented in the usage and health data collection are logged to the logging database and to the ULS logs.

The health logging schedule can be modified to fit the needs (also known as Service Level Agreements) of your organization. It is important to remember that there is a hidden cost associated with the increased logging. The hidden cost is mainly in the form of storage and possibly performance.

The ULS logs have the potential to grow large. The logs can be moved to a new physical location (physical spindle), which does not contain the operating system or WFE/Application server software. The physical location reference must exist on all servers in the farm.

The location of the logs is set within Central Administration. To access the setting, go to Central Administration, click Monitoring, and then select Configure diagnostic logging. Under the Trace Log section is the Path. This contains the location of the ULS logs.

There's more...

The logging information is retained for a period of 14 days by default. Using PowerShell you can change this parameter, using the following command:

Set-SPUsageDefinition -Identity <GUID> [-Enable] -DaysRetained 14

Microsoft SharePoint 2010 Administration Cookbook Over 90 simple but incredibly effective recipes to administer your Microsoft SharePoint 2010 applications with this book and eBook
Published: January 2011
eBook Price: $26.99
Book Price: $44.99
See more
Select your format and quantity:
        Read more about this book      

(For more resources on MicroSoft SharePoint, see here.)

Editing rule definitions in the health analyzer

SharePoint 2010 has a built-in health analyzer that acts as a best practice analyzer. The health analyzer will report whether or not the farm is compliant with each predefined health rule. The health analyzer builds upon the best practice analyzer from Microsoft Office SharePoint Server 2007.

There are roughly 65 rules that are categorized as follows:

  • Security
  • Performance
  • Configuration
  • Availability

Each rule is run by a timer job, and each rule has a specific purpose such as checking application pool memory, checking how security is configured on the farm, or checking drive space.

In Central Administration, it is possible to edit existing rules in order to meet the needs of your organization. Changes can be made to the scheduled execution of the job. On the ribbon, there is an option named Run Now that will execute the rule immediately. The rules are available out of the box and are meant to allow you to be proactive.

In this recipe, we will modify one of the existing health analyzer rules.

Getting ready

You must have farm-level administrative permissions to the Central Administration site.

How to do it...

  1. Open the SharePoint 2010 Central Administration website.
  2. Click Monitoring.
  3. Under the Health Analyzer section, click Review rule definitions.
  4. Under the category Security, click The server farm account should not be used for other services.

    SharePoint 2010 Monitoring and Reporting

  5. A form pops up, which contains the parameter of the rule. The left-most ribbon button is Edit Item; click the button. The following screenshot appears:

    SharePoint 2010 Monitoring and Reporting

  6. Change the Schedule to Daily, from the default value of Weekly.
  7. You must also manually change the value of the parameter Version. Change it to 2.0, from present 1.0.
  8. Click Save.

How it works...

The health analyzer rule definitions are run via the timer jobs. There are several parameters that the administrator can modify:

  • Title: This is the text description of the rule.
  • Scope: This is where the rule will run.
  • Schedule: This is how often the rules are employed.
  • Enabled: This designates the rule as active.
  • Repair Automatically: When the timer job kicks off, it will check the rules. If the rule can be checked and then corrected via SharePoint best practices, it will be.
  • Version: This is a manually edited text box that tracks versioning of the rules.

The page also notes who created the rule, and when the rule was last edited and by who.

There's more...

In addition to being able to edit the rule, there are several other parameters as shown by the following screenshot:

SharePoint 2010 Monitoring and Reporting

  • Version History: Shows all the versions
  • Alert Me: This notifies you when changes are made
  • Run Now: This executes the rule

More info—adding a new health rule

Every rule that a farm installation may need cannot be covered by the out of the box health rules. For instance, consider monitoring the number of tenants in the user profile social database. There may be a need for a governance rule that monitors this and flags the administrator when certain levels are reached; however, there is no out of the box rule available today that can help govern this.

In order to implement a new health rule, code must be written to utilize the Microsoft.SharePoint.Administration.Health namespace . Once the assembly is written, it must be placed in the Global Assembly Cache (GAC) on every machine. The new health rule must then be registered with the SharePoint Health Analyzer. The best way to do this is to create a SharePoint feature that can be activated and deactivated.

Viewing web analytics reports

Web analytics reports are an innate part of the SharePoint 2010 installation. These reports are prebuilt. They use collected data from the active SharePoint installation to present information such as number of site collections, top destinations, top pages, page views, and top referrers. Using this information, an administrator can determine the flow of traffic. This is information that will comprise part of the story for performance monitoring.

This recipe shows how to invoke the reports and how to view custom reports.

In this recipe, we will modify one of the existing health analyzer rules.

Getting ready

You must have farm-level administrative permissions to the Central Administration site.

How to do it...

  1. Open up the SharePoint 2010 Central Administration website.
  2. Click Monitoring.
  3. Under the Reporting section, click View Web Analytics reports.
  4. Choose a web application by clicking on it.
  5. The page that is presented contains a left-hand navigation, as shown here:

    SharePoint 2010 Monitoring and Reporting

    Click any of the above options and you will be presented with the appropriate report. When the report is presented, it is shown as a graph at the top and a grid at the bottom.

How it works...

The reporting data is collected by the usage data per web application, per site collection, per site, and finally, per search service application. The web analytics timer job runs as per its schedule and updates the collected information. This recipe showed how to access the reports through Central Administration. They can also be accessed through the site collection and sites via the Site Actions drop-down list.

Web analytics is now part of the services infrastructure. It is called the Web Analytics Service Application. This must be provisioned and configured similar to setting up the other services.

The following diagram shows the infrastructure components of the Web Analytics Service Application:

SharePoint 2010 Monitoring and Reporting

The information is collected on the web front-end (WFE) servers into .usage files. Timer jobs kick off a process that pulls the information into a staging database, where information is kept for 24 hours. Information is then aggregated into the reporting database, where it is retained for a period of 25 months by default.

There's more...

The data shown with date ranges can be modified. This can be achieved by clicking on the Change Settings link above the graph:

SharePoint 2010 Monitoring and Reporting

The following ribbon appears:

SharePoint 2010 Monitoring and Reporting

With a click of the appropriate date button, the data will be filtered. Depending on the report, there may be filters other than date.

Finally, the report can also be customized or exported to Excel. This can be done with the help of the two buttons on the right-most side of the preceding screenshot.

More info

Customized reports are also possible. There is an Administrative Report Library in Central Administration. There are folders in that library that contain reports written by someone in the organization. These reports may be particular to an organization's needs or audit concerns, among other things.

There is a Customized Reports link on the left-hand navigation shown in a preceding screenshot; currently, there is only Search Administration Reports in there.

Microsoft SharePoint 2010 Administration Cookbook Over 90 simple but incredibly effective recipes to administer your Microsoft SharePoint 2010 applications with this book and eBook
Published: January 2011
eBook Price: $26.99
Book Price: $44.99
See more
Select your format and quantity:
        Read more about this book      

(For more resources on MicroSoft SharePoint, see here.)

Troubleshooting with correlation IDs

An undesirable thing for users of SharePoint is getting an indefinite message that has a big red "X" and the word "Error" in bold adjacent to it. The user has done something but the page does not tell what the error is and how to fi x this error. It only points them to the site administrator, that is, you.

SharePoint 2010 has addressed this issue by creating a mechanism to track communications between the web front-ends and the user's requests. This is in the form of a GUID called the correlation ID. Now when a user gets his/her error page, he/she can contact the administrator and provide the correlation ID. The administrator can then track the cause of this error using the correlation ID as a reference in the ULS logs.

This recipe shows the steps to perform after the correlation ID is provided to the administrator. To induce the error with a correlation ID, we will stop the web analytics service.

Getting ready

You must have farm-level administrative permissions to the Central Administration site.

This recipe uses PowerShell. You must be a member of the SharePoint_Shell_Access database role on the configuration database. You also must be a member of the WSS_ADMIN_WPG local group .

How to do it...

  1. In Central Administration, navigate to System Settings. Under Servers, click Manage services on server.
  2. Click Stop associated with Web Analytics Web Service.
  3. Click Monitoring on the left-hand side navigation.
  4. Under Reporting, click View Web Analytics reports. The following error should be shown:

    SharePoint 2010 Monitoring and Reporting

  5. On the publishing farm server, select Start | All Programs | Microsoft SharePoint 2010 Products | SharePoint 2010 Management Shell.
  6. In the PowerShell command prompt, type in the following command, replacing the correlation ID with the one from your screen.

    Get-SPLogEvent | ?{$_.Correlation -eq
    "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}

    It should produce a message from the log fi le that reads:

    There are no instances of the Web Analytics Service Application
    started on any server in this farm. Ensure that at least one
    instance is started on an application server in the farm using
    the Services on Server page in Central Administration.

How it works...

The PowerShell command, Get-SPLogEvent, does the job of retrieving all events in the log files. The | character sends the output of Get-SPLogEvent to the next command. The ? is the "where" command. The curly braces is the "where" condition. The $_ notation is used to represent the object being sent across the pipeline. Finally, the -eq option represents the "equal to" condition.

As a whole, this statement does a search job in the log files for a particular correlation ID, and produces the information associated with the request.

A request is traced through its lifetime. The correlation ID collects information across multiple servers maintaining the integrity of the request. Different sites can consume information from an application server that resides in a different farm but is shared. Without the correlation ID, it would be very difficult and cumbersome to trace an error.

When an error occurs, the correlation ID will have the same reference across all of the servers. This applies to WFE, application, web services, and any other components that are consumed.

There's more...

There are two other methods for looking up a correlation ID other than PowerShell. They are:

  • Using Excel (or notepad): Log on to the Web Front End server that generated the error and navigate to the location of the ULS logs. Open the log file in Excel and utilize the find and innate filtering capabilities of Excel to find the correlation ID.
  • Utilizing the logging database: You can execute the Accessing the SharePoint 2010 logging database recipe and then look for the correlation ID.

More info

On Microsoft's site, there is a free ULS viewer that can be utilized. This is not supported by Microsoft. It allows users to open a ULS log file and display its contents in a readable manner. It contains filtering, sorting, and many other functions that make the data readable. The ULS viewer can be found here: http://code.msdn.microsoft.com/ulsviewer.

Enabling the Developer Dashboard

The Developer Dashboard is not just for developers who write code. It is an important tool in the arsenal of the SharePoint Administrator.

Tools such as Microsoft's Visual Round Trip Analyzer are used to determine why a page is performing poorly. The downside of tools such as this is that they interrogate the page from the outside and so information such as database queries cannot be seen. We would have to use another tool such as SQL Profiler to see this information.

The Developer Dashboard brings this functionality natively to SharePoint 2010. It provides information, such as how a page is built, how it is performing, what database queries are being run and for how long, at the bottom of a page in report form. Administrators can use this information to pinpoint what is happening on a page.

In this recipe, we will enable the Developer Dashboard and view the report at the bottom of the page. This is done through PowerShell and can be scripted in the SharePoint environment.

Getting ready

In order to run PowerShell commands, you must be a member of the SharePoint_Shell_Access database role on the configuration database. You also must be a member of the WSS_ADMIN_WPG local group .

How to do it...

  1. On the publishing farm server, select Start | All Programs | Microsoft SharePoint 2010 Products | SharePoint 2010 Management Shell.
  2. In the PowerShell command prompt, type in the following command:

    $db = [Microsoft.SharePoint.Administration.
    SPWebService]::ContentService.DeveloperDashboardSettings;
    $db.DisplayLevel = 'On'; $db.RequiredPermissions ='EmptyMask';
    $db.TraceEnabled = $true; $db.Update()

  3. Open a team site. You should see a screenshot similar to the following at the bottom of the page:

How it works...

The Developer Dashboard is a farm-wide setting. When you turn it on, the dashboard appears on page load at the bottom of the page.

The first line creates a reference to the necessary web service.

The RequiredPermissions parameter specifies who can see the Developer Dashboard.

Setting the trace level to true creates a new link called Show or hide additional tracing information... at the bottom of the Developer Dashboard.

There's more...

By default the Developer Dashboard is disabled.

There are three modes that can be set:

  • On
  • Off
  • OnDemand

When the OnDemand mode is specified, a button appears in the upper right-hand corner of the page as shown here:

SharePoint 2010 Monitoring and Reporting

When clicked, the Developer Dashboard is shown, and when clicked again, it disappears.

This gives administrators the flexibility of enabling the Developer Dashboard without the need to make it visible always.

More info

The Developer Dashboard is available only with Windows authentication and is not available with SQL authentication.

Summary

In this article we covered:

  • Accessing the SharePoint 2010 logging database
  • Configuring what gets logged
  • Editing rule definitions in the health analyzer
  • Viewing web analytics reports
  • Troubleshooting with correlation IDs
  • Enabling the Developer Dashboard

Further resources on this subject:


About the Author :


Peter Serzo

Peter Serzo is an English major from Kent State who started his technical career with EDS out of college. 20 years later, all as a consultant, he is a national speaker regarding to SharePoint having worked at organizations of all sizes. His next challenge is to bring SharePoint to children and teach them. He has been working with SharePoint since 2003 in companies such as Microsoft, Ford, ADP, and many others throughout the United States. He is a Senior SharePoint Architect for High Monkey Consulting. The name refers to an old Jamaican proverb that means the higher up you go, the more responsible you must be; High Monkey takes pride in its accountability and excellence of work in regards to its clients' needs.

Books From Packt


Microsoft SharePoint 2010 Business Performance Enhancement
Microsoft SharePoint 2010 Business Performance Enhancement

Microsoft Silverlight 4 and SharePoint 2010 Integration
Microsoft Silverlight 4 and SharePoint 2010 Integration

Microsoft Windows Workflow Foundation 4.0 Cookbook
Microsoft Windows Workflow Foundation 4.0 Cookbook

Software Testing using Visual Studio 2010
Software Testing using Visual Studio 2010

Getting Started with Microsoft Application Virtualization 4.6
Getting Started with Microsoft Application Virtualization 4.6

Microsoft SQL Server 2008 High Availability
Microsoft SQL Server 2008 High Availability

Microsoft SQL Azure Enterprise Application Development
Microsoft SQL Azure Enterprise Application Development

Microsoft Windows Communication Foundation 4.0 Cookbook for Developing SOA Applications
Microsoft Windows Communication Foundation 4.0 Cookbook for Developing SOA Applications


No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
k
f
Z
N
8
Q
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software