Let say you administer Microsoft 365 SharePoint Online and you want to get a list of new SharePoint sites (e.g. sites created during last week/month).
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 site objects but the object does not have “Created” field. You have to connect separately to each site and get root web object where you can check when the web was created. For small environments it is possible, for large environments it can take days… And still not nice. -Filter option would help, but “…Currently, you can filter by these properties: Owner, Template, LockState, Url.”
Get-SPOSite – similar experience.
Microsoft Graph API helps. It returns result in seconds. There are some pros and cons for each method though.
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.
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.
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 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
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), + teams chats, outlook groups conversations, yammer conversation -> bing, office.com, sharepoint
Bookmarks (new promoted results), acronyms, Q&A – all under “Answers”
BookmarksTargeting – 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
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.
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)
There is a know problem in SharePoint – it’s complicated permissions system. As a result, many sites are overshared (over-exposed) and site owners/administrators even do not know – who has access to their sites…
The most concern is sites shared with “Everyone”, “Everyone except external users” and “All users”. How do we find sites shared with “Everyone” in a large Microsoft 365 tenant?
Approach #1 (Brute force)
We can get full permissions report at tenant level (or permissions provided to “Everyone”). There are 3-rd party tools (e.g. ShareGate, SysKit, AvePoint, Metalogix etc.), or you can run PowerShell script…
Sounds easy? Well, if you have 1000 sites – probably it will work. But if your environment 10K+ sites – it will take forever. Permission report might run hours for an average site with site/subsite, list/library and list item details level. So the approach will not work for large enterprise environments.
We cannot limit report with root web only – we need report detailed up to every item level deep, as even one file with sensitive info shared with everyone can cause security issue.
So, if this approach is not working – what’s working?
Approach #2 (Search)
Clever idea: why do we need to iterate through all the tenant documents/items if all the content is already crawled by search? Can we just use search to get files shared with Everyone? Sure!
The idea is to use some dumb/test user account with no specific permissions provided and no group membership and try to search content on behalf of the user. Results we get are obviously from sites shared with everyone.
Check this and this articles. Can we get results programmatically (e.g. with PowerShell)? Can we use Microsoft Graph search API? Sure. Check this article “How to search against SharePoint Online Content with Microsoft Graph search API with PowerShell”.
But! We have two problems here.
Search Problem #1. The problem is the same as in “brute force”. Search returns so many results – it’ll take weeks to get all of them. (There are team sites “legally” shared with everyone, public Office 365 group based sites, communication sites… ).
Search Problem #2. Even if we get all search results – we do not know – what is the exact Url of the resource shared with all users. So we will need to build list of sites based on the search results – ant then still need to run permissions report against these sites.
Approach # 3 Hybrid
The idea: why do we need to get all search result if even one result from a site would be enough to add the site to the list of sites require permission review.
So, consider (imho, the best) approach.
You get list of sites in tenant. Here you can refine the list excluding, e.g. sites connected to public teams or known communication sites… Using sensitivity labels you can start with high-sensitive sites. Finally you’ll have a list of sites you want to check – if there are resources on this site shared with “Everyone…”
You run search against each site in the loop (e.g. consider KQL option “Site: https://yourTenant.SharePoint.com/sites/YourSite”. Once 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 couple of minutes.
NB: consider there are resources like “Styles Library” shared with everyone by default.
The Next step would be “How to let site owners know what are resources shared with Everyone… on their sites”.
Quick and simple answer: use SharePoint Search center or Microsoft Search, (or Bing if it is integrated).
Detailed explanation on how to find a public Team
In Microsoft Office 365, under MS Teams, there are 3 team types:
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 publicteams (but not all):
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) …
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:
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:
Solution: use SharePoint search SharePoint site is created once a team is created.
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 or SharePoint search center 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.
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:
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.
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 by default list column “Description” is mapped to non-searchable managed property.
“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 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:
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 (under testing… TBU) Change default mapping. e.g. unmap “ows_Description” crawled property from “Description” managed property. This should be enough, as “ows_Description” crawled property has “Include in full-text index” option ON:
NB: if you unmap “ows_Description” crawled property from “Description” managed property, it’ll affect other site lists.
Option #6. In addition to option #5 you can create your own managed property (e.g. “DescriptionSearchable”), make it searchable and map it to “ows_Description” crawled property.
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.
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”.
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: