Category Archives: Microsoft 365

SharePoint Inactive Site Policies

Leave a reply

SharePoint Advanced Management includes Inactive Site Policies under Site lifecycle management. Effective content lifecycle management is a key pillar of SharePoint governance. It plays a vital role in optimizing storage, preserving data integrity, and ensuring regulatory compliance. By systematically removing inactive or outdated sites, it also enhances security. Additionally, it supports successful Copilot implementation by ensuring that the information accessed is both accurate and current. So, how exactly this Inactive site policy works and what is the difference between Entra Id groups expiration policy and SharePoint Inactive Site Policy.

Inactive site policy vs groups expiration policy

The Groups Expiration Policy has been a feature of Azure AD (Entra ID) for quite some time. It is included at no additional cost. This policy automatically notifies group owners about upcoming expirations and provides options to renew or delete the group. Since all self-created Teams teams and Viva Engage communities are backed by SharePoint sites and managed through Microsoft 365 Groups, this policy also plays a significant role in SharePoint governance ensuring that information stored in SharePoint remains current and properly maintained. I have an article Microsoft 365 group expiration policy deep dive.

Inactive Site Policy is a feature of SharePoint Advanced Management (SAM), which is an add-on and require premium SharePoint license. It also Identifies inactive sites, Sends notifications to site owners and can automatically archive or make sites read-only. Sound like very similar to to groups expiration policy.

Key differences

FeatureGroups Expiration PolicyInactive Site Policy
Where to configure
Who can configure		Entra Id
Groups Admin		SharePoint Admin center
SharePoint Admin
Scope (policy is applied to)Microsoft 365 Groups
(including group-based sites, like teams, yammer)		SharePoint Sites
(including both – group-based and non-group-based sites)
Who is notifiedGroup OwnersSite admin (group owner), site owners (*) TBC
Notifications come from emailmsgroupsteam@microsoft.comno-reply@sharepointonline.com
Options provided to an ownerrenew the group
delete the group		certify site
learn how to delete a site
Can admin download report (list of inactive groups/sites)NoYes
Period of inactivity config optionsShould be greater than or equal to 30 days1, 2, 3 or 6 monthes
What happens with resources owner did not take action (or with orphan resources).Notifications is sent to a specific email address, group is deletedsite is archived or set to read-only or nothing

Inactive site policy user experience

Here is how the email notification looks like:

Note that

The email subject includes “Action required” and site title (name).
It always says “… has been inactive for more than a month” even if the policy configured for “6 months”.
It shows SharePoint logo, which might mislead “teams-oriented” users.
Site title is not clickable, so site admin/owner cannot just click site link but have to navigate to site manually.
When user clicks button “Certify site” – a message “The action completed successfully” pops up at the bottom of the email for a few seconds and then disappears. The email itself does not change, so when a user opens the same email again – there is no visual evidences the action was taken.

At the bottom of the email Microsoft mentions tenant name.

The email template is the same for all kinds of policies – it does not matter if the policy action is configured configured as “do nothing”, or to automatically enforce archive site or set it to read-only. I.e. email just says “Select Certify site to confirm if it’s still in use, or consider deleting it if the site is no longer needed.”. Email does not inform users that site will be set to read-only or archived.

Also there is no link where a user can get more info on the subject.


Admin – Inactive sites report

You can download a csv report of inactive sites generated by policy.
Report includes fields:
Site name, URL, Template, Connected to Teams, Sensitivity label, Retention Policy, Site lock state, Last activity date (UTC), Site creation date (UTC), Storage used (GB), Number of site owners, Email address of site owners, Number of site admins, Email address of site admins, Action status, Total notifications count, Action taken on (UTC), Duration in Read-Only.

There is no GUI to see the list of inactive sites (you can only download a csv file), but there is a magic button “Get AI insights”.

Get AI insights

Here are insights I have seen so far:

  • Inactive sites with significant storage usage
  • Multiple sites owned by the same account
  • Sites inactive for over a year

Inactive sites policy behavior

tbc…

References

Content Shared with Everyone: Access Review

Leave a reply

This article is for SharePoint or Microsoft 365 admins focusing on governance and information protection. If you have SharePoint Advanced Management (SAM) – aka SharePoint Premium licensed or you got at least one Copilot for Microsoft 365 license (as having m365 Copilot license automatically enables SharePoint Advanced Management in tenant), then under reports – Data access governance (in SharePoint admin center) – you can not only get Content shared with ‘Everyone except external users’ (EEEU) reports, but also initiate access review. Let us look more closely at this functionality and discuss the pros and cons..

I’ll not repeat Microsoft documents:
– SharePoint Advanced Management
– Content shared with ‘Everyone except external users’ (EEEU) reports
– Site access reviews for Data access governance reports
but I’ll focus on what is not there and a real-world experience.

