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)
todo
Microsoft is improving Search (MC489165):
Manage result layouts for SharePoint results in Microsoft Search
We’re making changes to Microsoft Search. This update will allow Microsoft Search administrators to change result layouts for select SharePoint content using adaptive cards with Result Type feature in Microsoft Search administration.
The default result layouts for SharePoint sites, pages, list items and Portable document format (PDF) results can now be replaced with layouts built using adaptive cards. The changes can be made for Organization level search applicable to Office.com and SharePoint home as well as site level search on SharePoint sites. Changes for Microsoft Search in Bing will be rolled out soon. Note that the feature does not support changing of Office file search results.
This message is associated with Microsoft 365 Roadmap ID 81952
Before the change, when you add a new result type under “Search and intelligence” Customizations – it looked like this:
So there was no built-in “SharePoint” content source as an option – only custom “external” data sources.
But with the new feature implemented list of content sources for the result type will look like this:
If you choose “SharePoint and OneDrive” content source – the next option would be to select type of content:
You also can create different result types for different types of content based on properties-based rules (e.g. one result type for all sites – and a separate result type for a specific site or hub) with optional “Set rules for this type of content”:
Default site result experience would look like
Search results with modified SharePoint result type might look like:
When you modify template via Layout Designer – it is essential to know available object properties.
You can get properties from the “Available properties” below – there is also search through properties feature.
Or you can use SharePoint Search Query Tool to get metadata on search results.
It might take hours and even days for your search to start showing new layouts, but “&cacheClear=true” should help.
… to be continued …
References
Bert Jansen (Microsoft) revealed some details on throttling when you access Microsoft 365 programmatically – via Microsoft Graph or CSOM and guided developers on how to regulate request traffic for optimized throughput using RateLimit headers (Here).
Throttling is necessary to ensure that no single user or application consumes too many resources compromising the stability of the entire system, which is used by many clients.
Throttling happens at
Very common reason for throttling – when an Application (Delegated or Application permissions) reaches “Resource units per app per minute” threshold.
Usually you catch HTTP errors 429 or 503, wait for some time (respect Retry-after header) and try again.
SharePoint provides various APIs. Different APIs have different costs depending on the complexity of the API, but Microsoft favor Graph API over SharePoint REST/CSOM. The cost of APIs is normalized by SharePoint and expressed by resource units. Application’s limits are also defined using resource units.
Quota depends on tenant size.
Resource unit limits for an application in a tenant (please refer to the Microsoft article)
Predefined costs for Microsoft Graph calls:
What is the Microsoft Search KQL query field limits for a verticals? Is there limited number of characters or lines?
You know what is Microsoft 365 Search Vertical and what is KQL query in vertical configuration, right?
Under Microsoft 365 admin center Search and intelligence you can configure search verticals. There are some out-of-the-box verticals – like All, Files, Sites, People and you can configure custom one.
As a part of vertical configuration – you can specify KQL query – if you want e.g. limit search with some sites or content types etc.
The question is – how many sites I can specify in this query field? E.g. can I specify 1000 sites? 10k sites?
And the answer is: It does not matter, because the limit is not in number of characters or lines.
In my dev environment I was able to save 50,000 lines (~3M characters). But attempt to save 100K lines (6M symbols) has failed (due to timeout, I believe:
Again, as I said the problem is not here.
The problem is time required for search to apply query. I.e. when you ask search to bring you something – after it gets results from index and before display results to you it applies KQL query configured for the vertical. And this time is the bottleneck.
Here is what I got measuring search response time depending on query size:
| Search | response time, seconds | KQL query # of lines | KQL query size, # of symbols |
| works | 1 | 500 | 28,000 |
| works | 5 | 1000 | 59,000 |
| works | 9 | 2000 | 120,000 |
| works | 25 | 3000 | 180,000 |
| works/fails | 30 | 3500 | 208,000 |
| fails | 35 | 3600 | 214,000 |
| fails | 35 | 50,000 | 3,000,000 |
| n/a | n/a | 100,000 (can’t save KQL query | 6,000,000 (can’t save KQL query) |
Which means that after ~ 1000 lines (50,000 characters) KQL query size – query becomes too slow, and after ~3000 lines (180k chars) – can fail (due to timeout I’d say).
Every team in Microsoft Teams or a Microsoft 365 group or a SharePoint site must have an owner/owners. Otherwise to whom we communicate on any question – site/group permissions, membership, site/group/team retention policy, content classification etc. Who will be responsible for team/site/group content and configuration and who will provide access to this site for other users.
MS: A team in Microsoft Teams or a Microsoft 365 group and its related services can become ownerless if an owner’s account is deleted or disabled in Microsoft 365. Groups and teams require an owner to add or remove members and change group settings.
Recently Microsoft implemented a new feature: a policy that automatically asks the most active members of an ownerless group or team if they’ll accept ownership. Very important feature. TY Microsoft!
The configuration via wizard is straightforward and intuitive.
But still we have some questions regarding the policy.
Q: Why it is important?
A: Because many other “governance” activities (e.g. permissions attestation, retention policies) rely on site/team ownership. I.e., before we notify site owner that the site is going to be deleted due to inactivity – we want an owner present.
Q: Is it about groups ownership or sites ownership?
A: Group ownership and group-based sites ownership (teams, yammer etc.). Non-group based aka Standalone sites (e.g. communication) are not in scope of this feature/policy.
Q: Who can configure this policy? What kind of permissions required to create/update policy?
A: Microsoft says “Manage Microsoft 365 groups” permissions required – e.g. admins with Global admin or Groups Admin roles required. “Teams administrator” or “SharePoint Administrator” cannot configure the policy.
Q: How about group with no members? What if somebody created a group but did not add any members?
A: Assuming somebody created a group and left company. In this the policy will not work – as there is nobody who can be a new owner. This kind of groups must be handled manually, as no owners no members does not mean nobody uses related SharePoint site.
Q: How do we know the group is ownerless? Only if owner has been deleted from AAD? What if an owner is just blocked or unlicensed?
A: blocked or unlicensed users are still users; so the policy will be triggered if the group owners list is empty.
Q: We have implemented Azure AD Settings “EnableGroupCreation” and “GroupCreationAllowedGroupId” (as per Microsoft: Manage who can create Microsoft 365 Groups), so not everyone can create m365 groups. Would this impact ownerless groups policy? In other words – if a user cannot create group – would this keep user from being assigned as a group owners?
A: No. Microsofts’ Manage who can create Microsoft 365 Groups trick regulates groups creation only. Later – when a group is created – nothing prevents such user to be added as a group owner.
Q: I support a large Microsoft 365 environment and we already have hundreds of ownerless groups. I’m concerned how users might react and whether our helpdesk support teams are ready for new type of tickets etc. Implementing the policy in test/stage environment does not make much sense, since there are no really active users etc. So, can I test this policy in production – on real users, but pilot it within a small number of users or ownerless groups before applying to all groups in the environment.
A: Yes, you can do a test or pilot implementation in production limiting the impacted users or groups.
– if you need to limit users who will be getting notifications a “pilot team” – during Step 1 “Notification Options” under “Specify who can receive ownership notifications” you can select “Allow only certain active members” and under “Specify security groups to allow members” you can select a security group – so only members from the specified security group will be sent ownership request. Microsoft 365 groups do not work here.
NB: But there is a bug (I believe): When you specify this option (Allow only certain active members and a security group) – the policy just does not work.
another option – you can test the policy on a several selected m365 groups:
Q: I know the policy is applied to Microsoft 365 groups only. But I have many standalone sites with no owners (no site collection administrators). How do I deal with ownerless SharePoint sites?
A: How about converting standalone sites to Microsoft 365 group-based sites (TBC)?
Q: What happens to group that become ownerless after the policy is created?
A: The policy will be triggered against this group – so next day the most active group members will receive invitation.
Q: What happens if several of the notified members accepts the ownership request?
A: Two first served basis. As per Microsoft, only two members can be assigned to group owners via the policy. When a group got two owners – invitation message actionable item for the rest will be converted from “Would you like to be a group owner?” to “MemberName1 and MemberName2 have already agreed to become group owners.” with no “Yes” and “No” buttons.
How do I, as an Microsoft 365 administrator, know if the policy works or not, are the emails sent or not and how many (if any) users are accepted “Would you like to be a group owner?” invitation?
Microsoft 365 Audit Search under Microsoft Purview (Compliance center) should help.
Operations:
UserId: OwnerlessGroupComplianceAssistant
Record Type (AuditLogRecordType): 126
It seems like event is not added to the Audit log when a policy is created or updated.
If a public group does not have an owner – all requests to joint the team will be declined with “The team does not have an owner” message:
(that means no new members, i.e. no new contributors, but read-only visitors access is sill available for everyone, as group is public):
Users can go to My Groups to see groups (Teams, Yammer communities and SharePoint Sites) they are members or owners of.
Proposal to be a group owner lasts forever. So if a user after some time finds an email that asks him “Would you like to be a group owner?” and clicks Yes – he/she will be a group owner, even if the policy is already updated or removed.
As per Microsoft, only first two members can accept the ownership of an ownerless group. No additional members are allowed to accept ownership. If either one or two members accept ownership, other members won’t receive further notifications.
Q: Can I customize an ownership notification?
A: Yes, but
– E-mail message body is limited to ~1040 character
– Policy does not provide any WYSIWYG rich text format, but you still can format it – headers, bold/italic, links, bullets/lists: more on email template format.
A member can forward invitation message, but recipient will not see actionable “Yes” “No” buttons.
Who can create Microsoft 365 Groups
It is possible to limit users – who can create Microsoft 365 Groups (please refer to Microsoft: Manage who can create Microsoft 365 Groups – there is a guide and PowerShell code sample). This might help to keep the environment under control – let say, “only managers can create groups”, or “contractor should not be able to create teams”.
It would be good if the configuration would be consistent in terms “if a user cannot create a group – user cannot be a group owner”. Unfortunately, with current configuration options (Aug 2022), this is not the case.
Azure AD Directory Setting “GroupCreationAllowedGroupId” works only for creation. Later, when the group is create – it is possible to add to group as a group owner those who is not able to create group.
“Ownerless group policy configuration failed” error message.
And “Failure in configuring ownerless groups policy” and “Please try again.”
– seems like a permission issue.
SharePoint admin, Teams admin or Group admin roles: cannot configure Ownerless Groups Policy.
Global admin: yes, can configure Ownerless Microsoft 365 Groups Policy.
What is the minimum role required?
According to a recent update of the Microsoft’s article – “A Global administrator can create a policy…”
If I get token with (Graph, MSAL, PnP) and use this token for (Graph API, SharePoint CSOM API, SharePoint REST API) matrix.
An App used in this tests has Sites.FullControl.All MS Graph API and SharePoint API permissions, as well as FullControl ACS based permissions to SharePoint (AppInv.aspx).
| Token/API | MS Graph /v1.0/sites | SharePoint CSOM PnP.PowerShell Get-PnPSite Get-PnPTenantSite | SharePoint REST API PnP.PowerShell Invoke-PnPSPRestMethod Invoke-RestMethod |
| MS Graph /oauth2/v2.0/token secret | OK | (401) Unauthorized | AudienceUriValidationFailedException |
| MSAL.PS Get-MsalToken with secret | OK | (401) Unauthorized | AudienceUriValidationFailedException |
| MSAL.PS Get-MsalToken with certificate | OK | (401) Unauthorized | AudienceUriValidationFailedException |
| PnP.PowerShell Get-PnPAccessToken with Certificate | OK | OK OK | OK AudienceUriValidationFailedException |
| PnP.PowerShell Get-PnPGraphAccessToken with Certificate | OK | OK OK | OK AudienceUriValidationFailedException |
| PnP.PowerShell Get-PnPAppAuthAccessToken with Certificate or secret | InvalidAuthenticationToken | OK OK | OK OK |
| PnP.PowerShell Request-PnPAccessToken with Certificate | InvalidAuthenticationToken | OK OK | OK AudienceUriValidationFailedException |
| PnP.PowerShell Request-PnPAccessToken with Secret | InvalidAuthenticationToken | OK OK | OK OK |
What if 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
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 or service accounts like SharePoint_Support@contoso.com
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 stating that currently it is not possible, 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 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:
(WIP)
| 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 | On | On | Off | On |
| Get-AzureADUser -ObjectId … | Select -ExpandProperty 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 |
Doesn’t it seem confusing we have properties:
Are these properties related to each other?
(WIP) 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 |
Some findings:
Note: Az module works fine too. I.e. Get-AzADUser instead of Get-AzureADUser and Set-AzADUser instead of Set-AzureADUser.
Sites.Selected MS Graph API permissions were introduced by Microsoft in March 2021. One year later, in 2022 they added SharePoint Sites.Selected API permissions.
Why is this so important? Because MS Graph API for SharePoint is still limited and cannot cover all possible needs. I’d estimate: 90% of applications use SharePoint CSOM, so developers have to use AppInv.aspx to provide permissions for their applications to SharePoint API.
But from this moment – having SharePoint API permissions in MS Graph – in theory – we can fully rely on permissions provided in Azure and – in theory – this should allow us disable SharePoint-Apps only principal:
Set-SPOTenant -DisableCustomAppAuthentication $trueMy math professor taught me: “before trying to find a solution – ensure the solution exists.” So let us test:
Are we really able to work with a specific SharePoint site using MS Graph and SharePoint API Sites.Selected permissions provided via Microsoft Azure?
What will happen with our new/legacy applications if we disable SharePoint app-only SPNs (DisableCustomAppAuthentication)?
I’m getting controversial test results… maybe PnP.PowerShell 1.10 is not fully support SharePoint Sites.Selected API.
Tech Wizard (Sukhija Vikas) on March 20, 2022 in the article “SharePoint and Graph API APP only permissions for Selected Sites” suggests using pre-release (AllowPrerelease).
So please ignore the following for a while.
Meantime I’ll test providing SharePoint Sites.Selected API permissions via Graph API call.
DisableCustomAppAuthentication: $false (SP-app-only spns are enabled).
All applications have “write” access provided to a specific site only.
Connecting with Connect-PnPOnline and then test access with Get-PnPSite
| App / Get-PnPSite | Secret | Certificate |
| ACS based (Azure+AppInv) | OK | The remote server returned an error: (401) Unauthorized. |
| MS Graph API Sites.Selected | The remote server returned an error: (403) Forbidden. | The remote server returned an error: (401) Unauthorized. |
| SharePoint API Sites.Selected | OK | OK |
| MS Graph API + SharePoint API Sites.Selected | Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) | OK |
| App with no permissions | The remote server returned an error: (403) Forbidden | The remote server returned an error: (401) Unauthorized |
| Action/Via | SharePoint + MS Graph Sites.Selected “secret” | SharePoint Sites.Selected “secret” | MS Graph Sites.Selected “secret” |
| Connect-PnPOnline | WARNING: Connecting with Client Secret uses legacy authentication and provides limited functionality. We can for instance not execute requests towards the Microsoft Graph, which limits cmdlets related to Microsoft Teams, Microsoft Planner, Microsoft Flow and Microsoft 365 Groups. | WARNING: Connecting with Client Secret uses legacy authentication and provides limited functionality. We can for instance not execute requests towards the Microsoft Graph, which limits cmdlets related to Microsoft Teams, Microsoft Planner, Microsoft Flow and Microsoft 365 Groups. | WARNING: Connecting with Client Secret uses legacy authentication and provides limited functionality. We can for instance not execute requests towards the Microsoft Graph, which limits cmdlets related to Microsoft Teams, Microsoft Planner, Microsoft Flow and Microsoft 365 Groups. |
| Get-PnPSite | OK | OK | The remote server returned an error: (403) Forbidden. |
| Get-PnPList | OK | OK | |
| Get-PnPListItem | OK | OK | |
| Set-PnPSite | Attempted to perform an unauthorized operation. | ||
| Set-PnPList | Attempted to perform an unauthorized operation. | ||
| Set-PnPListItem | OK | OK | |
| New-PnPList | Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) | ||
| Add-PnPListItem | OK |
DisableCustomAppAuthentication = $false
(SP-app-only spns are enabled).
All applications have Sites.Selected SharePoint and MS Graph API permissions.
Using Client Secret (not a certificate)
Using PnP.PowerShell
| Read | Write | FullControl | |
| Connect-PnPOnline | WARNING: Connecting with Client Secret uses legacy authentication and provides limited functionality. We can for instance not execute requests towards the Microsoft Graph, which limits cmdlets related to Microsoft Teams, Microsoft Planner, Microsoft Flow and Microsoft 365 Groups. | WARNING: Connecting with Client Secret uses legacy authentication and provides limited functionality. We can for instance not execute requests towards the Microsoft Graph, which limits cmdlets related to Microsoft Teams, Microsoft Planner, Microsoft Flow and Microsoft 365 Groups. | WARNING: Connecting with Client Secret uses legacy authentication and provides limited functionality. We can for instance not execute requests towards the Microsoft Graph, which limits cmdlets related to Microsoft Teams, Microsoft Planner, Microsoft Flow and Microsoft 365 Groups. |
| Get-PnPSite | Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) | ||
| Get-PnPList | Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) | ||
| Get-PnPListItem | |||
| Set-PnPSite | |||
| Set-PnPList | |||
| Set-PnPListItem | |||
| New-PnPList | |||
| Add-PnPListItem |
C#, SharePoint CSOM, PnP.Framework
PnP.PowerShell Get-, Grant-, Set- and Revoke-PnPAzureADAppSitePermission cmdlets require Azure App with MS Graph Sites.FullControl.All app permissions (otherwise it says “Access denied”) and authentication via certificate (otherwise it says “This cmdlet does not work with a ACS based connection towards SharePoint.”)
The same actions – managing permissions for the client app to the specific site collections – could be done via Microsoft Graph Sites Permissions API using just secret-based authentication.
If an azure app does not have Sites.Selected API permissions configured – “Grant-PnPAzureADAppSitePermission” works as expected – no error messages – the output is normal – as if Sites.Selected API permissions were configured in the app. The same for Get-, -Set and Revoke-. Permissions provided for the app to the site are not effective though: Connect-PnPOnline works well, but all other commands – starting from Get-PnPSite – returns “The remote server returned an error: (403) Forbidden.”
If an app have no permissions to SharePoint – “Connect-PnPOnline” works ok, but “Get-PnPSite” return an error: “The remote server returned an error: (403) Forbidden.”
Set-PnPAzureADAppSitePermission gives an error message “code”:”generalException”,”message”:”General exception while processing”
if the site is not specified.
AppInv is not working?
Error: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))