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;
siteCollection.Audit.Update();

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!

(The title of this post could also be: "How to disable output escaping of the columns in your SharePoint Data View from SharePoint Designer")

You may have tried to use a list with a Person column as the source for a Data View.  You may have even had Presence information available in that column.

It's likely that all you got was a bunch of garbled HTML when you actually rendered the column.  This is because by default, the XSL transformation will escape all the HTML characters rendered for the "People" column type.  With a simple attribute in your XSL you can fix this, and show single and multiple Person entries correctly.

If you look in your code view in SharePoint Designer where the column is rendered, you'll see a simple value-of select like this:

<xsl:value-of select="@People" />

Simply modify that by adding an output escaping attribute:

<xsl:value-of select="@People" disable-output-escaping="yes" />

And now it should render the column properly.  This will work for any data type that contains HTML.