Found some really good articles:
Microsoft 365 Search: built-in people search by nickname
Did Microsoft silently implement nickname search?
E.g.

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:


Please check “How to configure Microsoft 365 People Search by Nickname and Full Name“
SPO Site LastContentModifiedDate vs LastItemModifiedDate vs LastItemUserModifiedDate vs Graph LastModifiedDateTime
How do we know when the SharePoint site was last updated?
We have multiple “when the site was modified last time” properties – e.g. some we can retrieve with SharePoint CSOM:
- Site LastContentModifiedDate
- Web LastItemModifiedDate
- Web LastItemUserModifiedDate
Also we can get
- MS Graph site object with LastModifiedDateTime property
- get usage reports via Microsoft Graph (activity reports), and
- use “Last activity” field via Admin Center GUI
On the other hand – we can view and modify site in multiple ways – visit site home page, open and/or update document/list item, change site/library settings, configure site permissions, assign site sensitivity label, setup site property and so on.
Question: which site “last modified” or “last activity” properties reflect what events/actions?
This might be important if we think of retention policies, or any kind of clean-up processes… Let say, we are getting report on abandoned sites (inactive sites), but we are also assigning sites sensitivity labels, or we are updating site custom properties (e.g. for adaptive scopes), we have an ownerless groups policy working etc.
What if we assign site sensitivity label to an old inactive (5 years old) site – would it affect retention policy since site was updated this way?
Results
So i did some tests and based on detailed results below, it seems like
- Web LastItemModifiedDate is triggered when user just visited site (but property LastItemUserModifiedDate is not triggered)
- If a document or list Item updated by user or app – all properties are triggered
- MS Graph site property LastModifiedDateTime, root web property LastItemModifiedDate and Site LastContentModifiedDate – same values
- If site custom property is updated – it does not affect any site “last modified” property
- The same for sensitivity label updated by app – it does not affect any site “last modified” property
- The same for Microsoft ownerless groups policy – when user accept or decline group membership – no site “last modified” properties are changed (the same is true for Microsoft 365 group last modified date/time property).
Please refer to the table below
Detailed test results
Test results if the event triggers property update:
Event | Last Content Modified Date | Last Item Modified Date | Last Item User Modified Date | Graph Last Modified DateTime | GUI Last activity |
Page viewed by user | Yes | Yes | No | Yes | |
Home Page viewed by user | |||||
Site Page viewed by user | |||||
Document or list item updated by user | Yes | Yes | Yes | Yes | |
Document or list item updated by app | Yes | Yes | Yes | Yes | |
Site config settings updated by user | |||||
Site config settings updated by app | |||||
Site custom property updated by app | No | No | No | No | |
Site Sensitivity label updated by user via SharePoint | Yes | No | No | No | |
Site/Group Sensitivity label updated by user via Teams | |||||
Site/Group Sensitivity label updated by user via Azure | No | No | No | No | |
Site Sensitivity label updated by app | No | No | No | No | |
Site collection admin updated by user | Yes | Yes | No | Yes | |
Site collection admin updated by app | Yes | Yes | No | Yes | |
SharePoint group membership updated by user | Yes | Yes | No | Yes | |
Standalone Site connected to a group by user | Yes | Yes | Yes | Yes | |
Add Microsoft Teams to Site by User | Yes | Yes | Yes | Yes | |
Update m365 group membership via M365 admin console by admin | Yes | Yes | No | Yes | |
Update m365 group membership via Azure by admin | |||||
Update m365 group membership via Teams by user | No | No | No | Yes | |
Update m365 group membership via App | |||||
Accept group ownership invitation sent by ownerless groups policy | No | No | No | No | |
Decline group ownership invitation sent by ownerless groups policy | No | No | No | No | |
Using Path property in Microsoft 365 Search Query
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 (“:”)
Path:https://contoso.sharepoint.com/sites/MySite
These path could be matched with:
Path:https://contoso.sharepoint.com/sites/MySite
Path:https://contoso.sharepoint.com/sites/MySite/subsite
Path:https://contoso.sharepoint.com/sites/MySite2
Path:https://contoso.sharepoint.com/sites/MySite2/subsite
Path:https://contoso.sharepoint.com/sites/MySite3
Obviously, the match intent is unclear. Adding a trailing slash clarifies that only MySite (and below) matches. So intended matches would be only:
Path:https://contoso.sharepoint.com/sites/MySite
Path:https://contoso.sharepoint.com/sites/MySite/subsite
Using SPSiteUrl property
The other option – use the SPSiteUrl property with the full path:
SPSiteUrl:https://contoso.sharepoint.com/sites/MySite
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.
Microsoft 365 Retention Policies SharePoint Adaptive Scopes Advanced Query
Basic query is available as GUI:

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…
References
SharePoint Sites Lookup
That’s a very common problem in SharePoint world. You are looking for a site owner but there is no tool available for regular user to find who owns the site.
Scenarios.
You get a link to some SharePoint site, but you do not have access to it. You requested access but nobody has responded. You need to find who is the site owner.
(To be continued)
PowerShell scripts for Microsoft 365 SharePoint
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.
It’s here: https://github.com/VladilenK/Manage-m365-with-PowerShell
Get all SharePoint and Teams sites owners report with PowerShell
This PowerShell script pulls all tenant sites and all sites owners. The script require app authentication with Sites.FullControl.All and Directory.Read.All permissions.
PnP.PowerShell for PowerShell 7 is used.
The script generates two reports
- Owners report: one user per line, include: Site Url, Title, Owner e-mail, name and type
- Sites report: one site per line, include: Site Url, Title, list of owners e-mails
Here is the script:
$connAdmin = Connect-PnPOnline -ReturnConnection -Tenant $tenantId -Url $adminUrl -ClientId $clientid -Thumbprint $certThumbprint
$allTenantSites = Get-PnPTenantSite -Connection $connAdmin | Sort-Object Url
$allTenantSites.count
$sitesReport = @()
$ownersReport = @()
foreach ($tenantSite in $allTenantSites) {
Write-Host $tenantSite.Url
$connSite = Connect-PnPOnline -ReturnConnection -Tenant $tenantId -Url $tenantSite.Url -ClientId $clientid -Thumbprint $certThumbprint
$site = Get-PnPSite -Connection $connSite -Includes RootWeb, GroupId, Owner
$siteOwnerEmail = ''
$siteOwnersReport = @()
if ($site.GroupId.Guid -eq '00000000-0000-0000-0000-000000000000') {
$siteAdmins = Get-PnPSiteCollectionAdmin -Connection $connSite | ? { $_.PrincipalType -eq 'User' }
$ownerType = 'Site Collection Administrator'
$isGroupSite = $false
}
else {
$siteAdmins = Get-PnPAzureADGroupOwner -Connection $connAdmin -Identity $site.GroupId.Guid
$ownerType = 'Group Owner'
$isGroupSite = $true
}
foreach ($siteAdmin in $siteAdmins) {
if (!$siteAdmin.UserPrincipalName) {
Get-PnPProperty -Connection $connAdmin -ClientObject $siteAdmin -Property UserPrincipalName | Out-Null
}
$aadUser = Get-PnPAzureADUser -Connection $connAdmin -Identity $siteAdmin.UserPrincipalName
if ($aadUser.AccountEnabled) {
$siteOwnerEmail += $aadUser.Mail + '; '
}
$siteOwnersReport += [PSCustomObject]@{
SiteUrl = $site.Url
SiteTitle = $site.RootWeb.Title
IsGroupSite = $isGroupSite
OwnerEmail = $aadUser.Mail
OwnerName = $aadUser.DisplayName
OwnerType = $ownerType
Enabled = $aadUser.AccountEnabled
}
}
$ownersReport += $siteOwnersReport
$sitesReport += [PSCustomObject]@{
SiteUrl = $site.Url
SiteTitle = $site.RootWeb.Title
IsGroupSite = $isGroupSite
OwnerEmail = $siteOwnerEmail
}
}
$ownersReport.count
$sitesReport.count
Source code: https://github.com/VladilenK/Manage-m365-with-PowerShell