Document Set Metadata – How does it work?

I had a student ask me the other day, does a document set get the metadata at the document set level?  I didn't know the answer…until now!  Let's start with a simple search on for "docset", we get nothing

Enable document sets in the site collection via "Site Actions->Site Settings->Site Collection Features->Activate Document Sets". Create a document set called "My Document Set" with a column called "Custom"

  • Create a new column called "Custom" in the document set 
  • We then need to setup some sub content types that the document set will contain via the "Document Set settings" link on the Document Set management page
  • Assign the Document Set to a library (with allow management of content types enabled)

Create a new instance of the Document Set with the "Custom" column filled in with "docset"

  • Re-index the content via the Search Service Application

Re-running the orginal search, we get only the document set:

Running a search for a sub document we get both document set folder and the document back:

So that begs the question…why doesn't Document Set metadata filter down to the sub items?  I think it should, but in the current version, it doesn't seem too with out some magic.

You may be asking the question what are "Shared Columns":

Well, you would think maybe it would cause the metadata to cascade down, but it doesn't, it only adds the column to the sub documents, which is weird in the first place because every time you add a content type, all the columns are added to the entire list anyway!

UPDATE!  A comment posted earlier pointed out there is a Timer Job Service that runs to update the metadata in the subcolumns.  Firing this job will supposedly update the sub document data.  However, I found that it doesn't for my Farm.  It would also make sense that your sub-document content types have a column with the same name as the document set level (if you didn't do the Shared Columns approach) or I'd guess this Timer Job would not do anything.  None-the-less, even after adding the column to the sub level docs via Shared Columns and the sub content types, the Timer Job still didn't update them 🙁  Still some bugs to be worked out here…

So the answer to the students question is no, a document set folder does NOT cascade its metadata to sub documents by default, it has to be updated by a Timer Job (supposedly)!

Have fun exploring!

More Forms Authentication Madness

Every time you apply an update or change some setting in Central Admin, the Root web.config file gets updated to add the <clear/> element back into the providers.  If you are using the machine.config file to propagate your membership settings, then this will be QUITE annoying. 


SharePoint Search Administration Component Error

If you get an error when creating your SharePoint Search Service Application manually, it is because the manual creation doesn't set the proper permission on the databases created (but the Farm Config Wizard does).  You need to add "Database Owner" permission to the following databases for the service account after Service Application creation (using SQL Management Studio):


Otherwise you get the cannot connect to the Admin Component error on the Search Management page.


SharePoint 2010 Forms Authentication Migration (For Developers)

For IT Pros, it is simple to setup the Forms Auth in SharePoint 2010.  However, when a system is migrated to 2010 that uses the Membership Provider generic factory classes extensively…all hell breaks loose!  The class definition for the Membership provider and MembershipUser is here.  After looking at that, consider a piece of code such as:

MembershipUser.ResetPassword("oldpassword", "newpassword");

The default membership provider set in SharePoint 2010 is  "Microsoft.SharePoint.Claims.SPClaimsAuthMembershipProvider".  The main job of this provider is to play an aggregation patten.  Find all username in all available providers and allow you to select them.  It also does some mapping of those users from the internal formats to a human readable format in the SharePoint web sites.  This particular membership provider as advanced as it is…DOES NOT IMPLEMENT ALL THE METHODS OF THE MEMBERSHIP PROVIDER MODELS!

This means if you used the membership methods extensively in your code (forms and web parts) in 2007, it is NOT going to work in 2010 when you migrate!  You will get several different errors around method not implementing and good luck with getting everything to work.  You will need to update your code to specifically call and instanate an instance of the membership providers that have been loaded in the process.  Such as:

MembershipProvider prov = Membership.Providers["AspNetSqlMembershipProvider"]

From there, you would then make the appropriate calls in your forms and web parts using the defined provider variable.

Good luck with the code migration!  And reference my other blog about other forms based auth migration issues here!

Installing SharePoint 2010 Error

Recently I was doing yet another install of SharePoint 2010 and the pre-requisite installer would keep failing on the IIS/Application server setup.  It simple wouldn't run.  I looked at the log file and there was nothing apparent in the log file that would tell me what was happeing.  Because I have done the install many times, I realized the only piece that wasn't doing anything was the IIS setup.  Looking at the command that the prereq installer would execute:

servermanader.cmd -inputpath <path to config>

I decided to run this manually and see what was up.  It was here where you do get an error:

Error: A configuration started by SP2010-WFE1Administrator is currently in progress.  Before you can start a configuratio, SP2010-WFE1Administrator must log in to complete the current configureation or the configuration in progress must be canceled.

Would have been nice if the SharePoint installer would have bubbled up the exception to the UI.