SharePoint Reporting – What’s Up?

Joel and I had a lot of fun doing this video for TechEd Online about the state of SharePoint reporting.

 SharePoint Reporting—What’s Up? 

Key Points about SharePoint 2007 reporting.

If you want to roll your own reporting solution here are some things to keep in mind:

  • SharePoint parses the IIS logs and rolls up the information into its own logs. That information is then stored in the content database.

  • SharePoint won’t report anything unless A. IIS is logging and B. Usage analysis is enabled and has enough time to process the logs.

  • Search reporting must be enabled in the SSP settings.

  • It’s best not to touch the SharePoint databases directly. Modification is a huge no-no and will result in loss of support.

  • It may be OK to read from the database in certain situations. Performing one time queries during off hours should be OK. Building a reporting solution that rolls information into a separate warehouse may also be OK to if done right; however, keep in mind that queries can affect your availability, performance, and the underlying schema may change at any time without warning. MSFT in no way supports direct database reads or writes. If you are not a SQL guru who can design lightweight queries stay out of the database!

  • The content database contains some accessible information on storage, bandwidth, and discussion usage and some info on hits and visits.

  • The content database also contains some rich information on each web, but this information is stored in binary form and there’s no information available on how to read it. The best way to access that information is through the published APIs. Check out the SDK for more information.

  • Farm admins will find the data available through the OM very useful, but keep in mind that enumerating this information on a per site basis across a large farm will take a long time and may impact performance if done poorly.

  • You can parse the IIS logs directly if needed. Log parser 2.2 rocks!

  • It’s not always easy to determine what users are doing from the IIS logs. Many operations are not logged in a meaningful way.

In summary, SharePoint 2007 out of the box reporting is big improvement over 2003. Portal and farm administrators may want more info and should look into third party solutions or rolling their own solution; however, when rolling your own be sure to do in a supportable way that doesn’t impact farm performance.

Comments (7)

  1. Joel and I had a lot of fun doing this video for TechEd Online about the state of SharePoint reporting

  2. decatec says:

    For a customer we do extract periodically data from the Sharepoint DB’s with SSIS (a la datawarehousing)into a custom DB on which we do run queries and Reporting Services.

  3. to the point !

    we couldn’t have described it better ourselves 🙂

    That’s why we created CardioLog, it designed exactly in order to mitigate the issues mentioned in this article.




  4. John says:

    Our company are running the Sharepoint 2007 and as we have nested sub-sites for each department. From the out of the box reporting, it seems the data are count on each publishing site and there’s no way to include all sub-sites.

    Are there any solution or a 3rd party is required for recursive sites reporting?

    Thanks a lot.


  5. MAPILab provides a very good SharePoint usage reporting solution: MAPILab Statistics for SharePoint. Detailed reports on visitors, documents, lists, search and more. You can try free trial version or online demo:

  6. Alexander says:

    One another sharepoint analytics tool – HarePoint Analytics for SharePoint (…/Default.aspx )

Skip to main content