Microsoft 365 Q&A

Q: What permission or role is required to get search Usage analytics reports
A: To see Microsoft 365 Search and intelligence usage analytics reports you’d need “Global reader” or “Search editor” role.

Q: What permission or role is required to get access to Search Feedback under Microsoft 365 admin center – Settings – Search & intelligence – Insights – Feedback
A: You’d need at least “Global reader” or “Search editor” role.

vscode stuck on start with blue frame

I’ve got a new machine, installed Visual Studio Code but it did not start.

Problem

My Visual Studio Code just stuck on start showing a blue frame and “Visual Studio Code” – “The window is not responding” message: “You can reopen or close the window or keep waiting”, after a while:

I tried

code --verbose --log debug --disable-extensions

And found:

[704:0622/103533.849:ERROR:gpu_process_host.cc(983)] GPU process exited unexpectedly: exit_code=-1073741819

[704:0622/103533.850:WARNING:gpu_process_host.cc(1288)] The GPU process has crashed 1 time(s)

[704:0622/103538.853:ERROR:gpu_process_host.cc(983)] GPU process exited unexpectedly: exit_code=-1073741819

[704:0622/103538.853:WARNING:gpu_process_host.cc(1288)] The GPU process has crashed 2 time(s)

[704:0622/103543.835:ERROR:gpu_process_host.cc(983)] GPU process exited unexpectedly: exit_code=-1073741819

[704:0622/103543.835:WARNING:gpu_process_host.cc(1288)] The GPU process has crashed 3 time(s)

[main 2022-06-22T05:35:45.833Z] CodeWindow: detected unresponsive

So it seemed to me like some GPU-vscode conflict – Which led me to “VSCode stopped opening – The GPU process has crashed” discussion.

It turned out this Electron issue is to blame. It is recommended to avoid –no-sandbox flag as it disables application sandbox for all processes, since this issue is isolated to the gpu process –disable-gpu-sandbox should serve as an alternative.

Solution

Just run Visual Studio Code with “–disable-gpu-sandbox” parameter:

code --disable-gpu-sandbox

Note: if one instance is started this way, second instance is started the regular way

Note: it seems the issue happens with vscode versions 1.66-1.68, so workaround would be return to v 1.65

Note: since the issue is some kind of conflict between new versions of vscode and new machine’s GPU – this might happen when you upgrade a vscode or upgrade your hardware or both.

References

Ownerless Microsoft 365 groups, teams and sites Q&As

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.

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.

Track the ownerless group policy in action via Audit Log

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:

  • OwnerlessGroupNeedAttention – “Unattended ownerless group”
  • OwnerlessGroupNotified – “Notified ownerless group”
  • OwnerlessGroupNotificationResponse – “Responded to ownerless group notification”

UserId: OwnerlessGroupComplianceAssistant

Record Type (AuditLogRecordType): 126

It seems like event is not added to the Audit log when a policy is created or updated.

Some more findings:

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.

Issues

“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…”

References

How to configure Refinable Strings for Adaptive retention policies scopes

(WIP)

Microsoft recently implemented “Adaptive retention policies” that use “Adaptive scopes”. Adaptive scopes can use “Site Url”, “Site Name” and 100 Refinable Strings from “Refinable String 0″ to ”Refinable String 99”.

How to configure SharePoint the way Refinable Strings are used in the Adaptive retention policies scopes?

The steps are:

  • Create an indexed site property
  • Map crawled property to a refinable string managed property

Detailed steps:

Indexed site property

Create an indexed site property or “Adaptive Scope Property” with some values. Ensure you property name (key) is unique, e.g.

PropertySiteRetentionProperty
ValueY10

with PowerShell Set-PnPAdaptiveScopeProperty or with Set-PnPPropertyBagValue -Indexed:$true. Examples:

Set-PnPAdaptiveScopeProperty -Key "SiteRetentionProperty" -Value "Y10"

Wait until search crawler pics up you site property. Now you have a crawled property.

Search schema mapping

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.
Assign alias so you could easily identify what is the RefinableString55 about.

(*) Notes

