SharePoint 2013 Search ‘InternalQueryErrorException’ in case of sorting on non-sorted property

After deployment plus configuration of an out-of-the-box component in our SharePoint 2013 farm, that component reported a fatal error when used on a SharePoint page:

Microsoft.Office.Server.Search.Query.InternalQueryErrorException: Search has encountered a problem that prevents results from being returned. If the issue persists, please contact your administrator...

As the logged information is very limited / useless, I analyzed the problem by executing the same code in an own Console Application, and via trail-and-error find out what exactly causes the problem.

The problem cause was this:

• In a KeywordQuery, a managed property is added to the SortList parameter collection
• However, that same managed property was not configured as Sortable in SharePoint Search administration

Executing the keywordquery via SearchExecutor.ExecuteQuery() results in the Search Service Application (SSA) throwing the 'InternalQueryException' due the mismatch in Search administration versus Search query/usage.

With this inner knowledge, the quick fix then is to set the managed property as ‘Sortable’ in SharePoint 2013 Search Administration.

Cosmetic extension / modification of AdvancedSearchBox UI

A customer required several modifications wrt to the screen-behaviour of the standaard MOSS AdvancedSearchBox control:

1. Hide the resulttype picker
2. Initial display 3 property-filter rows, instead of the default 1
3. Automatic pre-select in these 3 rows a specific property to filter on
4. For properties with a limited and fixed set of allowed values, let the user select from these via a dropdown control

The changes are all cosmetic, the customer is satisfied with the query construction + evalution of the AdvancedSearchBox.

My first idea was to realize these cosmetic changes by inheriting from AdvancedSearchBox, and overload the rendering of the control. However, this approach is not possible because Microsoft made the class sealed. Effectively this prohibits to address the customer requirements via a server-side resolution. I shortly did consider to re-engineer the AdvancedSearchBox in an own dedicated webpart. However, such is non-advisable: it's no small thing to try delivering the total of the AdvancedSearchBox functionality, and make sure it's tested and robust. And moreover, why should you even build your own control when the SharePoint application platform provides you with this rich control ? Only makes you vulnerable for updates to the SharePoint platform - from service packs and patches, and next year with the upgrade to SharePoint 2010.

So I had to come up with another approach, in which still the AdvancedSearchBox is utilized, but its appearance and UI behaviour is slightly modified. Well, in essence the UI of the control runs within the browser context. Another possible approach is therefore to make the UI modifications on-the-fly clientside, applying JavaScript / JQuery to alter via the Document Object Model. The elegance of such approach is also that it preserves the out-of-the-box SharePoint platform functionality. I'm not allowed to expose the source code. But I can outline the essence:

• attach an own method to the body.onload event
• in this method, use client-scripting to hide the resulttype row, and initially display upto 3 property-filter rows. Pre-select in each row a specific property
• runtime construct via the client DOM a Select object, and position it next to the standard displayed Input element used for entering the filter value
• runtime overload the onchange callback-function of the property Select element, and extend it with logic to either display the standard property-value Input element, or the Select variant in case of fixed set of values for the active selected property
• propagate the selection made in the property-value Select element to the standard property-value Input element

Example of the resulting modified UI + behaviour: