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 .
permission inherit
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 .
metadata
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
Categories: Metadata, sharepoint2010