Mark Gilbert's Blog

Science and technology, served light and fluffy.

Not so Happy Feeture*

My current project involves building an internet-facing site on Microsoft Office SharePoint Server (MOSS) 2007.  For the last few weeks we’ve been working to get some of the “framework” pieces in place, such as custom master pages, picture galleries for the content, etc..  Last week we started wrapping our components and settings into “features”.

A feature allows you to encapsulate things like custom list columns, master pages, page layouts, etc. into an installation package (of sorts), and include instructions on how MOSS should install them.  Then, you install them, and activate them, either at the site or the site collection level.

A feature has the following benefits:

  1. Encapsulated (sort of) – the Feature.xml and associated files define everything that goes into that feature. For example, we built one that would install the master pages for our site, and all of the associated images. I say “sort of” because it’s not like building a .NET assembly that can be dropped in the GAC – the feature is merely a collection of files, strung together by a couple of XML documents, all in the same directory.
  2. Repeatable installs – for the development environment, we’re frequently making changes directly in SharePoint (or SharePoint designer). Eventually, we will have to reproduce this in the production environment, and it will be very time-intensive to do this by configuring SharePoint – both in terms of the time it takes us to write up a process for doing it, and the time to do it. Additionally, the more we can roll up into a feature, the fewer chances there will be for us to miss a step in our process, and have to rework something.
  3. Self-documenting – To a certain extent, the features can document the major steps of deploying the application. Our process might be “run these 15 features in this order to deploy the site”, and if the features are named like “SiteMasterPages”, “ProductPage”, “AssemblyInstructionLibrary”, etc., you can get a sense of what each of them is doing. Granted, there may be details that need some additional explanation, but at least you can get some value at the 5,000 foot level.

Looks like we just had our glitch for this mission

One of our tasks was to create a custom list, and then populate it.  Our first few attempts at doing this produced a feature “template”, what appears on the new list Create page.  Defining a template would allow us to define the structure of the new list, but wouldn’t actually create the list.  With a little more tweaking, we got it to work.

Houston, we have a problem

Unfortunately, somewhere along the line, we ended up hosing the entire server.  When we tried to visit the “Site Settings” page, that shows the entire site collection in a Windows Explorer-like screen, we got this:

Feature ’00bfea71-e717-4e80-aa17-d0c71b360101′ for list template ‘101’ is not installed in this farm.  The operation could not be completed.

The GUID referenced was not the one we were using with our feature, but we tried deactivating and uninstalling our feature – same error.

We tried deleting the web application and site collection that we had activated the feature under.  If you delete the code that is throwing the error, the error goes away, right?  Well it didn’t go away, which meant that our new feature wasn’t causing this error, at least not directly.

We tried access the Site Settings page for the other two major site collections being hosted on this server (representing two different development projects going on here at BlueGranite).  They were ALL throwing this error now.

Ok, so now that I had the attention of two entire development teams, we could put our collective grey matter to the task.  There must be an easier way to ask for help…

You are Go for the manual burn

After trying several things, digging through page after page of Google search results, and poking into the MOSS server with a custom tool that a colleague of mine (Joel) wrote, we discovered that the GUID being referenced was for the Document Library template.  It started looking like the out-of-the-box document library feature had somehow been corrupted by one (or more) of our early attempts to get our own feature working.  Based on this, Joel made a remarkable leap in logic.  The document library feature is in the same directory as all of the others.  Let’s try reinstalling THAT one, just like we would if it were a custom feature.

We ran two stsadm’s (one to install it, and one to activate it) and an iisreset.  Then we tried the Site Settings page again, and it worked!  We tried the Site Setting pages for all of the other affected sites, and they were working again as well.

The ship is secure

So, what the heck did we do?  As near as we can tell, we left out one or more required fields in the Elements.xml file.  This file defines the particulars about the list, the master page, the custom column, etc. that you are trying to install.  This link describes the ListInstance element in more depth, including which fields are required:

Leaving out one of these required fields allowed the feature to be installed, but since it had to have something in that field it filled it in with whatever it could – in this case a reference to the Document Library feature.  When we didn’t see ours working, we would uninstall it, and try again.  Since we didn’t think to check the Site Settings page in between, we don’t know which of the steps broke it.  However, Joel made a blog entry on March 5 that also talks about this particular issue, and his is probably the best explanation of which field was the culprit – FeatureId.

Because there is only one Features folder per MOSS server (typically under C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\Template\Features), it affects every site collection hosted on it.  When we hosed the document library feature for our site collection, it took it out for all of them.

So, there are a couple of lessons to take away:

  1. When you’re building a feature, make sure all of the required fields are specified.
  2. Be mindful of the fact that installing features affects the entire server, and not just your site collection. The “12-hive” contains a lot of sensitive documents and settings, so you need to tread lightly. Unfortunately, while we thought we knew that going into this process, we have a much better appreciation now.
  3. It looks as though MOSS uses what’s defined by the Feature to set up structure in its databases. Once that structure is set up, the files on the file server are no longer used. That would explain why installing our new feature hosed the server, but re-installing the built-in Document Library feature fixed it. It would be interesting to see if this is a recommended solution to errors like this.

*A nod to one of Joel’s previous posts (, January 8, 2007) about features.

March 7, 2007 - Posted by | MOSS

Sorry, the comment form is closed at this time.

%d bloggers like this: