Tuesday, December 30, 2014

Limit search results to “Documents”

An often asked question is to have Document Search, where the want is to list documents only - typically Office type formats like Word, Excel and PowerPoint. But the exact answer is not that white/black, and can differ from company to company.

One query you might consider executing to list documents only in SharePoint is IsDocument:true.

This query will return everything SharePoint deems a file or web page.. or not a list item (almost), returning Office documents, images, zip files… you name it, it will be part of the returned result set.

Which brings up the question: What is a document?

Monday, December 29, 2014

Solution to cannot search content in the Description field of a list

See Site descriptions are now searchable!! (and more) for an update on the Description field.

Got the scenario where someone had created a custom list in SharePoint and been so adventurous as to add a custom column to that list named Description. Talk about a bold move!

What happens in this scenario is that the column data is mapped to a crawled property named Office:6, and not ows_description which would be the natural property following the column –> crawled property naming convention. The Office category crawled properties are usually used for metadata coming from inside of Word, Excel and PowerPoint files, not list columns (See this old post from 2008), so I’m guessing an “edge case” bug :-)

Friday, December 26, 2014

The 100% way of automatically updating Result Types (on-prem only)

I have previously written The 100% way of getting your custom managed properties to show in your Display Templates, where after updating a display template with new managed properties you have to go to the Result Type settings page and click the “Update” link in the yellow alert shown. That’s what this post is about -  how to automate the manual click step.


Tuesday, December 23, 2014

How to enable Content Search Web Part Display Templates for Search Result Web Part

By default the out of the box control and display templates have been marked to work with their respective web parts. You can however re-use the templates across both web parts, as long as you ensure any script dependency is fixed. For example the CSWP has a reference to _layouts/15/search.cbs.js which must be added to the page in order for the Search Result Web Part to use the CSWP display templates.

The good thing is that the CSWP display templates are installed even though you don’t have the CSWP available. Here are the steps you need to perform to use the “Two Lines” CSWP display template with the Search Result Web Part.
  • Navigate to site settings
  • Under “Web Designer Galleries” go to “Master Pages”
  • Go to the “Display Templates” folder
  • Go to the “Content Web Parts” and you should see this listing

  • Edit properties on “Control_List.js”
  • Check “Search Results”

  • Click “Save”
  • Apply the same property change to “Item_TwoLines.js”
You have now enabled the display templates for use in the Search Result Web Part, and it’s time to set it up on a page.

Content Search Web Part vs. Search Results Web Part

Want the book? Go get it!

This is the bonus episode in my series “SharePoint Search Queries Explained - The Series”. See the intro post for links to all episodes.

If you have Enterprise license for SharePoint 2013 on-premises or you are using SharePoint Online Plan 2 (Office 365 E3/E4) then you have both web parts available. If you don’t have the E powers, you only have the Search Result Web Part, and this is what I will try to highlight. In what scenarios can you use the Search Result Web Part when you don’t have the license for CSWP?

Monday, December 22, 2014

Video Portal Troubleshooting

A new release without issues hard to achieve and Office 365 Video is no exception. I will explain a couple of typical scenarios which you might encounter.

  • A channel with that name already exists
  • I have renamed my channel, but the channel name is still listed with the old one on the channel listing page

Wednesday, December 17, 2014

S15E11: FAST Query Language (FQL) – The Unwanted Step Son

Want the book? Go get it!

This is the eleventh episode in my series “SharePoint Search Queries Explained - The Series”. See the intro post for links to all episodes.

In the first two episodes of the series I covered KQL and a couple of the new operators introduced with SharePoint 2013 which came from FQL - XRANK, NEAR and ONEAR.
In addition FQL has even more operators, some of them listed below:
  • starts-with
  • ends-width
  • count
  • andnot
  • range
There are also other operators which gives you great control over how a query is being sent over and parsed, and I recommend reading over the samples at FAST Query Language (FQL) syntax reference.

The post title plays at the fact that FQL is sort of hidden away, and no one really talks about it while the underlying search engine (and the refiner UI) in SharePoint (still) uses FQL.