Reports

First of all, report does not provide you with all SharePoint content shared with “Everyone except external users”. Report helps you with what was shared with EEEU in the last 28 days. That drastically limits usage of this feature. I.e. you should first get initial report on the all content shared with EEEU, and somehow take care of it by other means (consider How to Find Content Shared with Everyone in SharePoint and Teams), and only then you can use this Microsoft’s content shared with EEEU report and access review.

You can share content with EEEU or directly – by adding EEEU to resource permissions directly or by including EEEU into SharePoint group. So content shared with EEEU reports come in two flavors – “Specific files, folders and lists” and “Site membership”

“Specific files, folders and lists” user experience

When you initiate access review from the “Specific files, folders and lists” type of report – users (site admins/owners) get email notification that says “You have sites with specific files, folders or lists shared with ‘Everyone except external users’. This means everyone in your organization has access to this content. Review the items shared for potential oversharing and manage their access.“

Scrolling down, in the email, site owner can see a list (table) of incompliant sites with the following columns: Site name, privacy, sensitivity, external sharing and “Items shared”. Site name is clickable and sends user to the root of the site.

Below the list of sites there is a button “View shared items” that sends user to the special system page –
“https://orgname.sharepoint.com/teams/site01/_layouts/15/siteaccessreview.aspx/<id>” where he/she can see list of SharePoint items shared with EEEU. Columns are: (item) Name, Shared on (date), Shared by (email), Action (manage access). Item name and manage access are clickable.

If item is a library item – e.g. document – it is displayed correctly – with icon according to the doc type and doc name. Clickin on the doc name – an actual document opens so you can review it’s content.

If item is a list item – it is displayed incorrectly – no icon, no meaningful info about the item (it is displayed as “”). Clicking on the link – a warning icon and message “Can’t preview this file. Open the file or download it to view in your desktop app”. Buttons “Open” and “Download” are there but not helpful as well.

Clicking on “Manage access” opens almost standard “Manage access” dialogue you can have via “manage access” item context menu, but with no “…” more options at the top right:

which makes this dialogue screen useless, as you can only provide additional access to the item or remove all access. You cannot remove EEEU from access without three dots “More options”.

“Stop sharing” literally remove all permissions to the item except owners

By clicking on a group name – admin opens standard SharePoint “People and Group” membership page:
/_layouts/15/people.aspx?MembershipGroupId=X, which is nice.

“Site membership” user experience

In the case with a “Site membership” report, text would be slightly different: “You have sites where ‘Everyone except external users’ has been added to the site membership. This means everyone in your organization has access to this site. Review site permissions for potential oversharing and manage access.“, which makes sense.

Right after that, in the email, site owner can see a list of incompliant sites with the following columns: Site name, privacy, sensitivity, external sharing and “Groups with org-wide access”. Site name is clickable and sends user to the root of the site.

Then there is a button “View SharePoint groups” that sends user to the special system page –
“https://orgname.sharepoint.com/teams/site01/_layouts/15/siteaccessreview.aspx/<id>” where he/she can see list of SharePoint groups (clickable) with EEEU as members. By clicking on a group name – admin opens standard SharePoint “People and Group” membership page:
/_layouts/15/people.aspx?MembershipGroupId=X, which is nice.

siteaccessreview.aspx page

User can navigate directly to the reviews page:
“https://orgname.sharepoint.com/teams/site01/_layouts/15/siteaccessreview.aspx” and if there were reviews initiated by SharePoint admins – and it’ll work – admin will see all access reviews initiated for this site – columns are: Review name, Description, Requested on (date), Status, reviewed by (email) and admin comment. In case no reviews were initiated against tie site – “You have no reviews to take action on” will be displayed. That’s good.

GUI only

Once you got report – you can initiate access review. All must be done in GUI, click-click-click selecting sites… But what if you have thousands? There is no PowerShell cmdlets or API for this functionality, which really limits your ability to implement it gracefully, especially in large Microsoft 365 environments and automate it.

Download detailed report

Report “Specific files/folders/lists…” does not include files, folders, list – i.e. it does not include what exactly is shared with EEEU. Report includes site id, url, name, template, is it teams-connected, sensitivity (?), privacy, external sharing, primary admin name and email, and number of items (?) shared with EEEU.

So technically you can communicate to site owners, but you’d need to rely on them to figure out what content is shared with everyone.

Email template

When you initiate Site access review – an e-mail notification is send to site owners. This e-mail is not customizable at all. The only admin can do is to add a message (for every “initiate Site access review” action).

This email comes from “SharePoint Online <no-reply@sharepointonline>” address (not customizable), so comes “from outside of your organization” and can be considered as scam.

