Some findings (TBC)
There are site properties that cannot be modified if custom script is disabled.
E.g. we can setup site property bag only if DenyAddAndCustomizePages is set to False.
Some findings (TBC)
There are site properties that cannot be modified if custom script is disabled.
E.g. we can setup site property bag only if DenyAddAndCustomizePages is set to False.
I will be saving my personal gotchas on Microsoft 365 External Access and Guest Access in SharePoint and Teams
We configure external/guest access in AAD, m365 Admin Center, Teams Admin Center, SharePoint Admin Center, specific Group, Team or SharePoint site.
We can configure external guest access directly, or can configure sensitivity labels and policies in Purview (Compliance Admin Center). Configuring sensitivity labels for sites/groups we configure external guest access settings. Configuring sensitivity labels policies we apply labels.
Be careful with “All users” group created as part of the process.
Microsoft: “The dedicated All Users group includes all users in the directory, including guests and external users.” And indeed, “All Users” group by default include external users.
So here is the scenario: we have a site where external sharing is enabled, and someone is sharing a specific file1 or folder1 with some external users. The other site/group member is sharing another file2/folder2 with “All Users” assuming All Users means all this group member. This gives external users access to file2/folder2.
Option 0: remove “All Users” group
Option 1: exclude External users or Guest users from “All Users” group:
(user.userPrincipalName -notContains "#EXT#@")
or
(user.userType -ne "Guest")
(explained here).
Option 2: schedule a job that removes “All Users” from all sites UIL. Optionally inform site owners not to use “All Users” but use “Everyone except external users”.
Let say, you have a public site and you indeed want to provide access to all internal users with the exception of specific relatively small group of people. E.g. 10,000 users in company and only 200 are not fully integrated yet and you do not want to consider as equals in rights to all others and you do not want to provide automatic access. Unfortunately, there is no “deny access” options in SharePoint. All the functionality is about to “allow access” to something. What are you options?
Option 1: Create a security group and include in the group 9,800 users.
In this case you’d need to review all sites with access provided to EEEU
Option 2: Change user type in AAD (Entra Id) from Member to Guest.
In this case those users will not be a part of EEEU. They will be “Internal Guests”.
You’ll still be able to provide direct access to sites and include such users in teams but they will be marked as Guests.

Think of it that there are internal and external users, and there are guests and members.
Typically all internal users are members, and all external users are guests. But that does not always reflect real life. And if you change a “User type” property for some internal user from Member to Guest – this users will be an Internal Guest. Check this MS article: Understand and manage the properties of B2B guest users
Aug 2024 Update: you cannot apply site template from Look Book. You must use PowerShell to apply a Look Book template to your site.
Here is the article: Applying PnP Templates to SharePoint Sites
Some templates can be applied by regular users (site admins) and some templates would require SharePoint tenant admin permissions. But now it’s only via PowerShell. You can get an idea how templates look like at
PnP provisioning engine is something that us used under the hood.
If you are interested in automation of provisioning templates – please let me know in comments below or via site feedback.
===============================
So the information below is obsolete and I will keep it just for the sake of history of SharePoint:
SharePoint Look Book – a site with a collection of modern SharePoint site templates. You can browse through dozens of good-looking templates… but how do you apply chosen template to your site?
Gotcha #1
There is a button “Add to your tenant>” and it says “You must be a tenant administrator to deploy this template.” Really? No… but
Actually, SharePoint Administrator role is required to apply template from lookbook.
So yes, tenant-level admin role but just SharePoint service admin role.
Site admin role is not enough…
Gotcha #2
Next, when you try to get template by clicking “Add to your tenant>” button, it actually offers you to create a new site. But it also says “…can use existing URL”. Really? No.
When you type existing site Url into the “Relative URL to be used for the site” field –
You can get “Can’t add this template. The provided site is already in use and the current template cannot be provisioned onto an already existing site. Please provide a different URL” message:

Or, if you managed to enter existing Url, you might get: “Unfortunately your site provisioning at least partially failed!”:

Note: When you follow instructions provided by Microsoft, beware that “Connect-AzureAD” works only in Windows .net framework – i.e. PowerShell 5.1.
if you try to run it in PowerShell 7 – you can get “Connect-AzureAD: One or more errors occurred. (Could not load type ‘System.Security.Cryptography.SHA256Cng’ from assembly ‘System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’.)” Error.
(check Connect-AzureAD Could not load type ‘System.Security.Cryptography.SHA256Cng’ from assembly)
Sensitivity labels are configured under Microsoft Purview (Compliance Center), Solutions, Information Protection. You’d need a global admin or “Compliance Administrator” or “Azure Information Protection Administrator” (?) role:

