SharePoint 2013 Crawl Log Error: Index was out of range

A customer of mine has installed SharePoint Server 2013 integrated with Project Server 2013. Moreover, they use lots of Search-driven web parts (mini Search Based Apps) to aggregate content across their complex projects.

When using one of these apps, they recognized some of the tasks are missing. Some new tasks as well as some old, despite having Continuous Crawl turned on.

After doing some troubleshooting research on their environment, we found an interesting error message for these tasks. It said: “Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index”

As you can see, besides being integrated with Project Server, this farm is installed in Hungarian language. This makes the story even more challenging, as always 😉

After spending hours and days with troubleshooting, we found the problem was with the Managed Property “AssignedTo”. Afterwards. we were able to reproduce the error on various server and the conclusions are:

The issue is not with Project Server integration. The issue can be reprodured even on “single” SharePoint installations.
The issue is not with Hungarian language. The issue can be reproduced even on English installations.

Table of Content:

1 The Trick…

2 The Advanced Trick…

3 One more Trick in the Trick

4 Side Note

The Trick…

The SharePoint column “AssignedTo” is a multi-value field. This makes sense, every task can be assigned to multiple persons. Therefore, the Managed Property “AssignedTo” in Search is allowed to have multiple values, too. This is its default, out-of-the-box setting.

As soon as we set the Managed Property not to allow multiple values, the tasks can be indexed without any error. The downside of this solution is that the values stored in the SharePoint column “AssignedTo” will be merged into one string in the Managed Property. For example, it’ll have one value like “User1;User2;User3” – one string, values separated by ‘;’ – opposed to the original, multi-value setting when the values are stored as an array in the Managed Property: [“User1”, “User2”, “User3”].

The Advanced Trick…

But we’re not really satisfied with this workaround. Being set to single-value, the Managed Property cannot be used as Refiner, for example.

Let’s create a new Managed Property in Search, with the name “AssignedTo2”. Use the very same settings and the very same Crawled Property mappings as in case of AssignedTo out-of-the-box, allowing to have multiple values. After a full crawl, each of the tasks will be indexed, again! – And now, we have a multi-value Managed Property!

Now, you can even decide to delete the Managed Property. But be careful – you might have some existing applications that use this out-of-the-box property! When deleting it, these applications will be broken!

One more Trick in the Trick

In one of my playground farms, I decided to delete the Managed Property “AssignedTo”. Everything worked fine with my new Managed Property “AssignedTo2”. But I didn’t like its name, decided to rename to “AssignedTo” (as I deleted the out-of-the-box one earlier). And gues what? – The crawling of tasks got broken again!! Setting back its name to “AssignedTo2” (or anything but “AssignedTo”) fixed it again.

Side Note

As the customer’s environment was in production, we could not delete the Managed Property “AssignedTo”. We decided (and documented!) to force using the property “AssignedTo2” in our Search Applications, instead. Tasks are being crawled, life is good.

Related Posts:

Share it:

Twitter Facebook LinkedIn Email