Microsoft’s logos and other graphics are blocked by default and e-mail includes a button “View shared items” – enough red flags for users to consider it as spam. Keep this in mind.

The good news is e-mail contains site name – so site owner can recognize it at act accordingly.

Usage scenarios

Small tenants

In small Microsoft 365 environments – yes, this functionality probably can be used “as is” (and should be used). Especially for new tenants – I’d recommend enable reports and use this feature on a regular basis.

Medium-size tenants

I’m not sure. It depends on your governance rules and company culture.

Enterprises

I’m very pessimistic if this functionality is useful in large environments. Reasons are:

  • if your tenant is not new – you already have a lot of overshared content, so you still need to come up with your custom solution (idk – PowerShell scripts?) to deal with oversharing. But once you designed your custom solution – why don’t you continue to use it?
  • In enterprises usually all the communication must follow approved templates, branding and so on.
  • User experience of reviewing shares with everyone… and managing permissions designed very poorly… In enterprise you do not want to deal with thousands of tickets from site owners who could not figure it out
  • In enterprises you’d think of automation

Solving Issues with m365 Copilot Agents

Leave a reply

Issue # 1 – Unable to create

It says “Unable to create” and “We were unable to create this agent due to an error. Try again.”
or
“Unable to update” and “We were unable to update this agent due to an error. Try again.”

Unable to create We were unable to create this agent due to an error. Try again.
Unable to update We were unable to update this agent due to an error. Try again.

