로그인
 
홈라이브러리학습다운로드지원커뮤니티포럼
Resources for IT Professionals >
> 
> 
Logs of

已答复 Logs of

  • 2012년 8월 9일 목요일 오후 6:24
     
     
    로그인하여 투표
    0

    Hi all!  I'm looking for help getting started on a project I've been tasked with.  We have a SharePoint 2010 dashboard that contains links to several reports and dashboards.  We would like to know who, when and how often a user accesses our reports and dashboards.  

    There are typically 3 ways a user can access a report/dashboard:

    1.        SharePoint Quick Launch links on the left of our site
    2.        Going to a SharePoint library and opening a PDF of a pre-run report
    3.        Accessing the PDF reports from a link in Outlook

    so there may be different ways to log the access for each method.  I know there are execution logs that live in the C:\Program Files\Microsoft Shared\Web Server Extensions\14\LOGS folder but I don't know if these give us the information on user access - they seem to be more diagnostic in nature.  I'm not an administrator so I don't currently have access to these logs (access has been requested but it might take a while).  

    It seems to me that this shouldn't be an unusual requirement - there are many highly regulated environments that I believe should require logging.  

    Thanks for any help you can give to get me moving in the right direction!

    Brad


     

모든 응답

  • 2012년 8월 9일 목요일 오후 6:45
     
     답변됨
    로그인하여 투표
    2

    The most accurate way to get this information would be by running queries against your IIS logs to see how many requests are sent for the URLs you want to track, which can be done using a tool such as LogParser (Todd Klindt has a good intro to using LogParser on his blog: http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=85).

    You may also be able to enable SharePoint's Auditing functionality to track this, but I haven't had much experience with it so I don't know if this will give you exactly what you want or not. Here's instructions on how to enable auditing for a site collection (http://office.microsoft.com/en-us/sharepoint-server-help/configure-audit-settings-for-a-site-collection-HA102031737.aspx) and how to view audit reports in SharePoint 2010 (http://office.microsoft.com/en-us/sharepoint-server-help/view-audit-log-reports-HA102039795.aspx)

    SharePoint 2010 also provide site collection usage reports, but I don't think that will give you the level of granularity that you're looking for in this case since its specific targets within a SharePoint site. Auditing may work for you, but I suspect that the IIS logs are going to be your best bet for targeting usage of those specific items.

    John

    MCITP and MCTS: SharePoint, Virtualization, Project Server 2007
    My books on Amazon: The SharePoint 2010 Disaster Recovery Guide and The SharePoint 2007 Disaster Recovery Guide.
    My blog: My Central Admin.

    • 답변으로 표시됨 Rock Wang– MSFT 2012년 8월 16일 목요일 오전 10:49
    •  
     
  • 2012년 8월 10일 금요일 오후 4:38
     
     
    로그인하여 투표
    0

    John - Thanks for the detailed response.  I've got the LogParser and LogParserLizard downloaded and ready to go.  But I don't have access to the logs but it's in process.  I'll let you know how it goes.  It seems that this would not be an unusual situation so it might help others.  

    Thanks again,

    Brad

     
  • 2012년 11월 19일 월요일 오후 7:11
     
     답변됨
    로그인하여 투표
    0

    The solution to this issue has become quite an adventure.  The good news is that as of SharePoint 2010, Microsoft has made it substantially easier to get logging data.  There is a new database called WSS_Logging that you can browse through SSMS.  So you no longer need the LogParser and LogParserLizard software to access the logs.    

    While the old IIS log files still exist, they are now loaded into this database by periodic jobs.  There are a lot of great tables and views available.  SharePoint rotates through 32 partition tables keeping one day's worth of data in each partition table.  However by default the WSS_Logging database keeps 14 days of detail before rolling off.  For example, the request usage data for 11/1/2012 is written to RequestUsage_Partition0 table, data for 11/2/2012 is written to RequestUsage_Partition1 and so on.  After 14 days, these are cleaned out.  You can adjust the settings to keep up to 32 days of data but beware of your table sizes.    

    WSS_Logging also contains views that concatenate all the partition tables together - this is the best way to go to gather all data in one place.  

    We focused on users usage patterns so we used tables and views called RequestUsage.  I was able to write SSIS packages against these views to extract usage patterns that will help us see how clients are using our dashboards.  Here are two links with great information to get you started:  

    http://technet.microsoft.com/en-us/library/hh769360.aspx

    http://www.codeproject.com/Articles/70865/SharePoint-2010-Logging-Database

    Of course there are a ton of different options to set through General Administration mostly related to what is logged.  Logging is enabled by default in 2010 so you should be able to pull the data relatively easily. 

    However, we ran into some messy problems.  When I began this project I developed against our UAT environment and had no problem pulling data.  However when I moved to production, only a small amount of data was available.  We have 3 web front end servers in the farm and only one was writing log data.  The environments were the same between UAT and PROD and on the 3 WFE servers.  I was able to diagnose this by looking at the MachineName field in the RequestUsage view and comparing it to the list of servers in our farm.  

    It took a ticket with Microsoft to find the issue.  We needed to add the Community app pool account into the "Performance Log Users" group on each server.  We're not sure how this got out of sync but we did have an upgrade in July that had some significant issues that might have caused it.  After we made that change, all the data has come through. 

    Some other things to consider.  Make sure the jobs that read the IIS logs and load them to WSS_Logging are not failing and that there is enough room in the logging database so that it doesn't fill up.  

    I hope this helps out someone who might face the same issue.  These logs contain a great amount of information on the back end functions of SharePoint that can be leveraged to make things run more smoothly. 

    • 답변으로 표시됨 Duckettb 2012년 11월 19일 월요일 오후 7:11
    •