Resolving API Permission Approval Issues in SharePoint Online

Recently, I encountered an issue that had me scratching my head. A developer needed to enable the Power Virtual Agents API permission, but it required approval in SharePoint Online. Here’s what happened and how I resolved it.

The Problem

When I navigated to API Access in SharePoint Online, selected the pending request, and clicked Approve, I received an error.

I had the correct permissions, and there were no outages reported, leaving me puzzled. After some troubleshooting on my own, I decided to open a support ticket with Microsoft. Interestingly, the support engineer was able to replicate the issue on their end, confirming it wasn’t just me.

Troubleshooting Steps

The support team walked me through a few checks. Here’s what we reviewed:

  1. Check the SharePoint Online Client Extensibility Web Application Principal Helper
    • Ensure the Client Extensibility Web Application Principal Helper is enabled for users.
    • In my case, it was already enabled, so this wasn’t the root cause.
  2. Update the Redirect URIs in Azure Portal
    This step turned out to be the fix.

Solution: Update Redirect URIs for the SharePoint Web App Principal

Here’s how to resolve the issue:

  1. Go to the Azure portal and navigate to Applications > App registrations.
  2. Select the All applications tab and search for SharePoint Web.
  3. Locate the Principal Helper app and open its overview page.
  4. Under Redirect URIs, you’ll see something like this:
    • 1 web, 0 spa, 0 public client
    • Click on this link to begin the migration process.
  5. On the next screen, you’ll see a link labeled:
    • “This app has implicit grant settings enabled. If you are using any of these URIs in SPA with MSAL.js 2.0, you should migrate URIs.”
    • Click this link to proceed.
  6. A side pane will appear with the URI details.
    • Check off the URI listed.
    • Click Configure to apply the change to the app principal.

Once the URI is updated, return to SharePoint Online and try approving the API request again. This should resolve the issue.

SharePoint UI Migration Bug

I am unsure if this is just a GCC High bug, but if you navigate to your SharePoint online admin portal and click on the migration link on the left side, you get an endless spinning icon.

My first thought was to check the dev tools to see if it was some how getting blocked, but all it showed was a status code of 200 doing a POST. Off to the AAD Sign-in Logs…

After filtering for my account, I saw a generic app is disabled message.

It didn’t dawn on me, but a co worker did see that the app was disabled in Enterprise Applications and under Microsoft applications. Thinking that was it, but nope, next error:

At this point, my gut was telling me something is wrong on Microsoft’s end. I popped a ticket and once they circled back to the SharePoint team, it is indeed a bug. So, how do you workaround this? Add /fileshare to the end of the URL.

After that, the Migration manager pulled up…

Logic Apps – GCC High SharePoint Connector – Maury Povich Edition

If you came across this post because you are trying to use the SharePoint connector with Logic Apps in GCC High…let’s continue below…

https://learn.microsoft.com/en-us/connectors/connector-reference/connector-reference-logicapps-connectors shows that SharePoint is supported in Azure gov, but that turned out to not be true.

After spending too much time trying to figure out how to make the SharePoint Connector log into GCC High, I popped a support ticket. Microsoft quickly told me that it indeed does not work in GCC High, but should be available this year (2023). I had to laugh because the support rep said it would be quicker to implement the fix into GCC High than update the documentation. LOL, I’ve been working with Azure for so long that statement is 100% true.

Workaround? Power Automate. That stinks because it requires a license, but it is what it is.