Saturday, December 15, 2012

Problem with broken managed metadata fields when use Backup-SPSite/Restore-SPSite across Sharepoint farms

Backup-SPSite and Restore-SPSite are useful standard PowerShell cmdlets which allow to copy site collection from one web application to another. These web applications may be located on different farm, or they can be in the same farm, but use different instances of Managed metadata service application. In this case you will face with the problem that all managed metadata fields will be broken: they will be grey and not editable.

The problem is caused by different Managed metadata service application instances, or by different term store ids to be more precise. If target web application uses different instance (which may have even the same name, if we are talking about different farms. On the same farm it is not possible to create 2 instances of managed metadata service application with the same names) all bindings became broken.

One of the possible solution which you may think is to use the same guids for termsets and terms on source and target. Unfortunately it won’t help with Restore-SPSite, fields anyway will be broken. Even if you will use approach similar to described in the following article: Migrate SharePoint 2010 Managed Metadata to another farm or Service Application, fields anyway became broken because term store ids will be different anyway.

There are several possible solutions:

  1. Share managed metadata service application across the farms. Here is the article which shows how to do that: How to publish a Managed Metadata Service for cross-farm consumption.
  2. Copy term store from target to source using Export-SPMetadataWebServicePartitionData and Import-SPMetadataWebServicePartitionData cmdlets. When use this way term store id is preserved. See e.g. this post for example: Managed Metadata, Taxonomy & More.
  3. Backup managed metadata database in Sql server and restore it on target farm. The create new managed metadata service application instance and use restored database. It can be done from UI (specify name of the existing database when you will create new managed metadata service application on the source farm) or PowerShell (using New-SPMetadataServiceApplication or Set-SPMetadataServiceApplication cmdlets). Then associate your web application with newly created managed metadata service application using service connections in Central administration.
  4. All previous ways assume that you need to modify your existing target environment. If we are talking about living production environment they can be riskous options. If you don’t want to change it, there is one more option: fix broken managed metadata fields from UI. Go to Site settings > Site columns or Site settings > Content types > Select content type and select managed metadata field which should be fixed. Then specify binding manually and click Ok (choose propagate changes to the list when you will do it). After it field will become working. This way can be automated by PowerShell script.

Hope that it will help you if you will face with this problem.

1 comment:

  1. I have migrated metadata database, as you describe in #3, and migrated content database. I expected that metadata fields will be preserved, but now I can see that binding is corrupted. is it normal, or do I perform migration in wrong way? I migrate to completely different domain, it might be some issues with system accounts permissions and stuff like that.

    ReplyDelete