Since we are talking sensitivity labels for SharePoint Sites (not documents), we define label scope as “Groups and Sites”: “Configure privacy, access control, and other settings to protect labeled Teams, Microsoft 365 Groups, and SharePoint sites.”

Then we define which protection settings for groups and sites we should configure on the next steps:
– Privacy and external user access settings – Control the level of access that internal and external users will have to labeled teams and Microsoft 365 Groups.
– External sharing and conditional access settings – Control external sharing and configure Conditional Access settings to protect labeled SharePoint sites.

If we selected previously “Privacy and external user access settings” – now we need to select group/team privacy (These options apply to all Microsoft 365 Groups and teams, but not standalone sites). When applied, these settings will replace any existing privacy settings for the team or group. If the label is removed, users can change privacy settings again. You can also allow external user access – if group owner will be able to add guests:

Next step – define external sharing and conditional access settings. Specifically, if the content of the SharePoint site can be shared with Anyone (anonymously) or with authenticated users (new or existing) or no external sharing is allowed:

And you can either control the level of access users have from unmanaged devices or select an existing authentication context to enforce restrictions:

Sensitivity label policy is basically which label should be available to apply for what users and some other settings like
– do users need to provide justification before removing a label or replacing it with one that has a lower-order number or
– will users be required to apply labels and optionall the default label

“Global reader” role allows view existing sensitivity labels configuration:

Wording would be a little different, but all aspects of the label configuration will be mentioned. E.g. when editing GUI says label scope is “Groups & sites”, read-only label summary defines Scope as “Site, UnifiedGroup”.
Site sensitivity label is applied to site collection only and cannot be applied to subsite (web object).
To apply a label to a m365 group or Teams site with a group behind: MS Graph API support only Delegated permissions.
“Set-PnPSiteSensitivityLabel” works in the current site context.
Description says “If the site does not have a Microsoft 365 Group behind it, it will set the label on the SharePoint Online site and will not require Microsoft Graph permissions and will work with both delegate as well as app only logins.”
In fact (7/22/2022) app permissions are not working. This cmdlet can assign label to a standalone or a group-based site only with delegated permissions.
“Set-PnPTenantSite” allows you to remove or apply site sensitivity label to both standalone and group-based sites with app permissions. Furthermore, group and team settings respect this. I.e. if you apply label to a group-based site – group will pick this up.
Channel sites should inherit sensitivity label from root site.
I’m not sure if it’s a bug but
– when you create a team and select sensitivity label as part of team creation process – all the channel sites you create after (Private or Shared) will inherit sensitivity label immediately
– when you apply sensitivity label to an existing team – with existing channel sites – in this case Private channel sites inherit team sensitivity label immediately, but with Shared channel sites it’s strange: GUI shows sensitivity label assigned, but site object model does not.


