Ir al contenido principal

How to Backup/Restore Managed Metadata from one farm/environment to another

What?
SharePoint 2010 -2013 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
Powershell for 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;
mmsApp:
Navigate to CA > Application Management > Manage Service Applications > Managed Metadata Service Application



#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;


Fuente: 

http://underthehood.ironworks.com/2011/10/sharepoint-2010-how-to-backuprestore-managed-metadata-from-one-farmenvironment-to-another.html

https://blogs.msdn.microsoft.com/taj/2011/01/11/site-collection-backuprestore-and-managed-metadata/

Comentarios

Entradas populares de este blog

O365 - Forms - Transferir la propiedad de un formulario

Fuente :  https://support.office.com/es-es/article/transferir-la-propiedad-de-un-formulario-921a6361-a4e5-44ea-bce9-c4ed63aa54b4 Si ha creado una encuesta, una prueba o un sondeo, puede moverlos fácilmente a un grupo para que todos los miembros del grupo se conviertan en propietarios de ese formulario. Transferir el formulario a un grupo En el explorador Web, vaya a  Forms.Office.com . En la pestaña  mis formularios  , busque el formulario que desea transferir. Haga clic en  más acciones de formulario    y, a continuación, seleccione  mover . Nota:  Solo puede mover el formulario si es el propietario de ese formulario. No puede transferir la propiedad de un formulario que está compartido con usted. Seleccione el grupo al que desea transferir el formulario y, a continuación, haga clic en  mover . El formulario que ha movido aparecerá en la pestaña  formularios de grupo  . ¿Qué ocurre con el libr...

Event ID 8031 The uri endpoint information may be stale

An exception occurred while updating addresses for connected app {6783ce5e-c88h-4021-8d5b-12614875cbfa_b79f19ab-1d40-4824-9911-3466cf8b070a}. The uri endpoint information may be stale. System.InvalidOperationException: The requested application could not be found.    at Microsoft.SharePoint.SPTopologyWebServiceApplicationProxy.ProcessCommonExceptions(Uri endpointAddress, String operationName, Exception ex, SPServiceLoadBalancerContext context)    at Microsoft.SharePoint.SPTopologyWebServiceApplicationProxy.ExecuteOnChannel(String operationName, CodeBlock codeBlock)    at Microsoft.SharePoint.SPTopologyWebServiceApplicationProxy.GetEndPoints(Guid serviceId)    at Microsoft.SharePoint.SPConnectedServiceApplicationAddressesRefreshJob.Execute(Guid targetInstanceId) After de-commissioning some SharePoint servers, you might notice the above error on other WFEs /Application server’s event viewer . It appears that the SharePoint still has a reference...

SP 2013–2010 - An exception occurred in AD claim provider when calling SPClaimProvider.FillResolve(): Thread was being aborted

  Error: An exception occurred in AD claim provider when calling SPClaimProvider.FillResolve(): Thread was being aborted..   Resolution In order to determine the best MaxConcurrentApi value for your servers, several data points must be brought together and calculated by using a formula. The data to be used to estimate MaxConcurrentApi is as follows: Net Logon semaphore acquires Net Logon semaphore time-outs Net Logon average semaphore hold time Duration of the performance logging that is completed, measured in seconds After the data is obtained, the following formula can be used to estimate the correct MaxConcurrentApi value: ( semaphore_acquires + semaphore_time-outs ) * average_semaphore_hold_time / time_collection_length = < New_MaxConcurrentApi_setting After you collect the Net Logon performance data from when the server was under authentication load, you should determine the duration of the data-collecting process by looking at the Line View beginning and en...