I recently saw an email on internal DL about things not working if you backup and restore site collection from one Farm to another. The team was using Managed Metadata in some list columns. These are scenarios where you want to move content from one environment to another and ensure your termsets are also available in target environment.In this post I will brief you about what needs to be done to make it work and reasons for same.
Wherever you restore the site collection, Managed Metadata Service should be available. Managed metadata columns consult the MMS service whenever we interact with data stored in these columns. If MMS is not there things can break and show unexpected behavior. The easiest option to make things work is to restore the termstore from source farm to target farm.
You can use Export-SPMetadataWebServicePartitionData to export term store from source application.http://technet.microsoft.com/en-us/library/ff607847.aspx. You can import the same in target MMS using Import-SPMetadataWebServicePartitionData http://technet.microsoft.com/en-us/library/ff607667.aspx. By using this technique the term store is available on the target. The sspId used internally by the Termstore and referred by Managed metadata columns in list is retained.
Go ahead and test restored site collection in target Farm. You should find things working properly. In my random testing everything seems to be working fine. Please report issues, if you see any.
UPDATE
Hari requested me to put a sample as the API name is misleading. The service doesn't need to be partitioned for things to work. It works for un-partitioned service application also. Service Application Proxy ID has to be passed for -Identity parameter. Example given below and hope it helps.
#Export $mmsApp = “4a867ce5-d9ee-4051-8e73-c5eca4158bcd”; #this sets the exporting MMS ID $mmsproxy = Get-SPServiceApplicationProxy | ?{$_.TypeName -eq "ExportTaxonomyProxyName"}; Export-SPMetadataWebServicePartitionData -Identity $mmsApp -ServiceProxy $mmsproxy -Path \\location\exportfile.bak; #Import $mms2 = "d045d3ce-e947-4465-b039-0dfbbe24fb22" #this sets the importing MMS ID $mms2proxy = Get-SPServiceApplicationProxy | ?{$_.TypeName -eq "ImportTaxonomyProxyName"}; Import-SPMetadataWebServicePartitionData -Identity $mms2 -ServiceProxy $mms2proxy -path \\location\exportfile.bak -OverwriteExisting;
Awesome post. It worked like a charm. I would request you to put the example as well.
Export of metadata worked for me, but if i try to import the file on testserver, i get following error:
PS C:\Windows\system32> Import-SPMetadataWebServicePartitionData -Identity "ee9c
f807-5cbd-484a-a11d-77ebbf2ef071" -ServiceProxy "680fdccd-fc67-498c-8fc4-587fae4
54b6b" -Path \\testserver\backup\SPF01_Metadata.bak -OverwriteExisting
Import-SPMetadataWebServicePartitionData : Bei der Konvertierung eines nvarchar
-Datentyps in einen datetime-Datentyp liegt der Wert außerhalb des gültigen Ber
eichs.
Die Anweisung wurde beendet.
At line:1 char:41
+ Import-SPMetadataWebServicePartitionData <<<< -Identity "ee9cf807-5cbd-484a-
a11d-77ebbf2ef070" -ServiceProxy "680fdccd-fc67-498c-8fc4-587fae454b6b" -Path \
\grazsp99\backup\SPF01_Metadata.bak -OverwriteExisting
+ CategoryInfo : InvalidData: (Microsoft.Share...cePartitionData:
SPCmdletImportM...cePartitionData) [Import-SPMetadataWebServicePartitionDa
ta], FaultException`1
+ FullyQualifiedErrorId : Microsoft.SharePoint.Taxonomy.Cmdlet.SPCmdletImp
ortMetadataWebServicePartitionData
BernHard- I don't understand the language used in the error message. Also, I have never faced an exception with this mechanism.
Hi !
It seems that we have the same error on our French platforms (French OS, French version of SQL and French version of SPS). The error message indicates : "Unable to cast nvarchar to datetime".
We don't reproduce the error on another platform with English OS and English version of SQL. We are going to deploy SP1 (and CU June 2011 if necessary) on our French platforms.
Do you think that the error comes from the language of the platform (OS and/or SQL) ?
Regards
Nicolas
Hey,
I found the problem and a workaround:
Problem is the CmdLet calls exec proc_ECM_GetChanges @SinceTime='2012-02-27 15:30:22.530' with an English format date.
If your SQL Server is not in EN, it tries to parse this date, but fails.
Workaround is to set temporarly the default language for the involved DB user (farm account) to English (from SQL Management Studio, Security, Properties for the user, then change his default language).
Will MS fix this??