Auditing with SharePoint 2007 is something that I’ve managed to avoid playing with until our current project. Frankly, this has mainly been because the user interface for audit details is inadequate out of the box. Most other systems, you just go to a page, and see what happened to that item.

Anyway now that I’ve started to take a look at it in more detail, I notice a few other minor problems with it…

No audit on SPWeb…

… or rather, there is an SPWeb.Audit.GetEntries() function, but it returns all the entries for the SPSite. Genius. So I can get audit info for an SPSite, SPList, or SPListItem – but not a web. Instead, try filtering it:

SPAuditEntry entry = ....
SPWeb web = ...
string filterpath = web.ServerRelativeUrl.Substring(1, web.ServerRelativeUrl.Length - 1);
if (entry.DocLocation.StartsWith(filterpath))
{
// Do whatever - this entry is for our SPWeb
}

Yes, with a lot of items, that’s pretty slow.

What Version was viewed?

You can audit Views of documents, pages, home pages, lists and list views, which is excellent. But with documents, there seems to be a problem. The ‘Version’ details in the audit log do no match the versions in the ‘Version History’ page. You can end up with it such that if you upload a new document version to SharePoint and then go an view it the audit shows that you’ve updated to Version 3.0, but just viewed version 0.4.

Doesn’t seem to match:

Viewing previous versions is not Audited.

Not really a lot more to say really. Makes it a bit hard to see who has seen what. At least with this you could write an HTTPModule and write your own entries into the audit log.

Weird viewing ‘version 0.-1’ entries

I’ve no idea what these really mean, or are about. If you know, please comment below – it’d be a help.

Some changes not obvious on Audit

• Restoring a version just appears as an update in the Audit log.
• Creating a new document just appears as an updated in the Audit log.

Size

The audit logs populate a database table called AuditData. Apparently this can get a bit … huge. Like massive. Even with a moderate number of sites. I guess that there is little way around that issue – if you’re logging all views in a site, it’s kind of inevitable – but it is worth noting.
Really, all this makes the standard SharePoint audit unusable for us – which is a shame ‘cos it’s so nearly very, very good, but ends up being unreadable for users. The only alternative options I can come up with are:

An EventReceiver on all lists – this would capture lots of useful info, but not some things, such as views of an item.

An HTTPModule – Powerful, but complex to build. Would capture and process all HTTP Requests to our web app, which would add a lot of overhead. We could pick up views, and viewing old versions, and so on – but we’d need to check the structure of the HTTP requests from things like Word, etc.. Not sure how it we’d log WebDAV actions, either.