References
Every resource under Microsoft 365 (Microsoft Teams team, Microsoft 365 group or 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.
NB. This article is about ownerless groups policy. There is a new (released 6.3.2025) “Site Ownership Policies” that can work against standalone sites.
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!
It is important 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.
That is how out-of-the-box notification email looks like:

The configuration via wizard is straightforward and intuitive, and Microsoft documented it well, but still we have some questions regarding the policy behavior.
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.
Upd (June 2025): Microsoft released a new SharePoint “Site Ownership Policies” that works against standalone sites.
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: After the policy activated – who will receive notification? What exactly “most active members” mean?
A: Microsoft only says “most active members” and does not disclose specific algorithm behind.
Q: How about group with no members? What if somebody created a group but did not add any members and then left?
A: In this case the policy will not work – as there is nobody who can be notified. This kind of groups must be handled manually, as no owners no members does not mean nobody uses related SharePoint site. What if the group is public and hosts some valuable data?
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 became unlicensed?
A: For the policy Microsoft consider blocked or unlicensed users presented in the group owners list as valid users and still group owners; so the policy will not be triggered until 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. Microsoft’s 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 and thousands 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 – e.g. 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.

but be aware – if you choose this option – it is possible that Microsoft 365 groups might have more active members who are not the security group members. E.g. it might make sense to use this option for piloting – against a small number of isolated set of groups/members, but for not for phased implementation. If you have some specific requirements for group ownership – e.g. “only managers could be group owners” or “contractors cannot be group owners” – using security group to limit potential group owners would make sense.
Another option you can use for phased implementation or piloting the policy is to scope it down to a several selected m365 groups – use “Apply policy to” – “Specific groups” option:

NB! After all notifications are sent for a group – you will never ever get any more notifications for the same group. Even if you re-activate the policy or change policy parameters or whatever – it will not help. Once messages sent – it’s done for the group forever.
NB: Please also check “Microsoft ownerless groups policy in large environment“
Q: How many groups I can specify if I select Apply policy to Specific groups option? Is there a maximum?
A: Yes, there is a limit. You can specify no more than 50 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: Options are: manual intervention, PowerShell, 3-rd party tools – depending on your specific case. E.g. you can elevate some “Site Owners” SharePoint group members to site administrators. For modern sites – how about converting standalone sites to Microsoft 365 group-based sites (TBC – as at the moment it is not clear if it is possible)?
Q: What happens after one of the notified members accepts the ownership request?
A: No more notifications will be sent for this group. But previously sent notifications will still be valid.
Q: What happens if several of the notified members accepts the ownership request?
A: Only 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” actionable buttons.

NB!
I have tested the policy one more time, and this time after first member accepted ownership – no other members were able to accept ownership. They got a message “Johan Lorenz has already agreed to become group owner”:

@Microsoft, any comments?
Q: What if admin assign owner to group?
A: The group becomes not ownerless. Notification messages will not display invitation to become an owner anymore, and instead of “Would you like to be a group owner? – Yes or No buttons” it will be shown as “username has already agreed to become group owner.”:

Q: Can I customize an ownership notification?
A: Yes, but
– E-mail message body is limited to ~1040 characters
– Policy does not provide any WYSIWYG rich text format options (but there are some tricks you can use to format it with headers, bold/italic, links, bullets/lists: more on email template format.)
Q: Can I use shared mailbox or security group or distribution list as a “send from” e-mail account?
A: No. You can use only user or m365 group mailbox.
Q: Should “send from” user e-mail account be licensed with Exchange?
A: TBD (but most likely no).
Q: What if a group become ownerless after policy is activated?
A: Policy detects the group is ownerless and start sending notifications within 24 hour.
Actually the policy was designed to prevent ownerless groups. So it is recommended to activate the policy once you get the tenant.
Q: We know, that if a user declined ownership once – he will not get any more emails on the same. Is that true for current policy or for any further policies activations? I.e. If the policy updated/re-activated – will it remember user’s decision or it all starts from scratch?
A: TBD
All the next incarnations of the policy will not trigger e-mail notification for the group if all notifications were sent earlier. I.e. in this case user will not receive any more notifications on the same group.
Q: If user declines ownership – does that mean that somebody else will start getting emails so “number of active members” configured stays the same? What if all “active members” choose “No” at week 1 – will the policy select other members or what?
A: No. The policy will send notification to other initially selected members.
Q: If nobody accepted ownership – can we reconfigure the policy to sent more notifications – e.g. to wider range of active members or with more strict language in an e-mail template?
A: Yes and No.
Yes – if you e.g. specified 2 members and 6 weeks in the policy, and then after 3 weeks you want to increase number of members to notify to 10. But (it seems like it’s a bug) you have to deactivate the policy and activate it again with new parameters.
No – if the policy’s specified number of notifications is expired. I.e. if all emails supposed to be sent are sent – no more emails will be generated for this group, even if you reconfigure or deactivate/activate the policy, so the group active members will not get any more notifications on the same group. Workaround: you can add a dummy account to group owners and then delete this dummy account from AAD, so groups become normal and then ownerless again.
Q: What if we specify emails should be sent for 5 weeks, but stop the policy after two weeks? And then we re-activate the policy.
A: It is expected the policy will continue sending e-mail notifications until 5 emails sent.
Q: What if we specify 3 weeks in policy, but then re-configure the policy with 5 weeks specified and activate it again?
A: tbc – not tested yet
Q: Is there a difference in the policy behavior when we reconfigure the policy or deactivate and then reconfigure the policy?
A: Yes, at least – what I noticed so far:
To update number of members to notify – if you just reconfig the policy – it pics up update but acts like there was no updates. So to actually update number of members to notify you need to deactivate the policy and activate it again with new parameters.
Q: What if we have more than 10,000 notifications to send? Will the policy drop some of them or all notifications will be send but next day?
A: tbc – not tested yet
Q: Let say we have an ownerless group with 20 members. Let say we specified security group to limit user who will get invitations. And this security group includes only 6 users from the orphan group out of total 20. Microsoft says the policy will select the most active users. So the question is: will the policy select the most active users from the 20 orphaned group users and if the user in the security group – he/she will get an email?
A: No. The policy will select the most active users only from these 6 users that included in the security group, ignoring 14 users, even if they were more active then these 6 selected.
Q: What happens after the policy expires? E.g. after all notifications are sent…
A: Policy does not expires. If the policy is activated – it works. If all notifications are sent for the group – so yes, policy is done for this group. But if a new group became ownerless – policy will be triggered for this group again.
Q: If all the notifications are sent for the group – what are admin options to activate ownerless groups policy against this group?
A: There are no “legal” options, but there is a workaround. You can add an owner to the group and then delete this account – so this way you make the group ownerless again – and the process would start from scratch, as for the policy this group will be a new ownerless group.
User can forward invitation message, but recipient who is not a selected group member – will not see actionable “Yes” “No” buttons. Selected Group
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.
You can de-activate the policy and then activate it again. Or you can reconfigure the policy. If you activated the policy again (or re-configured it), but emails are not sent – this might be an expected behavior. Let say you initially specified 3 weeks and 3 notification were sent to the most active ownerless groups members. That means no more emails will be generated for these groups.
Just uncheck “When there’s no owner…”, and save it to stop the policy:

downside – you’d need to configure the policy from scratch – all previous settings are gone now
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:
(No-brainer) – means that the policy sent e-mail notification to some of the group members. Under “Members” property you can see list of notified users, and under ExtendedProperties – “FirstNotificationDate” and “NotificationChannel” (usually “Outlook”)
Could have “ResponseType” as “AcceptOwnership” or “DeclineOwnership” under ExtendedProperties, as well as “OwnerCount”.
indicates all notifications are sent and the group is still ownerless. In the event details you’ll find under ExtendedProperties:
{
"Name": "FirstNotificationDate",
"Value": "05/04/2023 13:46:07"
},
{
"Name": "LastNotificationDate",
"Value": "05/11/2023 14:28:21"
},
...
UserId: OwnerlessGroupComplianceAssistant
Record Type (AuditLogRecordType): 126
It seems like event is not added to the Audit log when a policy is created or updated.
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”.
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. But, if you want your tenant configuration consistent in terms “if a user cannot create a group – user cannot be a group owner” – consider using the same security group in policy’s notofication options “Specify who can recieve ownership notifications”
And “Failure in configuring ownerless groups policy” and “Please try again.”
– seems like a permissions 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…”. In my experience – groups admin can also configure the policy.
When a user clicks on a button “Yes” or “No” in a notification email, a message “The remote endpoint returned an error (HTTP ‘500’). Please try again later.” pops up:

Since around Feb 5 2025 users who want to accept group ownership and click Yes – get an error message “We are unable to complete that action right now.Please try again later.”
Microsoft is aware of it. Waiting for a fix.
Microsoft recently implemented “Adaptive Scopes” for retention policies”. Before that we had to use “static” scopes only, i.e. we could apply the policy to all sites or to specific selected sites we had to choose manually. With adaptive scopes we can use rules like “This adaptive scope must include all sites with Site Url starts with A or Site name starts with A” and so on. And then we’d apply the retention policy to all the sites in this adaptive scope. This is nice, but actually site Url and site name does not have much to do with sites categorization for the retention policies. How can we implement sites classification to apply different policies to different sites categories? Luckily, when you configure adaptive scopes, you can use Refinable Strings, and refinable strings is something you can configure to have values from custom site properties. So finally we can assign specific value to custom site property and the site would fall under this or that retention policy based on the value we dynamically assigned to the site.
Note: you can also use site properties like date site created or site last modified date in advanced query builder under adaptive scopes – please check “Microsoft 365 Retention Policies SharePoint Adaptive Scopes Advanced Query“.
The steps are:
Detailed steps:
Create an indexed site property or “Adaptive Scope Property” with some values. Ensure you property name (key) is unique, e.g.
| Property | Value |
|---|---|
| SiteRetentionCategory | Y10 |
You can use PowerShell (with PnP.PowerShell module) commands:
Set-PnPAdaptiveScopeProperty or
Set-PnPPropertyBagValue -Indexed:$true. Examples:
Set-PnPAdaptiveScopeProperty -Key "SiteRetentionProperty" -Value "Y10"
Wait until search crawler picked up you site property. Now you have a crawled property.
As you know, Refinable Strings are just pre-created by Microsoft refinable managed properties. So you can select one that is not used(*) and map it to crawled property.
You can assign alias so you could easily identify what is the RefinableString55 about (but aliases do not work in advanced query).
select one that is not used
select one that is not used is an important, bacause if you select refinable string that is already taken at the some site level – there is a conflict. So before configuring pre-created refinable properties at tenant level – I’d recommend to get report on managed properties taken at sites levels. It would be good idea if you arrange with sites owners on properties ranges (e.g. from 00 to 99 – reserved for tenant use, from 100 to 199 – available at sites level search customizations). And/or you can – after getting report on managed properties taken at sites levels – reserve all unused managed properties by assigning aliases e.g. “this-property-55-is-reserved-by-admin-for-tenant-level-config”.
site custom script
If site custom scripts are enabled (DenyAddAndCustomizePages = false), then site collection admin can change site properties. So if you do not want the property being altered at site level – ensure that noscript site property is enabled (DenyAddAndCustomizePages equals true)
If site custom scripts are disabled (DenyAddAndCustomizePages = true), then an admin must enable them before using “Set-PnPPropertyBagValue” cmdlet (then disable again).
“Set-PnPAdaptiveScopeProperty” cmdlet handles this automatically.
If you configure Verticals Query at the tenant level – i.e., Microsoft 365 Administration -> Settings -> Search and intelligence -> Customizations -> Verticals
then search results will be trimmed everywhere – SharePoint Landing Page, Office landing page (Office.com), Office App, Bing search (but not other sites).
Teams search will not be affected as from Teams you only search for teams content. Same for Onedrive and Yammer. Sites with site or hub search scope will not be affected too.
If you configure verticals at site level: Site Settings -> Microsoft Search -> Configure search settings -> Verticals
and want this be in effect – ensure site search scope is set to site or hub scope. But in this case you will loose answers functionality.
Global search settings – like acronyms, bookmarks and verticals – works only at tenant level search or at site leve if the site search scope is set to tenant.
If site search scope is site or hub – then site-level search verticals will apply (and no answers functionality will be possible).
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 |
Published: May 1, 2022
Update from Mar 5, 2023: Microsoft confirmed this as valid solution.
Update from May 20, 2024: still true
Update from June 12, 2024: I have just found “ABP in Exchange Online“
Update from Oct, 2025: Teams Search now respects hidden user attributes (e.g., ShowInAddressList, HiddenFromAddressListsEnabled)
You want specific users do not appear in Microsoft 365 SharePoint, Teams or Outlook search results. For instance, when user left company and the account is not deleted, but just disabled in Entra Id (Azure AD), so account is present and searchable. Or there are two accounts of the same person – main one and a secondary one – so you want secondary account is removed from org structure and search. Etc.
Set “ShowInAddressList” Azure AD User object property to false.
It’s done using Az module, e.g. with PowerShell:
Update-AzADUser -UPNOrObjectId $upn -ShowInAddressList:$false
In many cases we do not need some accounts to appear in Microsoft 365 Search. Examples are:
a) secondary or 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.Admin@contoso.com
b) role, shared or service accounts: marketing@contoso.com
c) non-mail-enabled objects
d) disabled accounts
Getting multiple search results for the same person might confuse users and even lead to miscommunication and broken processes.
There is a good article by Tania Menice (Microsoft): Exclude Users From Delve and SharePoint Online People Search with the latest updates explaining how it is done for classic search and stating that currently it is not possible for modern search, but Microsoft is working on it.
In short, the article says:
It works perfect for classic search. The problem is it does not work as expected in modern Microsoft Search.
“People” vertical is not customizable so far. So we cannot change query in Microsoft 365 search to do the same trick. But… it seems like Microsoft is working on it so finally it should be done by some kind of ootb config.
Here is how different services or search entry points respect SPS-HideFromAddressLists SharePoint UPA 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:

