I encountered a weird issue while working at a client’s site this week, where we were trying to update the catalog url of some SharePoint Publishing Catalog Connections after we restored the content database from a different farm. The client in question has three SharePoint environments: a Dev one, a Quality Assurance (QA) one and off course, a Production one. Each of these environments had been given a different url. Ex:
| Development | http://dev.sharepoint.contoso.com |
| Quality Assurance | http://qa.sharepoint.contoso.com |
| Production | http://prod.sharepoint.contoso.com |
The client’s SharePoint environment is entirely based on Cross-Site Publishing to display content. They wanted to refresh their Dev environment with a copy of the content from production. So we went ahead and proceeded to refreshing their content database and their Managed Metadata Service database. Because the content was taken from a different environment, the Catalog connections listed still exhibited a Url that pointed to http://prod.sharepoint.contoso.com, so we needed to change this to reflect the dev url.
So to keep things simple, we decided to simply go and delete all existing Connections, and recreate them using PowerShell, but this time having them pointing to the dev.sharepoint.contoso.com url. Upon executing our PowerShell we got the following weird error:
Exception calling “Update” with “0” argument(s): “The object you are trying to create or modify has the same name as another object.
This error seemed to indicate that somehow there was already a catalog connection that existed and that had the same name as the one we were trying to create. However, there were no connections showing up on the Manage Connection page.
One thing I’ve learned from troubleshooting this issue is that SharePoint automatically creates a Search Results Source for every Catalog Connection you define. These Result Sources will be given the name of your Catalog Connection, followed by the word “Results”.
Normally, if you delete a catalog connection, its associated Result Source is also automatically deleted. However, in our case, when we brought back a copy of the production database, somehow a link got broken in the background, and when we deleted the Catalog Connection, the Result Source was still existing. So the solution to our problem was to go ahead and to delete the orphan Result Source at the Site Collection level using PowerShell.
$site = Get-SPSite "http://dev.contoso.com/"
$ssa = Get-SPEnterpriseSearchServiceApplication;
[void][Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server.Search")
$fedManager = New-Object Microsoft.Office.Server.Search.Administration.Query.FederationManager($ssa)
$owner = New-Object Microsoft.Office.Server.Search.Administration.SearchObjectOwner([Microsoft.Office.Server.Search.Administration.SearchObjectLevel]::SPSite, $site.RootWeb)
$resultSource = $fedManager.GetSourceByName("Home - Products Results",$owner)
$fedManager.RemoveSource($resultSource)
* Credits for this PowerShell snippet goes to Sathish Nadarajan
Once the Result Source was properly deleted, we managed to execute our PowerShell to recreate the Catalog Connections without a problem.
