Corey Roth [MVP]

I’ve done a number of SharePoint projects now and I see a growing trend where companies are treating consultants as a replacement for proper SharePoint training.  Where I see this most is in SharePoint 2010 installations / migrations.  The consultant will get ready to start the project and the manager or CIO will declare, “I want my IT person to be present when you do the install so he or she can learn how to do it.”  My response is always, “That’s great!  I’m sure your IT person will learn a lot, but what kind of training do you have scheduled for him or her to solidify his or her SharePoint skills?”.  At that point, the response I usually get back indicates that training hadn’t even been considered.  Don’t get me wrong. I love to teach people about SharePoint.  If I didn’t, I wouldn’t be in this industry.  However, there is only so much you can learn during a consulting engagement.  You are doing your company and your “IT Person” a huge disfavor if you think he or she will learn everything about SharePoint in just a couple of days during an install.  It simply isn’t going to happen.

When the management insists on having an employee present, I usually have the employee do “the driving” as much as possible.  This means, the IT person will be behind the the keyboard and mouse.  This actually works well for me because I can document the settings used while he or she is typing them into SharePoint.  When I am doing installs, I try to explain why we are making particular configuration changes so that the administrator has a better understanding of the environment.   In my experience though, the problem with this “training” approach is that I have yet to see an employee actually take notes during any part of the process.  I’m not sure if this is due to lack of interest or what.  A lot of times SharePoint is just another piece of software that gets dumped on an administrator’s lap.   He or she gets some hands-on experience with the install and configuration, but the administrator may have trouble when they have to do this configuration later on his or her own. 

I’m definitely not saying to not have your IT person present when you do a SharePoint install.  It’s definitely a good thing.  As a consultant, I will strive to arm your administrator will all the right weapons to make your SharePoint environment a successful one.  However, I am hoping to reset your expectations coming into the engagement.  Consultants simply can’t teach your IT person everything there is to know about SharePoint administration, architecture, development and do the migration in such a short period of time.  If your administrator has limited SharePoint experience, you really need to invest in some quality SharePoint training.  This will boost your administrator’s confidence in his or her ability to manage the SharePoint environment.  Not to mention, he or she will probably get some sort of training manual as a take-away in which to refer.  What if there is an outage?  Will your administrator be able to handle it?  Does he or she know how to troubleshoot the environment and look for errors?  It’s something you need to consider.  Am I off-base here?  I’m just hoping to help some people get the proper training that they deserve. :)  What do you think?

As someone who focuses mostly on ECM and Search, I am a huge fan of the new Metadata Navigation feature on document libraries in SharePoint 2010.  It provides a great alternative to folders when it comes to navigating your document libraries.  A list administrator can configure Metadata navigation on the document library settings page.  However, I prefer to make changes using CAML or code so that I can deploy them easily to other environments.  Usually, my first choice is with CAML, so I did some digging today and I discovered the trick to deploying your Metadata navigation settings using a SharePoint feature.

When I first started investigating this, I assumed it might be some new element or attribute inside the schema.xml file of the list.  It turns out my assumption was incorrect.  We actually set this by assigning some XML to the client_MOSS_MetadataNavigationSettings property on the root folder of the list.  We can assign this value using code, but you know I prefer to use CAML.   We can use the PropertyBag element to make this happen.  Before we look at the PropertyBag element itself though, let’s look at the underlying XML.  Let’s take my list here with three items selected for Metadata Navigation: a site column named DocumentType, the Content Type of the documents in the library, and the Folders in the library itself.  Here is what the XML will look like.

The first line seems to always be the same.  It enables the Metadata Navigation and it will take care of automatically adding new index columns when AutoIndex is set to true.  The NavigationHierarchies section actually defines which fields will be used for Metadata navigation.  If you want to navigate by folders, add a FolderHierarchy element and set HideFoldersNode to false.  If you set it to true, folder navigation will not be present.  The MetadataField element defines which fields to use for navigation.  You need the GUID for each site column to include.  You can get this from your list’s schema.xml file.  You then need to specify the FieldType.  Remember that it only supports Single-value Choice (Choice),  Managed Metadata (TaxonomyFieldType) , and Content Type (ContentTypeId) field types.  You then need to specify the field name in the CachedName field and then you can customize the display name as you see fit with CachedDisplayName.  The last thing to note here is that you have to create a Managed Index for any choice fields you add.  This is why you see a ManagedIndex element with the DocumentType field.  Set the IndexId and IndexFieldId attributes equal to the Id of the field.

At this point, we are ready to assign this XML to the the client_MOSS_MetadataNavigationSettings property.  We need to encode the above XML, because it is being stored inside an attribute of another XML document.  Here is what your elements.xml file would look like.

It’s kind of hard to read the contents of the Property element, but it is just the encoded version of the XML above.  As for the PropertyBag element, you just specify the relative Url to the document library on your site.  In this case, it’s Shared Documents.  Always set ParentType to Folder and RootWebOnly to false.  At this point, you can activate this feature after you have deployed your document library and it will enable the Metadata navigation.  Here is what the Metadata Navigation settings page looks like.

Here is what my document library looks like with the navigation enabled.

It’s pretty easy to set this up as you can see.  Keep in mind that if you set this value, it will overwrite any values previously stored.  This includes any Key Filters or Indexes that might already be present on the list. 

Speaking of Key Filters, we can add them to the document library using the client_MOSS_MetadataNavigationSettings as well.  Let’s look at some more XML.  In this case, I am adding key filters for DocumentType, All Tags, and Modified By (editor).

The elements are pretty similar to that of the NavigationHierarchies element.  You add one MetadataField element for each field you want with the same attributes as before.  However, a few more fields types are supported such as Person or Group (User).  It also recognizes Enterprise Keywords through the use of the All Tags (TaxonomyFieldMulti) filter.  You can also do Date and Time fields as well as Number fields too.  I also added the ManagedIndex field for Editor (the Modified By filter).  You can probably leave the indexes out since AutoIndex is true, but if you run into issues, you can add them manually as you see above.  You can deploy KeyFilters and NavigationHierarchies elements at the same time.  You’ll need to encode the XML again just as you did before.  When you activate the feature, you’ll have Key Filters enabled on your document library.

Using the PropertyBag element, you can easily add metadata navigation to your document libraries.  This is a great alternative to defining these settings using code.