select one that is not used
select one that is not used is an important moment, as if you select refinable string that is already taken at the 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 agree with sites owners on properties ranges (e.g. from 00 to 99 – reserved for tenant use, from 100 to 199 – available at sites levels). And/or you can – after getting report on managed properties taken at sites levels – reserve enough unused managed properties by assigning aliases e.g. “this-property-55-is-reserved-do-not-use”.

site custom script
If site custom script is 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)

References

(tbc)

SharePoint Search: Site vs Tenant Scope, Placeholder Text, Answers and Verticals

(wip)

Service vs Site search

If you configure Verticals 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 if site search scope is tenant.
If site search scope is site or hub – then site-level search verticals will apply (and no answers functionality will be possible).

Token – SharePoint API compatibility matrix

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/APIMS 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) UnauthorizedAudienceUriValidationFailedException
MSAL.PS
Get-MsalToken
with secret
OK(401) UnauthorizedAudienceUriValidationFailedException
MSAL.PS
Get-MsalToken
with certificate
OK(401) UnauthorizedAudienceUriValidationFailedException
PnP.PowerShell
Get-PnPAccessToken
with Certificate
OKOK
OK
OK
AudienceUriValidationFailedException
PnP.PowerShell
Get-PnPGraphAccessToken
with Certificate
OKOK
OK
OK
AudienceUriValidationFailedException
PnP.PowerShell
Get-PnPAppAuthAccessToken
with Certificate or secret
InvalidAuthenticationTokenOK
OK
OK
OK
PnP.PowerShell
Request-PnPAccessToken
with Certificate
InvalidAuthenticationTokenOK
OK
OK
AudienceUriValidationFailedException
PnP.PowerShell
Request-PnPAccessToken
with Secret
InvalidAuthenticationTokenOK
OK
OK
OK
AudienceUriValidationFailedException = Exception of type ‘Microsoft.IdentityModel.Tokens.AudienceUriValidationFailedException’ was thrown

Hide User Accounts from Microsoft 365 People Search

What if you want specific users do not appear in Microsoft 365 SharePoint, Teams or Delve search results?

Solution

Set “ShowInAddressList” Azure AD User object property to false

Details

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:

  • Set the profiles AD property msExchHideFromAddressLists to True or Yes,
  • Sync/wait, so finally SharePoint UPA service SPS-HideFromAddressLists property will be set (msExchHideFromAddressLists AD property is mapped to the UPA SPS-HideFromAddressLists)
  • Under SharePoint classic search – update query:
    {searchboxquery} to {searchboxquery} -“SPS-HideFromAddressLists”:1

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 pointrespect SPS-HideFromAddressLists
(msExchHideFromAddressLists)
web Outlook “New message” user pickerYes
web Outlook “Contacts”Yes
Office.com “All” verticalYes
Office.com “People” verticalNo
SharePoint landing page “All” verticalYes
SharePoint landing page “People” verticalNo
Bing Work All VerticalYes
Bing Work People VerticalYes

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 Account12345
EnabledYesNoYesYesYes
Licensed (E5)NoYesYesYesYes
m365 Admin Center: Show in Global Address Listn/aNoNoYesNo
Exchange Admin Center: Hide from global address list (GAL)n/aOnOnOffOn
Get-AzureADUser -ObjectId … | Select -ExpandProperty ShowInAddressListnullnullnullnullFalse
SPO UPA ‘SPS-HideFromAddressLists‘ valueFalseFalseFalseFalseTrue
Outlook Address List “All Users” Shown
Office.com Search: Vertical “All”Shown
Office.com Search: Vertical “People”ShownShownShownShown
Bing Work Search: All/People verticalsShownShown
Teams Search: “All” VerticalShownShown
Teams Search: “People” verticalShownShownShownShown
Microsoft 365 Profile card – OrganizationShownShown
Teams Profile card – OrganizationShownShownShownShown
Teams People PickerShownShownShownShown
SharePoint People PickerShown
Outlook People Picker:Shown
* – some users can see changes after hours, for some it takes days

Doesn’t it seem confusing we have properties:

  • “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

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 assignedYesOffnullFalse
Uncheck “Show in my organization address list” under Microsoft 365 admin centerNoOnafter one minute: null
after 24 hours: null
after one minute: False
after 24 hours: False
Set “ShowInAddressList”
Azure AD User object property to “True”
YesOffTrueFalse
Set “ShowInAddressList”
Azure AD User object property to “False”
NoOnFalseTrue

