How to create a daily summary alert for any change in a SharePoint site

Question

I recently got the requirement for a person to receive a daily summary alert for any change within a SharePoint site; each site has an owner who is in charge of the content on their site.

The current way we have something working is to automatically set up alerts for every list/library within the site.

// Get the Lists on this Site
SPListCollection siteLists = currentSite.Lists;
foreach (SPList list in siteLists)
{
    if (!list.ToString().Equals("Master Page Gallery"))
    {
        if (list.ReadSecurity == 1) // user has read access to all items
        {
            // Create an Alert for this List
            Guid alertID = currentUser.Alerts.Add(list, SPEventType.All, SPAlertFrequency.Daily);

            // Set any additional properties
            SPAlert newAlert = currentUser.Alerts[alertID];
        }
    }
}

This creates two problems:

1. The user has a lot of different alerts created. Ideal: Only ONE email with the daily summary.
2. Some sort of monitor would have to be set up to check for new lists or libraries in the site and automatically set up alerts for the user.

Q: How can I create a daily summary alert for all changes in a site?

Answer 1

I believe the solution you're looking for is available through the auditing framework. Auditing is very robust in SP, unfortunately it's easy to get overwhelmed by the output.

The Audit is a property available on the SPSite, SPWeb, SPList, and SPItem properties.

Adjust the specific audit flags (using the .Audit.AuditFlags properties) using this property to suite your needs (the specifics will depend on how you define "change" but almost anything you can think of is available).

Details about the SPAudit object are available on MSDN.

Once you've defined what/where you want to audit, you'll have to get that information back to your users.

By default, SP sets up some nice reports that available at the site collection level ([url of site collection]/_layouts/Reporting.aspx?Category=Auditing). These may meet your needs.

Your initial solution mentioned alerts via email for the users. Given that most users want to centralize their information in email (though their MySite is great place to put a link to the reports!) you'll have a little more work to do.

You can pull the required audit information through the object model using the SPAuditQuery and SPAuditEntryCollection objects. Again, MSDN has some information on how to use these objects.

I would recommend setting up a custom SPJobDefinition that runs at the end of the day to email the users the audit report for their site. Andrew Connell has a great explaination of how to setup a custom job on his blog.

To summarize:

• enable auditing for the SPWeb's in question
• create a report using SPAuditQuery and SPAuditEntryCollection for each SPWeb
• create an SPJobDefinition that runs each night to email the report to each SPWeb owner

Answer 2

A thing to consider before enabling auditing policy on a site, is the performance overhead you add.

I would recommend keeping the footprint as little as possible here!

By that i mean if its only a certain content type or a certain list that you want this information from, be sure to only enable the information policy on these CT's or lists!

Also keep the logging to a minimum. Eg if you are only interested in views, not deletion or restore, only log these events!

On large sites i have seen auditing really trash performance!

Also be aware of some caveats here: even though you can enable auditing on lists (as in not document libraries), alot of events (for example view events) is not logged specifically for list items! This is not described anywhere (in fact i have even seen Ted Pattison mention item level audit in an MSDN article) but i have it directly from CSS and product team that item level audit is not implemented in SP2007 because of performance issues. Instead you just get a list event in the log specifying that the list has been touched.

Documents is tracked fairly ok, but i have seen problems with auditing view events on publishing page (which in the API is considered a document not a list item) depending on how and where auditing was set (for example if audit policies were implemented with inherited CT's) so thats something to be aware of.

[edit: did some testing around this yesterday and its even worse: In fact publishing pages is only tracked if you set on site level audit policy! If you set a policy on a list or a content type (or even a content type that inherits from a content type with a policy) you will get no SPAuditItemType.Document level events at all. Set it on a site and you will get too many audits! Eg. a view will trigger x2 view events, and same with updates, so you end up with too much being logged. It definetely looks like a bug that nothing is audited when policies are put on lists and CT's...]

The main message here is: careful what you log, since it will affect your sites performance TEST that what you expect to log is really logged!

hth Anders Rask