Archive for May, 2013

Fixing: “No Two Choices Should Have The Same ID” Error in SharePoint 2010 Lists

May 15, 2013 Leave a comment

I recently ran into an issue with trying to ‘Add from existing site columns‘ to one of my SharePoint lists on a specific SharePoint site.

When doing so I was presented with:


An unexpected error has occurred.
Correlation ID: GUID


Looking up that Correlation ID in the SharePoint 2010 ULS logs I saw this error:

“Unexpected System.ArgumentException:  No two choices should have the same ID at Microsoft.SharePoint.ApplicationPages.ChoiceCompareWithDefaultGroup.Compare”

What this initially told me was there were two Site Columns in my Site that was using the same internal name, and that Site column was associated with my list which is preventing me from adding any additional columns.

By browsing to the Site Collection Site Columns (http://portal/site/_layouts/mngfield.aspx) I noticed under one of my Site Column Groups that there were two Site Columns listed with the same InternalName, Type and Source.

After verifying  that this Site Column was not being used in my List I removed one of the Site Columns from that Site Column Group.

Once I removed that Site Column I went back to my list, and was now able to ‘Add from existing site columns‘ without error.

Hopefully this helps others who have encountered the same issue.

Manage Deletion of Index Items in SharePoint 2010

May 13, 2013 8 comments

In the environment I work SharePoint Search is considered a number #1 service for our customers, so refining the Search Service with quick returns, and limited errors is one of my top priority.

As many might already know SharePoint 2010 Enterprise Search can sometimes become a “pain” in configuring to meet high demands, you sometimes need a full time job with Search just to get it environmentally accepted.

I think i’ve had to completely blow away search 5+ times already in my production environment due to all types of reasons,  and then having to recreate and configure.

With SharePoint 2010 Enterprise Search you might encounter Crawls (Incremental and Full) that return all kinds of errors.  What i’ve noticed is when there is tons of errors in a Search the crawls tends to complete slower, and usually take more time to complete.

My job was to get my Incremental crawls to return results in 15 minutes or less, every 15 mins.  I was able to accomlish this.

One of the major issues that was slowing my crawl rate down was the amount of errors that were returning during each crawl (Incremental and Full).    My farm has over 800,000+ searchable items, which is not a whole lot compared to larger organizations, and was returning 2000+ errors, which is not bad at all.

However having those 2000+ errors was spiking my incremental crawls above the 15 minute return window.

Looking at the Crawl Error Log I noticed that majority if not all the errors I was receiving was due to SharePoint 2010 Crawl not cleaning up deleting items in the Index.

Errors such as (Item not found or Access Denied) were showing up.  By default SharePoint 2010 Enterprise Search cleans up (deletes items) from the Index only  if that item is returned in 30 separate crawls (Incremental and Full) every 30 days.  So even if that item no longer exists SharePoint will still count it towards the crawl results as an error, which in return slows the crawl return rate down.

I wanted to remove these (Item not found or Access Denied) errors but did not want to have to click through every single error in my crawl log and select ‘Remove the item from Index’.  That would take forever.

Luckily in SharePoint 2010 they have now have allowed us to Manage the deletion of index items in search with the use of PowerShell.

Below is how I utilized the PowerShell cmdlt to redefine Enterprise Search deletion policy to fit in my environment.


Deletion policy name String Default value
Delete policy for access denied or file not found ErrorDeleteCountAllowed



720 Hours (30 days)

Delete policy for all other errors ErrorDeleteAllowed



1440 Hours (60 days)

Delete unvisited policy DeleteUnvisitedMethod 1
Re-crawl policy for SharePoint content RecrawlErrorCount



360 Hours (15 days)

Deletion policy name Description
Delete policy for access denied or file not found When the crawler encounters an access denied or a file not found error, the item is deleted from the index if the error was encountered in more than ErrorDeleteCountAllowed consecutive crawls AND the duration since the first error is greater than ErrorDeleteIntervalAllowed hours. If both conditions are not met, the item is retried.
Delete policy for all other errors When the crawler encounters errors of types other than access denied or file not found, the item is deleted from the index if the error was encountered in more than ErrorDeleteAllowed consecutive crawls AND the duration since the first error is greater than ErrorIntervalAllowed hours.
Delete unvisited policy During a full crawl, the crawler executes a delete unvisited operation in which it deletes items that are in the crawl history that are not found in the current full crawl. You can use the DeleteUnvisitedMethod property to specify what items get deleted. You can specify the following three values:

  • 0, all unvisited items are deleted.
  • 1 (default), unvisited items that have the same host as the start address specified in the content source are retained, and unvisited items that were discovered by following links to other hosts are deleted.
  • 2, none of the unvisited items are deleted.
Re-crawl policy for SharePoint content This policy applies only to SharePoint content. If the crawler encounters errors when fetching changes from the SharePoint content database for RecrawlErrorCount consecutive crawls AND the duration since first error is RecrawlErrorInterval hours, the system re-crawls that content database.

$SearchApplication = Get-SPEnterpriseSearchServiceApplication -Identity “<SearchServiceApplicationName>”
$SearchApplication.SetProperty(“ErrorDeleteCountAllowed“, 1) #Set the DeleteCountAllow policy for 1 crawl
$SearchApplication.SetProperty(“ErrorDeleteIntervalAllowed”, 1) #Set the DeleteIntervalAllowed policy to 1 hr.
SearchApplication.SetProperty(“ErrorDeleteAllowed“, 1) #Set the DeleteAllowed policy for 1 crawl
$SearchApplication.SetProperty(“ErrorIntervalAllowed“, 1) #Set the IntervalAllowed policy to 1 hr.

After setting the deletion policy I fired off a new Incremental crawl.  During this crawl the items marked for deletion in my Index were deleted.  After the incremental crawl completed I fired off one more Incremental crawl, and this time my Incremental crawl completely within a few minutes (3 mins) with only 2 errors.