I tested behavior for different kind of accounts and here are results:
| User Account | #1 | #2 | #3 | #4 | #5 |
| Enabled | Yes | No | Yes | Yes | Yes |
| Licensed (E5) | No | Yes | Yes | Yes | Yes |
| m365 Admin Center: Show in Global Address List | n/a | No | No | Yes | No |
| Exchange Admin Center: Hide from global address list (GAL) | n/a | Yes | Yes | No | Yes |
| ShowInAddressList Entra Id property value | null | null | null | null | False |
| SPO UPA ‘SPS-HideFromAddressLists‘ value | False | False | False | False | True |
| Outlook Address List “All Users” | Shown | ||||
| Office.com Search: Vertical “All” | Shown | ||||
| Office.com Search: Vertical “People” | Shown | Shown | Shown | Shown | |
| Bing Work Search: All/People verticals | Shown | Shown | |||
| Teams Search: “All” Vertical | Shown | Shown | |||
| Teams Search: “People” vertical | Shown | Shown | Shown | Shown | |
| Microsoft 365 Profile card – Organization | Shown | Shown | |||
| Teams Profile card – Organization | Shown | Shown | Shown | Shown | |
| Teams People Picker | Shown | Shown | Shown | Shown | |
| SharePoint People Picker | Shown | ||||
| Outlook People Picker: | Shown |
It seems confusing we have 4 properties responsible for the same:
Are these properties related to each other?
Let’s test it:
| Action-Consequences (immediate reaction – minutes if not other mentioned) | “Show in Global Address List” under m365 Admin Center | “Hide from global address list (GAL)” under Exchange Admin Center | ShowInAddressList Azure AD User object property | SPS-HideFromAddressLists SharePoint User Profile property |
| New user created, license assigned | Yes | Off | null | False |
| Uncheck “Show in my organization address list” under Microsoft 365 admin center | No | On | after one minute: null after 24 hours: null | after one minute: False after 24 hours: False |
| Set “ShowInAddressList” Azure AD User object property to “True” | Yes | Off | True | False |
| Set “ShowInAddressList” Azure AD User object property to “False” | No | On | False | True |
Note: AzureAD module is deprecated, but Az module works fine here. I.e. Get-AzADUser instead of Get-AzureADUser and Update-AzADUser instead of Set-AzureADUser.
Check my code samples here.
Set-PnPUserProfileProperty : Property Not Editable: This property can not be modified.“Here is what Microsoft says: regarding showInAddressList – Do not use in Microsoft Graph. Manage this property through the Microsoft 365 admin center instead. Represents whether the user should be included in the Outlook global address list. See Known issue.
Known issue (Microsoft): showInAddressList property is out of sync with Microsoft Exchange. When querying users through Microsoft Graph, the showInAddressList property may not indicate the same status shown in Microsoft Exchange. We recommend you manage this functionality directly with Microsoft Exchange through the Microsoft 365 admin center and not to use this property in Microsoft Graph.

