SharePoint 2013: Auditing discrepancies while using blob cache

  • Article

SharePoint audit reports may not accurately report the number of time a file is accessed if the file type is added to blob cache. For example, on a web application with blob cache enabled for mp4 files, if we try to access an mp4 file hosted on a document library multiple times and then generate an audit report, the hits are reported incorrectly. This is because the file being accessed from disk based blob cache from the IIS server instead of the SharePoint database. Similar behavior could be seen for other file types such as PDF, JPEG.

Cause of Problem

This is expected behavior in SharePoint 2013. When we use blog caching, the first time we access the file, the entry will be recorded in the audit table. Subsequent hits will not be recorded if the file is being read off the blob cache. If we happen to hit another WFE, that entry will be recorded for the first time too.

Solution for this Issue

A workaround to make sure we have accurate access audit for opening / viewing is to disable blob caching (off by default). If we need to ensure that audit is accurate for a specific file type, we can exclude that specific file type from blob cache settings. When removing media file types which can be very big in size, we need to understand that performance might be affected and at this moment, this is a tradeoff for audit accuracy.

Other potential workarounds:

  1. Video Portal / O365 Video / Azure Media Services has tenant wide auditing feature that does capture file access events from the Blog cache and with auditing directly from the video portal. But this is for SharePoint Online and not for On-Prem implementations.
  2. Another way of getting a similar report is to collect IIS logs from all the WFEs and run tools like logparser to extract the access information.
  3. Some third party tools may offer alternatives to SharePoint audit.

References

Post by : Bhanu Pratap Chagam [MSFT]