More info:
The problem appears to be when copilot tries to save agent (POST to https://powervamg.us-il105.gateway.prod.island.powerapps.com/chatbotmanagement/tenants/…/environments/Default-…/minimalBots/api/…/publish – it returns 500 Internal Server Error).

Cause:
In my case the cause was my license was assigned a few hours before, so it seems like it takes some time for Microsoft to populate updates.
In the other case I troubleshooted it turned out user did not have a license assigned (license was removed), but “Create an agent” button was available.

Solution:
Ensure you have a license for Microsoft 365 copilot assigned and (ideally) wait 24 hours.
Microsoft: “If you recently purchased a license or started a free trial, it may take up to 24 hours for the license to take effect.”

Azure ACS retirement: Track down ACS apps

Leave a reply

Since Microsoft announced retirement of legacy Azure ACS – all SharePoint admins are working against the clock. ACS permissions were here for 10+ years and there are tons of videos and blogs guiding users how to get these permissions and use it in apps. And imagine how many ACS apps are still there accessing SharePoint sites. We do not want business screams “My critical process stopped working! Do something right now!”. So we would get the list of such apps that are still using ACS to access SharePoint, get apps owners, sites and sites owners. The ultimate goal is to communicate to right people and let them know that ACS is deprecated now and engage them to update their solutions to use only modern authentication.

What kind of apps we are talking about, specifically? I can see the following options:

  1. Apps that were registered in SharePoint via AppRegNew.aspx (aka SharePoint app-only service principals) and provided with permissions in SharePoint via AppInv.aspx
  2. Apps that were registered in Azure (Entra Id) and provided with permissions in SharePoint via AppInv.aspx

Techniques we can use to get data:

  • analyze audit log to get events where apps are accessing sites
  • analyze audit log to get events where ACS permissions were provided to sites
  • get data from system that tracks request for new ACS permissions
  • use reports from admin center
  • use the PnP Microsoft 365 Assessment Tool 
  • get report on apps owners and permissions from from Entra Id

Let us deep dive into each data source to see if it is actually helps us to get ACS apps in use…

Audit log: apps accessing sites

Microsoft 365 audit log is supposed to save all events happening in Microsoft 365. It is available for admins via GUI, PowerShell Exchange Module and Graph API. GUI Search m365 audit log now lives under Microsoft Purview – Solutions – Audit.

GUI search Audit Log under Purview

Unfortunately, when an App registered in Azure and provided with ACS access (via appinv) is accessing SharePoint sites – no events are saved in m365 audit log.

SharePoint app-only principals (apps registered in SharePoint via appregnew) are tracked in m365 audit log. Events would have a UserId “app@sharepoint” (yes, single user id for all apps). Other event details would include activity/operation (PageViewed, FileModified etc.), Item (full Url of a document or page etc.), AppAccessContext (includes ClientAppid, ClientAppName), ApplicationId (yes, this is how we know what app access what url on the site), and many other details

Get Audit Log via Microsoft Graph API

The following reports are available in preview only (under beta):

Service principal sign-in activity

This report is available through the servicePrincipalSignInActivity resource type and details the sign-in activity for a service principal in your tenant. The sign-in activity can be delegated or application-only scenarios. For application-only scenarios, the application credential activity provides additional information on the credential usage.

Service principal sign-in activity report provides the following details for every service principal:

  • id,
  • appId,
  • lastSignInActivity,
  • delegatedClientSignInActivity,
  • delegatedResourceSignInActivity,
  • applicationAuthenticationClientSignInActivity,
  • applicationAuthenticationResourceSignInActivity

More on Service principal sign-in activity

Application credential sign-in activity

This report is available through the appCredentialSignInActivity resource type and details the usage of an app credential (secret, certificate, or federated identity credential) in your tenant.

Application credential sign-in activity report provides the following details for every service principal credential:

  • id, keyId, keyType, keyUsage,
  • appId, appObjectId, servicePrincipalObjectId,
  • resourceId,
  • credentialOrigin,
  • createdDateTime,
  • expirationDateTime,
  • signInActivity

More on Application credential sign-in activity

Application sign-in

Evaluate the usage of application sign-ins in your tenant using either a summary report or a report that provides details of sign-ins, such as the number of sign-ins and whether any errors occurred during sign-in.

Application sign-in report provides the following details for every service principal:
aggregatedEventDateTime, appDisplayName, appId, id, signInCount, status

More on Application sign-in

Audit log ACS permissions provided events

This is relatively easy. There are just 3 kinds of events that might help us to understand ACS usage in tenant:

SharePointAppPermissionOperation

Pull audit logs with record type is SharePointAppPermissionOperation so you’d get events where permissions were provided to apps. Operation type (activity) would be like AppPermissionGrant.

Microsoft started logging this record type not long ago and there is no documentation found (as of Feb 2025). So the only I noticed that might help is:

  • if user id is “app@sharepoint” – that indicates Sites.Selected permissions were provided to the app
    (e.g. via Grant-PnPAzureADAppSitePermission )
    under “AppId” you’d have an app (client) id of the client app (permissions provided to) in the form of
    “i:0i.t|ms.sp.ext|<appId>@<tenantId>”
    under “ApplicationId” and “AppAccessContext – ClientAppId” – you’d have an app (client) id of the admin app (permissions provided via)
    ApplicationDisplayName would contain the display name of the admin app
    Other fields: RecordType 205, UserType 5, AuthenticationType OAuth
  • if user id is one of your actual user’s account in tenant – that indicates ACS permissions were provided to the app (e.g. via appinv.aspx page at SharePoint site)
    under “AppId” you’d have an app (client) id of the client app (permissions provided to) in the form of
    “i:0i.t|ms.sp.ext|<appId>@<tenantId>”
    there would be no “ApplicationId” field and under “AppAccessContext” no ClientAppId
    ApplicationDisplayName Unknown
    Other fields: RecordType 205, UserType 0, AuthenticationType FormsCookieAuth

Appregnew.aspx and appinv.aspx

You can pull audit logs with record type is SharePoint and activity type (operation) is PageViewed and keyword for free search is appregnew. You’d get events when there was an attempt to register a new SharePoint app-only service principal.

The same but with appinv as a search keyword – to get events when there was an attempt to provide ACS permissions for a SharePoint app-only service principal or for an Azure App registration.

In both cases we know that there was an intention to have a principal with an ACS access. We can reach these people to inform that ACS is deprecated and so and so. Worst scenario – we notify somebody who already know that.

Some time ago (around mid – 2023) Microsoft by default disabled ability for site owners registering apps and providing permissions in SharePoint via Appregnew.aspx and appinv.aspx. So since then only SharePoint service admins could provide ACS permissions to apps. In this case you’d check with your request tracking system – to whom ACS were provided.

System that tracks request for new ACS permissions

In case you have a process of providing ACS permissions… Process might include tickets to service desk or similar kind of system… Anyway – check if you can get data from that system – like who requested for what app to what site etc…

Reports available at admin center

So far the only report that might help is in development (see Microsoft 365 Roadmap – feature Id 417481) and scheduled to be available in March 2025.

“Enterprise Application Insights is a powerful report which helps SharePoint Administrators to discover all the SharePoint sites that are allowed access by third-party applications registered in your tenant. The report also provides details on the application’s permission and requests count to help admins take further action to strengthen the security of the site. It is part of SharePoint Advanced Management capabilities.”

The feature is already documented here: Generate App insights reports and is seems like the report will not be available for all tenants – but just for tenants with Microsoft SharePoint Premium (SharePoint Advanced Management) or Copilot license assigned.

PnP Microsoft 365 Assessment Tool 

Microsoft 365 Assessment Tool is an utility designed by PnP team a while ago and since then serves SharePoint admins very well. In particular, it helps helps us identify and evaluate the Azure ACS usage for tenant by providing the usage data of ACS principals, and even generating a Power BI reports.

If you run this tool specifying AddInsACS mode, it provides you with:

  • classicacsprincipals report that includes apps with Allow AppOnly permissions.
    Details are: App Ids, if the app has Tenant or Site Collection Scoped Permissions, RedirectUri, AppDomains and ValidUntil
    If the ValidUntil field contains specific date – that means the app was registered via appregnew
    If the ValidUntil field contains “01/01/0001 00:00:00” date – that means the app was registered in EntraId
  • classicacsprincipalsites – sites these apps have access to
    Details are: AppIdentifier, ServerRelativeUrl
  • classicacsprincipalsitescopedpermissions – list of apps permissions to sites
    Details: AppIdentifier, ServerRelativeUrl, SiteId, WebId, ListId, Right (Read/Write/FullControl/Guest etc.)
    If the WebId field equals zeros, that means rights were provided to entire site collection
  • some other details

Unfortunately, this tool does not provide when the app was last time authenticated or when the app accessed the site

I use the following PowerShell to start the tool, get status and export reports:

$tenantDomain = "" # "contoso.sharepoint.com"
$clientid = "" # 
$certThumbprint = ""
$certPath = "My|CurrentUser|" + $certThumbprint

./microsoft365-assessment.exe start --mode AddInsACS --authmode application --tenant $tenantDomain --applicationid $clientid --certpath $certPath

./microsoft365-assessment.exe status

./microsoft365-assessment.exe report --id <report id> --mode CsvOnly --path ".\ACS-reports"

Highly recommended: SharePoint Add-In and Azure ACS Assessment

Report on apps owners and permissions from from Entra Id

Using all the methods above – you’d get a list of active service principals that use legacy ACS authentication. But to whom we need communicate to regarding this service principals? Obviously, we need this service principals owners. There are multiple options how to get an app owner from Azure (Entra Id):

More Observations

Test scenario 1
DisableCustomAppAuthentication is true, i.e. ACS are not allowed in tenant.
SiteOwnerManageLegacyServicePrincipalEnabled -s false, i.e. site owners cannot register apps at sites or provide permissions to app on sites.
It is not possible for admin to go to appregnew.aspx and create an app (app-only spn).
I registered apps in Azure.
It is possible for admin to go to appinv.aspx and “provide” permissions to the azure app registrations.

An app is shown under appprincipals.aspx only in case if ACS access was provided to app but Sites.Selected access was not provided. The moment you provide Sites.Selected access for the app to the site – the app disappears from list of apps under appprincipals.aspx page. The app is not visible for Get-PnPAzureACSPrincipal. PnP M365 Assessment Tool also fails to get list of ACS apps if the samr also has Sites.Selected permissions. It does not help if you remove Sites.Selected permissions. This issue is reported to Microsoft and confirmed. Microsoft is working on it.

Connect-PnPOnline works with certificates or with secrets.
Get-PnPSite works only if connection was made with a Certificate (if connection was made with secret – it gives 401 unauthorized).

Test scenario 2
DisableCustomAppAuthentication is false, i.e. ACS are allowed in tenant.
SiteOwnerManageLegacyServicePrincipalEnabled -s false, i.e. site owners cannot register apps at sites or provide permissions to app on sites.
Connect-PnPOnline and Get-PnPSite works with certificates or secrets if ACS access was provided for an app to at least one site.
If there was no ACS permissions provided for the app – Get-PnPSite gives “Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))”

