What?
SharePoint 2010 - How to Backup/Restore Managed Metadata from one farm/environment to another?
Why?
You will be amazed by the lack of proper import/export functionality.
It is quite a general requirement to migrate Managed Metadata Service / Termsets from one environment to the other.
There are a few approaches to backup/restore managed metadata between environments.
OOB, SharePoint 2010 allows for ONLY importing managed metadata in CSV format. You are required to use Powershell / Object Model to build the csv file. Here is a script that can do it. Managed metadata terms and termsets each have a unique guid. If you take a backup of a site that is using managed metadata in some columns and restore this site into another environment, the guids don't match up. You will have to go through and re click each term and "wire it back up" so it's okay and doesn't show in red text. Paul Culmsee did a good job of explaining the same with nice screenshots here. This is quite hectic especially if there is a lot of data.
How?
The easiest and the effective approach is to LIFT the managed metadata service application from one environment to the other. That way you can ensure that the guids of terms and termsets match.
This process is done in PowerShell and involves exporting managed metadata service application first, then importing it in the target environment/farm.
Powershell Configuration:
Open PowerShell. You might get an error. “The local farm is not accessible”
If the farm admin account is used, this error won’t show up.
Make sure that the account that is used for deploying solutions / executing Powershell scripts has the following role memberships for SharePoint Config Database:
- public
- SharePoint_Shell_Access
- db_owner
Follow this article to fix the error: http://www.sharepointassist.com/2010/01/29/the-local-farm-is-not-accessible-cmdlets-with-featuredependencyid-are-not-registered/
Powershell for Export:
$mmsAppId= "App ID Guid Placeholder"
$mmsproxy = Get-SPServiceApplicationProxy -Identity "Proxy ID Guid Placeholder"
Export-SPMetadataWebServicePartitionData -Identity $mmsAppId -ServiceProxy $mmsproxy -Path "Path to save Exported file placeholder"
App ID Guid Placeholder:
Navigate to CA > Application Management > Manage Service Applications > Managed Metadata Service Application
The App ID Guid Placeholder is the Guid that is highlighted in the below picture
Proxy ID Guid Placeholder:
Navigate to CA > Application Management > Manage Service Applications > Managed Metadata Service Application
Do not click on the Managed Metadata Service link and highlight it by clicking anywhere else in the row.
Click “Properties” in the ribbon.
Right click in the dialog and capture the appid as highlighted below:
The App ID Guid Placeholder is the appid that is highlighted in the below picture
If you get an error “Export / Import failed due to insufficient rights”, you will have to open SQL Server Management Studio in the SQL Server machine and make sure that the service account used by managed metadata service application has bulkadmin rights in SQL Server.
Give BulkAdmin rights to the managed metadata service account account as it is required for managed metadata service application import.
Execute the PowerShell script again and the script should run fine.
The Import Process:
Make sure that the exported backup file is copied physically into the server that hosts SQL Server and make sure that it is accessible from the WFE where the PowerShell script is executed.
Execute the below PowerShell commands.
$mmsAppId= "App ID Guid Placeholder"
$mmsproxy = Get-SPServiceApplicationProxy -Identity "Proxy ID Guid Placeholder"
Import-SPMetadataWebServicePartitionData -Identity $mmsAppId -ServiceProxy $mmsproxy -Path "Exported file’s path placeholder" -OverwriteExisting;
The "App ID Guid Placeholder" & "Proxy ID Guid Placeholder" will need to be identified using the same process above in the destination farm.
Make sure to remove the bulkadmin permissions to the managed metadata service account as soon as you are done with the import/export process.
Ironworks is always on the lookout for experienced professionals who believe in hard work, having fun, and great client service.
A little bit easier way to get Ids:
$metadataApp= Get-SpServiceApplication | ? {$_.TypeName -eq "Managed Metadata Service"}
$mmsAppId = $metadataApp.Id
$mmsproxy = Get-SPServiceApplicationProxy | ?{$_.TypeName -eq "Managed Metadata Service Connection"}
Posted by: Oleg Slyusarchuk | 02/09/2012 at 07:01 PM
A simple code-free approach:
1. Backup the managed metadata database in your source farm
2. Delete the MMS service in your target farm
3. Restore the managed metadata database to your target farm
4. Create a new MMS service in your target farm
5. Ensure correct service accounts have full control of MMS
My company looked at multiple methods of migrating from our Dev environment to a Stage and multiple production farms. We also use a content type hub and migrated a test site to production. Using the method above, all GUIDs are retained and the pieces just snap into place.
Posted by: K. Austin | 04/17/2012 at 01:19 PM
Thank you for the article. It is the best I have found so far with rgerad to stapling. I have done exactly as it stated, yet when I deploy the feature is there, but not activated. I would like to have the feature activated each time I create MySite. Is it possible to have a solution sent to me or maybe some hints as to what could be done wrong. I am attaching the GUID from the Manifest from the main feature by clicking on the design view manifest link of the first feature and adding this GUID to the elements. This is kind of urgent and any help would be highly appreciated. Thank you.
Posted by: Kulipai | 05/10/2012 at 08:57 PM