Site Collection BackupRestore and Managed Metadata

  • Article

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.https://technet.microsoft.com/en-us/library/ff607847.aspx. You can import  the same in target MMS using Import-SPMetadataWebServicePartitionData https://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;

Comments

  • Anonymous
    January 23, 2011
    Awesome post.  It worked like a charm.  I would request you to put the example as well.

  • Anonymous
    January 26, 2011
    The comment has been removed

  • Anonymous
    January 26, 2011
    BernHard- I don't understand the language used in the error message. Also, I have never faced an exception with this mechanism.

  • Anonymous
    August 23, 2011
    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

  • Anonymous
    February 27, 2012
    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??