SharePoint did it!

“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 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.

Brain Dump: Software Projects, Products, and Sales

For my debut post, I wanted to write about my reasons for starting a blog. I wondered if anyone would even want to read my opinions on life, technology, and other random blog-worthy topics. Then I realized that my 9 to 5 job is listening to people’s problems and helping solve them.

I guess that’s the definition of a consultant. And for the first 3 years of my professional life, I was affectionately known as a consultant. I would describe myself as a keyboard jockey (thanks Chuck Chen:, writing code all day. I know, sounds fun and sexy. At the beginning of the year I transitioned to a sales engineering role at a product based company.

Don’t worry, I have a point in this post.  The lesson I want to share is why the last project I was on before I left the consulting firm was marginally successful and what I’ve learned about the world of software since leaving.

We were late delivering our solution to the client. We put more developers and outside consultants on the team. We slowly realized that adding manpower to a late software project just makes it later. Our issues could have been solved before my consulting firm even stepped foot on the client site.  We did not fully understand their requirements. Moreover, we were building the requirements around a platform that did not meet their needs. We were migrating content out of HyperCard and into a custom built SharePoint solution. We thought we understood what the needs of the client were but we found ourselves repeatedly saying “SharePoint cannot do that.”  We spent months gathering requirements so that wasn’t our problem. We simply did not understand how to use SharePoint!

As a developer, I was shielded from the business requirements. It wasn’t until I became a sales engineer and started talking to end users that I even realized how SharePoint is used by businesses. My work became less about web services, event handlers, and JavaScript and more about controlling user access, capacity planning, and audit control in SharePoint. Now that I’ve moved into the technical sales world, I have a stronger understanding of what people actually use SharePoint for. Software is built to make life easier (thank you captain obvious). So where do I fit in? I prevent a common recurring problem: a solution that sounds good to a circle of software engineers but serves no purpose to the end users.