Inside a Support Incident: SharePoint site templates and auditing

Here at CSS (formerly PSS), our bread-and-butter is the support incident. One recent incident (hereafter referred to as 'the case') allowed me the rare opportunity to blog on what goes on here at CSS when an issue is raised by one of our customers, and I'll be blogging the progress of this particular case as time goes on, as will Gavin, the external party. First, the background:

Gavin, our customer, has run into a problem provisioning new SharePoint site collections based on a custom template. Gavin is one of our more active SharePoint customers, and he knows the drill - some initial troubleshooting was already done when the case was submitted, and there was a clear description of the problem. Having run into what seemed to be an impasse with his own troubleshooting, Gavin called the support line, and one of our front-end guys took the call, created the incident in our system and dispatched it to the ANZ Bizapps support queue, one of several I monitor.

We work on a callback system here in ANZ Premier - when a customer calls in with a problem, we won't immediately dive in and start troubleshooting on the same phone call. The complexity of our incidents is often high, and the callback model allows us to route to the appropriate specialists and allow those specialists to get up to speed before going live with the customer.

So when I received Gavin's case I had four lines of text to work on, describing the behaviour in a very succinct style, and the specific error message: "The specified web does not contain a reporting metadata list".

The first thing I'm likely to do with an incident like this, even before contacting the customer, is to fire up our internal Knowledge Base client and search on the error message. This I did, and discovered that there aren't many hits for this particular message. In fact, I found only one previous case with this message cited. Luckily for me I struck gold with this initial search - there is indeed a workaround, which is to run:

stsadm -o activatefeature -name Reporting -url https://server/sitecollection/ -force

Which essentially just switches on the reporting feature. I sent this over to Gavin, and received a nice positive response - it worked! This meant Gavin could now provision sites successfully. Of course, this doesn't tell us why this feature wasn't activated in the first place.

So at this point Gavin and I discussed the nature of the problem as it stands, and moved on to stage two, seeing if the problem will reproduce and understanding if the issue is caused by something in the product or outside the product. Gavin, to his eternal credit, had already done the 'minimum repro' thing, and provided me with a set of steps to reproduce the problem.

Onwards, to the Virtual Machine.

I have a base image I use for these problem repros, which consists of a full install of Office SharePoint Server 2007 on Windows Server 2003, all packaged up as a Virtual Server VHD image. When I need to play with MOSS, I fire up either an existing instance of this VM or start a brand new one. This is a pretty quick process. I just copy one file, run through a quick wizard in Virtual Server and fire it up.

In this particular instance, I decided to use an existing VM to reproduce the problem. Of course, Murphy's law kicked in and I ran into a problem provisioning the new site collection entirely unrelated to Gavin's own problem, which I was able to trace to a custom feature I'd installed on that particular VM. So out with that VM and in with a clean one.

This time, the repro went perfectly. Here are the steps I took. They're essentially the same as those posted by Gavin in this post.

• From a baseline install of MOSS, I provisioned a new Site Collection at https://sharepoint/ , based on the 'team site' template.
• In the 'site settings' page of this new site, I clicked 'save site as template', provided the basic info and saved to an STP.
• the resulting STP file was saved to disk, and I ran stsadm.exe to make this template globally available. The command is: stsadm.exe -o addtemplate -filename “audit-repro.stp” -title “Audit Repro Template” -description “Reproducing a reported problem with auditing activation”
• Back in SharePoint Central Administration, I provisioned a new Site Collection based on this new Custom Template.
• In 'Site Settings' for this new site collection, I clicked on 'Audit Log Reports' and received the self-same message as Gavin. The source site collection had no such issue.

So it appears that this problem is reproducible, and not something specific to Gavin's environment. It is, in essence, a bug* . That's a bug* , not a bug. At this stage, it's a bug report, and not officially confirmed by the powers that be, though it fits the definition of an unexpected error condition, reproducible on demand and contrary to expected behaviour.

And what's done at this point? Well, I log a bug report in our internal system and that is escalated to the Office Server Product Team for triage and an official response, then I sit back, reflect on quite a smooth incident thus far, and write up this blog post. And that's as far as our story goes for today. Tune in next time for the exciting conclusion!

Comments

• Anonymous
  January 01, 2003
  I am having a similar problem with site collections created from a template and was wondering if anyone else is having this problem… After creating a new site collection from my template, I go to “Edit Page” and “Add a web part” and the “All Web Parts” section is empty, preventing me from adding the common default web parts to teh page.  Is there a command to "Force" this feature for the default web parts on also?

• Anonymous
  January 01, 2003
  I got this error on all our extranet sites when I opened up the Audit Log Reports within Site Settings

• Anonymous
  January 01, 2003
  SharePoint auditing came up this past week so I thought it would be good to pull up my VPC and review

• Anonymous
  May 08, 2012
  Oddly, this issue still seems to exist in SP2010 SP1/June2011 CU. However, in order to make it work, we need to deactivate/re-activate "Reporting" in Site Collection Features.