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.