correct usage is “cacheClear=true”, e.g:
https://www.office.com/search/sites?auth=2&cacheClear=true&q=bird*
Reference:
correct usage is “cacheClear=true”, e.g:
https://www.office.com/search/sites?auth=2&cacheClear=true&q=bird*
Reference:
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?
Unfortunately, not… At least at 19:38 on 2023-03-30
… though please check Microsoft 365 Search: built-in people search by nickname.
It takes a few steps to implement search by nickname:
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.
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:
========================================
References
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).
Update from Mar 5, 2023: Microsoft confirmed this as valid solution.
You want specific users do not appear in Microsoft 365 SharePoint, Teams or Delve search results.
Set “ShowInAddressList” Azure AD User object property to false. If users are synchronized from local AD – set AD property instead.
In many cases we do not need some accounts appear in Microsoft 365 Search. Examples of are:
a) secondary/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.2@contoso.com
b) role, shared or service accounts
c) non-mail-enabled objects
d) disabled accounts
Getting multiple results for the same one 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.
Basically, the article says:
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 ootb means.
Here is the current situation on how different services or search entry points respect SPS-HideFromAddressLists property:
Microsoft 365 Service or Search Entry point | respect SPS-HideFromAddressLists (msExchHideFromAddressLists) |
web Outlook “New message” user picker | Yes |
web Outlook “Contacts” | Yes |
Office.com “All” vertical | Yes |
Office.com “People” vertical | No |
SharePoint landing page “All” vertical | Yes |
SharePoint landing page “People” vertical | No |
Bing Work All Vertical | Yes |
Bing Work People Vertical | Yes |
So only “People” vertical in Microsoft search does not respect SPS-HideFromAddressLists (msExchHideFromAddressLists).
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:
Here are experiment 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 |
Get-AzADUser -UserPrincipalName <upn> -Select ShowInAddressList -AppendSelected | Select-Object UserPrincipalName, ShowInAddressList | 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 |
It seems confusing we have properties:
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” | No | On | False | True |
Note: Az module works fine too. I.e. Get-AzADUser instead of Get-AzureADUser and Set-AzADUser instead of Set-AzureADUser.
Findings:
Set-PnPUserProfileProperty : Property Not Editable: This property can not be modified.
“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 through API e.g. via PowerShell and Microsoft’s vision is unclear.
Here is the video tutorial on the same – excluding account from people search in Microsoft 365
Your organization use Microsoft 365. You are implementing or configuring an Intranet Portal (Home Site). Search plays an important role here – you want search be relevant to the context – i.e.
Microsoft Bookmarks are working only at tenant level search – i.e. if you want bookmarks work on site level search – you need to set up site search scope as tenant.
So if you configure the Intranet Portal site (Home site) search scope to “site” or “hub” to limit results with site/hub content – you will loose “answers” functionality.
The solution is very simple:
Update Query field with KQL – e.g., with something like
(path:http//contoso.sharepoint.com/sites/IntranetPortal/ OR path:http//contoso.sharepoint.com/sites/CompanyNews/ OR path:http//contoso.sharepoint.com/sites/Onboarding)/)
to get results only from “Intranet Portal” and “Company News” sites.
Keep in mind that this will affect all other SharePoint search entry points – SharePoint landing page, Office.com etc. – so although you can configure All (and Files) verticals, but it’s not recommended. It will confuse users – they expect to search for everything under “All” vertical. Instead, consider custom vertical – e.g. “Official” scope.
After configuring – It might take 1-24 hours for the change to take effect, depending on tenant size.
If you configure that 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.
Teams search will not be affected as from Teams you only search for teams content. Same for Onedrive and Yammer.
If you want the “official” search results only under Intranet Portal and leave other search entry points unaffected – then
you need to configure the same at Home (Intranet Portal) site level: Site Settings -> Microsoft Search -> Configure search settings -> Verticals
and configure site search scope to site or hub scope. But in this case you will loose answers functionality.
Global search settings – like acronyms, bookmarks and verticals – works only if site search scope is tenant.
If site search scope is site or hub – then site-level search verticals will apply (and no answers functionality will be possible).
There might be two problems with that:
The solution is DepartmentId property:
Use DepartmentId={<Hub Site ID>} in the KQL qury and your search results will be limited to your hub content while answers will still be working too. You can even combine DepartmentId with other conditions to add more sites (that are not in hub) to search scope:
(DepartmentId={4965d9be-929b-411a-9281-5662f5e09d49} OR path:http//contoso.sharepoint.com/sites/Onboarding OR path:http//contoso.sharepoint.com/sites/CompanyNews)
It worth to mention, that DepartmentId is the property that propagated from the root of the hub site to all associated sites and their content – list items, documents and pages.
Another possible option would be – site property bag…
The ultimate goal is to provide users with “Official” results only. But official sites might not be all part of one Home site hub. We can include in All search vertical query 10, 50, 100 sites, but what if we have 10k official sites in enterprise – e.g. operated by different departments – and all of them might want to be present in search results.
So, how about – if the site is considered official – we create an indexed site property, e.g. “SiteIsOfficial” with a value “Yes”. Then we map the crawled property to a managed property – e.g. RefinableString89 – and use this managed search property in query – e.g. (SiteIsOfficial=Yes).
This is actually clever idea, but this does not work… This query would only return sites, not sites content. E.g. what was indexed as site object – will be included (including home page). But site items – i.a. documents, lists, other pages – all site content – will not be included…
So let’s get back to DepartmentId…
Again – the ultimate goal is to give users option to have “Official” results. But they still might want to be able to search through all content.
What if we rename the default “All” vertical to “Home Site” and configure query for official results only.
Then we can create a custom vertical called “Everything” or “All” with no query limitations to give users all reasults
Update: not a good idea either… If the home site search scope is tenant – so verticals are configured and be visible at tenant level – i.e. everywhere…
My personal preference is to keep All vertical as real All, and create a custom Vertical “Official” for official results only where we would use query trick.
In addition, it would be nice to highlight results from official sources by using custom result type – check “Manage result layouts for SharePoint results in Microsoft Search”
updated: Feb 13, 2022
(Old/Classic) SharePoint Search: content-centric (SharePoint Search Center)
(New/Modern) Microsoft Search: people-centric (Teams, Office, OneDrive, Delve etc.)
Office graph = codename for collective set of services and insights we generate on top of the infrastructure that fast office graph group developed
= social Intel concepts (SharePoint home, Delve, OneDrive Discoverview) are derivatives of Office graph
Microsoft Graph = API ( including universal search API)
The Graph Search API went General Availability (GA):
– Microsoft Search API in Microsoft Graph
– Use the Microsoft Search API to query data
– Microsoft Search API Code samples, Tutorials at github
Microsoft Search API provides one unified search endpoint that you can use to query data in the Microsoft cloud – messages and events in Outlook mailboxes, and files on OneDrive and SharePoint – that Microsoft Search already indexes.
Turing technology – understands you, answers your question e.g. hover over doc -> doc summary (based on “deep speed” AI model)
announcement at Ignite Spring, more on Ignite Fall 2021
Modern Search: MS nailed the fundamentals, now start bringing it everywhere – to Teams first, then SharePoint (said Nov 2020).
Modern Search Customizations – we’ll take the best from Classic SharePoint Search,
a lot will retire – investing in more flexibility
PnP modern Search
– custom result pages, webparts, branding theme; filters, refiners, scoping control )
pnp modern search – webparts (video)
https://microsoft-search.github.io/pnp-modern-search
Core idea behind Microsoft search is coherence
Bill Baer:
“People use search in a different ways
1) you have organisations who have a well-established intranet built around set of governance controls, a very clean architecture and they want to build a search into that intranet scenario; that’s why a lot of SharePoint capabilities are going to come along with Microsoft search for that particular endpoint
2) then you have other people who live their day in teams“
Shared search engine results page (developed once – transitioned everywhere)
Ctrl-F to search through teams (chats?) (contextual search)
Natural language search (starting from Outlook)
Image search (before eoy), +
Metadata content type search Syntex customers will be able to use content type to search in the advanced search flyout in document libraries that contain content types beyond the default types. Syntex only.
Conversations: teams chats, outlook groups conversations, yammer conversation can be found under Conversations vertical in Bing search. Later – in Office.com and SharePoint landing page.
E-mail messages are added to Conversations vertical in Bing search
Bookmarks (new promoted results), acronyms, Q&A – all under “Answers”
Bookmarks Targeting – for the specific audience based on device/OS, Country/Region, security groups…
SharePoint Search Admin Center -> will be migrated from SharePoint admin center to to Microsoft Search Admin Center transitioning (Search and Intelligence Admin Center) – long-running project custom dictionaries, spelling suggestions – will retire, (move to a graph-driven speller)
+ Viva Topics – based search capabilities
Graph Connectors
Graph Connectors are generally available (ADLS – Azure Data Lake Storage Gen2, Azure DevOps, Azure SQL and Microsoft SQL Server, Enterprise websites, MediaWiki, File share, Oracle SQL, Salesforce, Jira, Confluence, ServiceNow + 100+ from partners; New connectors coming to Microsoft Search: Jira Graph connector, Confluence Graph connector).
Graph Connector allows to connect external source of information to Microsoft 365 and makes that data available across all m365 apps and services so you can find what you need wherever you’re working, whether in one of your favorite productivity apps or one of the many Microsoft 365 services such as SharePoint or Office.com
Graph Connectors roadmap:
Actionable experiences
Search results on select Graph connectors will soon support actions that will allow users to interact with the result and perform changes to the Connector content within the Search application.
Results clusters
The results shown in a result cluster are grouped together based on the search vertical configuration.
Profile Query variables
Define any attribute from the user’s Profile, as a query variable and it would be resolved during query evaluation (This feature is currently in preview)
Profile enrichment with Graph connectors
…you will soon be able to enrich Microsoft 365 profile properties like Job title, Phone numbers, Skills etc. with data from HRMS systems using graph connectors. …then surface this rich profile information on people experiences like profile cards.
Search Federation
federation capabilities will allow enterprises build and integrate their custom LOB search experiences, customized search providers, into the overall Microsoft Search. With federated search, you can make information from systems where the data cannot leave the systems boundaries available to search across in Microsoft 365 productivity apps and services, without indexing its data with Microsoft Search.
Azure Cognitive Search Federation
PowerBI search vertical
Custom verticals and custom refiners
Custom result templates – search layout designer – wysiwyg editor
– Manage search result layouts
– Microsoft Search Layout Designer
Standalone Search – AAD identity – Graph connector – Ingest your data – use Search = in Windows 10, Office.com ( e.g. for those who have their data in other productivity suite, have no intent to use m365, but want to search)
More info:
Bill Baer “Making the most of Microsoft Search” @ MS Ingnite fall 2021
Current state of SharePoint Search and Microsoft Search scopes
Bill Baer: What’s new and what’s next for Microsoft Search (May 25, 2021)
There is a known problem in SharePoint (and Teams*) – complicated permissions system. Site owners/administrators provide access, site contributors upload documents and nobody knows – who has access to their sites. As a result – sometimes sensitive documents become overshared (over-exposed).
The biggest concern is when sites content is shared with “Everyone”. How do we find sites shared with “Everyone” in a large Microsoft 365 environment so for this sites we can request permissions review?
(*) Microsoft with the introduction of Teams had to simplify permissions in SharePoint – since there should only be 3 types of access levels – owner, member and visitor. It was… in some ways, but in other ways it made things worse.
You are lucky if you can use 3-rd party tools (e.g. ShareGate, SysKit Point, AvePoint, Metalogix etc.), with the ability to get full permissions report. Though there might be a problem to get full permissions report for all tenant sites if your m365 environment is not small. Some tools allow you to get tenant-wide permissions report for specific Ids – this option should work better for large environments.
Still there might be another problem. Consider the following. When I say “shared with Everyone” – I actually mean at least 3 possible “everyone” system logins:
– those are system id’s, but what if there are other ids – e.g. migrated from on-prem or cloud-born custom security or Microsoft 365 groups in tenant that also includes everyone (e.g. dynamic security group that includes all org accounts)? How do you think this group will be identified as “Everyone” group? So – you’d also know which groups include “all” or “almost all” users and get report for these groups also.
Obviously this option #1 is not free, as it requires licenses to be obtained. And still it worth to consider option 3.
You can get full permissions report per site or for entire tenant with PowerShell, which if free… The only you need is to write a script yourself or find existing one. Sounds easy?
Well, first problem is it takes a decent amount of time and competences to write such script. If if you find one – it would require some skills to adopt it and run. Frankly say, I have not seen so far scripts that are ready OotB to do that job. And it is not a good idea to run scripts you are not fully confident with against production environment.
Another possible problem – size of environment. The script I designed and use to get comprehensive permissions report might run hours against a good site – if I need full details on site/subsites, lists/libraries, folders and list items levels. So if you have less than 1000 sites – probably this approach can fly. But if your environment is 10K+ sites – it will take forever. So the approach might not work for large enterprise environments.
One might say – we can limit report with root web permissions only to get it faster. But this would not be accurate. And what is not accurate in the IT security – lead to even bigger risks. So, we need check permissions up to every item level deep, as even one file with sensitive info shared inappropriately can cause security issue. (Btw, 3-rd party tools usually by default limit reports to libraries level, so check reporting options)
The other issue with this approach… Let say you got full permissions report… It would look like “resource -> group -> permissions”… How do you know for each group – what is the group in terms of membership?
Ok, if this solution is not easy to get working – what are other options?
This solution is based on simple but clever idea: why do we need to iterate through all the tenant documents/items if all the content is already crawled by search? Search is also respect permissions. Can we just use search to get files shared with Everyone? Let us see.
What if we use some dummy user account with no specific permissions provided and no group memberships and try to search content on behalf of that account. The idea is if this user can see some data – then these data is open to everyone.
Check this and this articles. Can we get results programmatically (e.g. with PowerShell)? Can we use Microsoft Graph search API? Sure. Check also this article “How to search against SharePoint Online Content with Microsoft Graph search API with PowerShell“.
With this option we would use search query “*” and all 5 possible SharePoint entities – driveItem’,’listItem’,’list’,’drive’,’site’ to find everything that is shared with everyone. We’d pull results with paging (we’d use “from” option in a loop to pull all results). After we get all results – we’d select only unique site collections. But! We might have some problems here.
Problem #1. Again, for small environments or if there are not much “Open” sites – it would work. But for large enterprise environments the problem is the same as in “brute force”. Search would returns too many results – and it might take weeks (exact time is unpredictable) to get all of them. (Surely there are sites “legally” shared with everyone, public Office 365 group based sites, communication sites… So your search will be flooded with content from sites you already know are shared with all).
Problem #2. We are getting results with paging. But recently Microsoft started limiting number of returning results. E.g. your search request result might say like “there are 3659735 total hits” but after result number 1000 it just stops returning anything, even with paging.
The idea is: why do we need to get all search results if even one result from a site would be enough to put the site to the list of “open” sites. In other words, we do not need all results from the site, we only need to know if there are any results from the site, at least one – so we know if the site is open for everyone or not.
So, consider the following approach:
There are sites “legally” shared with everyone – e.g. corporate portal, department communication sites, public teams, public Viva Engage communities etc. If it is know that these sites are public – you can exclude them from all sites list – so in the “Solution#3 Option #2 – loop sites” – you’d loop only through sites that are not supposed to be public. I know – percentage of “legally public” sites in tenant to all sites is a relatively small number, so should not significantly decrease elapsed time… but still.
Pro: the only fast enough (at least predictable time to complete) and accurate enough to rely on solution.
Con 1 : crawling and indexing takes time, so search-based reports can miss recent changes in data and permissions
Con 2: this approach cannot be automated (since we need an interactive authentication). I.e. we need to run it manually every time.
Con 3: After we get all sites shared with everyone – we do not know – at what level permissions are broken and provided to everyone. It might be entire site or one file. If you want to know what exactly is shared with everyone – run permissions report against this shortlist.
Note 1: consider there are resources like “Styles Library” shared with everyone by default, especially on migrated sites
Note 2: There are might be security groups intended to hold all or part of the enterprise (e.g. “All employee” or “all contractors”). If the enterprise comprises from several businesses or regions – it might be “All Business 1” or “All EMEA”… you got the idea.
You can modify search-based solution if you add your dummy account you are running search on behalf of to some of theses groups to find out if there are resources shared maybe not with everyone but with all “North America based” users or with “all employees”, which might make sense also.
Note 3: separate service, but consider implementing/using sensitivity labels. At least you can start with high-sensitive sites. With sensitivity labels – site owners/member would know – what kind of site they are working on.
Ok, we know list of SharePoint resources shared with everyone, but what would be the next step? Should we communicate to site owners – if so how to let site owners know that there are resources shared with Everyone… on their sites.
To be continued…
Consider the following:
“The following Azure AD user attributes are synced to the UPA.” :
(Azure AD attributes) – UserPrincipalName, DisplayName, GivenName, sn, telephoneNumber, proxyAddresses, PhysicalDeliveryOfficeName, Title, Department, WWWHomePage, PreferredLanguage, msExchHideFromAddressList, Manager
Respective User profile property display names: Account Name, User Name, User Principal Name, Name, FirstName, LastName, Work phone, Work Email, SIP Address, Office, Title, Job Title, Department, Public site redirect, Language Preferences, SPS-HideFromAddressLists, Manager (here)
Q: “Why isn’t it possible to map additional properties for UPA synchronization to sync from Azure AD to the User Profile Application?”
A: “UPA synchronization is limited to a preconfigured set of properties to guarantee consistent performance across the service.” (here)
“You can make the following attributes from Azure Active Directory (Azure AD) visible on users’ profile cards. These attributes are not case-sensitive: UserPrincipalName, Fax, StreetAddress, PostalCode, StateOrProvince, Alias” (here)
“You can add any of the 15 Azure AD custom extension attributes to users’ profile cards… Custom properties are not searchable and can’t be used to search for people across Microsoft apps and services.” (here)
It takes a few steps to solve the problem:
Detailed:
Hint: you can fill this property for some user profiles – for search to pick it up and crawl the property – so you could configure search schema mapping before synchronizing property from Active Directory
That would be a custom solution – e.g. scheduled PowerShell script. You can host this script in Azure Functions if you sync Azure AD attributes to SPO or use on-prem machine if you need access to local AD.
PowerShell Script example (TBP)
If you want your custom property is generally available in full-text-search – i.e.
user simply enter value in a search bar and gets results – typical scenario might be an employee id – here are the steps (under Search Schema)
Free-text search: you just enter what you search for into search bar and click search.
Query-based search allows you to use KQL – e.g. you are searching for keyword “PowerShell” with full-text search, but want only people with PowerShell skills located in a specific building or campus –
search query might look like “PowerShell campus:Stanford”
If you want to be able to refine your search with custom property – in this case the steps are (under Search Schema):