This means KQL statements are translated to FQL before being executed. If this will hold true forever no one knows, but probably until that part of the search engine is being rewritten at some point – and this is good news as FQL has some tricks up it sleeve compared to the polished KQL counterpart.

Monday, December 15, 2014

Irregular gathering of crawled properties with SharePoint web crawls

To pick up data from <meta> tags when crawling web pages:

  • Make sure the crawled markup has line breaks after tags
  • Look in both Web and Document Parser crawled property categories for your crawled properties
  • Register the file extension crawled as the right mime type
  • Add the file extension crawled as the supported File Types


Thursday, December 11, 2014

How to trigger re-indexing of updated user profiles in SharePoint Online

You asked for it, and I deliver an early Xmas present for your pleasure and enjoyment!https://github.com/wobba/SPO-Trigger-Reindex

This script was made possible by the September 3rd release of the CSOM SDK which implements user profile write support. And DO NOT run it from a SharePoint Online Management Powershell, use a regular Powershell with no special cmdlets loaded. If not you get CSOM DLL hell.

Problem: You map an existing (or new) crawled property corresponding to a user profile property to a new managed property you want to use in search (phew). After the mapping, you wait and you wait and you wait (as you cannot start a full crawl yourself in SPO)… and you never get a value in your managed property. You curse some, you Google some, you post some questions in forums or Yammer. Then you go and edit your user profile in the SPO UI, wait some more.. and voila the value is there. You’re seriously baffled at the randomness and think to yourself

How the can I ask my 5,000 users to go edit their user profile to get that new property working in search??

(don’t worry - my script will help you out!)

Monday, December 8, 2014

The right robots.txt settings for allowing SharePoint to crawl your site

If you want you want to allow SharePoint 2010 or 2013 to crawl your web site add the following to your robots.txt file.

User-agent: MS Search 6.0 Robot

Even though the crawler sends Mozilla/4.0 (compatible; MSIE 4.01; Windows NT; MS Search 6.0 Robot) as the user agent string, this is not what you should check against. Logical…. nah, but it is what it is.

Total cost to figure this out: 6h Sad smile

Reference: The SharePoint Server crawler ignored directives in Robots.txt

Friday, December 5, 2014

Tip for working with / troubleshooting search configurations in a production environment

I’m currently involved in a project where we have the typical DEV, TEST, STAGE, PRODUCTION way of deploying. Access wise you can typically view them like this:

DEV God rights!
TEST Demi-God rights!
STAGE Scream over the fence rights!
PRODUCTION Low life employee rights!

So, you’ve created your documentation and deployment packages, gone through all environments and finally handed them over to the PRODUCTION GOD. Hopefully all your meticulous steps have been followed, but alas, something is not working! SHOCKER! <insert scream here>

You have no way to examine configurations, as you can only search as yourself and have view rights.

In SharePoint 2010 you had to go to the SSA in order to view configuration, which was and still is very much hands-off unless you’re sitting in the same room or sharing a screen with the PRODUCTION GOD. In SharePoint 2013 Microsoft came up with this interesting concept that you could change the search settings not only on the SSA level, but on tenant, site collection and site level as well. From the PRODUCTION GOD’s point of view this is still evil as you need site owner rights to view search configurations, and you could potentially quick-fix stuff without them ever knowing – GOD FORBID ;-)

So I came up with this super duper awesome amazing solution which was approved by the powers that be.

Note: Our search configuration is deployed either to the SSA or the Site Collection level, as the search site is hosted at https://search.company.com. No site level configurations.

What I managed to pull off was for them to create a sub-site (any template really) with broken inheritance, where I was added as site owner. The site is also marked not to be indexed to avoid it showing up as a site hit. This effectively allows my regular account to go to that sub-site and view all inherited search configurations on schema, query rules, result sources and result types. If I tried to do a modification on this sub-site it wouldn’t matter at all, as I’m at a lower level than the production site, only messing up locally for that sub-site.

I am now able to troubleshoot and at check the configuration to make a more educated guess as to what the error might be before I engage with PRODUCTION GOD to fix matters.

First fix from this? I discovered some crawled and managed properties was not mapped causing a refiner to not show up – and it ended up being a step missing in the deployment documentation.