Category Archives: Software

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

    Using metadata to refine your SharePoint search

    Leave a reply

    Though search in Microsoft 365 SharePoint is good out-of-the box and you can do a full-text search and refine your results by “File type” and “Last modified”, but what if you want your content be tagged with your custom metadata (e.g. “Article category”), and you want to be able to refine your search results based on this metadata? I’d say it is possible and I’ll provide the solution below. The solution includes working with site term store (creating terms, term groups, term sets), configuring list/library columns and updating site search schema (mapping crawled properties to managed properties).

    See also:

    PowerShell Script for Files Deduplication

    1 Reply

    If you think you have a lot of duplicated files that consumes your hard drive storage space, this article is for you. Personally, I have a lot of video and pictures on my working hard drive and on a backup HDD. While working with photos and videos I can rename files, copy or move them from folders to folders. As a result, I end up with gigabytes and terabytes occupied with duplicated files. So I need a tool to a) find duplicated files and b) remove duplications. I tried to find good scripts but somehow I was not happy with what I found, so I wrote scripts myself.

    Surely you can buy/try a 3-rd party toot with GUI, but if you are comfortable with PowerShell – consider the following.

    …

    References

    Restricted SharePoint Search Deep Dive

    Leave a reply

    Restricted SharePoint Search is a new Microsoft feature to mitigate sites oversharing issue when you are implementing Copilot. The feature is documented here, but still I have some questions, e.g.:

    • How about external data? Copilot can use external data to learn from via agents and connectors. But would Restricted SharePoint Search if implemented allow data from external connectors to be used in copilot?
    • “Users’ OneDrive files, chats, emails, calendars they have access to” – means own data for every single user or all shared OD data?
    • What exactly is “Files from their frequently visited SharePoint sites”? I mean, how frequently user needs to visit site for this?
    • What exactly means “Files that the users viewed, edited, or created.”
    • What about teams chat messages, e-mails, viva engage messages?
    • “Files that were shared directly with the users” – does that mean “individual files shared” or can include folders, libraries, sites?
    • If user is a member of a teams – would all team content included?
    • It says “Files…” but would site pages be included? Or list items? Or list items attachments? Pages is something that people use to create wiki to share knowledge.
    • How long it takes for Microsoft 365 to start restricting results after Restricted SharePoint Search is enabled
    • How to deal with “You do not have the required license to perform this operation”

    Here I’m going to answer the questions above.

    So far I build a test scenario using my dev tenant that includes multiple collaborated users and content in the form of files, pages, list items and messages spreaded across multiple sites falling into different categories of Restricted SharePoint Search allowed content.

    You do not have the required license…

    If you are getting “You do not have the required license to perform this operation” when you are trying Get-SPOTenantRestrictedSearchMode or Get-PnPTenantRestrictedSearchMode – that means there is no Copilot for Microsoft 365 licenses assigned to tenant yet. This feature – Restricted SharePoint Search – works only when at least one Copilot license is assigned to tenant.

    … TBC

    References

    SharePoint Governance

    Leave a reply

    Governance in IT is establishing rules, policies, tools and practices that helps you manage and protect your enterprise resources. SharePoint governance (or wider – Collaboration governance) covers

    • resources ownership and lifecycle
    • users’ access to resources
    • compliance with your business standards
    • security of your data

    References

    Granular Application Permissions to SharePoint

    Leave a reply

    In 2021 Microsoft implemented “Sites.Selected” Graph API permissions to allow application access (without a signed in user) to specific sites (entire site only). In 2024 Microsoft implemented granular access – to specific list/libraries, as well as to specific documents/files and list items. Now name convention is *.SelectedOperations.Selected.
    Permissions come in two flavors – delegated and application:

    • Files.SelectedOperations.Selected – Allow the application to access a subset of files (files explicitly permissioned to the application). The specific files and the permissions granted will be configured in SharePoint Online or OneDrive.
    • ListItems.SelectedOperations.Selected – Allow the application to access a subset of lists. The specific lists and the permissions granted will be configured in SharePoint Online.
    • Lists.SelectedOperations.Selected – Allow the application to access a subset of lists. The specific lists and the permissions granted will be configured in SharePoint Online.


    Restricted SharePoint Search rationale

    Leave a reply

    Restricted SharePoint Search is a new (2024) Microsoft 365 feature that should help Copilot and general search results be more relevant, especially in large Microsoft 365 environments.

    The problem background

    When you have a really big number of sites – it is very difficult to keep them all in a well-managed state, e.g. to have reasonable (minimal) permissions provided to each site. So the typical situation (unfortunately) is: we have a lot of overshared sites. There are also a lot of ownerless sites where permissions are not managed. We know that search is security-trimmed, i.e. a user can get search results from content he/she already has access to. But with overshared sites – users get results they should not be able to see. With regular search experience – a user can see with his own eyes the source of the content he/she gets results from – so user can understand that results are coming from sites user should not have access to (overshared sites). But when it comes to AI-based search (Copilot) – user is getting answers, but he/she do not always know the source of that data.

    So the problem is – we want to ensure Copilot is trained on a proper set of data and results are curated to users needs and access permissions. So for Copilot we really need to exclude from search scope such sites we are not sure content is valid, accurate and properly secured. We do not want users to get garbage or exposed sensitive information as an authoritative answer from Copilot.

    The solution

    This is where Restricted SharePoint Search feature should help, as with this feature your can restrict organization-wide search (and Copilot) to a curated list of SharePoint sites – “allowed sites” – public sites that passed attestation and where permissions are checked and data governance policies are applied, and content user work with on daily basis – his/her own documents and content shared with user directly (check details on Microsoft’s How does Restricted SharePoint Search work) – e.g. content user is supposed to have access to normally.

    Excluded from search scope would be sites shared with user indirectly, e.g. something that was shared with everyone.

    The root cause

    Interesting, that with this feature Microsoft is not solving the real issue, but hiding (concealing) the real issue and just making Microsoft 365 to look more secure.

    The real problem (root cause) is over-sharing data. But Microsoft already sold us SharePoint (and then Microsoft 365). And now Microsoft is trying to sell us Copilot, so they “solved” the over-sharing issue with “let us limit search” solution instead of “let’s fix oversharing”.

    Note 1: Restricted SharePoint Search feature is free – i.e. it is included in standard Microsoft 365 license. Do not be confused with site access restriction policy – feature that require SharePoint Premium license and allows to restrict access to some SharePoint sites with specific groups only.

    Note 2: I know that Microsoft is trying to address over-sharing issue as part of their SharePoint Premium (SharePoint Advanced Management) package, e.g. with AI Insights and Data access governance insights – reports that can help prevent oversharing by detecting sites that contain potentially overshared or sensitive content. With Manage content lifecycle we’d decrease amount of “garbage” or outdated content.
    But SharePoint Advanced Management is licensed separately, when Restricted SharePoint Search is free.

    Note 3: I know that users are an even more real problem because they tend to simplify and share information irresponsibly.

    References

    New Microsoft Graph Connector service plan

    Leave a reply

    Microsoft Graph connectors allow your organization to index third-party data into Microsoft Graph. Microsoft Graph connectors enable Microsoft 365 Copilot better as it has more information relevant to your organization to answer prompts.

    According to Microsoft, Microsoft 365 will soon include a new service plan, Graph Connectors Search with Index, offering a 50 million item index limit per tenant at no cost. Rollout starts September 2024.

    Microsoft Search and Intelligence - Data Sources. You can build and customize connections managed by your organization. These can index data from apps such as Salesforce, Oracle SQL and Azure DevOps. Connections listed as Search under Connected experiences count toward your search connection quota utilization.

    Previously, to index third-party data into Microsoft Graph through Microsoft Graph connectors, you either needed to have a built-in entitlement through specific licenses (e.g., 500 items of index quota per Microsoft Copilot for Microsoft 365 license) or purchase add-on quota. With this change, the index quota per license entitlement is removed, as is add-on cost for additional quota. You now receive an entitlement of 50 million items for each tenant.

    Each entity (or record) from the source data system that you add to Microsoft Graph can be considered an item which then shows up as a unique citation in Copilot’s responses, as a unique search result in Microsoft Search, etc. Depending on the type of data source, 1 item is –

    • 1 document (word, excel, ppt, pdf, etc.) in file share
    • 1 wiki page in Confluence
    • 1 webpage in a website
    • 1 ticket/issue in Jira

    Total quota utilized is calculated in terms of total items stored in the index. Updates/changes to an item are not counted in any manner. There are no cost implications of updating an item multiple times. It still counts as 1 item only.

    Applicable to subscriptions: Office 365 E1, Office 365 E3, Office 365 E5, Microsoft 365 E3, Microsoft 365 E5, Microsoft 365 F1, Microsoft 365 F3, Office 365 F3, Microsoft 365 Business Basic, Microsoft 365 Business Standard, Microsoft 365 Business Premium, Office 365 G1, Office 365 G3, Office 365 G5, Microsoft 365 G3, Microsoft 365 G5, Office 365 A3, Office 365 A5, Microsoft 365 A3, Microsoft 365 A5