Missing Office Document Properties in SharePoint 2010 - Properties Promotion

Recently I was asked to stand up a Records Center in SharePoint 2010 for legal hold capabilities.  After configuring everything, I proceeded to run an eDiscovery and hold job.  When I took a look at the document library in the Records Center where the documents were sent, none of the documents’ metadata was there.  Moreover, I could open the document in Word and see that the metadata was still there under Info>Properties.  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 worked 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:

 

The following image illustrates the property demotion 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://recordscenter.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 Hold job works as expected. Case closed (but I'd still love to know why this functionality is disabled by default).

 


Tags:
Permalink | Comments (0) | Post RSSRSS comment feed