CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
Programming Audit
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
To enumerate all the Audit entries of a Site, it is possible to use the method ‘GetEntries’ in this way:
SPSite mySite = new SPSite("http://ServerName");
SPAudit myAuditCol = mySite.Audit;
foreach (SPAuditEntry myEntry in myAuditCol)
{
Console.WriteLine(myEntry.DocLocation + " - " +
myEntry.Occurred.ToLongDateString()
" - " + myEntry.UserId.ToString() + " - " +
myEntry.Event.ToString());
}
In the code, after the creation of an object containing the Site Collection information and another object for the Audit entries, a loop reads each entry and prints some properties.
In a similar way, after creating the Audit object, it is possible to eliminate all its entries:
myAuditCol.DeleteEntries(DateTime.Now.AddMilliseconds(1));
The delete method uses as input parameters a future date and time, and the code uses the actual time plus a millisecond. Remember that this code generates a new entry in the Audit to register the elimination and is impossible to delete.
As explained earlier, SharePoint saves some default activities if it has been configured. The Object Model sanctions the creation of new types of entries using the method ‘WriteAuditEvent’. For example, to save a document modified by an unauthorized user, the exception can be trapped using an Event Handler or WorkFlow and registered in the Audit:
myAuditCol.WriteAuditEvent(SPAuditEventType.Custom, "NotAuthorized", "<myXml>Modification Not Authorized</myXml>");
The code to detect the exception is not shown in the example, and the latest parameter may include all the information about the user and exception time. The method accepts three parameters: the event type (‘Custom’ in this case), the title, and the description of the event. Note also that the description has been written inside a ‘<Name>’ XML tag.
