Auditing in SharePoint 2007
Tracking the complex trail of information within an organization is a major task. To address this issue, Microsoft introduced Audit support possibilities in SharePoint 2007. Audit undertakes the verification and validation of systems, and then processes the results in automated technologies to guarantee the integrity and accuracy of the information. The Audit mechanism ensures that each activity in the system is saved in a repository.
Because SharePoint is Microsoft's primary system to store information, it is essential that it includes a built-in Audit system. In legacy versions, SharePoint lacked a proper default system; although it was possible to program a kind of audit mechanism in SharePoint 2003, it was not a default component. SharePoint 2007 introduced a default system that covers Site Collections, Lists, Libraries, and includes an Object Model to implement custom applications if necessary.
Many companies have strict policies and guidelines related to storing records concerned with the flow and activity of information. With a nod to assuring enterprise transparency, governments require sophisticated tracing procedures to determine juridical responsibility. SharePoint Audit mechanism ensures that each activity that occurs at Site Collection, List/Library, Content Type, and Document/Item is stored in the database, with sufficient security to avoid alterations.
Although the Audit mechanism is a general SharePoint component, only Microsoft Office SharePoint Server (MOSS) has an interface to activate and configure it. Windows SharePoint Services (WSS) can duplicate the process, but developers need to program the appropriate interfaces to utilize it.
Auditing in MOSS
The Audit mechanism in MOSS is not activated by default. Go to Site actions, Site settings, Site collection Audit settings to activate at the Site Collection level.
Figure 1: Configuration of Audit for a Site Collection
At Site settings, you can reach the Informs Audit log reports page. The default Audit reports (elimination, modification, revision, and so forth) is displayed in Excel format; it's also possible to define new custom reports. The Excel report has two tabs: one for a summary of the activities and a second for detailed information, including site and element identifiers, date, event type, and user.
To activate Audit at a Library level, from the configuration page of the Library or List use the Settings page, Information management policy settings, Define a policy..., 'Ok, and Enable Auditing.
Figure 2: Configuration of Audit for a List or Library
Activity reports can be found in the same place as the Audit reports for the Site Collection.
It also is possible to activate Audit for Content Types. The procedure is the same as with Libraries: Create the Content type or select an existing one from the Content type gallery, use the Information management policy settings option, and create the policy.
Finally, Audit can be activated at a document or item level, but neither MOSS nor WSS have interfaces to activate, configure, or review them. In this instance, developers can use the Object Model to create an interface.
The objects for Site Collection, Lists, and Items (SPSite, SPList, and SPListItem) each have a public property 'Audit' of the SPAudit type. This class permits total control over the respective Audit.
The class SPAudit has an interesting property, 'AuditFlags', making it possible to read or configure the events to be registered (read, change, delete) and the following four methods:
- DeleteEntries: Eliminates all the entries in the Registery. To guarantee Audit integrity, the elimination is saved as a new activity that cannot be deleted. In this way, if records are removed, a permanent trace 'saves' the procedural history
- GetEntries: Displays the Registry collection
- Update: Saves changes made to a Registry
- WriteAuditEvent: Writes a new entry in the Registry
Page 1 of 4