Sample script: get report for SharePoint add-ins and azure acs retirement

[mkm17]

Create a sample script that provides a report detailing the retirement status of components within the current SharePoint Online tenant

---

Original issue

Usage

m365 spo report retirementstatus

Description

Retrieve a report detailing the retirement status of components within the current SharePoint Online tenant

Options

Option	Description
-s, --sharePointAddInsOnly [sharePointAddInsOnly]	To get information about SharePoint add-ins only
-e, --eventReceiversOnly [eventReceiversOnly]	To get information about Event Receivers only
-a, --azureACSOnly [azureACSOnly]	To get information about Azure Access Control Service only

Examples

Retrieve information regarding the retirement of Azure ACS, SharePoint add-ins, and Remote Event Receivers.

m365 spo report retirementstatus

Retrieve information specifically about the retirement status of Azure ACS only.

m365 spo report retirementstatus --azureACSOnly

Retrieve information specifically about the retirement status of SharePoint add-ins and Remote Event Receivers.

m365 spo report retirementstatus --sharePointAddInsOnly--eventReceiversOnly 

Default properties

• Type: (Azure ACS, SharePoint Add-in, Remote Event Receiver)
• Path: (Specify the location or details related to the feature)
• Suggestion: (Provide basic information on recommended replacements, e.g., for RER -> Webhooks)
• Retirement Date: (Include the date when the feature is scheduled for retirement)

Additional Info

Hi everyone,

I have a proposal that I believe could greatly benefit our tenant administration process. I'm thinking of creating a report that provides insights into the retirement status of various features, such as the SharePoint Online add-ins and more. This report aims to help administrators be better prepared for upcoming feature retirements, ensuring a smoother transition. Some details are available here.

While I'm not certain about the feasibility of gathering all the information needed, I'm eager to hear your thoughts and suggestions on this idea.

[milanholemans]

Hi, @mkm17, very nice suggestion! This could definitely be useful for a lot of people. However, I would like to know if we should make a sample script of it instead of a command. Commands should always be relevant. Over a few years when these things are marked as end-of-life, the command won't be used anymore. That's why I think it's better that we make it a sample script.

@pnp/cli-for-microsoft-365-maintainers any opinions?

[waldekmastykarz]

Great suggestion @mkm17 and agreed @milanholemans that it would be a better candidate for a script if we're considering the retirement angle.

Before we commit to it, we'd need to research if it's even possible.

[mkm17]

@milanholemans @waldekmastykarz Ok, you are right, the script would be better. However, just in case, I would also check if there is a way to obtain this information.

[waldekmastykarz]

Would you be willing to help us with the research @mkm17?

[mkm17]

@waldekmastykarz of course. I am not an expert in these solutions, but I will try to investigate to have a foundation for further discussion.

[waldekmastykarz]

We appreciate your help @mkm17. Don't hesitate to share your findings and ask for help if you're stuck at any time

[mkm17]

Hi @waldekmastykarz @milanholemans, After a quick investigation, it appears that obtaining all information is achievable using the current commands contained in the CLI.

• Remote Event Receivers For Remote Event Receivers, the script should analyze all sites, webs, and lists/libraries through the spo eventreceiver list. The results give also default Event Receivers, identifiable by properties such as e.g. "ReceiverAssembly" Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" or "ReceiverClass": "Microsoft.SharePoint.Webhooks". In this scenario, we can choose to exclude them by checking for the presence of the string "Microsoft." in ReceiverClass or ReceiverAssembly. Alternatively, all receivers can be included, accompanied by a note specifying that these are default receivers (I am not sure if we can create a custom receiver setting these properties).

• Azure ACS After creating an app using the page _layouts/15/appregnew.aspx I managed to locate it in the Azure Portal under the Enterprise Application section with the Application Type filter set to All Applications. We can retrieve these applications by executing m365 entra sp list and filtering items based on the servicePrincipalType being equal to Legacy

• SharePoint Add-Ins In this case, we can retrieve all libraries with BaseTemplate 330 which corresponds to the global AppCatalog type, and 336 represents a local AppCatalog on my tenant. For these libraries we obtain all files using m365 spo file list and search for items with the .app (to be confirmed if is correct) file extension in the Name or ServerRelativeUrl property (confirmation if this is enough needed). The .sppkg extension is associated with modern packages.
  
  We store the data for all solutions with the .app extension and then search for the same names/ids among installed solutions per site using spo app instance list

The script would proceed as follows:

• Get tenant app catalog - m365 spo tenant appcatalogurl get
• Get packages information from the tenant app catalog - m365 spo file list
• Get all sites - m365 spo site list
• For each site
• Get all webs -m365 spo web list
• For all webs including root
• Get all lists - m365 spo list list
• Check local app catalog information - m365 spo file list
• Check app instances - m365 spo app instance list
• Check event receivers - spo eventreceiver list for web and all lists
  
  
• Check Entra service principals - spo eventreceiver list

Do I have missed something? Unfortunately, I do not have any custom SharePoint Add-ins on my test tenant so I cannot confirm if all information included is correct.

[milanholemans]

Thorough research @mkm17! Really nice! It all makes sense to me. I think app add-ins end with .app indeed. We only have to question whether we assume that the user has access to all sites because that's what we need to read every site in the tenant. Should we include an option to add the user as site collection admin to each site?

About site collection app catalogs, we can easily list them using spo site appcatalog list as well.

[mkm17]

Hello @milanholemans, thanks for the tips. I had some free time, and I created an initial script in my branch. Before submitting a pull request, I have a few questions that need clarification:

1. Is the location for the script correct (sample-scripts/tenant/...)?
2. I tried to find examples of previous scripts, and I hope that the structure is correct.
3. I had the opportunity to discuss with @Adam-it, and I think that using the Entra app with certificate for login could be a good idea. (in the script a user can choose a preferable method)

I still need to test the script on different tenants, but I plan to do so next week. If everything goes smoothly, we should have the script ready by the end of the following week.

[Adam-it]

@mkm17 we have a guide how to properly add a script sample for our repo https://pnp.github.io/cli-microsoft365/contribute/script-sample/new-script-sample

you may go over the steps and the structure and double check if it answers your questions. Don't hesitate to reach me (us) out directly if you need any kind of help or have any kind of question 👍