I have created a user “Robert Dylan” and never used name “Bob”, but search understands that I’m looking for Robert Dylan when I’m searching for Bob or Bob Dylan or Bobby.
Important thing – result is shown under “All” and “People” verticals.
I know Microsoft claimed m365 search is backed by Turing technology – it understands you, answers your question but not just blindly display keyword occurences (announcement at Ignite Spring, more on Ignite Fall 2021)… So is that it?
But the same trick did not work with Dick for Richard or (of course) Syd for Roger Barrett:
Using Path property in Microsoft 365 Search Query was kind of ambiguous. But now Microsoft implemented update and clarified some details. So below are some tips and tricks on filtering by site Url (path) in query field in Microsoft 365 Search verticals.
Path filter with trailing slash (“/”)
In November 2022 Microsoft rolled out an update for multiple search features, including checks on the path managed property for a trailing slash. Previously path filters were valid with and without trailing slashes.
Consider the following scenario.
Given the path filter with the contain operator (“:”)
SPSiteUrl and Path properties use different matching strategies. When using contains operator (colon sign “:”) – SPSiteUrl will match the full value, while Path will do a “starts with” match.
DepartmentId
DepartmentId is a search managed property used under Hub sites and propagated through all associated sites content.
That means if we want to scope down search to hub site with it’s content – we can use DepartmentId property, e.g.
DepartmentId=4965d9be-929b-411a-9281-5662f5e09d49
instead of iteration through all hub sites and using path: property.
where you can use objects: “Site Url”, “Site Name” and “Refinable String 0″..”Refinable String 99”. Conditions would be “is equal to”, “is not equal to”, “starts with” and “not starts with”. Or you can select “Advanced query builder” and enter KQL query.
Advanced query builder
Advanced query builder allows us to use more site properties then “Site Url”, “Site Name” and “Refinable Strings” and more conditions than “is (not) equal to” and “(not) starts with”.
E.g. we can use “Title”, “Created”, “Modified” site properties and “=”,”:”,”<“, “>”, “<=”, “>=” conditions.
Working queries examples:
created>=2022-07-21
modified>1/31/2023
created>12/31/2021 AND modified>=7/31/2022
created<=2020-11-15 OR modified>2023-02-06 (?)
created<=2020-1-15 OR modified>2023-01-31 (?)
created<=11/15/2020 OR modified>1/31/2023
title:test
SiteTitle:test
RefinableString09:Test*
RefinableString09<>Test
RefinableString09=Birding AND RefinableString08<>Included
Not working queries examples:
site:https://contoso.sharepoint.com/sites/test*
RefinableString11 = Birds # (do not use spaces in advanced query)
Path:https://contoso-my.sharepoint.com
Template:STS
Template:"SITEPAGEPUBLISHING#0"
Template:SITEPAGEPUBLISHING*
? RefinableString09<>Birding AND RefinableString08:Official
modified>31/1/2023 (should be like modified>2023-01-31
)
Query against custom site property (aka property bag value)
You can create custom site property and assign value to the property with Set-PnPAdaptiveScopeProperty or Set-PnPPropertyBagValue. Property must be with “Indexed” parameter. Once the property is set up, m365 search crawls site and creates crawled property. Then you map crawled property to some pre-created refinable string managed property. You can assign alias to this managed property.
In my test scenario I used RefinableString09 with alias SiteCustomSubject.
Site property value
Query
result
Birding
RefinableString09:Bird
does not work
Birding
SiteCustomSubject:Bird
does not work
Birding
RefinableString09:Bird*
works
Birding
SiteCustomSubject:Bird*
does not work
Birding
RefinableString09:Birding
works
Birding
SiteCustomSubject:Birding
does not work
Birding
RefinableString09:Birding*
works
Birding
RefinableString09=Birding
works
Birding
RefinableString09=Bird
does not work
Birding
RefinableString09=Bird*
does not work
Birding
SiteCustomSubject=Birding
does not work
RefinableString09<>Birding
works
RefinableString09=Birding AND RefinableString08<>Included
works
Query against multi-value property.
Site property value
Query
result
TestA TestB
RefinableString09:TestA
works
TestA TestB
RefinableString09 = ‘TestA TestB’
does not work
TestA TestB
??? RefinableString09=’Test10 Test5′
does not work
TestA TestB
RefinableString09:TestB
?
TestA,TestB
RefinableString09:Test*
works
TestA,TestB
RefinableString09=Test*
does not work
TestA,TestB
RefinableString09:Test
does not work
TestA,TestB TestA;TestB TestB TestA TestA TestB
RefinableString09:TestB
works
TestA, TestB TestB,TestA TestA TestB
RefinableString09=TestA
does not work
TestA,TestB
(basic) RefinableString09 starts with test
works
Some more findings
Modify adaptive scope
If you need to modify adaptive scope – you’d better delete it and create a new one. The reason – if you want to validate what sites are included in scope with GUI – via button “Scope details” – you want to see only sites that are in scope, but that’s not the case when you modify the scope, because if you modify the scope – you’d see sites that are not in scope with “Removed” status.
Alternatively you can use filter to filter out removed from scope sites.
what else?
What is the takeaway from this for SharePoint administrators? We would be asked to configure SharePoint the way compliance…
After many years working with SharePoint I wrote a lot of PowerShell scripts that help me support, troubleshoot, administer and secure SharePoint. So I’m sharing my scripts with you.
Manage result layouts for SharePoint results in Microsoft Search
We’re making changes to Microsoft Search. This update will allow Microsoft Search administrators to change result layouts for select SharePoint content using adaptive cards with Result Type feature in Microsoft Search administration.
The default result layouts for SharePoint sites, pages, list items and Portable document format (PDF) results can now be replaced with layouts built using adaptive cards. The changes can be made for Organization level search applicable to Office.com and SharePoint home as well as site level search on SharePoint sites. Changes for Microsoft Search in Bing will be rolled out soon. Note that the feature does not support changing of Office file search results.
This message is associated with Microsoft 365 Roadmap ID 81952
Before the change, when you add a new result type under “Search and intelligence” Customizations – it looked like this:
So there was no built-in “SharePoint” content source as an option – only custom “external” data sources.
But with the new feature implemented list of content sources for the result type will look like this:
If you choose “SharePoint and OneDrive” content source – the next option would be to select type of content:
You also can create different result types for different types of content based on properties-based rules (e.g. one result type for all sites – and a separate result type for a specific site or hub) with optional “Set rules for this type of content”:
Default site result experience would look like
Search results with modified SharePoint result type might look like:
When you modify template via Layout Designer – it is essential to know available object properties.
You can get properties from the “Available properties” below – there is also search through properties feature.
Or you can use SharePoint Search Query Tool to get metadata on search results.
It might take hours and even days for your search to start showing new layouts, but “&cacheClear=true” should help.
DepartmentId
If your sites are organized in hierarchy under Hub site – you can use DepartmentId managed property to include all hub-associated sites content
Each time we need to validate a recent change in Microsoft Search configuration, we need to use query parameter that clears cache, and each time I’m not sure is it clearCache or cacheClear 🙂
Nickname (or alias or moniker or hypocorism etc.) is some another name – usually shorter than original name and widely used in maybe all countries in the world. E.g. Bob is a nickname for Robert in the US and GB, Checo is the other name for Sergio in Mexico. There might be personal names also – e.g. Bapu (father) is an word that is usually associated with Mohandas Karamchand Gandhi, also known as the Mahatma Gandhi. More examples: David “Noodles” Aaronson, Roger Keith “Syd” Barrett etc.
In Microsoft 365 we want to search for a person’s name we know – and in many cases it’s a nickname – e.g. Beth (Bethany) or Alex (Alexander). Can m365 search do that?
It takes a few steps to implement search by nickname:
create a custom property under SharePoint Online User Profiles service
fill this property with values
configure Search Schema – map crawled property to managed property
Step-by-Step
Create a custom property under SharePoint Online User Profiles service
Ensure you have a SharePoint Administrator role activated
Navigate to SharePoint Admin Center – more features – User Profiles – Manage user properties – New Property
Configure custom property according to your needs, – ensure “Policy Settings” “Default Privacy Setting:” Everyone is selected – ensure “Search Settings” “Indexed” is selected
Fill SharePoint Online User Profile Properties with values
That would be a custom solution – e.g. manual work from SPO Admin Center GUI or PowerShell script ( e.g. with some dictionary). This is required for search to pick it up, crawl the property and create crawled property – so you could proceed with search schema mapping.
Configure Search Schema – map crawled property to managed property
For the nickname to be generally available in full-text-search – i.e. user simply enter value in a search bar and gets results – here are the steps:
Ensure you have a SharePoint Administrator role activated
Navigate to SharePoint Admin Center – More features – Search – Manage Search Schema
Select Crawled Properties and ensure search picked up your custom property and crawled it – check your crawled property name under Category: People.
Under Managed Properties – create a new managed property
select “Searchable”
under Advanced searchable settings – select Full-text index: PeopleIdx
What is the Microsoft Search KQL query field limits for a verticals? Is there limited number of characters or lines?
You know what is Microsoft 365 Search Vertical and what is KQL query in vertical configuration, right?
Under Microsoft 365 admin center Search and intelligence you can configure search verticals. There are some out-of-the-box verticals – like All, Files, Sites, People and you can configure custom one.
As a part of vertical configuration – you can specify KQL query – if you want e.g. limit search with some sites or content types etc.
The question is – how many sites I can specify in this query field? E.g. can I specify 1000 sites? 10k sites?
And the answer is: It does not matter, because the limit is not in number of characters or lines.
In my dev environment I was able to save 50,000 lines (~3M characters). But attempt to save 100K lines (6M symbols) has failed (due to timeout, I believe:
Again, as I said the problem is not here.
The problem is time required for search to apply query. I.e. when you ask search to bring you something – after it gets results from index and before display results to you it applies KQL query configured for the vertical. And this time is the bottleneck.
Here is what I got measuring search response time depending on query size:
Search
response time, seconds
KQL query # of lines
KQL query size, # of symbols
works
1
500
28,000
works
5
1000
59,000
works
9
2000
120,000
works
25
3000
180,000
works/fails
30
3500
208,000
fails
35
3600
214,000
fails
35
50,000
3,000,000
n/a
n/a
100,000 (can’t save KQL query
6,000,000 (can’t save KQL query)
Which means that after ~ 1000 lines (50,000 characters) KQL query size – query becomes too slow, and after ~3000 lines (180k chars) – can fail (due to timeout I’d say).
DepartmentId
If your sites are organized in hierarchy under Hub site – you can use DepartmentId managed property to significantly decrease number of lines in query, as you can cover all sites under the hub with
If you configure Verticals Query at the tenant level – i.e., Microsoft 365 Administration -> Settings -> Search and intelligence -> Customizations -> Verticals then search results will be trimmed everywhere – SharePoint Landing Page, Office landing page (Office.com), Office App, Bing search (but not other sites).
Teams search will not be affected as from Teams you only search for teams content. Same for Onedrive and Yammer. Sites with site or hub search scope will not be affected too.
If you configure verticals at site level: Site Settings -> Microsoft Search -> Configure search settings -> Verticals and want this be in effect – ensure site search scope is set to site or hub scope. But in this case you will loose answers functionality.
Global search settings – like acronyms, bookmarks and verticals – works only at tenant level search or at site leve if the site search scope is set to tenant. If site search scope is site or hub – then site-level search verticals will apply (and no answers functionality will be possible).
Published: May 1, 2022 Update from Mar 5, 2023: Microsoft confirmed this as valid solution. Update from May 20, 2024: still true Update from June 12, 2024: I have just found “ABP in Exchange Online“… Looking into it…
Scenario
You want specific users do not appear in Microsoft 365 SharePoint, Teams or Outlook search results. For instance, when user left company and the account is not deleted, but just disabled in Entra Id (Azure AD), so account is present and searchable. Or there are two accounts of the same person – main one and a secondary one – so you want secondary account is removed from org structure and search. Etc.
Solution
Set “ShowInAddressList” Azure AD User object property to false. It’s done using Az module, e.g. with PowerShell:
In many cases we do not need some accounts to appear in Microsoft 365 Search. Examples are:
a) secondary or admin accounts e.g. a person have several roles and several accounts under the same name, e.g. regular user: John Smith John.Smith@contoso.com administrative account: John Smith John.Smith.Admin@contoso.com b) role, shared or service accounts: marketing@contoso.com c) non-mail-enabled objects d) disabled accounts
Getting multiple search results for the same person might confuse users and even lead to miscommunication and broken processes.
There is a good article by Tania Menice (Microsoft): Exclude Users From Delve and SharePoint Online People Search with the latest updates explaining how it is done for classic search and stating that currently it is not possible for modern search, but Microsoft is working on it.
In short, the article says:
Set the profiles AD property msExchHideFromAddressLists to True or Yes,
Sync/wait, so finally SharePoint UPA service SPS-HideFromAddressLists property will be updated (as it is mapped to msExchHideFromAddressLists AD property)
Under SharePoint classic search – update query to: {searchboxquery} -“SPS-HideFromAddressLists”:1
It works perfect for classic search. The problem is it does not work as expected in modern Microsoft Search.
“People” vertical is not customizable so far. So we cannot change query in Microsoft 365 search to do the same trick. But… it seems like Microsoft is working on it so finally it should be done by some kind of ootb config.
Here is how different services or search entry points respect SPS-HideFromAddressLists SharePoint UPA property:
So only “People” vertical in Microsoft search does not respect SPS-HideFromAddressLists (msExchHideFromAddressLists).
(Modern) Microsoft 365 Search
What about cloud-based accounts (not synchronized from local AD)?
There is a configuration setting “Show in global address list” that does the same job. It’s under Microsoft 365 admin center -> Active Users -> User – Edit -> Mail -> Show in global address list:
And another configuration settings “Hide from global address list (GAL)” under Exchange Admin Center:
I tested behavior for different kind of accounts and here are results:
User Account
#1
#2
#3
#4
#5
Enabled
Yes
No
Yes
Yes
Yes
Licensed (E5)
No
Yes
Yes
Yes
Yes
m365 Admin Center: Show in Global Address List
n/a
No
No
Yes
No
Exchange Admin Center: Hide from global address list (GAL)
n/a
Yes
Yes
No
Yes
ShowInAddressList Entra Id property value
null
null
null
null
False
SPO UPA ‘SPS-HideFromAddressLists‘ value
False
False
False
False
True
Outlook Address List “All Users”
Shown
Office.com Search: Vertical “All”
Shown
Office.com Search: Vertical “People”
Shown
Shown
Shown
Shown
Bing Work Search: All/People verticals
Shown
Shown
Teams Search: “All” Vertical
Shown
Shown
Teams Search: “People” vertical
Shown
Shown
Shown
Shown
Microsoft 365 Profile card – Organization
Shown
Shown
Teams Profile card – Organization
Shown
Shown
Shown
Shown
Teams People Picker
Shown
Shown
Shown
Shown
SharePoint People Picker
Shown
Outlook People Picker:
Shown
* – some users can see changes after hours, for some it takes days
It seems confusing we have 4 properties responsible for the same:
“Show in Global Address List” under m365 Admin Center
“Hide from global address list (GAL)” under Exchange Admin Center
“ShowInAddressList” Azure AD User object property
“SPS-HideFromAddressLists” SharePoint User Profile property
Are these properties related to each other?
Let’s test it:
Action-Consequences (immediate reaction – minutes if not other mentioned)
“Show in Global Address List” under m365 Admin Center
“Hide from global address list (GAL)” under Exchange Admin Center
ShowInAddressList Azure AD User object property
SPS-HideFromAddressLists SharePoint User Profile property
New user created, license assigned
Yes
Off
null
False
Uncheck “Show in my organization address list” under Microsoft 365 admin center
No
On
after one minute: null after 24 hours: null
after one minute: False after 24 hours: False
Set “ShowInAddressList” Azure AD User object property to “True”
Yes
Off
True
False
Set “ShowInAddressList” Azure AD User object property to “False”
“Show in Global Address List” under m365 Admin Center and “Hide from global address list (GAL)” under Exchange Admin Center – same switch, i.e. if you change one – another is updated automatically Neither of them affect “ShowInAddressList” Azure AD User object property or “SPS-HideFromAddressLists” SharePoint User Profile property
“SPS-HideFromAddressLists” SharePoint User Profile property is not changeable. If you try to change the property value you get an error message: “Set-PnPUserProfileProperty : Property Not Editable: This property can not be modified.“
“ShowInAddressList” Azure AD User object property is editable and synchronized to “Show in Global Address List” under m365 Admin Center and “Hide from global address list (GAL)” under Exchange Admin Center, and also with “SPS-HideFromAddressLists” SharePoint User Profile property (takes minutes), but then search crawler must pick this change up (takes hours) to hide/show the user (this was tested and validated for cloud-born accounts only)
here Microsoft says: regarding showInAddressList – Do not use in Microsoft Graph. Manage this property through the Microsoft 365 admin center instead. Represents whether the user should be included in the Outlook global address list. See Known issue.
Known issue (Microsoft): showInAddressList property is out of sync with Microsoft Exchange. When querying users through Microsoft Graph, the showInAddressList property may not indicate the same status shown in Microsoft Exchange. We recommend you manage this functionality directly with Microsoft Exchange through the Microsoft 365 admin center and not to use this property in Microsoft Graph.
Disclaimer
I used and tested all cloud-born accounts only. I do not have on-prem AD, so If your users are synchronized from local AD – do your own research – is this property synced from some local AD property, and if so – set AD property instead.
Microsoft is constantly changing the product. So what I found out here now might differ with what you work with.
It’s a good idea to test/validate this solution in your non-prod environment and against test users in your prod environment.
Bottom line
Setting “ShowInAddressList” Azure AD User object property to “false” is the most effective way to hide user account from search, but it could be changed only with PowerShell:
If you have an opposite issue – user account is missing from search – check this property value: msExchRemoteRecipientType – generally it should be “1”, all other might indicate account type not indexed.
Video tutorial
Here is the video tutorial on the same – excluding account from people search in Microsoft 365