Export Search Service Application Crawler Settings to PowerShell in SharePoint 2010

If you ever wanted to take a snapshot of your search service application crawler settings in SharePoint 2010 then you already know that there’s no easy way of doing it without writing custom code. Even if you initially deployed crawler settings to your SharePoint farm using PowerShell scripts, chances are that some settings have been updated manually and the current configuration no longer matches the original deployment scripts. The following PowerShell script exports the main properties of Content Sources, Crawl Rules and Server Name Mappings that exist within a search service application. It’s not complete by any means but can serve as a starting point to be customized and extended to match your specific requirements. One thing to highlight is that the script doesn’t simply export the current search crawler settings to a data file but it actually translates your configuration into PowerShell commands that can later be executed to restore crawler settings to the current state.

$ssaName = "FASTContent"
$searchApp = Get-SPEnterpriseSearchServiceApplication $ssaName

$filePath = "ContentSourcesExport.ps1"
"`$searchApp = Get-SPEnterpriseSearchServiceApplication `"$ssaName`"" | Out-File $filePath
Get-SPEnterpriseSearchCrawlContentSource -SearchApplication $searchApp | Foreach-Object {"New-SPEnterpriseSearchCrawlContentSource -SearchApplication `$searchApp -Name `"" + $_.Name + "`" -Type " + $_.Type + " -StartAddresses `"" + [System.String]::Join(",",$_.StartAddresses) + "`""} | Out-File $filePath -Append

$filePath = "CrawlRulesExport.ps1"
"`$searchApp = Get-SPEnterpriseSearchServiceApplication `"$ssaName`"" | Out-File $filePath
Get-SPEnterpriseSearchCrawlRule -SearchApplication $searchApp | Foreach-Object {"New-SPEnterpriseSearchCrawlRule -SearchApplication `$searchApp –Path `"" + $_.Path + "`" –CrawlAsHttp `$" + $_.CrawlAsHttp + " -Type " + $_.Type + " -FollowComplexUrls `$" + $_.FollowComplexUrls} | Out-File $filePath -Append

$filePath = "ServerNameMappingsExport.ps1"
"`$searchApp = Get-SPEnterpriseSearchServiceApplication `"$ssaName`"" | Out-File $filePath
Get-SPEnterpriseSearchCrawlMapping -SearchApplication $searchApp | Foreach-Object {"New-SPEnterpriseSearchCrawlMapping -SearchApplication `$searchApp -Url `"" + $_.Source + "`" -Target `"" + $_.Target + "`""} | Out-File $filePath -Append

The script below can be used to easily delete all of Content Sources, Crawl Rules and Server Name Mappings that exist within a given search service application.

$ssaName = "FASTContent"
$searchApp = Get-SPEnterpriseSearchServiceApplication $ssaName

Get-SPEnterpriseSearchCrawlContentSource -SearchApplication $searchApp | Remove-SPEnterpriseSearchCrawlContentSource

Get-SPEnterpriseSearchCrawlRule -SearchApplication $searchApp | Remove-SPEnterpriseSearchCrawlRule

Get-SPEnterpriseSearchCrawlMapping -SearchApplication $searchApp | Remove-SPEnterpriseSearchCrawlMapping

GAC Multiple Assembly Versions Using SharePoint 2010 Solution Package

Ever wanted to deploy multiple versions of an assembly to the GAC as part of a SharePoint 2010 solution package? Visual Studio 2010 makes it easy to GAC a single assembly version but will throw an error similar to the one below if you try to package a project with multiple versions of a dll, in this case AjaxControlToolkit.dll.

Both "Contoso.SharePoint" and "Contoso.SharePoint" contain a file 
that deploys to the same Package location: AjaxControlToolkit.dll.

The solution is simple and this post walks through it step-by-step.

We start with no AjaxControlToolkit.dll versions in the GAC.

Next, we are going to create a new SharePoint 2010 project in Visual Studio 2010 (or you can use an existing project).

Make sure that “Deploy as farm solution” option is selected.

Then double-click the Package.package in the Solution Explorer and click Advanced in the lower-left corner.

Press Add and select the “Add Existing Assembly…” option, browse to the location of one version of the assembly – in my case 3 different versions are stored in subfolders under the AjaxControlToolkit parent folder. Visual Studio automatically populates the Location field with the assembly name – go ahead an prefix the name with the version number followed by a backslash. Repeat for each version of the dll.

Now all versions of the assembly should appear in the Additional Assemblies grid in Visual Studio.

If we package the project and browse to the pkg folder, you’ll see that each version of the assembly is located in a separate subfolder.

Opening the manifest file also confirms that all assembly versions are included in the solution package.

Go ahead and deploy the solution package and, voilà, all of our assembly versions are now in the GAC!