Partager via

Error When Importing Custom Search Configuration Settings - SharePoint 2013

  • Article

Custom Search configuration settings created at the site or site collection scope, such as results sources, query rules, and result types are stored in the Search Service Application.  Therefore when a site or site collection backup/restore, or export/import occurs these settings don't come along for the ride. 

The best, and easiest way to maintain those settings across environments is to use the built-in Search Configuration Import/Export utility within the SharePoint UI.  Details about this process are documented here so I won't cover the process in this post.

What is important in that article, however, is that you meet the following criteria when importing:

  • That the search configuration file and the target for your import do not have settings with the same name, except for managed properties.
  • That the source of your export does not include managed properties or aliases that contain the invalid characters listed in Invalid characters causing the import to fail.
  • That managed property names and aliases are unique within the combination of the search configuration file and the search configuration settings on the target site and its parent site collection.

Also important is this list of reasons the import might fail:

  • If the search configuration file and the target for your import have settings with the same name, the import of the search configuration file fails when it encounters this setting. Exceptions:
  • If you reimport a search configuration file, the settings that have the same name in the search configuration file and on the target do not cause the import to fail.
  • Managed properties with the same name do not cause an import to fail if the individual managed property settings are the same on the property in the search configuration file and on the target property.
  • Managed properties with the same name do not cause an import to fail if the aliases and mappings to crawled properties are different on the managed property in the search configuration file and on the target managed property. The import adds the aliases and mappings on the managed property in the search configuration file to the aliases and mappings on the target managed property.
  • If the search configuration file contains managed property names or aliases that contain invalid characters, the import fails when it encounters that managed property name or alias.
  • The managed property names and aliases of a search schema must be unique for a site and its parent site collection. This means:
  • If your search configuration file has a managed property that has the same name as an alias for a managed property on your target site or the parent site collection of your target site, then the import fails.
  • If your search configuration file has a managed property with an alias that has the same name as a managed property on your target site or the parent site collection of your target site, then the import fails.

So, after trying this process and having it fail I discovered two reasons:

  1. Some of the Managed Properties in my source environment had been set to be Refinable (see above bullet point about the managed property settings being the same).  This resolution was simple: set the target environment property settings to Refinable…Done.
  2. I was getting an error that the "Search Config List does not exist"

This is another one of SharePoint's extremely (un)helpful errors.  So, to the ULS logs I went searching for the correlation, which I found and looked like the following:

[Forced due to logging gap, Original Level: Verbose] Ensuring that SearchConfig List feature is activated.. 080f9f9c-c3c7-00e6-f747-e381d72a7204

Search config settings features are installed. Verifying activation. 080f9f9c-c3c7-00e6-f747-e381d72a7204

Search config settings feature 41dfb393-9eb6-4fe4-af77-28e4afce8cdc was not activated. Activating 080f9f9c-c3c7-00e6-f747-e381d72a7204

Feature Activation: Activating Feature 'SearchConfigFields' (ID: '41dfb393-9eb6-4fe4-af77-28e4afce8cdc') at URL https://site. 080f9f9c-c3c7-00e6-f747-e381d72a7204

[Forced due to logging gap, cached @ 06/27/2014 14:18:26.29, Original Level: Verbose] SQL connection time: 0.0688635008080636 for Data Source=SQLServer;Initial Catalog=Records_Content_DB;Integrated Security=True;Enlist=False;Pooling=True;Min Pool Size=0;Max Pool Size=100;Connect Timeout=15;Application Name=SharePoint[w3wp][2][Records_Content_DB] 080f9f9c-c3c7-00e6-f747-e381d72a7204

The element of type 'Field' for feature 'SearchConfigFields' (id: 41dfb393-9eb6-4fe4-af77-28e4afce8cdc) threw an exception during activation: A duplicate field name "Status" was found. 080f9f9c-c3c7-00e6-f747-e381d72a7204

Feature Activation: Threw an exception, attempting to roll back. Feature 'SearchConfigFields' (ID: '41dfb393-9eb6-4fe4-af77-28e4afce8cdc'). Exception: Microsoft.SharePoint.SPException: A duplicate field name "Status" was found. at Microsoft.SharePoint.SPFeature.HandleProvisioningException(Exception e, Boolean force) at Microsoft.SharePoint.Administration.SPElementDefinitionCollection.ProvisionFieldsAndContentTypes(SPFeaturePropertyCollection props, SPSite site, SPWeb web, SPFeatureActivateFlags activateFlags, Boolean fForce) at Microsoft.SharePoint.Administration.SPElementDefinitionCollection.ProvisionElements(SPFeaturePropertyCollection props, SPWebApplication webapp, SPSite site, SPWeb web, SPFeatureActivateFlags activateFlags, Boolean fForce) at Microsoft.SharePoint.SPFeature.Activate(SPSite siteParent, SPWeb webParent, SPFeaturePropertyCollection props, SPFeatureActivateFlags activateFlags, Boolean fForce) 080f9f9c-c3c7-00e6-f747-e381d72a7204

[Forced due to logging gap, cached @ 06/27/2014 14:18:26.39, Original Level: Verbose] SQL connection time: 0.131371445253517 for Data Source=SQLServer;Initial Catalog=Records_Content_DB;Integrated Security=True;Enlist=False;Pooling=True;Min Pool Size=0;Max Pool Size=100;Connect Timeout=15;Application Name=SharePoint[w3wp][2][Records_Content_DB] 080f9f9c-c3c7-00e6-f747-e381d72a7204

[Forced due to logging gap, Original Level: VerboseEx] Reverting to process identity 080f9f9c-c3c7-00e6-f747-e381d72a7204

Leaving Monitored Scope (Feature Activation: Activating Feature 'SearchConfigFields' (ID: '41dfb393-9eb6-4fe4-af77-28e4afce8cdc') at URL https://site.). Execution Time=202.671079704264 080f9f9c-c3c7-00e6-f747-e381d72a7204

Search config settings feature 41dfb393-9eb6-4fe4-af77-28e4afce8cdc could not be activated. Activation failed with message 41dfb393-9eb6-4fe4-af77-28e4afce8cdc 080f9f9c-c3c7-00e6-f747-e381d72a7204

What this told me is that the SearchConfigFields feature was not properly activating.

I got the ID from the ULS (underlined above) and ran the following PowerShell to manually activate the feature:

$web = Get-SPWeb -Identity https://mysharepointsite

Enable-SPFeature -Identity 41dfb393-9eb6-4fe4-af77-28e4afce8cdc -Url $web -Force -Verbose

The feature activated successfully.  I was now able to import my configuration file!

There wasn't much out there about this particular error, so I hope this helps others that may run into this issue.  Happy SharePointing!

Comments

  • Anonymous
    January 13, 2015
    Another thing to be aware of is that if you don't have your user profile service configured and running it won't work as well. This was an issue I dealt with at a client where we tried to use this feature.
  • Anonymous
    March 03, 2017
    if I use the script with the $web variable, it doesn't work.I used :Enable-SPFeature -Identity 41dfb393-9eb6-4fe4-af77-28e4afce8cdc -Url https://mysite -Force -Verboseit worked!