Error messages and possible fixes

“Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))” – happens if you try to access SharePoint API with an Entra Id app registration that have an API permissions but do not have legacy ACS permissions being authenticated with a secret.
Solution option 1: try authentication with a certificate.
Solution option 2: use Microsoft Graph API.

“The remote server returned an error: (401) Unauthorized.” – happens if you try to access SharePoint API being authenticated with a certificate with an app registration that do not have modern API permissions correctly provided.
Solution: ensure app registration is configured with SharePoint API permissions.

“(403) Forbidden” – happens if you try to access SharePoint API being authenticated with a secret with an app registration that do not have modern API permissions correctly provided.
Solution: ensure app registration is configured with Graph API permissions.

“AccessDenied”,”Either scp or roles claim need to be present in the token.” – happens if you try to access Graph API being authenticated with a secret with an app registration that do not have modern API permissions correctly provided.
Solution: ensure app registration is configured with Graph API permissions.



References

SelectedOperations.Selected permissions in SharePoint

Leave a reply

Microsoft says “Initially, Sites.Selected existed to restrict an application’s access to a single site collection. Now, lists, list items, folders, and files are also supported, and all Selected scopes now support delegated and application modes.”. This article deep-dives into providing and using SelectedOperations.Selected granular permissions to SharePoint:

