Partilhar via


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. https://msdn.microsoft.com/en-us/library/ms441339.aspx
  • 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! https://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en
  • 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

  • Anonymous
    June 23, 2008
    Joel and I had a lot of fun doing this video for TechEd Online about the state of SharePoint reporting

  • Anonymous
    June 24, 2008
    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.

  • Anonymous
    June 24, 2008
    Don't forget AvePoint: http://www.avepoint.com/products/sharepoint-administration/sharepoint-administrator

  • Anonymous
    July 18, 2008
    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. Thanks, Uri, Intlock.

  • Anonymous
    August 26, 2008
    The comment has been removed

  • Anonymous
    August 04, 2009
    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:  http://www.mapilab.com/sharepoint/statistics/

  • Anonymous
    January 25, 2012
    One another sharepoint analytics tool - HarePoint Analytics for SharePoint ( www.harepoint.com/.../Default.aspx )