“It’s not my fault, SharePoint did it!”

“I didn’t realize I was deleting a site!

….did you press OK on the pop-up confirmation?”

“Well, it’s working on my machine. I don’t know why you can’t do it on your box.”

Who hasn’t heard these excuses? At least SharePoint is recording all these events…

For the people managing SharePoint, the audit reports contain some of the most important information regarding what actions users are taking on the farm. Some of the most common auditable actions include deletions, content viewing, and permission changes. These pieces of data are key for organizations that are using SharePoint strategically and need to determine if users are in compliance with their governance plan.

My guess is 10% of SharePoint administrators use this function. I speak with IT departments across all industries who they are all dealing with similar pains in SharePoint. Whether I’m talking to a university, public company, or government agency, everyone has the same issues around permission changes, creation and deletion of content, and who is doing what on their farm. This knowledge is integral in making sure your governance plan is being followed. And if it’s not, you can quickly discover who violated your policies and take corrective action.

One of the biggest uses for the audit reports is to manage user access changes. You can track when user permissions have changed, users are added or removed from groups, and when inheritance has been broken or restored. To be honest, administrators love these reports so they can play the “blame game.” Fixing the actual problem that occurred is just an added bonus. Other common use cases for the audit logs are reports on views, updates, check-ins, check-outs, deletes, moves, and copies of SharePoint objects. I’m sure you can imagine a time when viewing these events would have proved extremely beneficial. For example, if your governance plan prohibits users from breaking inheritance at the site level, you can quickly find all the places people have broken inheritance all over your farm.

Although the audit reports contain very powerful data, they will consume a ton of space in your content database. You can enable auditing only at the site collection level and are therefore forced to collect about every subsite, list, and item inside that site collection. The dbo.AuditData table can grow at a rate of approximately 64 KB per page hit.  Assuming that you have 1,000 hits to a page in a day, the growth in size would be 1,000 * 64 KB = 62.5 MB/day. This means that even if you do not
add any content to the site, the content database will still grow by over 1.8 GB per month. Pretty scary statistics- don’t tell your DBA that you’ve enabled auditing! Of course, STSADM or PowerShell can save you and will let you trim your audit table based on the date of the audit record. See
http://technet.microsoft.com/en-us/library/cc825328.aspx#TrimData
for the command.

I hope you realize how powerful these reports can be and what they can be used for in the day-to-day upkeep of your environment. Most of all, these will give you the most specific data to make sure your end users are following the governance plan you’ve put in place.