One of the most talked about capabilities since the launch of SharePoint 2010 is the Managed Metadata Service.  For those of you who aren’t already familiar with this service and the support it provides for modelling and deploying a rich corporate taxonomy.   For those who need get to the basics, configuration & related features for it, we would recommend going thru the links available at “Managed Metadata and Taxonomy in SharePoint Server 2010”

We would use this blog post  to bring about some additional information on situations which you might face in day to day work .

The Taxonomy Field is lookup field.

The taxonomy field is a lookup field. The lookup list associated with this field is called the Taxonomy Hidden List. This list is located at http://siteURL/lists/taxonomyhiddenlist. It exists only on the root web of the site collection, and is used as lookup by all the site/list taxonomy fields within that site collection.

Every time a term is used for tagging an item, an entry is made for that term in the Taxonomy Hidden List. The entry will differ depending upon whether the term was used in a Managed Term field/ Enterprise Keywords field.   Here is a blog which talks  about this in more details   Dissecting the SharePoint 2010 Taxonomy fields

Users  can’t see the  values of the  Managed Metadata Columns  for list items

Users can browse to the site & see list items etc.  but they are not able to see values in a metadata column on a SharePoint list. The only users who can view the item are Site Collection Administrator and any user who was given permissions from policy for Web Applications.   This occurs because of missing permissions  on “TaxononyHiddenList”  for the site collection .   By default the “TaxonomyHiddenList”  has unique permissions assigned as below  for a Classic Mode Web-Application .

 

Read Permissions should exist for the following principals based on the Classic Claims  mode of the Web-application

NT AUTHORITYAuthenticated Users	Read	Classic  Web-Application
All Authenticated Users	Read	Claims Web-Application

Site Collection Import /Export  OR  Backup /Restore  OR Content Deployment Scenarios across Farms

Use of Termsets & Managed Metadata columns has found increased usage in Lists either directly or via a content types which provides a  Metadata column . Once a user adds a Tag to the list item the list Column is updated with Value of the TAG along with the TermID for the Taxonomy Tag.

Explained as below we see List  Metadata Columns Test11 & Test 12 & Terms in use as seen from List Items & Taxonomy Hidden list . Notice how we store this column values in SQL for List “DocLibSC2” .  The format used is TermName|IDForTerm .

 

NOTE: It is not recommended to execute SQL queries against the SharePoint databases.

Now if we Export /Import or Backup /Restore  or Do Content deployment across farms , we are  able to get the list Items Along with the Values of  Tags in Metadata columns ( due to fact that we carry the  contents of TaxonomyHiddenList along ) but they would not resolve or Match up to a Term in Termstore published by managed Metadata service on Destination farm . Even If we have the Termset/Terms  with same name created on the Target Farm  the ID’s won’t match . This would lead to  the Metadata column values being Greyed out (un-editable ) & other inconsistencies .

These are the Scenarios  where you would want to move contents from One Environment to another to ensure Term sets/Terms are also available  to target environment .  Two ways to make thing work in these scenarios are

a. Publish the Managed Metadata service Application on the Source farm or any other Services farm & ensure that both Source & Target farms consume the Managed Metadata from this same location. Please refer to articles below to Publish  & Consume  Managed Metadata services

Share service applications across farms (SharePoint Server 2010)
How to publish a Managed Metadata Service for cross-farm consumption

b.  You can use Export-SPMetadataWebServicePartitionData to export term store from source application & import the same in target MMS using Import-SPMetadataWebServicePartitionData . By using this technique the term store is available on the Target Farm. The tsid GUID does not change.  So if you have created a Managed Metadata Service and Import /Export to another farm, it will stay consistent.

matadata url

 

Here is a sample  Cmdlet as the name is somewhat  misleading

#Export

$mms1 = “4a867ce5-d9ee-4051-8e73-c5eca4158bcd” –This sets the exporting MMS ID which can be obtained from Get-SpServiceApplication

$mms1proxy = Get-SPServiceApplicationProxy | ?{$_.TypeName -eq “Managed Metadata Service Connection”} — Assuming there is one Proxy , If you have  more , get the correct one based on ID

Export-SPMetadataWebServicePartitionData -Identity $mms1 -ServiceProxy $mms1proxy -Path \locationexportfile.bak

#Import

$mms2 = “d045d3ce-e947-4465-b039-0dfbbe24fb22”  –This sets the importing MMS ID

$mms2proxy = Get-SPServiceApplicationProxy | ?{$_.TypeName -eq “Managed Metadata Service Connection”} — Assuming there is one Proxy , If you have  more , get the correct one based on ID

Import-SPMetadataWebServicePartitionData -Identity $mms2 -ServiceProxy $mms2proxy -path \locationexportfile.bak-OverwriteExisting

Note : With the OverwriteExisting switch it maintains the name space.   Also if there were terms in the destinations that are not in the import file, then it removes them.  In other words, the only items in the term store will be the ones you import in.  Nothing more and nothing less.

Note: The Path Specified in Import-SpMetadataWebServicePartitionData has to a location on Shared Location on the SQL server of the farm  & ensure SQL  & Sharepoint Service accounts have required access . Refer to  Post Here for more details