If you have scripted your SSA, make sure the farm account has db_owner on your search db’s, or you may find yourself in a lot of trouble one day!

My musings on Office 365, search, programming and technology.
(June 1st, 2019, I started as a full time employee of Microsoft, thus any post before that date are solely written on my own behalf)
I have previously written about how you via REST can retrieve the Search Center URL for a particular SharePoint site.
If you are already on a page which has a search web part on it, you can get the same value from the page itself with the following command:
Srch.ScriptApplicationManager.get_current().states['searchCenterUrl']
To be clear; when a search web part exist on the page search Search.ClientControls.js is loaded and makes the Srch namespace available.
Got a challenge for a one liner by the strongest man in SharePoint (@tarjeieo) to do this using CSOM as with with SSOM you can set the DisplayFormat property of the field. Using CSOM, this property is not available.
A one liner would be ugly, but the way to accomplish this is to modify the SchemaXml of the field, so you could encapsulate the code below in a function.
Using XML manipulation I ended up with this.
ClientContext clientContext = new ClientContext("https://site/);
Web web = clientContext.Web;
Field field = web.Fields.GetByTitle("DummyNum"); // Field to modify
clientContext.Load(field);
clientContext.ExecuteQuery();
XmlDocument doc = new XmlDocument();
doc.LoadXml(field.SchemaXml);
XmlNode fieldNode = doc.SelectSingleNode("Field");
XmlAttribute decimalAttribute = fieldNode.Attributes["Decimals"];
if (decimalAttribute == null)
{
decimalAttribute = doc.CreateAttribute("Decimals");
fieldNode.Attributes.Append(decimalAttribute);
}
decimalAttribute.Value = "4";
field.SchemaXml = doc.OuterXml;
field.UpdateAndPushChanges(true);
clientContext.ExecuteQuery();
If you create query rules which modify the query on your tenant or SSA level, then you are effectively killing off any such rules on the site collection level.
The below screen shot is taken running a query in the query rule tester. You see the first rule for blog’s is triggered. This rule has been set to stop, as it modifies the query and I want no more processing. You can see the stop flag actually works works, as the next rule is grayed out.
But then a rule from the SSA is showing in blue again, not honoring the Stop flag from the site collection. Ideally it should have been grayed out as well. The reason for this is that if you have more than one rule which modifies your query, then neither is executed (even though the test interface shows so).
In my case the SSA rule is adding an exclusion rule for all search results on Local SharePoint Results. The way to solve this is to create a custom result source on the SSA (or any other level where you need it), add the exclude filter here, and set this source as the default source instead.
Or if the results excluded shouldn’t be used anywhere, mark the site not to be indexed instead.
If you kick off a search query you get some default properties with a document. One of these are DocId.
The managed property DocId is of type text and marked as searchable, and you would assume you a search like DocId=123456 will bring back a result back.
For some reason this does not work. The workaround however is easy.
There exists a managed property called WorkId which is also returned per result, but it’s not visible in the search schema. This property is of type integer with the same value as DocId and you can bring back one item with the following query:
WorkId:123456 or WorkId=123456
You can also do WorkId<>123456 or -WorkId:123456 if you want all items except one item in particular.
Alternatively you can map the crawled property ows__dlc_DocId to a managed property of your choice and use that instead, but no reason to do that since another solution exists.
string siteUrl = "http://dev/sites/search"; ClientContext clientContext = new ClientContext(siteUrl); Web web = clientContext.Web; var nav = web.Navigation; NavigationNode searchNav = nav.GetNodeById(1040); NavigationNodeCollection nodeCollection = searchNav.Children; clientContext.Load(nodeCollection); clientContext.ExecuteQuery(); foreach (NavigationNode navigationNode in nodeCollection) { Console.WriteLine(navigationNode.Title + " : " + navigationNode.Url); }
When I move my computer around I tend to plug in and out different headsets, and Lync more often than not have the wrong one set as the default one. This results in that I a lot of times when on voice calls have to hang up, click the cogwheel icon, then Tools and Audio Device Settings, and pick the right audio device.
I’ve done this ever since Lync 2013 was released… up until today when I discovered a clever icon in the lower right corner of Lync. With two clicks I can now pick my Logitech headset – and hopefully remember to do it before a call starts.
When navigating to OneDrive in SharePoint Online you get a nice list on the left showing your recent documents. The list show documents you have recently used, that being opened/viewed or stored. I suspect this is sort of overlapping with My work in Delve, but different API’s and results.
A recent discussion internally about bringing relevant content to you on your start page, made me dig into this. Put it as part of your intranet home page, or filter the site on any project site, to show your most recent files. It’s all about you!
So, how do you get this list of documents? By using a REST call to the end-point
https://<tenant>.sharepoint.com/_api/me/getrecentdocs
If you add the usual headers of application/json;odata=verbose, you get the data back as JSON. If not, you get it as XML. For me it returned 31 items, more than enough for a good listing.
I just compiled v2.2 of the SharePoint 2013 Search Query Tool which has one major new function: Support to query the Office Graph in Office365 using GQL (Graph Query Language). Many thanks to Barry Waldbaum @ Microsoft for starting the work on this feature, and the joint effort to bring it into the tool.
One way to limit results to the current site collection in for example a result source or search web part is to use the following query template:
{searchTerms} SiteID:{SiteCollection.ID}
Turns out that there is a bug in SharePoint on this (present in both SPO and on-prem at the time of writing) where the ID returned for the SiteCollection is the ID of the root web, not the ID of the site collection itself. As per the MSDN documentation it should return the GUID of the site collection where the query was issued.
The workaround is to use the URL instead of the ID.
{searchTerms} SPSiteURL:{SiteCollection}