Tag Archives: Search

Get list of new m365 SharePoint sites or teams with PowerShell and Graph API

There are scenarios when you need to pull only newly created SharePoint sites, e.g. get sites created since yesterday or get last 100 created sites. Usually other articles and existing PowerShell scripts solve this by pulling all sites from tenant and then iterating through sites to get only new sites. That approach is not nice and simply does not work in large environments. How can we get only sites created recently, not all sites? Here is how I use Microsoft Graph API to get only new sites.

Update (6/28/2024): Microsoft announced updates to it’s delta API for SharePoint, so I added option 3 – see below.

Scenario

Let say you administer Teams, OneDrive and SharePoint Online in a Microsoft 365 tenant. You have a pretty big environment – ~10k or more sites and you want to quickly find just new SharePoint sites or teams (e.g. sites created recently – during last hour/day/week/month). This might be required for ad-hoc reports and for automation scenarios – like applying required configurations or assign some property value to all newly created sites.

With GUI it’s done easily: SharePoint Admin Center -> Active Sites -> sort based on “Date Created” – done.

With PowerShell – not so simple.
“Get-PnPTenantSite” cmdlet returns a site object but the object does not have “Created” field. It’s a web property (not site property). But to get a web object – you have to connect separately to each site and get root web object to check when the web was created. For small environments it is possible, for large environments it can take days… And still not nice.
“Get-PnPTenantSite” with “-Filter” option would help, but “…Currently, you can filter by these properties: Owner, Template, LockState, Url.”

Get-SPOSite – similar experience.

Teams + Exchange modules can help a little:

Get-Team | select GroupId | % { Get-UnifiedGroup $_.GroupId | select DisplayName, WhenCreated } | sort WhenCreated

but… 1) it’ll give you group-based sites only 2) it is not easy to automate 3) this might take long for large environments. I know much better solution:

Solution

Microsoft Graph API helps. It returns result in seconds and you can sort or filter results based on created date . Below are two methods: Option 1 is based on Search and filtering and Option 2 is based on Sites Search and sorting. So there are some pros and cons for each method.

Option #1: Microsoft Graph Search API.

Entry point: https://graph.microsoft.com/v1.0/search/query

Microsoft Graph Search API allows KQL in queries. So we can form a query with something like “created>=1/1/2021” and use entity type = ‘[“site”]’. Search should return only sites created after Jan 01, 2021.

Check PowerShell script sample here: Get-NewSites.ps1
https://github.com/VladilenK/PowerShell/blob/main/reports/SharePoint/Get-NewSites.ps1

If you are getting more than 500 results – think of paging.

Option #2: Microsoft Graph Sites API

Entry point: https://graph.microsoft.com/v1.0/sites

This option is also based on Microsoft Graph API, but sites entry point, which allows search too and sort results by property “createdDateTime”. So we will just search for everything and select how many results we need based on createdDateTime property.

Check PowerShell script sample here: Get-NewSites.ps1
https://github.com/VladilenK/PowerShell/blob/main/reports/SharePoint/Get-NewSites.ps1

Option #3: Microsoft SharePoint delta API

You can use “Get delta” under SharePoint Graph API – check for details here. It says “Get newly created, updated, or deleted sites without having to perform a full read of the entire sites collection”. I’ll do my own testing, but for now check this:
Video: Microsoft Graph Delta Capabilities in SharePoint API

References

Video tutorial:

DepartmentId for Enterprise Intranet Portal – Home Site and Search Scope and Relevance

Scenario

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.

  • Official Results – if a user searches something on a company’s intranet portal – user expect “official” results, not a something from somebody’s OneDrive or Yammer chat
  • Promoted Results – so information management team can adjust search with search answers – Bookmarks, Acronyms and Q&As

Problem

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.

Solution

The solution is very simple:

  • Keep site search scope as tenant-wide to use answers (boormarks), and
  • Configure search verticals and query to limit results to “official” sites only

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.

Service vs Site search

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).

Home site is a root site