Lists.SelectedOperations.SelectedProvides application access to a specific list
ListItems.SelectedOperations.SelectedProvides application access to one or more list items, files, or folders
Files.SelectedOperations.SelectedProvides application access to to one or more files or library folders

Set of SelectedOperations permissions is exactly what Microsoft promised a few years ago. And this is great, as we really need granular access to SharePoint sites. I’ve been supporting enterprise SharePoint for more than 10 years now, and I know that it was always a concern when application require access to a list/library or a folder or even document, but admins have to provide access to entire site.

Especially, I believe, this feature becomes more in demand because of Copilot for Microsoft 365. As for now – it’s mostly developers and data analytics who needs unattended application access to SharePoint, but what if regular users powered with m365 Copilot license start creating autonomous agents?

So below is my lab setup, PowerShell scripts and guides with screenshots on how to provide granular (not to entire site but to library/list or folder, or even just one document or list item) permissions to SharePoint and how to use provided permissions.

Admin App

First, we need an Admin App – an app we will use to provide permissions.

The only requirement – this app should have Microsoft.Graph Sites.FullControl.All API permissions consented:

Target Site and Dev Setup

For this lab/demo setup, I have created a team under Microsoft Teams (so it’s a group-based Teams-connected SharePoint site), then test list and test library:

There must be an App Registration for client application – application that will have access to Test-List-01 and Test-Lib-01 only. This app registration should have Microsoft Graph “Lists.SelectedOperations.Selected” API permissions consented:

and I will use Python to access SharePoint programmatically.