Some findings:

  • “Show in Global Address List” under m365 Admin Center and “Hide from global address list (GAL)” under Exchange Admin Center – same, i.e. if you change one – another will be updated momentarily
    But both does not affect “ShowInAddressList” Azure AD User object property and “SPS-HideFromAddressLists” SharePoint User Profile property
    and vise versa (???)
  • “SPS-HideFromAddressLists” SharePoint User Profile property is not changeable.
    If you try to change the property value you’ll get an error message:
    Set-PnPUserProfileProperty : Property Not Editable: This property can not be modified.
  • “ShowInAddressList” Azure AD User object property is editable and synchronized to “SPS-HideFromAddressLists” SharePoint User Profile property (takes minutes)
    but then search crawler must pick this change up (takes hours) to hide/show the user
  • here 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.
  • Results are inconsistent 🙁

Note: Az module works fine too. I.e. Get-AzADUser instead of Get-AzureADUser and Set-AzADUser instead of Set-AzureADUser.

References

Testing Sites.Selected SharePoint and MS Graph API

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.

Azure registered app with SharePoint and MS Graph API Sites.Selected 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.

(wip) Test set #1: Certificate vs Secret

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-PnPSiteSecretCertificate
ACS based (Azure+AppInv)OKThe remote server returned an error: (401) Unauthorized.
MS Graph API Sites.SelectedThe remote server returned an error: (403) Forbidden.The remote server returned an error: (401) Unauthorized.
SharePoint API Sites.SelectedOKOK
MS Graph API + SharePoint API Sites.SelectedAccess is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))OK
App with no permissionsThe remote server returned an error: (403) ForbiddenThe remote server returned an error: (401) Unauthorized

(wip) Test set #2: Sites.Selected SharePoint vs MS Graph (secret)

  • DisableCustomAppAuthentication = $false
    (SP-app-only spns are enabled).
  • All applications have “write” access provided to a specific site only.
  • Using Client Secret (not a certificate)
  • Using PnP.PowerShell
Action/ViaSharePoint + MS Graph
Sites.Selected
“secret”
SharePoint
Sites.Selected
“secret”
MS Graph
Sites.Selected
“secret”
Connect-PnPOnlineWARNING: 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-PnPSiteOKOKThe remote server returned an error: (403) Forbidden.
Get-PnPListOKOK
Get-PnPListItemOKOK
Set-PnPSiteAttempted to perform an unauthorized operation.
Set-PnPListAttempted to perform an unauthorized operation.
Set-PnPListItemOKOK
New-PnPListAccess is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Add-PnPListItemOK

(wip) Test set #3: Read vs Write vs FullControl

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

ReadWriteFullControl
Connect-PnPOnlineWARNING: 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-PnPSiteAccess is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Get-PnPListAccess is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Get-PnPListItem
Set-PnPSite
Set-PnPList
Set-PnPListItem
New-PnPList
Add-PnPListItem

(wip) Test set #5: Certificate vs Secret

C#, SharePoint CSOM, PnP.Framework

Findings

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

References

Testing environment

  • Microsoft 365 E5 Dev environment
  • PowerShell 7.2.2
  • PnP.PowerShell 1.10
  • “write” permissions to the specific sites for client apps were assigned via PnP.PowerShell

Providing Permissions to a Site for Sites.Selected App

How to provide permissions for an Azure registered application with MS Graph SharePoint Sites.Selected API permissions to a specific site via calling Microsoft Graph API from PowerShell.

We need an “admin” application – Azure registered application with with Sites.FullControl.All MS Graph API permissions. This method can use secret, so we need Client Id and Client Secret for this “admin” app.

We also need a Client Id and Application Display Name for an Azure application with Sites.Selected MS Graph and/or SharePoint API permissions provided.

And we need our “target” site Url.

With PowerShell scripts you can:

  1. Get Microsoft Graph Access Token with an “admin” app
  2. Get client (target) site Id
  3. Get current app permissions provided to client site
  4. Add read or write permissions for the client app to the client site
  5. Revoke one specific permission from site
  6. Revoke all app permissions provided to site

– please refer to the GitHub Repo Sites.Selected

References