There might be two problems with that:

  1. if a home site configured as a root site – you KQL will look like(path:http//contoso.sharepoint.com/ OR path:http//contoso.sharepoint.com/sites/CompanyNews)and that query will not work as any site Url will match the root site Url.
  2. if you need to mention many sites in KQL – like 50 sites with an Official Information – you might hit the “number of allowed character” limit

The solution is DepartmentId property:

DepartmentId

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.

Site Property Bag

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…

Rename All Vertical

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…

Separate Official Vertical

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

Update: Restricted SharePoint Search

There is a new feature in Microsoft 365 SharePoint Online – “Restricted SharePoint Search“. With Restricted SharePoint Search you can restrict organization-wide search to a curated set of “allowed” SharePoint sites – sites that you have checked the permissions and applied data governance for.

Resources:

Microsoft 365 Search: roadmap and announcements

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

Updates

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

  • Create Topic Answers with Microsoft Viva Topics to bring together people, content, and information (including synonyms and acronyms)
  • Knowledge answers provide a direct answer to questions authoritative information in an organization across SharePoint and OneDrive content
  • Files/Calendars/Links answers

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:

References

Bill Baer “Making the most of Microsoft Search” @ MS Ingnite fall 2021

Current state of SharePoint Search and Microsoft Search scopes

https://techcommunity.microsoft.com/t5/microsoft-search-blog/microsoft-search-at-ignite-2020/ba-p/1651098

https://techcommunity.microsoft.com/t5/microsoft-search-blog/what-s-new-for-microsoft-search-ignite-2020-edition/ba-p/1675291

Bill Baer: What’s new and what’s next for Microsoft Search (May 25, 2021)

Bill Baer on Search:

Microsoft 365 Search Roadmap

How to Find Content Shared with Everyone in SharePoint and Teams

There is a known problem in SharePoint (and Teams*) – complicated permissions system. Site owners/administrators provide access, site contributors upload documents and at any particular moment nobody knows – who has access to what files. As a result – sometimes content becomes overshared. The most frequent way to over-expose sensitive documents is when sites content is shared with “Everyone”. As admins, how do we know what content is shared with “Everyone”? Is there a report?

Obviously, only data owner decides who should have access to site documents, so we (SharePoint admins) do not fix permissions automatically (until there is a policy), but at least we can help site owners with reports and maybe initiate permissions review for “nasty” sites?

Below I’m sharing 3 possible solutions:

  • Solution #1 – also OotB report that comes with some 3-rd party tools
  • Solution #2 – PowerShell “Brute force” – free but require advanced skills and efforts
  • Solution #3 – Search-based – also free, and require less skills and efforts

Add-On – SharePoint Advanced management – EEEU report, comes with Premium license only

(*) 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.

Solution #1 (3-rd party tools)

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 – if your m365 environment is not small – there might be a problem to get full permissions report for all tenant sites. Some tools allow you to get tenant-wide permissions report for specific Ids e.g. EEEU – 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:

  • Everyone
  • Everyone except external users
  • All users

– those are system id’s, but what if there are other ids – e.g. migrated from on-prem or cloud-born custom security groups in tenant that also include everyone or big portion of users (e.g. dynamic security group that includes all or many accounts)?

What if your Identity management operates security groups “All employee” or “Contractors” or “All licensed users”? Do you think these groups can be identified as “Everyone” groups? Do you think it’d be a good idea to check if content is shared with other large groups (not only system Everyone…)? Would you like to run permissions report separately for all groups that include “all” or “almost all” users?

Also, knowing that full reports heavily load the system, 3-rd party tools might by default limit “how deep report is” to the root site and lists/libraries, not including e.g. folders and items. So you might need go to settings and turn on “full deep” option Keep it in mind.

Obviously this option #1 is not free, as it requires licenses to be obtained. For “free” reports – consider options below.

Solution #2 (PowerShell “Brute force”)

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/adopt 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 and run it. Frankly say, I have not seen so far scripts that were out-of-the-box ready to do that job. And it is not a good idea to run scripts you got from internet against your production environment until you understand it tested it and fully confident with.

Another possible problem – size of environment. The script I designed and use to get comprehensive permissions report might run hours against a good single 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 only top permissions (root web or default library) to get it faster. But this would be not accurate. And in IT security what is not accurate – leads 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.

The idea is: what if we use some dummy user account with no specific permissions provided (in terms of groups membership – let it be the same as anyone else – member of all default groups). That means if this user can see some data – then these content is open to everyone. Now what if we do search on behalf of that account? All the content returned would be content shared with Everyone except external users (EEEU). For background – 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“.

Solution #3 Option #1 – search through tenant

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 can sort and 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 days and weeks (exact time is unpredictable) to get all of them. (Surely there are sites “legally” shared with everyone – Communication sites, public Teams, Yammer communities… 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. And Microsoft explains it like “search is for search… nobody goes through 100 result pages”.

Solution#3 Option #2 – loop sites (hybrid approach)

At first, we can get only list of all sites and exclude legally open sites. Private sites are not usually supposed to be shared with everyone.

Now 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:

  1. You get list of all sites in tenant.
  2. You run search request against each site in the loop
    (e.g. consider KQL option “Site: https://yourTenant.SharePoint.com/sites/YourSite”.
    If at least something found in the site – add the site to the “Open Sites” list.
    With this approach you will get list of sites shared with “Everyone…” in a predictable time.

Solution#3 Option #3 – exclude known “open” sites

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.

Pros and cons of the Solution # 3

Pro 1: the only fast enough (at least predictable time to complete) and accurate enough to rely on solution.

Pro 2: There might be custom 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. So you can tweak this search-based solution by adding 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.

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. It does not really help if you try to get all search results from the site. If you want to know what exactly is shared with everyone – on the site – run permissions report against this site (shortlist of sites).

Notes

Note 1: consider there are resources like “Styles Library” shared with everyone by default, especially on migrated sites

Note 2: this is a separate topic, 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.

Add-On: SAM – DAG – Content Shared with EEEU

Microsoft implemented this report (Content shared with ‘Everyone except external users’ (EEEU) reports) in around mid-2024, but

What’s next

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…

References

Video tutorial:

Microsoft Search country-targeted bookmarks: new “Use Azure AD locations” flag

If you have country-specific content – Microsoft Search allows bookmarks to be configured to pop-up only for users from a specific country.

And “Use Azure AD locations” flag is a new option that make it actually works…
For a long time country settings were the same but without “Use Azure AD locations” flag. So what does “Use Azure AD locations” flag do?

Use Azure AD locations

“Use Azure AD locations” flag is a straight-forward configuration settings. It says: “This bookmark will only appear for users with Azure AD locations that match selected countries or regions. If cleared, the user’s IP address will be used to determine location. This checkbox can be altered from both Country or region setting and Targeted variations setting.”

I have tested this new “Use Azure AD locations” flag – it works. Once you configure user’s country in AAD and country-targeted bookmarks – all works good. Bookmarks appear for the user.

What if we do not “Use Azure AD locations” flag

to be provided

What was before “Use Azure AD locations” flag

What was before Microsoft implemented this “Use Azure AD locations” option? How did Microsoft understand “this user is from that country”. What was the criteria to correlate User <-> Country? License assigned country? Windows locale? Browser settings? Azure AD properties?

How does Microsoft define “this user is from that country”. What are the criteria to correlate User <-> Country? Physical IP address? License assigned country? Locale? Browser settings? Azure AD properties?

It turned out, the way it was designed previously:
– configure Microsoft 365 integration with Bing
– in Bing -> Settings : select Country/Region
– search from Bing
that was the only way to make it work! So yes, do not leave “Use Azure AD locations” option unchecked. Microsoft confirmed it was poor design.

Always “Use Azure AD locations” flag.

Resources:

Office 365 Search scopes

Search is everywhere in Microsoft 365. You can search from SharePoint, Teams, Delve, Yammer etc.

But! You cannot search for anything from everywhere!

  • Search for your Teams chat messages works only in Teams.
  • But from Teams you cannot search for regular (non-group) sites and public teams sites
  • All descriptions are totally out of search (e.g. site description, library/list description – including Yammer groups, Teams and regular sites).
  • Public Team Sites content is not searchable from Teams and Yammer

So, what are the scopes of each search entry point in Office 365 and is there an entry point you can search for everything?

Search scopesSharePoint
Search center
SharePoint home
Office portal
Office desktop app
Delve
TeamsBing
SharePoint contentYesYesYes
Teams contentYesYesYesYes
Teams chats(*1)YesYes
Yammer contentYesYesYes
Yammer chat(*1)Yes
User profilesYesYes
Email
(*1) Microsoft announced they are working on bringing conversations (both Teams chats and Yammer) to SharePoint landing page first, then to Office home page.

Detailed:

ScopeOut of Scope
SharePoint Search Center– all sites content
(Teams, Yammer, regular),
– user profiles
– OneDrive
Teams chat
Yammer chat
SharePoint Landing Pagesame as SharePoint Search center
but Teams chats and Yammer Conversations are coming
same as SharePoint Search Center
Office.comsame as SharePoint
(Teams chats and Yammer Conversations are coming after SharePoint)
same as SharePoint
Delve
TeamsTeams content
Teams chat
OneDrive
Yammer
User Profiles
regular SharePoint sites
BingEverything* * except people profiles content
(e.g. about me)

Seems like the only tool you can search for EVERYTHING with is Microsoft Bing:

Update: there are rumors that Microsoft is decommissioning work search in Bing… Pity… But something tells me that decomm is due to lack of usage/popularity, so Microsoft will introduce something similar…

After Microsoft add Teams chats and Yammer conversations to SharePoint landing page search scope (then to Office home page) – it’ll be the best place to search from for everything.

More on Microsoft Search vs SharePoint Search and Microsoft Search RoadMap

Microsoft Office 365 Search: Find what you need with Microsoft Search in Bing

It is possible customize Modern Microsoft Search pages with PnP Modern Search

How to find a public team in Microsoft Teams not knowing exact team name

Generally, if you want to join a public team – you must know exact team name to find it. This KBA explains how to find a public team by name or description or content even when you do not know exact team name. Quick and simple answer: use SharePoint Search center or Microsoft Search, (or Bing if it is integrated).

Detailed explanation

Below is why it is so complicated in teams and on how to find a public Team…

In Microsoft Office 365, under MS Teams, there are 3 types of teams:

  • Private team
  • Public team
  • Org-wide team

Private team: you can only join the team if you are invited or know the team code.
SharePoint site behind the private team is shared only to members – not for everyone. You cannot see team name or description or content until you are team member (details). You are not able to search for the team name or content.

Public team: you can join the public team if you wish. The site behind the public team is shared with everyone except external users, so you can see public team name and description, but from MS Teams (desktop or web application) you cannot see public team content until you are team member.

Org-wide team: you are joined the team automatically (details)

From Teams – you can click on “Join or create a team” and you should be able to see some public teams (but not all):

See how Microsoft describes it – Find and Join a team

There is a “Search teams” box at the top right,
so what if you are looking for a specific public team (not in the list) …

Scenario 1

You know exact team name or at least some first letters.
Solution: You are lucky. Just start typing team name in search bar at top right and hit “enter”- you will see shortened list of public teams matching your search criteria:

NB: do not use wildcards, it will not work:

NB: do not use top search bar, it will not work:

Scenario 2

You want to join a public team, but you do not know exact team name.
You know (or guess) something about the team, like

  • part of the team name
  • part of the team description
  • some keywords from team content files

Unfortunately, in this case both great Microsoft technologies – Search and Team – fail. You will not be able to find a public team:

What Microsoft says

Actually Microsoft does not have a solution and just did not provide workaround:
here is the concern “Search for a public team WITHOUT providing the exact name” with no answer from Microsoft.

Solution

Just use SharePoint search of Bing Search or Office.com – any other plain search wherever you can.
SharePoint site is created once a team is created to store actual content. If the team is public – SharePoint site behind will be accessible for everyone.

For public teams – SharePoint site has “Everyone except external users” by default in “Members” group:

which means literally “Everyone except external users” has access to the site with “Edit” permissions.

SharePoint search is security-trimmed, i.e. you will see the site content in search results only if you do have access to the site. So just go to the SharePoint landing page or SharePoint search center of Office.com and search for what you know or guess about the team:

You can use all the power of SharePoint search (wildcards, refiners, keyword query language KQL etc)

Once you found something – you can go to the SharePoint site:

Now from the site – look at the site name and hover the mouse over the site name – you’ll see pop-up window.
Now you know exact team name – and you can search for the team under Teams,
or, if you are so lucky you see “Join” button – just join the team.click site title or hove over the site title:

One moment – you cannot see team’s chat messages in SharePoint, as chats are kept in Azure. But you can search for chat content after you joint the team.

Somehow both – SharePoint Search and Teams Search are not working against site/team description. Hopefully this bug will be addressed.

You can also search for site Url in teams.
When you create a team – Office 365 generates a short team name (removes spaces and adds numbers if the team name is not unique; e.g. if the team name “Test” you might have “test381” as a short name, but if the team name is “This Is My Unique Team” – short name might be “ThisIsMyUniqueTeam”).
After you can change team name and/or SharePoint site name.
Team search under MS teams work for both names – short name initially assigned (kept as site specific Url) and new team name. But only starting with the beginning of the string.

Video tutorial

What is the correct way of searching for a Public Team in Microsoft Teams

Related articles:

btw, there is a good video tutorial on how to find a public team in Office 365 using full-text search

SPO: Description, Owner fields are not searchable

Update (Apr 2024): It seems like Microsoft changed this behavior for Microsoft 365, so consider this article as an obsolete. Though it is possible that content is still relevant for on-prem versions of SharePoint server.

Scenario:

You have a list (or a document library) in SharePoint Online.
You can search through the list but some fields (or document properties) like “Description”, “Subject”, “Author”, “Owner”, “AssignedTo”, “Created”, “CreatedBy” are not searchable.

Cause:

Crawled properties are mapped to non-searchable managed properties. So this is by design. Check Microsoft’s “Overview of crawled and managed properties in SharePoint Server” (we do not have this document for SharePoint Online, so we have to rely on this doc; though you can go to your Search schema in SPO to verify). You see some pre-created managed properties do not have “Searchable” option enabled.

Solution:

(See below for details, as this is still not finished:)

Prove:

I have created a new SPO site test78, a new list Test11 and created (not added from existing) a custom field “Description” to the list:

I also created “Description2” column the same way. No data is added to the list so far.

Search schema looks like:

for Description managed property:

mapping:

Notice that “Description” managed property is not searchable and “ows_Description” crawled property is mapped to “Description” managed property.

Searching for “ows_Description” crawled property gives me:

and that’s OK, as we have no data in the list so “ows_Description2” crawled property does not exist.

Now let me add some data to the list:

and wait a few minutes while continues crawl grabs data.

You can see:

Title and Description2 are searchable, but we are not able to search through “Description” field content.

Explanation

Actually this is by design.
Microsoft: “The index only includes content and metadata from the managed properties”.
(Maybe Microsoft tries to protect their resources from overloading or maybe they protect us from irrelevant results, but including entire document content in full-text search and at the same time not including properties like Document Subject – this does not make sense to me). So the sad fact is list column “Description” is mapped to non-searchable managed property by default.

“Searchable” means: “…The content of this managed property is included in the full-text index.” I.e. if the property is not searchable – “The content of this managed property is not included in the full-text index.” => that’s by design.

But – the good news – the property is Queryable!
Queryable “Enables querying against the specific managed property”.

E.e. “Description:Descr1*” query should work. And it works:

“Description2:Descr*” query should not work as we did not map Description2 property to any managed properties, so we can find content via full-text search but cannot find under managed property:

Solution

Option #1.
Use queries like “Description:TextToSearch” (check also SharePoint KQL).

Option #2.
Do not use name “Description”.
Choose something else like “Short Description” or “Case Description”

Option #3.
Use existing site column “Description” from group:Custom Columns. It’s “single line of text” though. Note: “SharePoint Server Standard Site Collection features” must be activated.

The thing is it’s internal name is “CategoryDescription” and display name is “Description”. So if you add this column to the list – the content will be searchable:

Option #4
Create a new site column, name it e.g. “DescriptionSrchblClmn”.
Add this column to the list from existing site columns.
Rename it to “Description”.

Option #5.
Create your own managed property (e.g. “DescriptionSearchable”), make it searchable and map it to “ows_Description” crawled property.

ensure crawled property has “Include in full-text index” option ON:

NB: changing search schema affects other site lists/libraries.

Remember: if you made a change in search schema, run “Reindex site” under Site Settings -> “Search and Offline Availability”. It’s like on-prem “Full crawl” but works at web level.

================================

Links.

Microsoft: Manage the search schema in SharePoint
Microsoft: Keyword Query Language (KQL) syntax reference
Vladilen: Search for a crawled property name with wildcards
Microsoft: Overview of crawled and managed properties in SharePoint Server

Search-for-a-crawled-property

Search schema: Search for a crawled property name wildcard

 

If you are managing SharePoint search, specifically if you are customizing SharePoint search schema, especially in SharePoint Online (Office 365) – you know how slow it works and how tiresome it is to “Search for a crawled property name”.

Search-for-a-crawled-property

Recently I found out that wildcard works. No, even two wildcards work

In this example I need crawled property started from ows and contains doc and type:

SharePoint search through crawled properties