Recently, as part of a customer proof-of-concept, I configured the content by search web part in a SharePoint Online publishing site to consume and display content from Office 365 Video.

Office Video is a really cool video platform available in Office 365 that allows users to publish videos, organize them within channels and share them across an organization. To get the most out of that service, it is important for users to be able to consume videos from outside that portal. In July (2015), the product team started rolling out the ability to embed Office 365 Video outside of the portal. This means that we can use that content to provide richer experiences in other SharePoint (and beyond) applications, including intranet portals, team sites, etc.

Naturally, I immediately started thinking about how I could surface videos through search and then use the video embed to display them on a SharePoint site page. The content by search web part is a natural fit here because I can provide a dynamic query and also customize the display of the results.

It is worth noting that Office 365 Video has its own API but this does not provide a search capability.

Configure CBS Query

The first step was to define the query. For that, I had to inspect some of the Office Video items in search results so I did some targeted queries using the SharePoint Search Query Tool. In my environment, I discovered that SharePoint online was classifying these videos as contentclass: sts_listitem_851. I also discovered the pattern for the path to the various site collections that represent the channels in Office Video: http://tenantname.sharepoint.com/portals/channel-name

Ultimately, my query in the CBS looked like the following:

contentclass: sts_listitem_851 path:{\Site.Url\”"}/../../portals/Executive-Briefing

where “Executive-Briefing” was the name of my channel. I could have removed “/Executive-Briefing” to search across all videos across the service.

Configure Display Template Managed Properties

In addition to the standard properties I need to display, like title and description, I also wanted to grab some media-specific properties as well as a few properties that would allow me to dynamically build the embed link. Below is a mapping of logical property to the property name in search:

• Video Id: UniqueId
• Site Id (channel id): SiteId
• Thumbnail Url: PictureThumbnailUrl
• Video duration: MediaDuration

Build Video Elements of Display Template

With the right query and the right properties, I composed my display template so each video result had the title, thumbnail and video duration. Using the Foundations Responsive Framework, I created modal popups that actually played the video.

Because I didn’t want to make a call to the actual video API to get the embed code, I built the embed code dynamically:

var videoEmbedUrl = “portals/hub/_layouts/15/VideoEmbedHost.aspx?chId=” + SiteId+ “&vidId=” + UniqueId + “&width=640&height=360&autoPlay=false&showInfo=true”

Keep in mind, the format of the embed URL is not officially documented so it could change. Ideally, the Office Video team would include this as one of the properties returned in search.

Other Ideas…

• Consider combining the above search with Graph Query Language to leverage the power of the Office Graph to return the most relevant video to the specific user

Another off-topic post but one that serves as an addendum to my previous post. Customers continue to wrestle with this and it is something the Office PnP team tends to address theoretically but not practically so I wanted to provide some more practical guidance.

As a matter of fact, just recently the PnP team posted this video about how to apply branding without customizing the SharePoint Online master page and it also provides a lot of guidance about when it is appropriate to customize your master page in SharePoint Online. One point they made which I found particularly noteworthy is that the guidance about when to customize a master page has not changed that dramatically. Microsoft has always encouraged companies to create custom master pages only when it made sense and they had identified requirements that dictated the need. The main reason for that is upgrades. Anytime you had to upgrade SharePoint on-premises, you had to go through a remediation process with the master pages as well as any other customizations. It’s the same with SharePoint Online. The difference with SharePoint Online, however, is that the upgrades are happening all the time. That’s not to say the master page is changing every time there is an update to the SharePoint Online service but there could be and that’s what this blog post is about.

My previous post was more tactical as to the particulars of doing an isolated comparison and roll out of those changes. This blog post is about how we manage the on-going process of checking for updates in the service and applying those updates to our custom master page. Below are the key components to this process.

Capture current state

The first thing you need to do is download the default master pages available in SharePoint Online. At the time of this writing, that includes oslo.master and seattle.master. Add these files to your favorite source control repository.

Create your custom page

Of course, this article is moot unless you actually create your custom master page. Using one of the defaults as a baseline or using a bare bones master page, create your custom master page but do not overwrite the existing ones. Make sure you give your custom master page a unique name (e.g. contoso.master). If you simply overwrite the out-of-the-box master, your changes will/could get overwritten by O365 you will have no way of determining what has changed because your the master page will now be "unghosted" and will not take updates from the service. Once you've created your custom master page, assign it as the master page for your site collection.

On-Going Master Page Evaluation

Go through the following steps on a periodic basis. I would suggest quarterly at least, but monthly might be more logical depending on the level of customization and adoption.

• Download a copy of oslo.master and seattle.master from your site collection in SharePoint Online. This will be the latest deployed to your tenant in Office 365.
• Update it in your source code repo as a new version
• Compare your new version with the previous version using your favorite diff tool. I use Visual Studio Online for source control so I am able to do a diff of different file versions directly within the browser console of the tool. My previous post talked about WinDiff and either of these as well as many others could work just as well Note any of the changes to the out-of-box master page since the last version

The example above is not really what I had to deal with.  In actuality, once I wrapped my mind around the elements of the master page, I think I made less than 10 line changes (excluding comments) to update my master page to reflect changes in the service over a 2-year period

• Determine if those changes impact your custom master page
• If those changes do impact your custom master page, update your master page accordingly

Notes:

• As mentioned above, master page changes from the service can impact your pages primarily in two ways:

1. 1. A feature might get added to the suite nav or some other global element of the default master page that your site won’t see. With our portal, it was the new app launcher. When that rolled out, we were stuck on the old horizontal menu.

   2. The default master pages might add code components (JavaScript or CSS includes) that are contingencies for other existing scripts. The result might be broken features on your master page without any clear idea as to why they’re broken.

• One of the primary things that keeps changing in the SharePoint Online master page is the Office 365 suite navigation, including the app launcher. From what I can tell, most of this rendering is done dynamically with JavaScript so as long as they continue to rev the referenced code and nothing specific in the master page itself, you will most likely stay fairly up-to-date there without any work of your own. As a matter of fact, I am hoping that is a model they move to more broadly for providing updates to these master pages.

Thank you to @Bob1German for his review of this content.

First, your mileage will vary with the specifics I provide here. Depending on the point in time you customized your master page and the customizations you made to it, you may have to do a deeper analysis. However, I hope you will benefit from the process I followed.

Before

The Process

The first thing I did was download the latest master page from a new site collection in SharePoint Online and compared it with our customized master page using WinMerge. This was pretty tedious and as someone who has only done limited customizations of master pages, it proved not to be very effective. My breakthrough came when I was pointed to this CodePlex project by Randy Drisgill. In this project, he dissects and labels the various elements of the master page. The samples he provides aren’t up-to-date with SPO but they still helped me decompose the elements of our master page and compare that to similar sections of the latest master page I pulled from SPO.

Ultimately, I zeroed in on the HTML div with the id=’'suiteBar” in both master pages. In the latest version, you’ll see that this div is wrapped in two SharePoint custom controls, AjaxDelta and FlightedContent. The latter really caught my eye.

Once I picked these notable discrepancies out, I reviewed the markup within them and felt pretty confident that I could essentially replace everything within the suiteBar div with the content contained in, and including, the SharePoint custom control, AjaxDelta. I also had to register the following two tag prefixes:

<%@ Register TagPrefix="wssucmui" TagName="MUISelector" Src="~/_controltemplates/15/MUISelector.ascx"%>

<%@ Register TagPrefix="wssucw" TagName="Welcome" src="~/_controltemplates/15/Welcome.ascx" %>

Roll Out

The development process for Office 365 is still an evolving story. Some companies are using separate tenants for dev, test, etc. while others are simply leveraging separate site collections within their tenant. For this, I am using a separate site collection, which serves my needs pretty well. I was able to configure a new site collection with the customizations from our production site collection by exporting a design package from the production site collection and importing it into the test environment. This created an apples-to-apples environment for testing. I copied the updated master page over the custom one and the new suite bar appeared.

After

For our next step, we’re going to push the update into one of our other affected production site collections and let users hammer it. Since this is only a subset of our sites, if there are issues that we have not yet discovered, hopefully the impact will be minimal. Once we’re comfortable there, we’ll push to our other five or six site collections. Unfortunately, our main site collection is also our most complex so we’re going to push there last and dedicate time for our internal team to hammer at it and identify issues before the general user base gets at it.

Hope this helps. Any questions, comments or feedback are welcome.

On Friday afternoon, Dan Benson and I will be presenting on SharePoint Search architecture. We are going to talk about how you can ensure your enterprise search capabilities can scale and be available all the time. Please don’t read too much into our timeslot. With the awesomeness of Office 365, this might seem like a moot topic but the reality is that most enterprises still require some investment in their on-premises architecture to support legacy applications and content that is not quite ready for the cloud. SharePoint Search provides the most robust bridge through its hybrid capabilities to ensure a seamless user experience for accessing on-premises and cloud content. So, please come join us to learn how your on-premises infrastructure can scale to meet the demands of your business!

In advance of the presentation, I wanted to post some of the materials we'll be showing. Specifically, we'll be walking through a few different PowerShell scripts for defining and deploying your initial search topology and then expanding that initial topology to support the growing demands of your business. Additionally, we built a simple JavaScript tool for monitoring the health of your search system. For all of these, the code is simple at best, flaky at worst so please use at your own risk. However, we are typically asked for access to the code we show during our presentations so I thought I would provide it in advance rather than accepting a bunch of business cards and losing track of my promise to post the code later.

If you're not attending this week, please look for our presentation on Channel9 once the conference is over. I will try to update this post with a direct link once it is available.

Both the PowerShell scripts and search monitoring code are accessible on this OneDrive share.

For the search monitoring code, I plan to follow this post up with another post detailing how to deploy it. Bear in mind that it references 3rd party libraries but those are not included in my downloads. Also, the SP.Search.js code is something I’ve been working on here and there for some time. It’s also accessible on GitHub here. At this very moment, the code I posted to my OneDrive might be more up-to-date than the GitHub repo.

I'm excited about our presentation on Friday and for those of you still in town, I hope you'll stop by to see us. Last, if you're interested in any of my insights as an attendee, feel free to follow me on Twitter.

In this post, I will show you how to build a custom display template using a federated result coming from an OpenSearch source.

OpenSearch Result Structure

As I started to dive into this, the first question I had was what managed properties are returned when going to an OpenSearch source? Using the search query tool, I was able to see that the default MP’s returned with a federated result are:

• HitHighlightedSummary
• LastModifiedTime
• OpenSearchSingleResultXML
• Path
• piSearchResultId
• RenderTemplateId
• ResultTypeId
• Title

The two most interesting properties in my opinion were the HitHighlightedSummary and the OpenSearchSingleResultXML. The former, also known as the dynamic teaser, should provide a snippet of the content that is relevant to the query. In my observation, however, it’s really just a snippet of the first sentence of the article so not a true dynamic teaser. The latter MP provides some raw XML about the document. Worth noting is that the HitHighlightedSummary seems to match the description sub-element of that XML.

This XML provides two other elements that I think might provide some value to our result display.

1. PubDate: While this is repeated in my LastModifiedTime managed property, it’s already nicely formatted for me in the raw result.
2. News:Source – This provides me with the source of the content. Certainly this will be interesting to our user.

Now that we know what our data looks like, let’s get to work building a custom display template.

Initialize Your Template

Go to the Design Manager and select Edit Display Templates. This will provide you with a list of display templates that are already deployed on your system. Download one of the existing templates and start by editing that. I would suggest choosing a simple template (Item_TwoLines is a good one) and working off of that.

Now that you have a template, the first thing you need to do is include the relevant managed properties in the template to ensure they’re available in the template.

<mso:ManagedPropertyMapping msdt:dt="string">

'Link URL'{Link URL}:'Path','Line 1'{Line 1}:'Title','Line 2'{Line 2}:'',

'FileExtension','SecondaryFileExtension','OpenSearchSingleResultXML'

</mso:ManagedPropertyMapping>

Feel free to modify the other MP’s in this mapping as well but for the sake of this post, we’re primarily concerned with including the OpenSearchSingleResultXML managed property.

Now that we have that, we want to crack it open and get the information we need out of it using JavaScript from directly within our template. Here’s some sample code (relies on jQuery):

var osxml = $getItemValue(ctx, "OpenSearchSingleResultXML");  xmldoc = $.parseXML(osxml.value);
$xml = $(xmldoc);
$newssource = $xml.find("News\\:Source");
$newsdate = $xml.find("pubDate");
 
var thenewssource = $newssource.text();
var thenewsdate = $newsdate.text();

In the first three lines of code, I use jQuery to create a DOM object out of the XML returned in the search result’s OpenSearchSingleResultXML field. Then, I can use standard jQuery lookup mechanisms to find the element of the DOM I need. You’ll notice that to get the news source, I had to escape the colon character with double back slash.

The final step is to render these data elements in the template display:

<div class="cbs-Detail" id="_#= dataContainerId =#_">
    <div class="">_#= thenewssource =#_</div>
    <a class="cbs-Line1Link ms-displayBlock" href="_#= linkURL =#_" 

title="_#= $htmlEncode(line1.defaultValueRenderer(line1)) =#_" 

id="_#= line1LinkId =#_">_#= line1 =#_</a>
    <!—#_     if(!line2.isEmpty)     {         _#—>
        <div class="cbs-Line2" 

title="_#= $htmlEncode(line2.defaultValueRenderer(line2)) =#_" 

id="_#= line2Id =#_">_#= line2 =#_</div>
        <!--#_     }     _#—>
    <div class="">_#= thenewsdate =#_</div>
</div>

And that wraps it up. Now all you need to do it copy this template back into the Display Template library where we got it.  You should rename the file so that it doesn’t overwrite the original template you copied and I suggest modifying the Title tag of the template so you can distinguish your new template from the original as well. I suggest something meaningful that describes the template, like “Open Search Bing News Item”.

I haven’t included additional details on the plumbing required to deploy display templates themselves. This blog post on Steve Peschka’s Share-n-dipity blog provides a pretty robust explanation of that process.

Here are a few tips to help manage your expectations:

1. You have limited control over managed properties in SharePoint Online. For instance, you cannot create managed properties in SPO that are refinable. You have to use one of the out-of-box MP’s that are refinable. Luckily, there are a lots of them. From the managed property screen, search for “refinable” and you’ll get a list covering all data types.
2. Indexing latency in SPO is variable and unpredictable. This is particularly an issue with testing but can also be an annoyance if, for instance, you’re inputting data on one screen and using search to retrieve that data on a subsequent screen. For retrieval of smaller data sets, still go at the list API’s. For larger sets of data, hopefully this indexing latency won’t impact you too much.
3. When building a SharePoint-hosted app that runs in your SharePoint Online tenant, search requires tenant-scoped permissions. This means you must be a tenant admin to deploy the app. Many IT organizations might not allow an app to have this level of permission. Hopefully, we’ll see updates from the product that improve this situation.

That’s it for now. I’ll update this post as I am able to identify and document other issues.

In the next few posts, I plan to do with a blog what I apparently couldn’t do while presenting to 500 people in Las Vegas: give the reader a foundation for consuming SharePoint search from their SharePoint 2013 (or Online) apps using JavaScript and the SharePoint REST API. The goal of this is not to create a conversation about how to use search in interesting ways. Rather, I want to provide a technical foundation so those that find those interesting ways aren’t starting from scratch. I probably won’t get every last nuance covered so please provide your feedback and questions in comments. And, to reiterate expectations properly, this set of posts will focus on using JavaScript and REST to build a SharePoint-hosted app.

The subject of this first post will be creating some core object model components and getting search results back.

The first thing you need to know  is that there really is no JavaScript Object Model (JSOM) API for search. You, we, have to build that OM around the REST API.

The Search JSOM that we want to build will contain the following:

• The query parameters accessible to us when submitting a search via the REST API
• The actions, or methods, we can execute when actually submitting that search
• The components of the response that we need to render our UI, including refiners, result blocks, etc.

First, I want to start by showing the targeted simplicity of our application logic code that will call this Search JSOM. If we’re building a simple results page, it can be as simple as the following:

var theQuery = new Query();
theQuery.SPSite = "https://my.sharepoint-site.url";
theQuery.QueryText = $('#searchBox').Value;
 
theQuery.RunSearch(
	function (results) {     alert(results);
	},
	function (error) {     alert(error);
	}
);

Of course, there is some nuance in there which I hope we will make clear in this or subsequent blog posts but as you can see, with an API, we hide a lot of the complexity of the search call and response processing.

Now that we know what our basic search call should look like, let’s start building this Query object in JavaScript by creating a JavaScript file called “SP.Search.js” and adding the following code:

function Query() {        

var self = this;        

self.SPSite = "";             

self.SearchApiPath = "/_api/search/query"        

self.QueryText = "";       

self.SourceId = "";             

self.SortFields = "";       

self.SelectProperties = "";            

self.Refiners = "";       

self.RefinementFilters = [];            

self.RankingModelId = "";       

self.StartRow = 0;       

self.RowLimit = 10;            

self.EnableStemming = "true";       

self.EnablePhonetic = "true";       

self.EnableFQL = "false";            

self.EnableQueryRules = "true";            

self.RequestMethod = "GET";       

self.RequestContentType = "application/json;odata=verbose";     

This code encapsulates the query parameters we can submit to the search engine via the REST API. It’s not 100% exhaustive but it hits the critical query parameters. It also sets some defaults for less-often used parameters.

For a full list of the query parameters available via the REST API, please check out Nadeem Ishqair’s EXCELLENT blog on the topic. I’m not going to go through the effort of explaining each parameter as Nadeem’s blog does that already. However, if you need clarification, please do not hesitate to post to comments.

Once I have the set of parameters to submit to the search engine, I build an HTTP request string to send off to the REST end point. I do that in the BuildQuery method. However, the API client doesn’t really need to know much about this method. This is an abstraction that my API provides but I show it here for your understanding (and feedback):

self.BuildQuery = function () {            

    var queryExpr = "querytext='" + self.QueryText + "'";            

    queryExpr += "&selectproperties='" + self.SelectProperties + "'";            

    queryExpr += "&refiners='" + self.Refiners + "'";                     

    if (self.SourceId != "") queryExpr += "&sourceid='" + self.SourceId + "'";                     

    if (self.SortFields != null && self.SortFields != "") queryExpr += "&sortlist='" + self.SortFields + "'";                    

    if (self.RefinementFilters.length > 0) {                            

        var refinementStr = "&refinementFilters='";                            

        for (var i = 0; i < self.RefinementFilters.length; i++) {                   

            if (self.RefinementFilters.length > 1 && i == 0) refinementStr += "and(";                   

            if (i > 0) refinementStr += ",";                                    

            refinementStr += self.RefinementFilters[i].PropertyName + ":ends-with(\"" + self.RefinementFilters[i].GetDisplayString(self.RefinementFilters[i].FilterValue) + "\")";               

        }                            

        if (self.RefinementFilters.length > 1) refinementStr += ")";               

        queryExpr += refinementStr + "'";           

    }                    

    queryExpr += "&startrow=" + self.StartRow;

    queryExpr += "&rowlimit=" + self.RowLimit;     

    queryExpr += "&enablefql=" + self.EnableFQL;    

    queryExpr += "&enablequeryrules=" + self.EnableQueryRules;           

    queryExpr += "&enablephonetic=" + self.EnablePhonetic;           

    queryExpr += "&enablestemming=" + self.EnableStemming;                    

    return queryExpr;       

};

There is quite a bit of logic going on this. I hope the reader can follow most of it. What might be a bit confusing is the 10 lines of code starting with if(self.RefinementFilters.length…. When we submit refinement filters to the search engine as part of a REST call, it must be formatted as a valid FQL expression. This is an odd requirement for a number of reasons, least of which being the fact that the default query text language is KQL. However, it’s required nonetheless and it happens to surface a lot of potential (a topic for another post -- sorry).

Moving on, the next thing we need to do is actually make a call to the REST endpoint. The following code does that using a standard JQuery AJAX request:

self.RunSearch = function (successFunc, failureFunc) {            

     var queryParamStr = self.BuildQuery();                     

     var searchUrl = self.SPSite + self.SearchApiPath + "?" + queryParamStr;                     

     $.ajax({

                url: searchUrl,

                type: self.RequestMethod,

                contentType: self.RequestContentType,

               headers: {

                   "Accept": self.RequestContentType,

               },

               success: function (data) {

                   var theSearchResults = new SearchResults();

                   theSearchResults.RawJson = data;

                   theSearchResults.BuildResultObject();

                   successFunc(theSearchResults);

               },

               error: function (data) { failureFunc(data);}           

    });       

};

The data argument submitted to the success callback function is a big JSON object representing the response from the search engine. That success function does a number of things, including calling methods to deserialize the response as well as invoke the callback method that is passed into the RunSearch method itself. All topics for the next post.

If you are an experienced SharePoint App developer, one thing that might surprise you is that this code does not leverage the RequestExecutor to handle the cross-domain call. Well, search happens to be somewhat unique in this respect in that it can make a call to the local domain (the App Web) and still consume the farm/tenant’s search service. This is because search is a service that spans the entire farm/tenant scope. All that said, I plan to refactor this code to use the proper cross-domain calls, mainly to account for the variety of scenarios and code reuse objectives that might surface. I’ll make sure this post reflects those code updates.

The core objective of this post is to start to build the foundation for a JavaScript object model API for SharePoint Search (2013 and Online). In this post, we defined the basic properties of a Query that reflect a search as well as the methods used to actually make the call.

In my next post, I will talk about how to take that JSON response, process it and return it to the calling application so that the data can be rendered for the user.

Did this post help you? What additional detail are you looking for? Please provide feedback, good and bad, so that I can refine and improve the content going forward.

P.S. I am still trying to figure out why my code sections have all the lines. I beg your patience.

Update: I have been able to get properly formatted code but have lost line numbers. Gonna live with that for now. No other updates to this post.

1. Edit the item
2. Go to the List Settings –> Advanced settings page and click on the Reindex List button

Then you get to wait around for it to be indexed.  Sometimes that can be quickly, other times not as quick.

While waiting around one day and playing with pulling all the managed properties for my documents I ran into another interesting managed property called CrawlTime.  This one doesn’t come up if you search for it on the Managed Search Schema page, but it is there:

Through some playing around with it I’ve determined that it is a date type property that is retrieve-only which is a bummer because being able to filter or sort your results by the date crawled would be very handy!

Nonetheless, it is better than nothing and applying a little PowerShell we can easily report on the indexing latency.   Like we did for the managed properties, run your query in the Search Query Tool and then copy the json off of the Raw tab.  Then run this in PowerShell:

$obj = ConvertFrom-Json (Get-Clipboard)
$results = $obj.d.query.PrimaryQueryResult.RelevantResults.Table.Rows.results
foreach ($r in $results) {
    $title = ($r.cells.results | ? { $_.key -eq 'Title' }).Value
    $path = ($r.cells.results | ? { $_.key -eq 'Path' }).Value
    $modified = Get-Date ($r.cells.results | ? { $_.key -eq 'Write' }).Value
    $crawled = Get-Date ($r.cells.results | ? { $_.key -eq 'CrawlTime' }).Value
    $delta = $crawled - $modified
    write-host $title
    write-host " Modified: $modified"
    write-host " Crawled: $crawled"
    write-host " Index latency: $delta"
}

You should get a report that looks something like this:

The first item took a little over an hour to index while the last one was just under 30 minutes.  Note that the ones with the really long delay were indexed by a Reindex List request and therefor the indexing latency isn't applicable (because the items haven't changed so the modified time didn't get updated). 

The PowerShell would be easy to adapt for other purposes.

Another idea I had was to create a tool that would periodically (every 10 minutes?) modify a list item and search for it.  Using the CrawlTime one could build a fairly accurate chart showing SPO indexing latency :)

SharePoint 2013 has a managed property called "ManagedProperties" that can be used instead. The ManagedProperties managed property is populated with the names of all the managed properties that have values for that document. The only trick is that this managed property is not retrievable, it can only be used as a refiner. 

You could add this refiner to your search center, but I have found it much more useful to explore using the SharePoint 2013 Search Query Tool and PowerShell.

To get started, download and fire up the Search Query Tool. Authenticate with you site and set up a query that returns the document(s) you are interested in.  Open a PowerShell window.

In the Query block of the Search Query Tool application configure the Refiners to be

managedproperties(filter=600/0/*)

and re-run your query. On the Refinement Results tab you should now see the managedproperties refiner that will have a big list of refinements. For example:

Scrolling through this list can often be helpful in itself, but sometimes it is nice to be able to see the values of all these managed properties and hand cutting-and-pasting can be quite cumbersome. The following technique can be used to make things much easier.

Go to the Raw tab and at the bottom you will see a big bunch of JSON like:

Select and copy all of the JSON. Now open PowerShell:

$obj = $obj = ConvertFrom-Json (Get-Clipboard)
$r = $obj.d.query.PrimaryQueryResult.RefinementResults.Refiners.results | `
         ? { $_.name -eq 'managedproperties' }
$names = $r.Entries.results | % { $_.RefinementName } | sort
$names -join "," | Out-Clipboard

And now you can paste the list of mps separated by commas. Go back to the Search Query Tool and paste the list into the Select Properties box and run your search again. On the Primary Results tab you'll now see all of the (retrievable) managed properties. (Note: some managed properties still won't have values because they have been configured to be non-retrievable.)

The neat thing is the “Other Value” which allows users to enter their own values here that might not appear at the top of the refinement list.  So in the next example, Apply will find results that match Audit, CPO or Tax

This works all well and good until you try it with a managed property populated from the Managed Metadata Term Store.  Now the checkboxes will work but the Other Value will always return no results, even if you enter in the exact value that you see in the top refinement results.   The reason for this is that the data in the refinement values is actually the unique identifier from the taxonomy

and the Other Value is being searched for using the Equals() operator.     You can see this by decoding the URL generated after clicking on Apply.   Just clicking the “HR” check box shows that it is searching for the id portion only:

while entering “HR” into the other box uses the equals() operator:

which clearly won’t match.

There is a workaround however.  In the Filter_MultiValue_Body.html template there is an option to override the equals to instead just searches for the string:

I haven’t (yet) figured out how to set the csr_useContains on the refinement control, but overriding the useContains variable in the template itself is easy enough and gets the job done:

The only downside of this is that you could run into situations where you match more than you’d intended.  But you can use wildcards which could be handy.