Thursday, March 26, 2020

Searching within Office 365 Groups or Teams content


There are at least three ways to limit the search results within a group or a team using the keyword query language (KQL). These are cases where the managed property used exists on all items for the site/group.


If you know the URL of the groups site you can use a path filter, and remember the trailing slash (/) to avoid edge case inclusion of other data.


Site Id

If you know the underlying site id of the Groups site.


Group Id

If you know the Group Id, meaning the AAD id of the group, you can use this as well.


Bonus: Search within all the groups a user is member of

And here’s the kicker to effectively scope results to all the groups a user is member of. Say you have pulled out a list of all the groups a user is member of via the Microsoft Graph API:$/
?$filter=groupTypes/any(a:a eq 'unified')

Armed with all the group ids, you can issue a SharePoint Search REST query using a wildcard (*) as the query text and the following FQL in the refinementfilters property.



If you are a member of many groups, then I suggest using a POST payload instead of GET, and refinementfilters is not limited by 4k either (at the time of this writing) :)

See for an explanation of refinement filter usage.

Note: How the above syntax will work using the Microsoft Graph Search API which is in beta, is not known at this point.

Photo by Mike Szczepanski @Unsplash

Friday, March 20, 2020

I finally found a use case for the Surface Pen (after 4 years)

I’ve been using Surface Pro’s since the Pro 3 and I know have a Pro 6. I have always liked the form factor of it and each one of them came with a Surface pen. Sure, I’ve tested the pen for fun and used it occasionally to sign something, but in the end I’m a laptop guy, not a tablet guy when it comes to work. So the pens have trustfully followed along in my back back never being used.

Until now that is!

In my home office I have opted to get a speaker phone as wearing a headset for longer periods of time is uncomfortable. The advantage with cabled headsets is that they have a mute/unmute button on the cord, allowing you to sit back and toggle the microphone on and off based on the conversation.

With a speaker phone I can still mute and unmute. Doing so requires me to stretch over to the speaker, not having the button easily in my hand. When using Microsoft Teams, I can use a keyboard shortcut shift-alt-m, but that requires the application to be active and is a bit too quirky.

You probably see where this is going :)

The solution is pretty simple. Being a programmer I browsed around and found out how to programmatically toggle a microphone on/off. You can find the C# code over at (I did look at NIRCMD, but it mutes speaker as well as mic when devices have the same names.)

As the program is a console application, I browsed to the .exe file, and created a shortcut for it as shortcuts can be set to be run minimized. The .exe takes the parameter of a string matching the name of your microphone device (if you have more) or “all” to toggle each one.


The last step is to configure pressing the eraser button on the Surface pen to launch this program.


Now I can relax back in my chair, not touching the keyboard, and mute/unmute myself as needed :)

Monday, March 16, 2020

Modern Script Editor web part now with support for Teams tabs!

Yeah, you got it, you can now use the modern script editor web part as a poor mans solution to bootstrap applications as a Teams tab. And the better approach is to develop a real Teams tab application – just so you know!

I did not really intent to do this, but I had a request to update the web part to SPFx v1.10.0 as some people have issues building SPFx v1.4.1 on their machines. While upgrading I figured I’d do a revamp so I updated the web part with a proper html editor and enabled Teams tab support as well – because why wouldn’t you right? (A shoutout to the PnP team for suggesting this).

Check out the readme from the below link if you want to test the Teams tab support as you need to edit some default settings to make that happen.


Side effect of mapping crawled properties to refinable managed properties

Image by Miguel Perales @ Unsplash

Mapping a crawled property to a refinable one is a common scenario in SharePoint search. If you expect the content behind the crawled property to also be full text searchable, you need to map the crawled property to an additional managed property which is set to be Searchable.


By default a crawled property is full text searchable. Meaning if the property contains the text “pnp is awesome”, then a query for the term pnp, will yield a result.

Once you map the ows_columnName crawled property to say RefinableString00, then the above query will not work as RefinableString00 is not searchable by default, and overrides the behavior of the crawled property. If you query for RefinableString00:pnp as a property query you get results as RefinableString00 is queryable.

If you want the content to be both full text searchable and to be used in a refiner, create a new managed property, for example named TotalRecall, and map ows_columnName to this property as well. Remember that a crawled property can be mapped to any number of managed properties, and something you might want to do especially when mapping them to refinable managed properties.

For crawled properties applying to user profiles you can map to HiddenContents, which acts in a similar way. See for additional details.