At this moment (we have a client app and secret, and “” API permissions, but did not provide for this app access to specific sites or libraries) – we should be able to authenticate to Microsoft 365, but not able to get any kind of data (we can get token, but other call to Graph API would return 403 error – Error: b'{“error”:{“code”:”accessDenied”,”message”:”Request Doesn\’t have the required Permission scopes to access a site.”,):

PowerShell script to provide selectedoperations.selected access for an app to a specific list would be as below. Here we use plain calls to MS Graph API. Full script for your refence is available at GitHub, but here is the essential part:

$apiUrl = "https://graph.microsoft.com/beta/sites/$targetSiteId/lists/$targetSiteListId/permissions"
$apiUrl 
$params = @{
	roles = @(
	    "read"
    )
    grantedTo = @{
        application = @{
            id = $clientAppClientId
        }
    }
}
$body = $params | ConvertTo-Json
$response = Invoke-RestMethod -Headers $Headers -Uri $apiUrl -Method Post -Body $body -ContentType "application/json"

Client Application

I use Python console app as a client application. Link to the code at the GitHub is shared below under References, but the core part of the Python code is (I do not use any Microsoft or other libraries here, just plain requests to Microsoft Graph for authentication and for data):

import requests
import json
from secrets import clientSc, clientId, tenantId, siteId, listId 

# specify client id, client secret and tenant id
# clientId = ""
# clientSc = "" 
# tenantId = "" 

apiUri = "https://login.microsoftonline.com/" + tenantId + "/oauth2/v2.0/token"

body = {
    "client_id"     : clientId,
    "client_secret" : clientSc,
    "scope"         : "https://graph.microsoft.com/.default",
    "grant_type"    : "client_credentials" 
}

try: 
    response = requests.post(apiUri, data=body)
    token = json.loads(response.content)["access_token"]
except:
    print("Error: ", json.loads(response.content)["error_description"])
    exit()

print("Got token: ", token[0:10], "...")
headers={'Authorization': 'Bearer {0}'.format(token)}

# Get specific site list
print("Geting specific site list")
# graph_url = 'https://graph.microsoft.com/v1.0/sites/' + siteId + '/lists/' + listId
graph_url = 'https://graph.microsoft.com/beta/sites/' + siteId + '/lists/' + listId
graphResponse = requests.get(   graph_url, headers=headers )
print(" Response status code: ", graphResponse.status_code)
if graphResponse.status_code == 200:
    list = json.loads(graphResponse.content)
    print(" List display name: ", list["displayName"])

Note.
I’m not sure if it’s a bug or my incorrect setup, but I noticed that if I provide access for the app to the list – app can read site.

TBC…

References

Automating SharePoint operations with Azure Functions

Leave a reply

There are many scenarios for SharePoint or Teams automations, and in most cases you need to run some code on scheduled basis (e.g. every 5 minutes or every 24 hours etc.). This is where timer-triggered Azure Functions might help. In this article I will provide use cases, overview of the whole scenario and technical setup, and provide links to the detailed step-by-step guides for configuring different parts of the entire solution.

Possible scenarios

Possible scenarios (end-user-oriented):

  • Create site upon user request
  • Convert site to a HUB site upon user request
  • Set site search scope upon user request
  • Setup site metadata (site custom properties)
  • Request usage reports/analytics

Possible scenarios (admin-oriented):

  • Provide temporary access to the site (e.g. during troubleshooting)
  • Provide Sites.Selected permissions for the App to the Site
  • Disable custom scripts or ensure custom scripts are disabled
  • Enable custom scripts (e.g. during site migration)
  • Monitor licenses – available, running out etc.

Typical setup

Front-end

SharePoint site works as a front-end. You do not need to develop a separate web application, as It’s already there, with reach functionality, secured and free.

The site can have:
– one or more lists to accept intake requests
– Power Apps to customize forms
– Power Automate to implement (e.g. approval) workflows, send notifications etc.
– site pages as a solution documentation
– libraries to store documents provided as response to requests

You can provide org-wide access to the site if your intention is to allow all users to submit requests or secure the site if you want to accept requests only from a specific limited group of people.

Back-end

Timer-triggered Azure Function works as a back-end. The function can be scheduled to run based on job specific requirements (e.g. every 5 or 10 minutes, or daily or weekly etc.). The function can be written in PowerShell, C#, Python etc.

The function’s logic is to

  • read SharePoint list, iterate through items to get intake requests
  • validate request eligibility
  • perform action
  • share results (e.g. update intake form, send e-mail, save document to library etc.)

Configuration

There should not be an issue to setup a front-end. You’d just need a solid SharePoint and Power Platform skills.

For the back-end the solution stack would include the following tools/skills:
– Azure subscription to host solution
– Registered Apps to configure credentials and API access permissions
– Azure Function App to actually run the code
– Azure Key Vault to securely save credentials
– programming skills in language/platform of choice
– SharePoint API, Microsoft Graph API

Please refer to the separate article Configuring Azure Function App and Key Vault to work with Microsoft 365 SharePoint via Graph API for the basic setup.

Secure

Having basic setup in place, we’d improve solution security. Specifically, we’d address the following:

  • Azure Function network security
  • Key Vault network security
  • Storage Account network security
  • Key Vault purge protection
  • tbc…

TBC…

References

Working with SharePoint from Python code via Graph API

Leave a reply

Python code samples published by Microsoft at the Microsoft Graph API reference pages use GraphServiceClient module. But you also can use just requests module and call Microsoft graph API directly, using requests.post or requests.get methods. Here I’m sharing my Python code samples.

https://github.com/VladilenK/m365-with-Python/tree/main/Graph-API-Plain

Azure ACS retirement: How to prepare your tenant – Guide for SharePoint Admins

Leave a reply

Microsoft announced EOL of ACS, and we as SharePoint administrators must take actions. ACS retirement as is a really big deal – entire era of SharePoint app-only service principals will be gone. SharePoint developers used ACS apps since 2013 to build solutions, and when it comes to software development – it always takes time. Imaging the code that was designed for ACS now needs to be reviewed and re-written to adopt changes, then re-compiled, re-tested, re-deployed etc. So it is critical that we should take measures now to avoid bigger issues in April 2026.

Recommended transition tactics: for developers

  • Get a new App Registration in Azure (Entra Id) with Sites.Selected permissions, ensure no ACS permissions provided to the app (see details on Sites.Selected) and use it
  • Prioritize using Microsoft Graph API
  • If Graph API does not provide required functionality – it’s ok to use SharePoint API, but keep in mind in this case certificate should be used (not secret) for authentication

Recommended transition tactics: for SharePoint admins

High-level recommended steps are:

  • Keep saving audit logs
  • Encourage users and developers to register applications in Azure (not in SharePoint)
  • Start providing Sites.Selected permissions
  • Disable ability for site owners to use AppRegNew and AppInv
    Stop registering service principals via AppRegNew and providing ACS permissions via AppInv
  • Pull report on existing Apps that use ACS permissions
  • Notify developers and users of the ACS apps
  • Switch ACS off earlier than Microsoft

Thinkin on devs – keep in mind:
– ACS apps have a huge legacy – tons of articles and code examples and so on…
– Switching to a modern authentication method would require changes in code (though minor, but still), so developers must be engaged
– Any change in code would require another round of code compilation, testing, deploying etc.

That means it is not easy (sometimes it is not even possible) to adopt a new modern authentication method. It requires efforts and time, so you need to notify dev as earlier as possible. So it is crucial to complete steps above and start communicating to users as earlier as possible.

Detailed steps for SharePoint administrators:

Keep audit logs

This should be done in advance, but if you did not – starting today and until it’s over you’d get audit logs from Microsoft 365 purview center – consider selecting all events with record type SharePointAppPermissionOperation. Also might be helpful to keep events anyone visited appinv.aspx or appregnew.aspx page. Pull logs now starting with earliest available event (usually 90 days). Some audit logs are available only through Microsoft Graph API. See more details regarding audit logs for ACS tracking KBA.

Encourage users registering applications in Azure (not in SharePoint)

Creating App Registrations in Azure is usually not what SharePoint admins do. Sometimes users are allowed to register apps, sometimes it is blocked for a regular user and done by identity management (or so) but the main idea – users and developers should be able to get service principals (App Registrations) in Azure. Users would need Sites.Selected permissions consented (see more about Sites.Selected) or granular permissions consented (more on granular permissions to SharePoint).

Some pro’s of App Registered in Entra Id (vs SharePoint App-only service principals):
– It supports authentication with client secret and/or certificate, custom expiration time
– It supports both APIs – Microsoft Graph API and classic SharePoint REST API

Be prepared to instruct users how to get and use certificates in their app registrations.

Provide Sites.Selected permissions

99% of requests for application permissions to SharePoint would require access to a specific site (sites), or to a specific list/library/folder/file (but not to entire tenant). So consider providing Sites.Selected permissions by default (or granular permissions when they are in GA). Create a process so users can request permissions to SharePoint sites for their Azure-Registered Apps. Consider automation if you are a large company (here is one of the possible Sites.Selected automation solutions).

Inform user that ACS is deprecated and you do not provide any new ACS permissions.

Disable registering new service principals in SharePoint

Once you are good in providing non-ACS permissions, it’s time to disable registering service principals in SharePoint. Users should not be able to get a new SharePoint App-only service principals (apps that they used to get from SharePoint sites just going to AppRegNew.aspx).

Disable ability for site owners register service principals in SharePoint via appregnew.aspx is done via Set-SPOTenant PowerShell cmdlet:

Set-SPOTenant -SiteOwnerManageLegacyServicePrincipalEnabled $false

When the value is set to false, the service principal can only be created or updated by the SharePoint tenant admin. Using AppInv.aspx page will also be disabled for site owners. Your users will start seeing “Your SharePoint tenant admin doesn’t allow site collection admins…” message (see details), but that’s ok.

There might be rare cases when your in-house solutions or 3-rd party apps got their secrets expired and would require new legacy ACS-based permissions, it is tempting to allow ACS permissions as an exception (as technically it is possible for SharePoint service admin to provide ACS-based access to sites), but I would strictly discourage you to do so. If you decide to provide ACS – track this activity (so you know for whom this ACS-based permissions were provided).

Pull report on existing ACS Apps that use ACS permissions

You need to know who are your vulnerable clients – you should pull reports to get a list of existing Apps that use ACS permissions, apps owners, maybe sites these apps have access to and sites owners

You can get list of developers combining
– audit log data from Admin Center and Graph API
– report from Entra Id on apps and owners
– report from SharePoint sites on permissions provided for apps
– reports generated by PnP Microsoft 365 assessment tool

Here is the detailed KBA on how to get reports on legacy ACS service principals usage in tenant

Consider the following steps to get ACS apps owners

  • get ACS apps with permissions using Microsoft 365 assessment tool
  • pull these apps owners from Entra Id
  • using Graph API audit logs data – mark apps active/inactive based on date of the latest login

Notify developers and users of the ACS apps

From the step above we can have a lost of legacy ACS apps and their owners, as well as apps activity (last login), so we can start communicating developers (app owners):

  • As earlier as possible – e.g. in March-April 2025 (1 year before ACS EOL), notify all apps owners that they need to transition to Azure apps and Selected permissions
  • Get ACS apps activity and repeat communication, including active app owners
  • Get ACS apps activity and repeat communication, including owners of sites apps still have access to
  • Communicate to all apps owners that there will be a temporary and permanent shut down of ACS (see below)
  • I case you have ACS apps with tenant-level permissions – communicate to them separately

    Switch ACS off earlier than Microsoft

    You need to plan actual ACS apps disablement in tenant in advance – earlier than Microsoft will do it (in case Microsoft will not put it off). Also consider temporary switch off ACS (“scream test”) even earlier, let say, starting September 2025.

    Temporary and permanent ACS disablements before official ACS EOL are needed as scream tests – in case there are users who ignored all communications and still use ACS apps. Disabling ACS early may cause problems with existing applications, but it is necessary to avoid more serious consequences when the time comes for Microsoft to turn it off. So be prepared to handle tickets and communicate to apps owners in advance.

    This might be your draft plan:

    • schedule the first and 2nd temporary (e.g. during 1 hour) ACS apps disablement ~ 6 and 5 months before EOL
    • schedule the 3rd and 4th temporary (e.g. during 24 hours) ACS apps disablement ~ 4 and 3 months before EOL
    • schedule the full (permanent) ACS apps disablement ~ 2 months before EOL

    References