Summary: Microsoft Teams will now respect hidden user attributes like ShowInAddressList without needing Scope Search, aligning with Outlook and Exchange. This change, rolling out in October 2025, simplifies user visibility management by removing Scope Search for hiding users, though it should remain for Information Barriers.
To improve consistency across Microsoft 365 services and reduce reliance on Scope Search, Microsoft Teams will now respect hidden user attributes—such as ShowInAddressList and HiddenFromAddressListsEnabled—without requiring Scope Search. This change aligns Teams behavior with Outlook and Exchange, simplifying user visibility management and resolving issues caused by Scope Search, such as difficulty locating Call Queues and Auto Attendants.
ShowInAddressList, HiddenFromAddressListsEnabled, msExchangeHiddenFromAddressList) without requiring Scope Search.ShowInAddressList set to False will no longer appear in People Search.HiddenFromAddressListsEnabledmsExchangeHiddenFromAddressListShowInAddressList to True if they should appear in search results.Setting “ShowInAddressList” Azure AD User object property to “false” is the most effective way to hide user account from search, but it could be changed only with PowerShell:
Get-AzADUser -UserPrincipalName $upn -Select AccountEnabled, ShowInAddressList -AppendSelected
Update-AzADUser -UPNOrObjectId $upn -ShowInAddressList:$false
Microsoft’s position on this is unclear
If you have an opposite issue – user account is missing from search – check this property value: msExchRemoteRecipientType – generally it should be “1”, all other might indicate account type not indexed.
Here is the video tutorial on the same – excluding account from people search in Microsoft 365
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 $true
My 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))
This article was written in April 2022. See Updated KBAs on Sites.Selected