The Case of the Missing Office Document Properties in SharePoint 2010

In preparation for a presentation on Records Management with Rob Bogue at a recent conference, I created some very simple demonstrations using the built-in Records Center template. The template creates a site with common records management artifacts, such as a drop-off library and records library, enables the various RM features (Document ID, In-Place Records Management, etc.), and replaces the default home.aspx page with a records-focused page. The scenario was simple: 1) create a content type with the "Author" site column, 2) associate the content type with the two default libraries, 3) create a content organizer rule which moves items from the drop-off library to the records library, placing each item into a folder based on the Author property in the document, 4) upload multiple items, check them in, and demonstrate how the organizer rule automatically creates folders in the target library and puts documents in the right place based on promoted metadata properties. Simple, right?

Not so fast. When I tried this on my shiny new Records Center site the Author property was never promoted from the Word document. I tried this on several different libraries, with and without records settings enabled, and the same thing happened each time – on upload the Author property never came through nor did Title, Subject, or any of the other standard document properties. So I went back and tried it on a normal Team Site and – voila! – it works just fine. What gives?

Turns out that the document parser is not enabled on a records center site by default (for dark and mysterious reasons that I don’t quite comprehend); therefore, property promotion does not occur. By way of background, property promotion refers to the process of extracting values from properties of a document and writing those values to corresponding columns on the list or document library where the document is stored. Property demotion is the same process in reverse. When the values of document properties change, the changes can be automatically written back to the list. When the values of columns or fields in a list item change, the changes can be automatically written back to the document that is associated with the list item. Thus both the document and its associated list item remain in sync.

SharePoint 2010 initiates property promotion or demotion when the following events occur:

• A file is uploaded to a document library.
• The fields of a list item that is associated with a file are modified.
• The Properties property of an SPFile object is updated programmatically.
• A file is downloaded for the first time after the list schema has changed.

In each case, SharePoint determines whether a parser is associated with the file type. If one is, the system invokes the parser, passing it the document and a property bag object. The parser then either fills the property bag with values that need to be promoted to the list or extracts from the property bag the values that need to be demoted to the document.

Properties are only promoted or demoted if they match list columns that apply to the document. The columns that apply to a document are specified by the following:

• The document’s content type, if one is assigned.
• The columns in the document library, if the document does not have a content type.

The following image illustrates the property promotion process:

So how do we fix this when using the record center site template? Fortunately, the answer is pretty simple. A little bit of powershell is all it takes to flip the document parser back on:

$site = new-object microsoft.sharepoint.spsite("http://rm.contoso.com/records")
$web = $site.openweb()
$web.parserenabled = $true
$web.update()

Now we’re back in business. Documents uploaded to the drop-off library now include the Author field and my demo works as expected. Case closed (but I’d still love to know why this functionality is disabled by default).