Wednesday, July 23, 2014

Gotcha on when a Query Rule Doesn’t Trigger

A small heads up if you are creating query rules, and you notice that they won’t trigger. If you include a KQL operator or wildcard as part of your query, the rule won’t trigger.

Consider the screenshots below where the first one shows the wiki block, and the rest don’t. And it doesn’t matter which triggering mechanism you choose, they won’t trigger.

Reading closely on the setup page this is expected behavior:


You can also test this using the SharePoint 2013 Query Tool or the Query Tool test feature on the Manage Query Rule settings page in SharePoint.





Tuesday, July 22, 2014

Custom Search Result Page Layout in SharePoint

You’re messing with the search result page and figure you need a new zone on the page for some cool web parts.

Being an avid SharePoint Designer fan as I am, you open up the site and copy _catalogs/masterpage/SearchResults.aspx to _catalogs/masterpage/SearchResults_custom.aspx. Then you add a new web part zone to the bottom of the page and save the layout.

Next you make the layout available on your site (Bing it) and create a new page based on the layout.

Boom! – Code blocks are not allowed


Turns out the fix is pretty easy as the file actually has code blocks in it.


Simply remove the <% %> parts which does conditional checks for the Ribbon being hidden if the user is in Browser mode (not Design, Catalog or Edit mode)

You can probably implement the check yourself in JSOM if needed, or simply show/hide the ribbon in all modes.

So, how come the default layout works with code blocks? Well.. SharePoint does whatever it wants with the default pages and can configure SharePoint to work as it pleases. Being an outsider you don’t have those powers.

Monday, July 21, 2014

Better Best Bets with Lists

imageBest Bets or Promoted results is a great way to give end-users the answer to their search query without the additional click to open a page or document to locate the precise information they were looking for. Bing and Google already have many examples of this if you for example look for weather information or currency conversion.
Head over to the Microsoft MVP Award Program Blog, and read more about how you can improve on SharePoint’s built-in solution!

Wednesday, July 9, 2014

July 2014 CU for SharePoint 2013 released–with a search feature long lost from 2010

You may now install custom PDF iFilters again, like the one from Foxit or Adobe! In SharePoint 2010 you could install any iFilter you wanted for text extraction and the most common to install was for PDF documents. With SharePoint 2013 this was replaced by an internal file handler instead, which could not be overridden.

With the July 2014 CU for SharePoint 2013, you can yet again install your custom PDF iFilter, or override any built-in handler to use the iFilter of your choice.

Friday, July 4, 2014

Mikael’s best practice for managing Managed Properties in SharePoint 2013/SPO–and how to deal with dates

I’ve had this on my mind for a while, but  Waldek Mastykarz post “Inconvenient Managed Properties and getting a list of all custom Managed Properties in SharePoint 2013” triggered me to share my thoughts.

To sum up Waldek’s posts, he shows a neat way to use PowerShell on-premises to filter out all non-system defined managed properties. The disadvantage is that the list will also include all managed properties auto generated from site columns. And you cannot use it for SharePoint Online.

One of the lacking points with the auto generated managed properties, is that they are of type text, even for date time values. If you want to filter on date ranges you need to use a managed property of type Date and Time which is sortable, and not a text property. As Waldek points out, the re-usable properties of RefinableDateXX are lacking as they return a string object and not a date object. They work for filtering, but in a Display Template they suck. This argument is used by Waldek to point out that you end up creating custom managed properties to deal with for example dates – and the argument is quite valid and not a bad one. Because Waldek is a pretty darn smart guy if you haven't noticed and his blog is certainly one to follow.


What makes a SharePoint column searchable?

By searchable I mean a user searches for a term, and get a search result if that term exists in a SharePoint column (without specifying a property query). Basically typing keywords in a search box.

By default when you create a SharePoint column on a list, it will generate a crawled property which is marked with Include in full-text index. This checkmark ensures you will get a hit for terms in this column. The naming of the crawled property is ows_internalColumnName.

If you look at managed properties, they have a corresponding property called Searchable. This means if your crawled property is mapped to a managed property marked as searchable, you will get recall on the column. However, if the managed property is not marked as searchable, even though the crawled property is marked with “Include in full-text” index, it will NOT be searchable.

To put it all in a table.
Crawled Property Managed Property
Included in
Full text-index
Not included in
Full text-index
Searchable Not
x x
x x
x x
x x


If a crawled property is mapped to two managed properties, where one of them is searchable, then the value will be searchable.

If a column is hidden or marked via column properties as "NoCrawl", then it will not be searchable.

If the crawled property is from a number/currencly column, you need to map it to a searchable managed property in order to get full text index recall.


In order to make a column in SharePoint not searchable, you either have to uncheck the option on the corresponding crawled property to include it in the full-text index, or map it to a managed property which is not marked as searchable.

Check out Benjamin Niaulin's post Understand SharePoint Crawled and Managed properties for search for more information on crawled and managed properties.