29. January 2009 14:29
Auditing from within MOSS (SharePoint Server) is quite simple -- There is a UI for enabling and disabling all of the events you may want to audit. There is also a facility for viewing and exporting these logs.
However, what if you would like to use auditing features in WSS 3.0 without MOSS? Believe it or not, most of the same auditing functionality is available, but without a UI.
Most of the information you need to do this is available already on the web, however its very spread out and difficult to digest. Rather than repeat information that is available elsewhere, let me point you to all your options with some explanations:
You can enable auditing on the list or site level via code -- Here's an example of what that looks like:
SPSite siteCollection = SPContext.Current.Site;
siteCollection.Audit.AuditFlags = SPAuditMaskType.All;
You might do this in a feature, or as an application page.
Here is additional information on enabling Auditing for a document library.
Here is information on enabling auditing for a site collection.
You can also enable the auditing without writing any code, using this custom STSADM command from Gary Lapointe.
Then you might ask yourself...
But how do I view my logs?
There is less information available about this. First, let's talk about where the logs live.
Audit logs are stored in your sites content database, in a table called "AuditData".
That table has a logical schema, and looks like this:
[SiteId] [uniqueidentifier] NOT NULL,
[ItemId] [uniqueidentifier] NOT NULL,
[ItemType] [smallint] NOT NULL,
[UserId] [int] NULL,
[MachineName] [nvarchar](128) NULL,
[MachineIp] [nvarchar](20) NULL,
[DocLocation] [nvarchar](260) NULL,
[LocationType] [tinyint] NULL,
[Occurred] [datetime] NOT NULL,
[Event] [int] NOT NULL,
[EventName] [nvarchar](128) NULL,
[EventSource] [tinyint] NOT NULL,
[SourceName] [nvarchar](256) NULL,
[EventData] [ntext] NULL
You may need to join this data to your Site table via the SiteID if you want to report on it effectively with SQL Reporting Services or even Excel.
Additionally, the Audit API has a more 'proper' way to access the audit data which will be safe in the event that the underlying schema changes in a future update.
Ted Pattison has prepared a sample with the ability to configure the logs and view the log data using the API.
Oh, and of course I plan to add the ability to view audit logs to my SharePoint Log Viewer in a future version!